Facebook recently released its Libra white paper and has been under the spotlight of the global media. Libra’s White paper articulates that its mission is to build a worldwide financial infrastructure that is simple, easy to use, bringing blockchain concepts and providing the world’s most in-need populations with a smooth, borderless payment experience.
The consensus protocol it uses is LibraBFT, a new Byzantine fault-tolerant consensus agreement, which is based on another consensus agreement, HotStuff with some minor changes. For technical reasons, Libra is currently a permissioned blockchain, but Libra’s stated goal is to become permissionless; to that end, Facebook promises to make Libra a permissionless blockchain, similar to Ethereum, in five years.
The HotStuff consensus algorithm has become a renewed focus of attention due to its implementation in Libra. As HotStuff’s lead scientist, Dahlia Malki, only four major projects have adopted HotStuff so far, but more projects are expected to follow. Cypherium is one of HotStuff’s early adopters. As Cypherium’s Chief Executive, Sky Guo, and the first author of the HotStuff algorithm paper, Ted Yin, are good friends, the Cypherium team has been paying attention to the HotStuff since the algorithm’s V2 version ( https://arxiv.org/abs/1803.05069v2), and the Cypherium dev team began implementing the software as of V5 ( https://arxiv.org/abs/1803.05069v5 ). But vastly different in intention and design from Facebook, Cypherium’s goal has always been to deploy a permissionless, open HotStuff consensus, and with its mainnet it does just that.
The difference between “permissioned” and “permissionless” blockchains has to do with whether an entity can access a blockchain network as a verifier node. In a “permissioned blockchain”, the entity runs the verifier node through its permission grant mode, to ensure the network’s stability without requiring much consideration for security; in a “permissionless blockchain”, any entity meets the technical requirements can run a verifier node. For permissionless chains like Ethereum, any miner who finds a qualified nonce value can participate in the processing of the transactions and receive a certain fixed mining reward and transaction fee reward. This is conducive to the extensive development of the entire ecosystem, but the design of the entire chain must give more consideration to the overall network performance and security. Permissionless blockchains can easily become permissioned blockchains, but the reverse is much more difficult.
Cypherium has implemented HotStuff with a dual-chain consensus mode permissionless mechanism. HotStuff consensus prototype’s verifier identities are within a fixed range, and in addition to that, LibraBFT is also built on the PoS mechanism. LBFT adds a realistic mechanism when applying Hotstuff to the blockchain use case, such as introducing the concept of epochs, allowing consensus node replacement, and incentive and penalty mechanisms. In order to prevent the leader from being attacked, an unpredictable leader election mechanism (VRF), and the like, are introduced.
The Cypherium team initially considered using the PoS system in HotStuff implementations as well, but later their devs found that due to the strongly closed PoS mechanisms, it is not good for the ecosystem development, as this structure easily attracts hacker attacks, only suitable for permissioned chains and cannot properly achieve the ultimate goal of Cypherium’s permissionless public chain. So, the team began to develop its unique design to adopt the PoW+HotStuff hybrid consensus mechanism.
When Cypherium CEO Sky Guo was considering which consensus algorithm to use for the underlying public chain design, his friend, the first author of the HotStuff paper Maofan “Ted” Yin introduced him to the HotStuff protocol. After Sky conducted an in-depth study of HotStuff, he discussed HotStuff’s design and performance aspects together with Ted.
Finally, Sky Guo and the Cypherium dev team decided this would be the ideal replacement for the PBFT algorithm, as they found that HotStuff can achieve their goals through the Cypherium’s unique double-chain architecture, consisting of an election chain and a transaction chain. In this architecture, one chain does the electoral rotation operations of the PoW mechanism, while the other is a chain of transactions based on the current verifier nodes of the consensus committee.
Because Cypherium has chosen a PoW mechanism in its first step, any computing device can become a verifier node and does not depend on a trusted third party to mine Cypher coins.
Whenever a miner successfully mines PoW, at that time, the node with the most participation in the verifier committee leaves the committee, and the new miner becomes a member of the verifier committee. No one can predict the election results, as the network achieves a permanent dynamic rotation.
Each committee rotation is generated as shown below, to form a Key chain:
the dynamic adjustment of the computational difficulty value makes the time for the PoW to obtain the verification value unpredictable, we define the Key chain as a slow chain (a block being generated in an average of a few minutes), and only the consensus committee or the leader replacement event gets recorded.
After the Key block is confirmed, the consensus verification node belonging to the Key block participates in the consensus processing of the transaction package under the Leader, and forms the V1, V2 , V3 , V4 , V5 views as shown in the following figure :
These views are connected to form another chain, which we define as a transaction chain. Since the PoW calculation is no longer needed at this step, the confirmation of each view only needs to be verified by the consensus signature of the consensus committee, so the block production rate is very fast, processing up to 6,000 transactions per second.
It is worth noting that the Key chain and the transaction chain mentioned above are actually a single, continuous chain in the HotStuff algorithm, as shown below:
When the normal node mines a PoW, it broadcasts to all the current verifier nodes, and the Leader of V2 initiates View Change, and will send a Cmd type=key corresponds to the Cmd part in Figure 2, indicates that a View Change for the verifier nodes has been requested. When the DECIDE step in Figure 2 is finished, a new View is generated. The View needs to record the identity information of all the verifier nodes of the current consensus committee (such as public key, IP, etc.), in order to save storage space and easy to search, the information is saved as a separate Key blockchain, also recorded on the transaction chain, the transaction chain has Cmd type=tx to differentiate from the Key blockchain.
The verifiers receive transactions from the client and shares these transactions with each other through a shared txpool protocol. In each round of transaction grouping, there is a verifier playing a leading role (Leader) and proposes to extend a transaction block to a sequence of blocks that contains complete previous transaction history.
The verifier receives the proposed block and checks its voting rules to determine if it should vote for the block. If the verifier intends to vote for this block, it will execute the transactions of that block without external influence. Then the verifier sends a vote on this block and its state to the Leader. After the Leader collects the voting result from all verifiers, it generates a quorum certificate (quorum certificate (QC)).
The QC is the proof of 2f +1 vote obtained for this block, and the QC with block data is broadcast to all verifier. When a continuous Three-chain commit rule is satisfied, the block is committed. If there is a QC at k-th round, and k + 1 and k + 2 rounds have two blocks and QCs confirmed, the block is committed.
The commit rules ultimately allow an honest verifier to commit a block. The Cypherium chain ensures that all honest verifiers will eventually commit the block. Once a block sequence has been committed, the state generated by the transaction execution can continue and forms a replicated database.
Each verifier node has a built-in PaceMaker to record the time difference between each step ( prepare, pre-commit, commit, and decide). If timeout occurs, the view change request is immediately sent to the new Leader. If the new Leader does not respond, then it is sent to the next Leader.
The traditional view change PBFT has O (n ^ 2) complexity of messaging. That is, before the view change happens, all honest verifier nodes shall confirm that all honest nodes indeed proceed to the next View.
HotStuff very innovatively turned the classic two-round consensus of PBFT into three rounds, and then reduce the cost of view change to O(n), view change does not need to wait for the “I know other people also know about the view change” layer. It is possible to change itself, so the message complexity is reduced from. O (n ^ 2) to O(n): as long as the honest node sends a view change request directly to the new leader and receives the new leader’s feedback, the view change will start.
After the view change is completed, the Cyperium chain will record the results of the corresponding QC and change, form a new Key block, and continue the process as described above under the new consensus committee.