DISCLAIMER: As of September 2019, Pantheon has been renamed to Hyperledger Besu. In posts prior to September 2019, we refer to the Ethereum client as Pantheon.
PegaSys is launching its Pantheon 1.0 release in late February. This blog is part 1 of our 1.0 Release series highlighting our IBFT 2.0 feature. In part 2 we will write about our new permissioning feature.
Consortium blockchains are different to the public Ethereum mainnet in that they consist of a smaller number of nodes that are known to each other. Enterprise nodes exist in controlled IT environments. Contrast this with the public Ethereum mainnet consisting of 1000s of nodes with no level of trust between each other. The 'trustless' nature of the Ethereum mainnet is addressed by using the well-known Proof of Work (PoW) Ethash consensus algorithm to make attacks prohibitively expensive.
Nodes use a consensus algorithm to agree on which blocks are added to the blockchain and, in the case of forks, which chain to follow. In this blog post, we use the term security to refer to the ability of consensus algorithms to withstand bad actors and function as intended.
With consensus algorithms, there's a tradeoff between transaction security and performance. Performance in blockchains is generally measured in transaction throughput. At one end, the Ethereum mainnet using PoW offers great security but low performance. At the other end, consortium blockchain solutions using earlier PoA algorithms offer high performance with little or no security.
Enhanced Proof of Authority (PoA) consensus algorithms such as IBFT 2.0 lie between these two extremes, providing a balance of increased performance while still providing protection against bad actors. Invoking Goldilocks: too slow, too insecure, just right.
A Quick Look at PoA History
Quorum, the first Enterprise Ethereum client, has implemented three consensus algorithms in an attempt to provide an acceptable solution to consensus for enterprise blockchains. The algorithms are RAFT (see also Quorum RAFT), Clique,and IBFT 1.0. Each consensus algorithm was intended to address different use case requirements.
Key Driver of IBFT
The key driver of IBFT is to guarantee immediate finality. Finality means that once a transaction is included in a block added to the blockchain, it is guaranteed to always be part of the blockchain. That is, there are no forks or chain reorganizations. If bad actors can fork a blockchain, it is no longer secure.
Areas for Improvement in IBFT 1.0
Two types of properties any blockchain consensus algorithm should ensure are safety and liveness. Safety means that nothing bad will ever happen. When applied to a consensus algorithm such as IBFT with immediate finality this means that no two valid but different blocks for the same height can be produced. Finality is a type of safety property.
Liveness means that something good will eventually happen. When applied to any consensus algorithm, IBFT included, this means that any transaction submitted to the network is eventually added to the blockchain of all participating nodes.
The IBFT 1.0 implementation has known areas for improvement with safety and liveness. Roberto Saltini, one of our researchers at PegaSys, recently proved theoretical flaws in IBFT 1.0 after problems were encountered implementing IBFT 1.0 in Pantheon. Discussions with our colleagues at Clearmatics determined that they too had encountered similar issues while implementing IBFT 1.0.On the safety side, one example is that in IBFT 1.0, if the proposer is Byzantine then under certain circumstances the Byzantine proposer can have different blocks committed at the same height of the blockchain by reaching consensus with two sets of validators. For example, if the network has 5 validators, IBFT 1.0 requires agreement of only 3 nodes for the next block to be added to the blockchain. As shown below, a Byzantine proposer can reach consensus on different blocks with two distinct sets of validators.
Byzantine Node Reaching Consensus with Two Sets of Validators on IBFT 1.0
On the liveness side, as proved in the analysis, in the presence of just one Byzantine node an IBFT 1.0 network can reach a state where nodes are locked on different blocks and no agreement can be reached on any of these blocks which means that no further blocks can be added to the chain.
IBFT 2.0
PegaSys has implemented IBFT 2.0 in Pantheon to produce a more stable and reliable Enterprise Ethereum client. Roberto Saltini's paper describes modifications to IBFT 1.0 to address IBFT 1.0 flaws.
Validators in IBFT 2.0 function as illustrated.
The super-majority modification changes the number of nodes required to reach quorum. This change addresses the issue of Byzantine nodes being able to reach consensus with two distinct sets of validators by requiring a super-majority. For example, with 5 validators, IBFT 2.0 requires 4 validators, rather than 3, to reach agreement on a block for the block to be added to the blockchain. With this change, a Byzantine validator cannot get two sets of honest validators to reach agreement on different blocks.
The round change modification addresses the liveness issues in IBFT 1.0. In IBFT 1.0, a round change always results in new block proposals. In IBFT 2.0, an enhanced round change protocol ensures that if any validator commits in a round, then the block proposed in any successive round matches the committed block. This mechanism, inspired by the PBFT view change protocol, removes the need for the block locking mechanism used in IBFT 1.0 which caused liveness issues.
The Future
PegaSys intends to work with the Quorum team, Clearmatics and others at the Enterprise Ethereum Alliance to standardize a consensus algorithm appropriate for enterprise use. The standardization process will involve discussions with other implementers and will continue working towards an improved algorithm.
The future is bright: blockchain research in general, and research into consensus algorithms in particular, is proceeding at a rapid pace. PegaSys will continue to provide leadership in Enterprise Ethereum by developing and maintaining a stable and reliable client.
Want to know more about IBFT 2.0 or Pantheon? Contact us at [email protected].
Thanks to David Wood for his extensive contribution to this post
Want the latest PegaSys updates straight to your inbox? Join our mailing list.
PegaSys is a thought leader in the Enterprise Ethereum space. Want to join the team? Check out our list of open roles.
.