The consensus mechanism determines how quickly and securely validators on the blockchain will reach consensus on the next block. Proof of Work (PoW), the first successful implementation of a consensus mechanism within a blockchain, was used in Bitcoin. In PoW, all network participants rush to solve a complex mathematical puzzle to get a chance to add their blocks to the network and win associated rewards.
The second application of a consensus mechanism gaining traction in the blockchain space is Proof of Stake (PoS). In PoS, participating validators receive rewards on the network based on the amount of the network’s native cryptocurrency they stake or lock in a wallet for a given period.
Another consensus mechanism, Practical Byzantine Fault Tolerance (PBFT), has been researched and developed for over two decades. PBFT is an ideal consensus mechanism for institutional consortia, such as blockchains, where all members are only partially trusted.
Consensus rounds in PBFT involve a node chosen as the leader. In contrast, the other nodes are each validators and can be divided into the preparatory and completion phases.
The leader broadcasts his proposal for a new block to other validators, who then post their votes on the proposal to the rest of the network. For messages to be broadcast continuously, each node in the network must count each vote.
When more than 2f + 1 consistent votes are seen, and the total number of validators plus the leader is 3f + 1 (f = number of malicious validators), the preparation phase is complete. Similar vote-counting is used during the commitment phase, where consensus is formed when 2f+1 consistent votes are seen.
A disadvantage of the PBFT consensus mechanism occurs when the network becomes extremely slow when it reaches a validator threshold and loses its ability to scale. This is due to the number of messages that each authenticator in the network must send and receive from each node.
Developed the tool. To address the scalability issue of PBFT, the Accelerated Practical Byzantine Fault Tolerance (APBFT) consensus mechanism is inspired by best practices, including Posschain, HotStuff, and Harmony’s consensus protocol (FBFT) create a consensus mechanism by reducing communication complexity within standard PBFT implementations. Rather than publishing the votes for each verifier, the leader conducts a multi-signature signing process to collect the votes of all verifiers. Now every node doesn’t need to take and count each of the voices of the remaining validators in the network; it just accepts one multi-signature.
A deeper dive into Posschain’s enhanced APBFT consensus mechanism reveals the two algorithms responsible for selecting the node to be the leader and the remaining validator nodes in each segment within the network. The primary algorithm used to choose the leader and validator nodes in a shard is a random function such as VRF. The VRF function will output the new leader for the fragment in a generation in each new era. Suppose the primary random function cannot extract a set of candidate leader and validator nodes. In that case, a secondary algorithm is called in the selection process to ensure that the epoch in a given shard has a set assigned to it.
Posschain’s APBFT consensus includes the following steps:
The leader broadcasts the block header he formulated to all validators. Simultaneously, the leader publishes the block’s content with the erasure coding, called the “announcement” stage.
Validators check the validity of the block header. If valid, they sign the block header with a Boneh-Lynn-Shacham (BLS) signature and send the signature back to the leader.
When the leader receives 2f H 1 valid signatures from the validators, it collects them into a BLS multi-signature. The leader publishes the batch multi-signature and a bitmap showing which validators signed it. This step forms the “preparation” phase with the second step.
Verifiers check that the multi-signature has at least 2f H1 signers, verify transactions in the block content broadcast from the leader in Step One, sign the message received from Step Three, and send it back to the leader.
The fifth and fourth steps make up the “commitment” phase. The leader then waits for at least 2f H1 valid signatures in step four, combines them into a BLS multi-signature, and creates a bitmap that logs all the signers. Finally, the leader commits and publishes the new block with all multiple signatures and bitmaps added for all validators to commit.
CONSENSUS ROLES
Validators: Validators are nodes on the Posschain blockchain that validate, process, and attest transactions on the blockchain. Through its democratic consensus mechanism, validators are voted for by community members that have voting rights.
Defenders: A node type attests to the validity of blocks as they are formed and submitted to the chains. A Defender fishes out for any illegal partnerships formed by malicious actors on the network and is rewarded for their work.
Nominators: Members who hold tokens on the chain nominate staking members as validators for transactions. Nominators receive a part of the reward that their nominated validators receive for their work in successfully assigning validators.
