SafeStake, a trust minimized middle-layer fostering the decentralization of ETH 2.0 Staking, uses the underlying consensus protocol HotStuff — a more robust variant of the Byzantine Failed Tolerance (BFT) protocol that helps improve security and minimize the validators’ slashing odds during ETH 2.0 Staking.
But what is the HotStuff protocol? Is it the same protocol that Facebook considered to achieve consensus with its LIBRA coin?
In this post, we want to delve deeper into the HotStuff consensus mechanism, so that ParaState users who use our SafeStake product during ETH 2.0 Staking can learn more about the mechanism helping them to improve their passive income, and why it is part of our efforts at ParaState to bring the best of blockchain technology to our ecosystem.
Byzantine Fault Tolerance (BFT): The Origin of HotStuff
Byzantine Fault Tolerance (BFT) consensus mechanisms are implemented on blockchains as an alternative to Proof-of-Work (PoW) mechanisms, with the intention of achieving the same security that PoW offers without the need of the high energy consumption of the PoW protocol.
Its general operation solves one of the great blockchain problems: the well-known problem of the Byzantine generals. If you want to know more about this topic, you can consult the
In essence, an unfair actor in a decentralized network is considered 'Byzantine.' One of the great achievements of Satoshi Nakamoto is to develop a consensus protocol, i.e., the PoW mechanism, to solve the Byzantine general problem.
In the blockchain application, the solution to the Byzantine Generals problem is achieved by loyal commanders adhering to a pre-established pattern of behavior, known as consensus algorithms.
A typical BFT algorithm solves this problem as follows:
- Each loyal lieutenant counts all the messages he has received from his companions. Some will say to attack, while others would wait.
- Not knowing which ones are loyal or not, he chooses the message to attack (what action to take) based on the one that has received the highest number of votes.
- If all loyal lieutenants behave this way, there is a mathematical guarantee that they will make the right decision as long as less than ⅓ of the members are Byzantines.
BFT essentially uses the simple formula “3f+1=x” to determine the ratio the system can tolerate of loyal/disloyal actors that make up the network.
Thus, if f is equal to 1, at least 4 minimum nodes (lieutenants) are needed for the BFT consensus mechanism to work.
When this protocol was originally conceived, the typical system size was n=4 or n=7, deployed on a local area network. However, the renewed interest in its use in blockchain networks calls for solutions that can scale to much larger ns.
Since the introduction of Practical Byzantine Fault Tolerance (PBFT), the first practical solution to replicate BFT in the partial synchrony model, many derivations have been built around BFT based on its two phases, with the practical objective that a stable leader can promote a consensus decision in just two rounds of messaging:
- A first phase that guarantees the uniqueness of the proposal through the formation of a quorum certificate (QC) made up of (n-f) votes.
- A second phase ensures that the next leader can convince the replicas to vote for a safe proposal.
In this system, as we have pointed out before, the algorithm for a new leader to collect information and propose it to the replicas — called view change * — is the epicenter of replication.
But the paradigm-based view switch of the previous two phases is far from straightforward, error-prone, and incurs a significant communication penalty even for moderately sized systems.
Even with only authenticators (digital signatures or message authentication codes), the transmission of a new proposal has a quadratic communication footprint [O(n^2)] in PBFT resulting in a scaling challenge in all PBFT-based derivations.
Although there are several variations of PBFT implemented by various blockchain platforms, in this post we want to highlight the key characteristics of qBFT and iBFT, considered to be among the most robust within the family of BFT protocols and which has served as the point of reference for SafeStake in choosing HotStuff as its consensus mechanism.
- Immediate purpose: Only 1 block is proposed at a given chain height.
- Dynamic validator set
- Optimal Byzantine Resilience when operating in a partially synchronous network
- Message Complexity of O(n^2)
- QBFT is based on the BFT agreement protocol presented in IBFT-Moniz.
- These networks require ⅔ of the validators to be operational to create blocks and networks with these protocols, in which 3 or less validators can produce blocks but do not guarantee finality when operating in harsh environments.
- While they generate excellent returns compared to PoW, the time to add new blocks increases as the number of validators increases.
- The key difference between qBFT and iBFT is that the validators take turns creating the next block within a non-randomized dynamic validator set.
- iBFT removes chain forking and hence supports transaction finality.
- Both protocols are more convenient to use in private or consortium blockchain networks.
- In the case of iBFT, the algorithm is deterministic, leader-based, and optimally resilient, tolerating f faulty processes out of n where n≥3f+1.
HotStuff: The First Partially Synchronous BFT Replication Protocol
Asynchronous Byzantine Fault Tolerance has become one of the most popular ways to achieve consensus in the distributed ledger technology space. However, some critics argue that they are slow and expensive protocols to run, as well as being self-restricted given the existence of an upper limit on network delay.
1.- HotStuff removes some complexities from the asynchronous BFT protocols to make it more scalable, introducing a simple function of the number of nodes in the network instead of a function of the number of nodes squared.
In addition, the simplicity of its code allows it to easily adapt to the demands of modern solutions to be deployed on the blockchain, solving the problem of state machine replication (SMR) in a few lines of code.
2.- HotStuff introduces a radical change in the PBFT mesh communication network by using a star communication network, shifting the communication burden to the leader which improves protocol response times.
3.- The protocol merges the view change process* with the normal process, reducing its complexity.
4.- The protocol for a new leader begins with the collection of new view messages from the replicas. The process for starting a new view after receiving a prepared message involves three phases in HotStuff instead of the two originally provided in PBFT: precommit phase, commit phase, and decide phase.
5.- Within the technological component of HotStuff are the threshold signatures to reduce the number of signatures in the consensus protocol.
6.- The last change applied to the PBFT by HotStuff refers to the pipeline of the consensus phases. Since all the phases have an identical structure, pipelining HotStuff can be achieved.
You can see that the three confirmation phases of Basic HotStuff have the same structure: other nodes vote on a message, and the leader combines the votes and broadcasts them to other nodes. These phases can be represented in a uniform and segmented way.
HotStuff has the advantage of being remarkably simple, due in part to its economy of mechanics: There are only two types of messages and simple rules to determine how each replica is treated. Security is specified through the voting and confirmation rules on the node graphs.
SafeStake Leverages HotStuff to Improve Ethereum 2.0 Decentralization
With the 'merger' on the horizon for the implementation of Proof-of-Stake in Ethereum, SafeStake is on track to avoid concentrating the staking service provider in the hands of a few operator nodes.
To achieve this, its architecture is similar to that of the SSV Network, by using threshold cryptography to split the validation key of the staker/validator into several shares, each of which will be sent to one of the operators.
The operator working together performs the relevant staking and validation task for the validators by running the threshold signature scheme. An adversary has to compromise a predefined threshold number of operators to launch a successful attack against the ETH staking service provided by the network.
This entire process occurs under the HotStuff consensus protocol, which plays a key role in validating transactions and keeping operators within the system committed to offering the service for as long as possible to avoid penalties or cuts due to inactivity.
In HotStuff's three-phase commit, the so-called voting refers to the signature of the threshold on a message from the replicas, which is then sent to the leader. The full signature is generated when the leader receives enough votes. The leader will attach this signature to the next phase message that it sends to the replicas, and the signature will be verified by them.
With HotStuff, SafeStake governs the operator networks to determine the message content of the threshold signature scheme among the operator nodes.
By implementing HotStuff on SafeStake, a node in the distributed system does not need to confirm the message; if "enough nodes want to make the view switch" before notifying the new leader, instead it can directly switch to the new view and notify the new leader.
This not only makes the network more robust, but also generates higher performance than other BFT-based protocol derivations such as PBFT, Tendermint, or Casper, as HotStuff batches multiple operations on each node, thereby mitigating the cost of digital signatures by decision.
HotStuff is a Byzantine fault-tolerant consensus protocol that has been gaining respect among the blockchain developer community for its robustness, security, and ease of implementation, which are among the reasons why Facebook's Libra whitepaper considered basing its LibraBFT protocol on HotStuff.
Unlike Libra, SafeStake has the goal and intent, in contrast to Facebook's design, to implement open and permissionless HotStuff, which ensures greater decentralization for its ETH 2.0 Staking service.
This not only favors the extensive development of the entire SafeStake ecosystem, but also avoids concentrating a lot of resources and attention on the performance and general security of the network.
SafeStake has implemented HotStuff with a permissionless mechanism of a dual-chain consensus mode based on Ethereum 2.0 PoS, to ensure a more open and democratic structure, providing more decentralized staking.
Thus, in SafeStake node operator and validator roles are separated. Node operator doesn't have to deposit Eth. Only validators need to deposit Eth on Beacon chain (32Eth) or your staking pool (2nd testnet stage for lowering staking threshold) to be a validator.
Final Thoughts
Despite adding a third phase to the protocol, HotStuff has been shown to achieve high performance. Thanks to its linear O(n) authenticator scheme to drive a consensus decision, the communication costs to reach a consensus are quite low compared to other BFT schemes.
For these reasons and the optimistic response capacity together with the linear leader protocol without delay, SafeStake implements HotStuff for chain confirmation of the message content of the threshold signature scheme implemented during the ETH 2.0 staking service.
ParaState is aware of the relevance of the Ethereum ecosystem and how vital it is to participate in securing the main network of decentralized applications on the market; so together with SafeStake, we are innovating with the best of available blockchain technology to together build a new decentralized world.