VeChain

<p>Block finality is an indispensable property for a modern blockchain system. It provides an absolute security guarantee for blocks (and therefore, all the transactions packed in them) that satisfy certain conditions. We, at the VeChain blockchain dev team, have been pursuing this property along the way to improving our consensus algorithm.</p><p>To do that, instead of replacing the Proof-of-Authority (PoA) consensus with a completely new one, we have chosen the path of designing and implementing a finality gadget, named the Finality with One Bit (FOB) to allow us to run dual modes of consensus, namely, the Nakamoto and BFT consensus, at the same time. The advantages of the current design, proposed by <a href="https://github.com/vechain/VIPs/blob/master/vips/VIP-220.md" rel="noopener noreferrer nofollow">VIP-220</a>, are:</p><ul><li>Achieving block finality</li><li>Maintaining the usability and robustness of our system by decoupling finality from the PoA process which allows the blockchain to grow in adverse environments</li><li>Introducing minimal complexity to the current PoA-based system, minimizing the potential risks caused by unknown design deficiency and implementation bug</li><li>Adding minimal extra information (one bit per block) for network communication so that we do not need to sacrifice system performance for achieving block finality</li></ul><h2 id="header-0">Background</h2><p>During our work on PoA 2.0, we have proposed two solutions to block finality, described in <a href="https://github.com/vechain/VIPs/blob/master/vips/VIP-193.md" rel="noopener noreferrer nofollow">VIP-193</a> and <a href="https://github.com/vechain/VIPs/blob/master/vips/VIP-220.md" rel="noopener noreferrer nofollow">VIP-220</a>, respectively. The former is based on the research in [1] and contains two major components: a VRF-based random beacon generator scheme and a committee-based Hotstuff-like BFT algorithm. During our implementation of VIP-193, we successfully applied the random beacon generator scheme to the current system, resulting in a much better source of randomness. However, the complexity and redundancy brought by the BFT algorithm hestated us to merge it to the system.</p><p>To reduce the complexity and redundancy to a satisfactory level, we collaborated with the researchers from UBC and sponsored their work on the view-less BFT via the <a href="https://github.com/vechain/grant-program/" rel="noopener noreferrer nofollow">VeChain Grant Program</a>. The research resulted in the finality gadget, named the Finality with One Bit. The algorithm has been described in VIP-220 and is the replacement of the one proposed in VIP-193. We can now define PoA2.0 as the combination of the VRF-based random beacon generator scheme and FOB. The committee mechanism is an optional component that would accelerate the finality process. In the following paragraphs, we will focus on describing FOB.</p><h2 id="header-1">Finality Gadget</h2><p>For the Nakamoto consensus, there is always a non-zero probability (although it could be a tiny small number) that a transaction could be reverted due to double spending. This is usually fine for our daily uses but could be troublesome in some security sensitive use cases. On the other hand, we don&#39;t want to completely replace the Nakamoto consensus mechanism since it has already proven its usability and practicality in adverse network environments.</p><p>Hence, &#34;finality gadget&#34; is then proposed. It is an add-on to the existing Nakamoto consensus that utilizes the information contained in the mined blocks to reach block finality. With a finality gadget, a transaction will first be confirmed by the Nakamoto consensus, and then be &#34;finalized&#34; by the gadget. Once it is &#34;finalized&#34;, it is proven to be absolutely secure, that is, there is zero probability that the transaction could be reverted as long as the finality security assumption holds.</p><p>There are similarities between the finality gadget and the known BFT mechanism (e.g., PBFT, Tendermint, Hotstuff, etc.). However, the difference is that a finality gadget is a &#34;gadget&#34; or a component running upon the Nakamoto blockchain system, and therefore, will not replace the original Nakamoto consensus. Following this definition, a finality gadget should satisfy the below two conditions: the finalized block needs to be</p><ul><li>a block on the original Nakamoto chain – Condition A</li><li>a confirmed block on the original Nakamoto chain – Condition B.</li></ul><p>By confirmed, it means that the block is appended by a sufficient number of blocks. Consequently, we cannot simply run a BFT algorithm in parallel as a finality gadget as it fails in Condition A. Moreover, we cannot be satisfied by the <a href="https://arxiv.org/abs/2009.04987" rel="noopener noreferrer nofollow">Ebb-and-Flow protocols</a>, which does not guarantee Condition B.</p><h2 id="header-2">Finality with One Bit</h2><p>FOB is our novel finality gadget inspired by the view-less BFT (VLBFT) [2]. The rest of this section will be used to describe VLBFT and FOB briefly.</p><p>Most existing BFT algorithms, including PBFT, Tendermint, and Hotstuff, achieve consensus with concepts of view and lock. A view can be roughly considered as a new round of consensus process. Nodes will start the consensus process in the current view and lock to the view, that is, not responding to other views. By design, if they cannot reach a consensus in the current view, nodes will have to trigger a view change process, unlock themselves and enter into a new view. The view change process is often expensive, significantly deteriorating system performance.</p><p>VLBFT does not use this paradigm. It utilizes the underlying blockchain to provide liveness and does not force all nodes to be in the same view to join the consensus process and lock to it. To mine a new block, the block proposer needs to collect votes from the supermajority (more than 2/3 of the consensus nodes) and put them in the block header to propose a valid block. Due to the nature of Nakamoto consensus, there could be multiple valid block proposers in a round. In that case, honest nodes will vote for all of them, instead of locking to only one of them as in the case of a view-based algorithm.</p><p>Alongside with each vote, nodes not only show agreement on the newly proposed block, but also give an extra bit of information of whether it has voted for multiple blocks in the previous rounds. If yes, it casts a &#34;Wit&#34; (stands for Witness) vote. Otherwise, it casts a &#34;Com&#34; (stands for Commit) vote. The block proposer then collects these votes to propose a valid block. If it is able to collect &#34;Com&#34; votes from the supermajority, then the parent block of this block will reach consensus.</p><p>The view-less and blockchain-drive liveness nature of VLBFT makes it a perfect foundation for a finality gadget. We thus propose FOB using the essence of VLBFT. Firstly, we define the first block of every L blocks as checkpoints (CPs). A CP is called justified if it is appended by blocks signed by more than two third of the Authority Masternodes (AMs) in the CP. We then define the CP height of a block by the number of justified CP before this block. In each block, the block proposer will give their opinions on whether they have proposed blocks for multiple CPs in the previous CP height. If not, they add one bit of &#34;Com&#34; vote in their proposed block. Otherwise, they vote &#34;Wit&#34; in their proposed block. In FOB, there is no separate vote collecting process. Instead, the votes are cast alongside the appending blocks. Then, if &#34;Com&#34; votes are collected from more than two third of AMs in the same CP height, the CP from the previous height is finalized. Note that the “Com” and “Wit” vote can be represented by one bit and that is why we name our finality gadget the Finality with One Bit.</p><h2 id="header-3">How is FOB compared to other finality gadget designs?</h2><p>We have already mentioned some desired properties (both Condition A and B) in FOB. Moreover, FOB is simple by design and adds minimal redundancy to the existing PoA-based Thor protocol.</p><p>Note that most existing finality gadget designs do not satisfy Condition B, which we consider a necessity for finality gadgets. It is because without Condition B, a finality gadget could rollback what the original Nakamoto consensus has confirmed, making the original consensus algorithm rather meaningless. On the contrary, FOB is one of its kind that satisfies Condition B.</p><p>Finality gadgets like Casper and Grandpa introduce a separate voting mechanism, in which the nodes vote for the checkpoints and broadcast them like transactions. In such systems, votes will be collected by the block proposers and therefore, requires an extra incentive mechanism to guarantee the honesty of all parties. It is unfortunate that neither Casper nor Grandpa has implemented it. On the other hand, this is not an issue in FOB as votes are directly cast in blocks with only an extra bit.</p><p>Last but not least, most existing finality gadgets follow the view-based paradigm of BFT algorithms. Nodes will have to lock themselves to a view until consensus is reached or they will be unlocked by the view-change process to avoid being deadlocked. The lock could result in a lengthy recovery period in case when the network suffers from a major failure and then returns to normal. On the other hand, in FOB, nodes are implicitly locked, i.e, they could vote by appending blocks for multiple forks. In fact, they are only &#34;locked&#34; to the &#34;Wit&#34; vote if they have done so in the previous CP height. As a result, FOB could recover from network failure as soon as the network returns to normal and the underlying blockchain is fork-free.</p><h2 id="header-4">References</h2><p>[1] Zhijie Ren and Peter Zhou (2020) SURFACE: A Practical Blockchain Consensus Algorithm for Real-World Networks, <a href="https://arxiv.org/abs/2002.07565v3" rel="noopener noreferrer nofollow">arXiv:2002.07565v3</a>.</p><p>[2] Jianyu Niu and Chen Feng. Leaderless Byzantine fault tolerant consensus. <a href="https://arxiv.org/abs/2012.01636" rel="noopener noreferrer nofollow">arXiv:2012.01636</a>.</p>

PoA 2.0: Finality with One Bit

Table of Contents

vechain

Other articles published on Jul 4, 2022

The 4 stable tokens in the StablePlaza pool

Weekly Report (27 Jun-3 Jul 2022): Bitcoin regains $19k after Thursday plunge, Addresses in loss ...

⏰⏰Another great week with UKA TEAM. Let's remind what happened this week

Metafity AMA Session

Meta starts experimenting with Facebook's NFT integration

The Community Fund Committee (CFC) election has concluded!

Join our free newsletter for daily crypto updates!