PlatON’s Giskard consensus protocol consists of PPoS (PlatON proof of stake), a probabilistic proof-of-stake consensus, and Giskard BFT (Giskard Byzantine Fault Tolerance). The PPoS selects the validators to participate in consensuses by staking, delegation, and random selection, while the Giskard BFT uses a BFT-like algorithm to implement block production and verification.

In this feature, we will delve into two technical issues with two articles. The first article will briefly introduce the PPoS consensus and BFT theory, and analyze the characteristics of the PBFT algorithm. The second article will focus on analyzing how Giskard BFT evolved by drawing on other consensus protocols such as PBFT, Tendermint, and Hotstuff.

In the previous article, PlatON Consensus Protocol: From PBFT to Giskard (1), we briefly introduced the PPoS consensus and the BFT theory. Meanwhile, we delved into the consensus process and the view change flow of PBFT with the application of the PBFT algorithm in the blockchain consensus as an example.

In this article, we will first talk about problems and bottlenecks of the PBFT and then explain in detail how Giskard BFT evolved by drawing on the PBFT, Tendermint, HotStuff, as well as other consensus protocols, and give an in-depth analysis of the optimization ideas of the Giskard BFT.

Problems of the PBFT

A detailed analysis of the three phases of the PBFT consensus process shows that the overhead of message transport is significant. When attempting to reach a consensus, all n nodes involved need to broadcast messages to other n-1 nodes, therefore, the communication complexity of the algorithm reaches O(n²), and in the case of 1000 nodes, the amount of communication to be exchanged will be 1,000,000. Experiments have shown that the performance of the algorithm drops sharply when the number of nodes exceeds 20.

Besides, when the Leader is elected in PBFT, possibly the elected Leader would keep running for a long time with multiple rounds of interaction, and the view change would only initiate after the Leader node failed. However, in a blockchain system, a view represents a consensus unit, and the consensus process consists of one view after another. In each view, a certain proposer is responsible for leading the consensus protocol and generating blocks, and the remaining validators would vote and sign the blocks to reach a consensus. As block generation is with interests (e.g., bookkeeping rights, block rewards, etc.), the block generation nodes need to be changed frequently, which means the view-change has to be conducted continually, causing huge consumption of network resources.

Giskard BFT Consensus Optimization

By taking into consideration the characteristics of the blockchain, we designed the Giskard BFT based on the BFT protocol, optimizing the protocol mainly from the following aspects.

Optimization of the view-change process

All BFT protocols replace the primary node via view-change. PBFT, SBFT, and other protocols have a separate view-change process that will be triggered when something goes wrong with the primary node. In Tendermint, HotStuff, and other protocols, there is no explicit view-change process, and the view-change is merged into the normal process, thus improving the efficiency of view-change and reducing its communication complexity.

The Giskard BFT is also a view-based consensus protocol. To reduce the complexity of communication, it also does not have an explicit view change process but integrates it with the block generation. The Giskard BFT defines that each proposing node generates 10 blocks consecutively in a view, and after each block reaches the QC state (Quorum Certificate, indicating that the node receives 2*f+1 signatures for the block), it automatically switches to the next view, without a separate view-change voting process.

The following figure shows the explicit ViewChange process, and we can see that, unlike PBFT, it does not have the view-change-ack and new-view phases, which are replaced by the subsequent prepareQC(n).

Here summarized the two key points of the optimization for the view-change process:

• No need for an explicit view-change process to reduce voting actions.
• Taking the properties of the blockchain, view-change-ack, and new-view is replaced with the subsequent prepareQC(n) to “indirectly” confirm new views.

Adoption of the BLS aggregation signature

To further reduce the communication volume, we have adopted the BLS aggregation signature technology. As the mainstream aggregation signature in the industry, the BLS aggregation signature is an extension based on the BLS signature.

In Giskard BFT, we aggregate multiple node signatures for block and view-change messages into a single signature, which can be simply put as: “compressing” a long section of signatures from multiple nodes into a single signature. This approach has greatly reduced the communication volume and has significantly improved the communication efficiency of the protocol.

Parallelization of block production and verification

As mentioned above, Giskard BFT is a view based consensus protocol, where each proposing node generates 10 blocks consecutively within a view, and the parallel process is as follows:

• The proposing node can propose multiple blocks in a row within a view, and the next block is generated without waiting for the previous block to reach the QC state.
• The validator can transact the next block in parallel while receiving the previous block’s votes.

This optimization is a unique innovation of the Giskard BFT. Parallelization here refers to the concurrency of block production and block verification. This approach greatly accelerates the block generation rate and also improves the consensus performance of the system.

Introducing the pipeline approach for block verification

In traditional BFT-dominated blockchain systems, the consensus of each block usually needs to go through the clear-cut phases of Pre-Commit and Commit before been verified:

• Pre-Commit: Pre-Commit will be broadcast when a node receives 2*f+1 Prepare votes, and Pre-Commit can be regarded as an acknowledgment of the Prepare phase.
• Commit: When 2*f+1 Pre-Commit votes are received, it indicates that all nodes agree on the specified message and commit it to the local disk.

Blocks in the Giskard BFT only go through the Prepare voting, and there are no explicit Pre-Commit and Commit phases, then how would the blocks reach final verification? The Giskard BFT can be seen as a Pipeline version of BFT, where each prepareQC is an advanced verification of the previous block.

As shown in the figure, prepareQC(2) is the Pre-Commit phase of Block(1), prepareQC(3) is the Commit phase of Block(1), and the Pre-Commit of Block(2).

Simply put, the Commit phase of PBFT is “omitted”, and this may be confusing to our readers: didn’t the previous article concluded clearly that messages from three phases must be passed to reach consistency? The Giskard BFT is not actually without a Commit stage, instead, by considering the properties of the blockchain, the QC state of the next block is adopted as an indirect Commit verification of the previous block.

With the chain structure of the blockchain in mind, Giskard BFT introduces the pipeline approach to verify the blocks, making the protocol simple and elegant. It not only streamlined the operations, but also improved the performance of the protocol, and leaving enough design space for its scalability.

Conclusion

At present, the PlatON test network and mainnet, as well as the Alaya network, which all adopted the Giskard consensus protocol, have fully verified its safety and liveness after running stably and efficiently for a long time. There is no doubt about the role of Giskard consensus in solving the over-centralization of the system, reducing the complexity of network communication and messaging, improving consensus efficiency, and the overall performance of transaction processing of the whole blockchain.

In later versions of the protocol, we will keep deepening the optimization: instead of solely using VRF for validator selection, PVSS, BLS, and other cryptographic algorithms of verifiable secret sharing are going to be integrated to further increase randomness; group consensus would be introduced to improve the scalability of the algorithm, enabling the efficient support of the participation of more nodes and increasing the safety and fault tolerance of the network.