UniChain’s DPOS-Hotstuff consensus algorithm
DPOS is a success consensus algorithm in many famous blockchain platforms including EOS, Bitshare, Lisk … while Hotstuff is recently used in Facebook Libra project. UniChain is the first blockchain platform that combines those technologies. In this post, I will explain how DPOS-Hotstuff work and how It is used in UniChain. Let’s explore
DPOS stands for Delegated Proof of Stake, a consensus algorithm was developed by Daniel Larimer, in 2014 to resolve drawbacks from the POS (Proof of Stake) consensus algorithm. Both DPOS and POS are similar in the sense of stakeholding, DPoS presents a novel democratic voting system, by which block producers are elected. Since a DPoS system is maintained by the voters, the delegates are motivated to be honest and efficient or they get voted out (resolve the Nothing-at-stake problem*). In addition, DPoS blockchains tend to be faster in terms of transactions per second than the PoS ones.
A DPoS-based blockchain counts with a voting system where stakeholders outsource their work to a third-party. In other words, they are able to vote for a few delegates that will secure the network on their behalf. The delegates may also be referred to as witnesses and they are responsible for achieving consensus during the generation and validation of new blocks. The voting power is proportional to the number of coins each user holds. The voting system varies from project to project, but in general, each delegate presents an individual proposal when asking for votes. Usually, the rewards collected by the delegates are proportionally shared with their respective electors.
Therefore, the DPoS algorithm creates a voting system that is directly dependent on the delegates’ reputation. If an elected node misbehaves or does not work efficiently, it will be quickly expelled and replaced by another one.
In regards to performance, DPoS blockchains are more scalable, being able to process more transactions per second (TPS), when compared to PoW and PoS
In UniChain, every stakeholder can apply for delegates (witnesses) as long as they meet some certain conditions (ex: enough coin for making transaction fee — 1000 UNW) and persuade the community for their cast votes.
To vote for the witness, the coin stakeholders must have the power. The power can only be obtained by locking their coin balance. The current power-coin rate is 1:1 ie. If stakeholders lock 10 UNW, they get 10 Power for voting. Coin will automatically unlock after a specific time (currently 72 hours). The top 55 witnesses who receive the most voting from the community will become the witnesses of the network. Top 33 witnesses will be the active witnesses who are responsible for producing blocks and maintaining the network. 22 other will be a standby witnesses who are ready for replacing any active witnesses if they cannot complete their tasks (ex: hardware failure or cannot produce blocks after a specific time)
Both witnesses and voters may receive rewards . Rewards are accumulated and can be withdrawn after 24 hours.
How about Hotstuff?
To understand how Hotstuff help, let take a look at the previous consensus algorithm: PBFT (the Practical Byzantine Fault-Tolerant) which is currently used in many blockchain platforms including EOS.
The PBFT uses two phases of peer-to-peer message exchanges to reach the network agreement (consensus).
The first phase guarantees proposal uniqueness through the formation of a quorum certificate (QC). The second phase guarantees that the next leader can convince replicas to vote for a safe proposal. The algorithm for a new leader to collect information and propose it to replicas — called a view-change. The view-change based on two-phase in traditional PBFT is not simple, bug-prone and complex communication
PBFT may consist of the following steps in the normal-case operation:
- Request: the user sends transactions to the leader.
- Pre-prepare: the leader produces a proposal containing transactions and forwards to all replicas.
- Prepare: Upon receiving a proposal, other nodes will verify it, and if it succeeds, they will broadcast a prepared message to all other replicas.
- Commit: Upon receiving prepared messages from ⅔ of all backups, replicas will now broadcast commit messages. This is the second round of voting.
- Reply: the client sees the result of consensus.
The drawback of pBFT is the exponentially increasing message count as nodes (replicas technically) are added to the set.
Let’s take an example of a system that tolerates upto 2 faulty replicas. In this case, We need 3f + 1 replicas ie. 3*2 + 1 = 7 replicas. The total message count for client requests will be: 1 + 6 + 24 + 35 + 5 = 71 messages:
- 1 message for request
- 6 messages (3f) for pre-prepare
- 24 messages (3f*(3f — f)) for prepare
- 35 messages ((3f — f + 1)(3f + 1)) for commit
- 5 messages (3f — 1) for reply
If We add one more replica to be faulty, We need at least 10 replicas and the total communication messages for one client request is 142! So much!
From PBFT to Hotstuff:
HotStuff is a leader-based Byzantine fault-tolerant replication protocol proposed by VMware Research in March 2018. The most important change to PBFT is that It changes the PBFT’s mesh communication network to a star communication network, which means each communication will rely on the leader.
By using the star communication network, the node does not broadcast a message in terms of P2P but sends it to the leader which processes it and sends it to other nodes. It removes the overhead, network congestion and computational power.
The other change is that the view change is processed in a single round, It does not need the confirmation any more. The leaders switch to a new view change, then notify that change to the new leader. This mechanism made blocks in UniChain finalized after every block.
