Defining the VeChainThor Blockchain Consensus — Proof of Authority

TL;DR — The Proof of Authority Consensus Model overcomes many of the obstacles presented in Proof of Work (PoW), Proof of Stake (PoS), Designated Proof of Stake (DPoS), and Practical Byzantine Fault Tolerance (PBFT) to make a platform that has low computational power requirements, no requirement for communication between nodes to reach consensus, and is optimized for system continuity. This is the ideal solution for enterprises relying on a timely and secure consensus.

At its core, designing the consensus model of a Blockchain is one of the largest decisions needed to be made. To many the consensus model represents scalability and the level of decentralization the protocol endures, however, long-term the importance of the governance model has more value than the rest. Recall that the underlying design philosophy of VeChain’s governance model is that:

“Neither a total centralization nor a total decentralization would be the correct answer, but a comprise and balance of both would.”

When building the world’s most used enterprise-grade public blockchain, none of the mainstream protocols, such as Proof of Work (PoW), Proof of Stake (PoS), and Delegated Proof of State (DPoS), are suitable for our system. The designed Proof of Authority (PoA) provides the governance needs of VeChainThors consensus protocol and enables the ability to prevent anonymous block producers.

To qualify as an applicant to be an Authority Masternode (AM) of the VeChainThor Blockchain, the individual or entities must voluntarily disclose their identity (and reputation by extension) to the VeChain Foundation in exchange for the rights to apply to be the ones who validate and produce blocks.

“It takes twenty years to build a reputation and five minutes to ruin it. If you think about that, you’ll do things differently.” — Warren Buffett

It is when their identities and reputations are at stake that all the AMs can be held accountable and incentivized to work in the best interest for the networks growth and security. To achieve this state, each VeChainThor AM will go through a strict Know Your Customer (KYC) procedure to satisfy the Foundations minimum requirements.

We summarize the main characteristics of the PoA protocol implemented as:

1. Low requirement of computational power;
2. No requirement of communications between AMs to reach consensus;
3. System continuity is independent of the number of available genuine AMs.

Proof of Authority In Detail

When designing the consensus protocol of any blockchain one must address three basic questions:

1. When is a block produced?
2. Who generates the block?
3. How do you choose from two canonical (legitimate) blockchain branches to establish the trunk of the blockchain (the now defined truth)?

When

Blocks within the VeChainThor Blockchain are produced once every Δ seconds. In the initial release of the protocol, the Δ is set to ten seconds. This increment of Δ is an estimation of the usage of the VeChainThor Blockchain at the official launch. With t0being the timestamp of the genesis block. The timestamp of the block with height n>0, tn, must satisfy tn=t0+m∙∆ where m∈N and m≥n.

Who

The VeChainThor PoA Protocol ensures that every AM has an equal opportunity to be selected to produce blocks. However, to satisfy security constraints, we do not want the order of AMs to generate blocks to be entirely deterministic. To achieve this state, VeChainThor utilizes a deterministic pseudo-random process (DPRP) and the concept of “active/inactive” status for AMs to decide if an AM a is a legitimate option to produce a block B(n,t) with height n and timestamp t. In this method t must satisfy (t-t0) mod Δ=0. To answer who generates the block, we first define DPRP to generate a pseudo-random number γ(n,t) by:

Where ∘ denotes the operation that concatenates two byte-arrays.

AB denotes the set of AMs with the “active” status associated with B. To verify whether a is the legitimate AM for producing B(n,t), we first define:

Where PA(∙) returns the parent block. Then compute index ia(n,t) as:

AM a is the legitimate producer of B(n,t) if and only if AB(n,t)a[ia(n,t)]=a. Note that we put double quotes around the word “active” to emphasize that the status does not directly reflect whether a certain AM is actually physically active in the network at that time, but merely a status derived from their validity to produce a block within the network.

To discuss the status updates of AMs let’s look at the situation illustrated in the above figure for an example. It shows four allowed time slots {t1,t2,t3,t4} for block production. The solid line marks the verified blocks produced on time while the dashed line is the missing blocks. For each time slot, the system can compute the index of the responsible AM using the above equation. The system sets the status of any AM that fails to produce a block as “inactive” and the status of the current block’s producer as “active”. In this example, after the system verifies B(n,t4), it updates the AM status associated with B(n,t4) as:

Where a* is the signer of B(n,t4).

From the above description, it can be seen that any missing block before a legitimate block timestamp t would completely change the order of the AMs that produce blocks afterwards. It would hence be more difficult for attackers to find out which AM is responsible for producing a number of consecutive blocks at a time relatively far away. Furthermore, the VeChain Foundation could deliberately let the AMs control the ability to skip producing a block occasionally to increase the unpredictability.

How

The final question we need to answer is how to choose between two canonical blockchain branches to make the “trunk”. Since there is no computational competition in PoA, the “longest chain” rule does not apply. Instead, the VeChainThor Blockchain choose the branch that is witnessed by more AMs as the better of the two. To do this, the protocol computes the accumulated witness number (AWN) for block B(n,t) as:

Since ‖AB(n,t)‖ computers the number of AMs that are active in associated with B(n,t), This can be considered as the number of AMs that witnessed B(n,t). Therefor, the branch with the largest AWN is chosen as the trunk. If the AWNs are the same, the VeChainThor Blockchain selects the branch with less length.

Formally, given two branches B and B’ with latest blocks B(n,t) and B’(n’,t’), respectively, the protocol first calculates their AWNs πB(n,t) and πB’(n’,t’). The system then makes the following decision: choose B as the trunk if πB(n,t)>πB’(n’,t’); or choose B’ if πB(n,t)<πB’(n’,t’). In case πB(n,t)=πB’(n’,t’), choose B if n<n’ and B’ if n>n’. If n=n’, keep the current trunk.

System Continuity

When considering a system’s performance, it is important to test the system continuity, or in other words, to find out in what situations that the system would halt. According the PoA protocol described above, the whole system does not require a minimum number of genuine validators to be available, like the practical Byzantine fault tolerance (PBFT) protocol does. This system enables the ability to perform multiple rounds of inter-node communications to reach consensus. No external factors could prevent an Authority Masternode from continuously performing the PoA protocol and reaching consensus about the current Blockchain state based on the information it receives from the network. In this way, the PoA protocol endows the VeChainThor Blockchain with substantial robustness and stability.

Resolving A 51% Attack

In theory, the PoA protocol is vulnerable to the so-called “51% attack”. This term is originally used to describe an attack to a PoW based Blockchain systems such as BitCoin and Ethereum. In these cases, the “51%” stands for more than half of the networks mining power. It surely should have a different meaning in the context of other consensus protocols. In PoA, the “51%” means more than half of the current available Authority Masternodes who collude.

This attack sets the requirement to not only on the number controlled in an attack but, more importantly, on the assumption that the rebelling Authority Masternodes collude. In reality, the PoA consensus significantly increases the difficulty of carrying out such a 51% attack.

Long Range Attacks

A long-range attack is one of most common ways to attack a Blockchain system. This attack exists when the attacker takes an old block, creates a new blockchain branch, and then tries to broadcast it to the network in an attempt to override the existing trunk. Very often, the fabricated branch is much longer than the trunk so as to fool the consensus protocol.

Normally, the long-range attack cannot be used to attack the proposed PoA protocol. The below figure illustrates a long-range attack to PoA where the white blocks represent the trunk while the grey blocks the fabricated branch. On one hand, since there has to be a ∆-second interval between two consecutive blocks, it is impossible for the attacker to produce a much-longer chain. On the other hand, PoA chooses the trunk based on the accumulation of the number of “active” Authority Masternodes. In that sense, to replace the current trunk with the fabricated branch, the attack has to gather more than half of the available Authority Masternodes to produce a larger total number than the existing branch. The attack then becomes a 51% attack which has been described above.