VECHAIN Docs
Ask or search…
K
Comment on page

Consensus Deep Dive

A deeper dive into our PoA consensus mechanism.

Proof of Authorithy (PoA)

One of the biggest decisions when designing a public blockchain network is about designing the consensus algorithm. The protocol not only dictates how blockchain participants agree on how the blockchain grows but embodies the governance model imposed upon the network.
Recall that the underlying design philosophy of our governance model is that:
"neither a total centralization nor a total decentralization would be the correct answer, but a compromise from and balance of both would."
VechainThor implements the PoA consensus algorithm which suits our governance model which states that there would not be anonymous block producer, but a fixed number of known validators (Authority Masternodes) authorized by the steering committee of the Vechain Foundation.
“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 Buffet
To be an Authority Masternode (AM), the individual or entity voluntarily discloses who they are, identity and reputation by extension, to the Vechain Foundation in exchange for the right to validate and produce blocks. Their identity, reputation and financial investment is placed at stake and this acts as an incentive for the AMs to behave correctly and keep the network secure. In VechainThor, each AM has to go through a strict know-your-customer (KYC) procedure and satisfy the minimum requirements set by the Vechain Foundation.
When discussing a consensus algorithm, we must answer the following questions:
  • When is a new block produced?
  • Who generates the block?
  • How to choose the "trunk" from two legitimate blockchain branches?

When

The VechainThor blockchain schedules a new block to be generated once every
Δ\Delta
seconds. We set
Δ=10\Delta = 10
, which is based on our estimation of the usage of VechainThor. Let
t0t_{0}
be the timestamp of the genesis block. The timestamp of the block with height
h>0h > 0
and
tht_{h}
,must satisfy
h=t0+mΔ_h = t_{0} + m\Delta
where
mN+m \in \mathbb{N}^{+}
and
h\geqslant h
.

Who

PoA allows every available AM to have an equal opportunity to be selected to produce blocks. To do that, we introduce a Deterministic Pseudo-Random Process (DPRP) and the “active/inactive” AM status to decide whether a particular AM
α\alpha
is legitimate for producing a block
(h,t)(h,t)
with height
hh
(uint32) and timestamp
tt
(uint64). Here
tt
must satisfy
(tt0)modΔ=0(t - t_{0})mod\Delta = 0
. We first define the DPRP to generate a pseudo-random number
γ(h,t)\gamma(h,t)
as:
γ(h,t)=DPRP(h,t)=hash(ht)\gamma(h,t) = DPRP(h,t) =hash(h \circ t)
where
\circ
denotes the operation that concatenates two byte arrays.
Let
ABA_{B}
denote the sorted set of AMs with the “active” status in the state associated with block
BB
. Note that on the VechainThor blockchain each AM is given a fixed index number and the numbers are used to sort elements in
ABA_{B}
. To verify whether
aa
is the legitimate AM for producing
B(h,t)B(h,t)
, we first define
AB(h,t)a=sort(APA(Bh,t)))aA^{a}_{B(h,t)} = sort(A_{PA(Bh,t))} ) \cup a
where
PA()PA(\cdot)
returns the parent block. We then compute index
ia(h,t)i^{a}(h,t)
as:
ia(h,t)=γ(h,t)modAB(h,t)ai^{a}(h,t) = \gamma(h,t) mod \parallel A^{a}_{B(h,t)} \parallel
AM
aa
is the legitimate producer of
B(h,t)B(h,t)
if and only if
AB(h,t)a[ia(h,t)]=aA^{a}_{B(h,t)} [i^{a}(h,t)] = a
. Note that we put double quotes around the word “active” to emphasize that the status does not directly reflect the physical condition of a certain AM, but merely a status derived from the incoming information from the network.

AM Status Updating

Given the latest block
B(h,t1)B(h,t_{1})
and its parent
B(h1,t0)B(h - 1,t_{0})
, for any
t0<t<t1t_{0} < t < t_{1}
and
(tt0)modΔ=0(t - t_{0}) mod \Delta = 0
, the system computes AM
ata_{t}
such that
AB(h,t1)at[iat(h,t)]=atA^{a_{t}}_{B(h,t_{1})}[i^{a_{t}}(h,t)] = a_{t}
and mark
ata_{t}
as "inactive" in the state associated with
B(h,t1)B(h,t_{1})
. In addition, the system always sets the status of the AM that generates
B(h,t1)B(h,t_1)
as "active". Note that we set all the AMs as "active" from the beginning.

Trunk

The final question we need to answer is how to choose the “trunk” from two legitimate blockchain branches. Since there is no computational competition in PoA, the “longest chain” rule does not apply. Instead, we consider the better branch as the one witnessed by more AMs.
To do that, we compute the accumulated witness number (AWN),
π\pi
, for block
B(h,t)B(h, t)
as:
πB(h,t)=πPA(B(h,t))+AB(h,t)\pi_{B(h,t)} = \pi_{PA(B(h,t))} + \parallel A_{B(h,t)} \parallel
with
πBgenesis=0\pi_{B_{genesis}} = 0
. Since
AB(h,t)\parallel A_{B(h,t)} \parallel
computes the number of AMs with “active” status associated with
B(h,t)B(h,t)
, it can be viewed as the number of AMs that witness the generation of
B(h,t)B(h,t)
. Therefore, we select the branch with the larger AWN as the trunk. If the AWNs are the same, we choose the branch with less length. Note that the AWN is stored in the block header as TotalScore.
Formally, given two branches
<B1<\mathcal{B}_{1}
and
B2\mathcal{B}_{2}
with their latest blocks
B1(h1,t1){B}_{1}(h_{1},t_{1})
and
B2(h2,t2){B}_{2}(h_{2},t_{2})
, respectively, we first calculate their AWNs
πB1\pi_{B_{1}}
and
πB2\pi_{B_{2}}
. The system then makes the following decision: choose
B1{B_{1}}
as the trunk if
πB1>πB2\pi_{B_{1}} > \pi_{B_{2}}
, or
B2B_{2}
if
πB1<πB2\pi_{B_{1}} < \pi_{B_{2}}
. In case
πB1=πB2\pi_{B_{1}} = \pi_{B_{2}}
, choose
B1B_{1}
if
h1<h2h_{1} < h_{2}
or
B2B_{2}
if
h1>h2h_{1} > h_{2}
. If
h1=h2h_{1} = h_{2}
, keep the current trunk.