Ethereum Clique PoA vs PoW
Why was PoA needed vs PoW?
PoW (Proof of Work) is fine when the network has value, as it is worth the expensive computing needed to protect the network against a 51% attack. While PoW does not work well when the network does not have value, like an Ethereum test network for instance.
No value networks
The Ropsten test network used PoW and was brought down in February of 2017 by people taking advantage of the network’s low PoW by increasing the block gas limit by almost 2000% while sending huge transactions through the network. Ropsten has since disallowed super high gas limits, but the issue with low PoW remains for the next exploit. This PoW vulnerability led to the next test network known as Rinkeby that uses a PoA (Proof of Authority) called Clique where authorized signers mint the blocks.
Clique PoA needed backward compatibility
The architects of Clique had to figure out a way to implement PoA while doing as little to the core data structure as possible to preserve existing Ethereum client compatibility. The two new things needed for Clique involved block verification during synchronization and a voting protocol.
Clique needed a way for users to verify blocks against a list of trusted signers while synchronizing. The problem is that Parity does not have access to the state during warp sync, nor does Geth when using fast or light syncmodes, thus ruling out using smart contracts to store the blocks’ trusted signers.
Clique also needed to wedge in a voting protocol designed to add or remove trusted signers, without adding any extra fields.
Clever repurposing of unnecessary fields
This is where the clever part comes in, they just extended the extraData field in the header from 32 bytes to 65 bytes so they could put the secp256k1 miner signature in that field. The extraData field is used for used for fun messages in the in the PoW version and adding an extra 33 bytes would likely not be big deal for the existing clients. On a side note, I did have to customize my version of Web3 Python to ignore the extra bytes, as it was causing an error in earlier versions when using Rinkeby.
Adding the miner signature in the extraData field make the miner section in block headers unnecessary, so they used that for authorized signers to propose a new or current signer to be voted on by all the current authorized signers.
Additionally, the nonce field is not used in PoA either, so in Clique it is used as the voting field. A nonce from an authorized signer with 0xffffffffffffffff means add the proposed signer, while a nonce with 0x0000000000000000 means to kick the proposed signer out. The nonce and miner fields are set to zero during normal blocks when voting is not taking place. The Clique voting protocol allows clients to tally up the votes for each proposed signer (while syncing) to determine the current valid authorized signers, thus validating each block header against a dynamic list of authorized signers. EPOCH_LENGTH is used as the number of blocks allowed before setting a checkpoint and resetting the pending votes. Checkpoints are also used to publish the list of authorized signers in the extraData field. This way a client could start at a checkpoint, instead of tallying up all the votes on proposed signers since the genesis block.
How secure is Clique PoA?
Clique requires N/2 +1 signers to be honest signers, thus a simple majority is all that is needed to run a secure network. A Byzantine (dishonest) signer cannot do much damage before it is kicked out as each signer can only sign once every N/2 + 1 blocks. Once a signer is thought to be Byzantine, the other signers can vote to kick the node out. An interesting twist is if the Byzantine signer tried to censor blocks that voted against it after it was discovered to be Byzantine. This type of censorship attacked is countered by restricting the signing frequency of nodes to 1 out of N/2, which means 51% of network would have be Byzantine for that to work.
Conclusion
Clique PoA has been cleverly integrated into Ethereum with minimal architectural disruption. Clique appears to have the same security as PBFT (Practical Byzantine Fault Tolerance) while offering superior scalability as Clique PoA has only one round of messages between the signers, where PBFT has three. I expect to see more enterprise companies implementing PoA and Clique in particular, where the users are partially or not trusted at all. Completely trusted systems are better off using Raft, like Quorum does to get 20 blocks minted per second. See my previous article about Raft and Quorum for more information.
How’d you like this article? If you liked it or learned something, please leave a clap! DarkBlock.io is an enterprise blockchain development company and we’re always taking on new clients. Reach out to me at sheffield@darkblock.io or visit our website at DarkBlock.io!
