• The VeChain blockchain dev team chose to design and implement a finality gadget to run dual modes of consensus instead of replacing the Proof-of-Authority (PoA) consensus.
• The latest stage of PoA 2.0 has been running on the testnet, and the stakeholder should enable its deployment on the mainnet.

Recently, VeChain’s Peter Zhou tweeted that the latest stage of PoA 2.0 (the FOB finality or the VIP-220) has been running as expected on the testnet. He added that he looks forward to the stakeholder vote enabling its mainnet deployment.

According to the VeChain development team, PoA 2.0 will combine the various types of blockchain consensus to achieve the holy grail of mechanisms for the real-world environment. The block finality provides an absolute security guarantee for blocks that fulfill specific conditions. It is an essential property of any modern blockchain system, which is why the VeChain blockchain dev team has been pursuing this property to improve its consensus algorithm.

The VIP-220 proposal

The team proposed to design and implement a finality gadget (known as finality with one bit, FOB). Thus, they can run dual consensus modes (Nakamoto and BFT consensus) simultaneously instead of replacing the Proof-of-Authority consensus with a completely new one. A FOB has a simple design with little redundancy to the current PoA-built Thor protocol.

Besides achieving block finality, this proposal, known as VIP-220, also suggested the introduction of minimal complexity to the current PoA-based system. Thus, reducing possible risks created by implementation bugs and unknown design deficiency. Regarding the Nakamoto consensus, there is always a probability of a transaction reversal because of double-spending.

While there can be security issues with the Nakamoto consensus mechanism, it has proven usable and practicable in adverse network environments. Thus, the VeChain development team proposed the “finality gadget” as an add-on to the Nakamoto consensus. The introduction of a finality gadget means it will ‘finalize’ any transaction, which the Nakamoto consensus mechanism has confirmed.

However, a finality gadget must satisfy two conditions. The finalized block must:

• A block on the original Nakamoto chain
• A confirmed block on the above chain.

While the finality gadget and the BFT mechanism share some similarities, running a BFT algorithm in parallel with a finality gadget is impossible because the finalized block isn’t a block on the original Nakamoto chain.

It is worth noting that the blockchain-liveness nature of the viewless BFT (VLBFT) makes it the perfect building block for the finality gadget. The voting mechanism is one significant difference between finality gadgets (such as Casper and Grandpa) and FOB.

Finality gadgets introduce a separate voting mechanism, while it isn’t an issue in FOB since votes are directly cast in blocks with an extra bit. Also, many of the current finality gadgets are built using the view-based paradigm of BFT algorithms. Conversely, nodes are implicitly locked in FOB nodes.