Skip to main content

Validator Node

Arcana runs 7 validator nodes to verify transactions and propose a new block using a PoS (Proof of Stake) mechanism. Validators are chosen from a pool to propose a new block in proportion to the amount of tokens that they have staked. More specifically, Arcana implements the IBFT (Istanbul Byzantine Fault Tolerant) protocol in order to select honest validators and reach consensus. Malicious validators lose their staked tokens which disincentivizes bad actors from attacking the network.

Broadly, each validator node transitions from state to state once a quorum of validators have reached the same result about the validity of a block. Once a 66% majority confirms that the block is indeed valid, it is locked-in to be added to the main chain. IBFT prevents forking of chains and therefore blocks are rarely invalidated at a later time.

The Arcana blockchain itself is a self sovereign chain which stores the following publicly verifiable information -

  • Usage
  • DID documents
  • Access Control Lists

Usage pertains to the user level limits for both storage and bandwidth for a dApp user. The DID is a decentralised ID which is a unique identifier for every file that is uploaded to Arcana. Access Control Lists show the list of public keys that the owner has given access to. The structure of the DID is a JSON in the following format (this is the DID for Arcana's technical paper) -

{
"@context": "https://www.w3.org/ns/did/v1",
"id": "did:arcana:123456789abcdefghi",
//public keys that own the subject of the DID
"publicKeys": [{
...
}],
//controllers, if any, to whom control has been delegated by owner(s)
"controller": ...,
//the mechanism to authenticate public keys owning/controlling the DID
"authentication": [{
...
}],
//ways to interact with the DID and the subject.
//typically end-points to request access, download...
"service": [{
...
}],
//list of public keys that owner/controller have given access to
"acl": [{
...
}]
}