SURFACE (PoA 2.0): Better Performance, Uncompromised Security and a Dual-Consensus Model

PeterZ
vechain
Published in
4 min readSep 8, 2020

--

By Zhijie Ren and Peter Zhou

Consensus mechanism is the core of any blockchain system, which determines its security and capacity of processing transactions. VeChain has adopted the Proof-of-Authority (PoA) consensus that belongs to the family of Nakamoto consensus and is well known for its practicality and efficiency. However, as applications and businesses running on the VeChainThor public blockchain thrive, there is an ever growing demand for better preformance (higher TPS and faster transaction confirmation) and uncompromised security to empower business innovations within VeChain’s ecosytesm.

Designing a consensus that delivers both performance and security is a hard problem. Most of the existing consensus systems only focus on one aspect. They are designed either to perform well in a good network condition but risk security when the condition gets worse, or to have an uncompromised security under any network condition but sacrifice a lot on its performance.

We tackle the problem with a new consensus algorithm, named SURFACE (PoA2.0) which stands for a Secure, Use-case-adaptive, Relatively Fork-free Approach of Chain Extension. Following the design principle of “hope for the best and prepare for the worst”, we decouple the problem into two sub-problems:

  • How to optimize performance under desired network conditions?
  • How to achieve uncompromised security under undesired network conditions?

and tackled the problems with a dual-consensus model that runs the Nakamoto and Byzantine Fault Tolerance (BFT) consensus at the same time.

Specifically, we attempt to achieve the near optimal performance for the Nakamoto consensus (hope for the best) when the network condition is good (meaning messages between nodes can be received in time); and utilize an asynchronous BFT mechanism to guarantee uncompromised security (prepare for the worst) when the network condition is bad (meaning the communications among nodes could be blocked due to extreme situations like natural disasters or malicious attacks). We will explain how the model works in the following.

Near-optimal performance for Nakamoto consensus

Our recent joint research with researchers from the Oxford University has identified that the fork rate is the single biggest factor affecting the performance of the Nakamoto consensus mechanism.

Whenever forks happen, honest nodes would be misguided and waste their resources on an invalid chain, which degrades the security of the system and delays transaction confirmation. Moreover, the bandwidth used for broadcasting forks would be a total waste as transactions on forks are eventually discarded. This problem has been tackled either by introducing redundancy, e.g., sending a 1MB block in 10 min when the network capacity is large enough for a 10MB block as done in Bitcoin, or by directly using some complicated BFT algorithms to reach consensus on each block to totally avoid forking. Both methods substantially sacrifice the performance.

In SURFACE, we adopt a random committee selection mechanism to achieve “relatively fork-free” in practical and normal network conditions. To do that, we randomly select a small group of nodes from the network to validate each proposed block and endorse the block before its publication. As a result, the probability of having a fork is significantly reduced compared to the classical Nakamoto consensus algorithms where the proposed block is only decided by one node. Note that this technique is much less complicated and more efficient than the BFT algorithms that typically involve multiple rounds of node communications. As the probability of having a fork decreases, SURFACE allows us to best utilize bandwidth for transmission of block data so that the throughput is nearly optimized, and the time for confirmation could also be reduced due to the fact that a block has already been confirmed by multiple nodes when it is published.

VIP193 has outlined the implementation details of the above part of SURFACE.

SURFACE can achieve better throughput as it uses bandwidth more efficiently.

Guaranteed security

Besides hoping for the best, we also need to prepare for the worst in case the network is severely partitioned or under massive DDOS attack. In that case, our sole focus would be to design a mechanism that guarantees uncompromised security. To do that, we introduce an asynchronous BFT algorithm that provides block finality to the system and more importantly, co-exists with, instead of replacing, the committee-based Nakamoto consensus described in the last paragraph.

The basic idea is to force the producer and committee to reach a consensus on their local finality states and put their state information into blocks to allow other nodes to be aware of their states. Nodes are then able to conclude BFT finality on blocks locally based on the information. In such a way, the two types of consensus are allowed to function simultaneously with a limited overhead. This finality mechanism has been introduced in VIP200.

With such a dual-consensus mechanism, a transaction will be first confirmed within a rather short time (e.g., less than 1 min), and then finalized after a longer period (e.g., 5 mins). Users could use confirmed transactions for their daily usage as it is at least as secure as other blockchains using Nakamoto consensus (like Bitcoin or Ethereum). They can also wait for a longer time till the transactions are finalized if absolute security is required.

Details of SURFACE can be found in our paper.

Conclusions

Here are some key takeaways from this article:

  • SURFACE (or PoA 2.0) is proposed to meet the demand for better performance and security due to the ever-growing number of enterprise applications running on VeChain Thor.
  • It is designed following the principle of “Hope for the best and prepare for the worst” and introduces a dual (Nakamoto and BFT) consensus model to meet the design requirements.
  • The dual-consensus model provides users flexibilities to choose different levels of security of their transactions according to their actual needs.

--

--