Proof of Authority Consensus

In the article Hyperledger Besu Private Network using Docker, we demonstrated running a private Ethereum blockchain network using the Clique consensus algorithm.

So what is Clique and how does the consensus protocol work ???

Clique is a type of consensus protocol referred to as the Proof of Authority (or PoA for short). In a PoA consensus algorithm, a set of trusted nodes known as Authorities, each identified by their unique identifier, are responsible for mining and validating the blocks in the blockchain. Each block is produced by an authority at a fixed interval. The responsibility of creating the next block is shared amongst the set of authorities and is done in a round-robin fashion.

In the Clique consensus protocol, the set of trusted authorities are referred to as the Signers. The process of mining a block is referred to as Sealing a block. If the next block is identified by BLOCK_NUMBER and the number of signers is identified by SIGNER_COUNT, and the signers are lexicographically sorted by their unique identifiers in a list, then the next block is sealed by the signer located at the index BLOCK_NUMBER % SIGNER_COUNT, where % is the modulus operator.

Using our earlier example of 3 signers [A, B, C] in a sorted list, signer at index 1 (B) would seal block #1 (1 % 3 = 1), signer at index 2 (C) would seal block #2 (2 % 3 = 2), signer at index 0 (A) would seal block #3 (3 % 3 = 0), and so on.

In the Clique consensus protocol, the signers collect and execute the transactions from the network into a block and update the world state. At the fixed interval referred to as the BLOCK_PERIOD, the next signer in the list (identified by BLOCK_NUMBER % SIGNER_COUNT) calculates the hash of the block and then signs the block using its private key (sealing the block). It then broadcasts the sealed block to all nodes in the network.

For Ethereum to leverage Clique without breaking compatibility with its existing clients, the field extraData from the Ethereum block header is used for signing. The first 32 bytes of the extraData field (referred to as EXTRA_VANITY) is reserved for any vanity data for the signer. The last 65 bytes of the extraData field (referred to as EXTRA_SEAL) is where the signature of the signer goes.

Also, the field difficulty is set to a value of 2 if the block is sealed by the in-order signer (referred to as DIFF_INTURN). Else, is set to a value of 1 if the block is sealed by an out-of-order signer (referred to as DIFF_NOTURN).

Hmm - why and when will we need an out-of-order signer ???

What happens if the in-order signer is down for some reason ??? Given that a sealed block is to be generated every BLOCK_PERIOD, if the next in-turn signer is down, a block is missed after the fixed period and the remaining out-of-order signers will wait for a random (SIGNER_COUNT * 500) ms delay and the first out-of-order signer (after the delay) will seal the next block.

Note that a block sealed with a value of DIFF_INTURN has a higher priority than a block sealed with a difficulty value of DIFF_NOTURN.

In order to prevent a malicious signer from sealing fraudulent transactions, any signer is only allowed to seal a block every FLOOR(SIGNER_COUNT / 2) + 1 blocks. This implies, at any point in time, there are only SIGNER_COUNT - [FLOOR(SIGNER_COUNT / 2) + 1] signers who are allowed to seal a block.

In Ethereum blockchain, for the Clique voting process, the fields miner (coinbase) and nonce from the Ethereum block header are used. The field miner will contain the unique identifier (wallet address) of the new signer to be added or the unique identifier (wallet address) of the existing signer to be dropped. The field nonce will contain a value of 0xffffffffffffffff (referred to as NONCE_AUTH) when a new signer is to be added or a value of 0x0000000000000000 (referred to as NONCE_DROP) when an existing signer is to be dropped.

The existing signers cast a vote to either add or drop another signer when they seal a block. Votes are counted for majority as the sealed blocks are processed and added to the chain. Once a majority consensus is reached, the action to add or drop is finalized and takes effect immediately.

Once every N number of blocks (referred to as EPOCH_LENGTH with a default value of 30000), a special block called the epoch block is broadcast on the block network to tally any unprocessed votes and for synchronizing all the nodes with the final list of signers (after any votes processing).