Introduction
Now that you have chosen Hyperledger Besu to create your private blockchain network, you will have to decide on the consensus mechanism you use in your network - the coordinating process that the network uses to confirm, sync, and finalize new blocks on your blockchain. In this article and the subsequent tutorials, we are going to explore the two Proof of Authority (PoA) consensus mechanisms that you can use with Hyperledger Besu: Clique and IBFT 2.0.
In a private network, we want to avoid using the consensus mechanism that is used on Ethereum mainnet - Ethash Proof of Work (PoW). Why? Ethash works well for Ethereum mainnet because anyone can participate in Ethereum mainnet by running a node and providing computation power to the network. Therefore, this computationally intense consensus mechanism ensures that any participant must compete with the other participants to confirm and sync blocks (which we call mining). The incentive of block rewards serves to ensure they are following the rules of the network. The more computing power that each node brings to the network, the greater benefits to the security of the network when PoW is the consensus mechanism.
We are going to assume that you are not using the Ethash Proof of Work (PoW) consensus mechanism that is used for Ethereum mainnet because your network has participants that are:
Known to each other, and
Have a certain degree of inherent trust in each other.
These two assumptions allow for your network to use a consensus mechanism which is more computationally efficient for the participants - they do not have to have the same computing power required of a node on Ethereum mainnet. These assumptions also allow for the removal of the incentive of block rewards to ensure compliance. Using a PoA consensus mechanism gives your network:
Faster block creation as compared to a network running Ethash: Your network can create new blocks in a one or two seconds. As a comparison, Ethash on mainnet averages about 15 seconds for creation of a new block.
Greater transaction throughput for the network: Without the need to incentivize the participants, the size of each block can be arbitrarily large, allowing for blocks with many transactions included as your network needs them to be included. Large transactions will not significantly or noticeably slow down the network (smaller blocks will be processed faster than larger blocks, the end user should not notice a difference).
PoA assumes that the creators of the blocks - which are sometimes called minters, signers, sealers, or validators (we will refer to nodes on a PoA network as validators from here on) - are authorized to be validators. At the creation of the PoA network we declare a group (or “pool”) of validators, and as the network runs, those starting validators can add and/or subtract other validators.
A short explanation of PoA
To understand PoA, it helps to specifically discuss the consensus mechanism Clique PoA, as it was designed to approximate Ethereum mainnet for use in Ethereum testnets. The Ropsten testnet used PoW, but was plagued by attackers forcing reorgs and forks in the testnet and increasing the block gas limit and sending large transactions, which effectively stopped the network. A new consensus mechanism was designed by Péter Szilágyi called Clique, which could replace PoW on networks like testnets. Clique PoA was designed to use the existing Ethereum block data structure to add voting functionality. Generally in any PoA consensus mechanism, validators alternate adding blocks to the blockchain in a series. In addition to adding blocks, they can choose to vote to add or kick out a validator. This allows malicious validators to be removed from the network, and trusted validators to be added. This gives PoA resistance against certain kinds of attack vectors like:
A malicious validator - if a machine is compromised, and a validator proposes incorrect blocks, they can be voted out by the other validators
A censoring validator - if a compromised validator proposes votes to remove good actors, they can be removed by being voted out
A spamming validator - if a validator makes a voting proposal in every block that the validator creates, the network is spammed by having to consistently tally the votes (votes being to add or remove a validator). By resetting voting after a set period of time (this period of time is referred to as an epoch and is set to be 30,000 blocks in our tutorials), this problem can be mitigated.
Concurrent block creation by a validator can also be prevented by ensuring there is a substantial enough lag between each block being added to the blockchain.
In short, many of the features of mainnet Ethereum can be approximated, but without needing to use PoW and the challenges that using PoW on a private or test blockchain would entail.
Clique PoA Compared to IBFT 2.0 PoA
Now that we know a bit more about PoA, we’ll compare Clique PoA with IBFT 2.0 PoA in regards to:
Finality - the amount of time required to guarantee a block has been added to the blockchain.
Validators required - the minimum amount of validator nodes that have to participate in the network in order for the PoA consensus mechanism to work as intended.
Liveness - the number of validator nodes that must be online or “live” to allow the network to continue running. This can also be thought of as a kind of fault tolerance - the number of validators that can fail at a given point in time and the network will still run.
Relative Speed of Block Creation - how long it takes for each PoA consensus mechanism to create and sync new blocks and the factors that impact the speed of block creation.
Property | Clique | IBFT 2.0 |
Finality | Forks / Reorgs possible | Immediate Finality |
Validators Required | 1 | 4 |
Liveness | ½ validators live | >= ⅔ validators live |
Relative Speed | Faster than IBFT 2.0 | Slower than Clique |
Finality
Instantaneous finality is possible when only one block can be added at a point in time to the blockchain. If there is a possibility that multiple blocks are proposed at the same time, then a fork or reorganization can occur, and the validators are forced to make a choice about which block is a part of the final chain.
In Clique PoA, a block will not be guaranteed to be added to the chain upon creation because there is a possibility of two blocks being proposed at the same time if a validator proposes a block out of turn. Blocks proposed simultaneously cause a fork in the network, as there are now two possible blocks for the next validator to create a block subsequent to (the second signer is prevented from signing subsequent blocks by the consensus mechanism). Because there are now two possible chains that could be built, the network must reorganize (or reorg), choosing which chain to build on. Due to this possibility, finality can be delayed when using Clique PoA if validators create blocks out of turn, and a block is not definitively confirmed upon creation.
IBFT 2.0 has immediate finality, provided there are four validators. Once a block is created it becomes part of the blockchain. There are no forks.
Validators Required
Clique can run with a single validator (the use case for a single validator is purely demonstration purposes). As the number of validators in a Clique network increases, the probability of forks in the network increases.
IBFT 2.0 requires four validators to be byzantine fault tolerant. Three or less validators running on an IBFT 2.0 network will no longer guarantee immediate finality or prevent network manipulation, particularly if one or more of the validators is acting in an adversarial nature.
Liveness
Clique can operate with half of the validators running (half of the validators can go down and the network will still work).
IBFT 2.0 can operate as long as at least ⅔ of the validators are working. As noted in the validators required section, three or less validators running on an IBFT 2.0 network will no longer guarantee immediate finality, particularly if one or more of the validators is acting in an adversarial nature.
Speed
Clique is faster than IBFT 2.0 at adding blocks.
IBFT 2.0 is slower at adding blocks. As more validators are added the time to add new blocks increases.
Specific Examples
Guitar Manufacturing
A custom guitar manufacturer wants to create transparency for their customers to show the woods they are using in building custom guitars. They source woods locally and use reclaimed woods from the city they are based in. They want to write a transaction to a blockchain so that a customer can scan a QR code and see each transaction associated with the various woods used in the guitars. They work directly with two wood suppliers, and with an additional individual who helps them with salvage work to get reclaimed wood from old buildings. Looking at this case, we see the following:
There is anywhere from a single to maybe four participants to start (the two wood suppliers and the reclaimed wood supplier)
This is a project to provide transparency to the end-user, so transactions can be sent as needed, with addresses being created to represent specific guitars that are being built.
The transactions will represent different woods and provide information on their sourcing
If a single node were run, if it were to go offline, it would only impact the guitar builder.
Because immediate finality is not required, there is the potential of only needing a single validator at the start, it would be possible to use a Clique PoA network. If the suppliers wanted to join the network, they could all do so, and if one of them left the network, there would not be an impact to running the blockchain.
Casinos
A group of six casinos decide to create a sportsbook together, in order to share in winnings and decrease the individual exposure of each casino. Each casino will run a validator node and transactions will be the bets that bettors place on basketball games. As the games being bet on have a specific start time, bets must be included in the blockchain to receive a payout. If bets are not included, the payout is not able to be made to the bettor. Looking at this use case, we see the following:
There are at least six participants at start, and therefore we assume there will be six validators
The bets that are made have to be included in a block. Immediate finality is required
If a certain number of casinos go offline, we may have to question whether to take bets or not, since the other casinos become more exposed to the betting positions.
There should be a high volume of transactions allowed, as the scenario of the number of placed bets is likely to increase the closer a basketball game approaches the start time.
Because immediate finality is required, we are drawn to using an IBFT 2.0 PoA network. If we were to do this, then we would need at least 4 validators. Since there are six casinos participating, we can use an IBFT 2.0 PoA network. If more than two casinos were to leave then the network would no longer be able to run. In terms of liveness, the network can withstand a validator going offline (due to a power outage or other reason), and continue to operate, which is very important for the overall success of the sports book.
Determining the PoA Consensus Mechanism to Use in Your Network
Based on these examples, here are questions to ask yourself, which can help you determine which PoA consensus mechanism may make more sense.
What are my finality requirements?
Does my use case require that each block created instantly be confirmed?
If a block is not instantly confirmed, what are the potential impacts?
How many validators do I intend my network to have?
How many will I have at the start?
How many could be added to the network over time?
Do I think validators could leave my network?
Would I stop running the network if a certain number of validators left?
Do I need participants to join the network without being validators? Should they be able to submit transactions?
What fault tolerance does my network require?
Does the number of validators that will participate at start allow for the network to continue running if one goes down?
What happens if two or more validators go down?
How fast do I need to be able to create new blocks?
Will the speed at which I need to create new blocks stay constant or can it slow down if new validators are added?
These questions can serve as a guide in thinking which PoA consensus mechanism makes sense for your use case.
In our next article, we will walk through creating a Clique PoA and IBFT 2.0 networking, using these preconditions.