VeChain Docs
  • Welcome to VeChain
  • Blockchain Basics
    • Introduction to blockchain
    • Introduction to digital property
    • The evolution of the internet
  • Introduction to VeChain
    • About the VeChain blockchain
      • Consensus Deep Dive
      • Governance
    • Dual-Token Economic Model
      • VeChain (VET)
      • VeThor (VTHO)
    • Acquire VeChain Assets
    • Sustainability
  • Core Concepts
    • Networks
      • Thor Solo Node
      • Testnet
      • Mainnet
    • Nodes
      • Node Rewards Programme
    • Blocks
      • Block Model
    • Transactions
      • Transaction Model
      • Transaction Fees
      • Transaction Calculation
      • Meta Transaction Features
        • Transaction Uniqueness
        • Controllable Transaction Lifecycle
        • Clauses (Multi-Task Transaction)
        • Fee Delegation
          • Multi-Party Payment (MPP)
          • Designated Gas Payer (VIP-191)
        • Transaction Dependency
    • Block Explorers
    • Wallets
      • VeWorld
        • User Guide
          • Setup
          • Wallet
          • Signing
          • Activities
          • Settings
        • FAQ
      • Sync2
        • User Guide
          • Setup
          • Wallet
          • Signing
          • Activities
          • Settings
        • FAQ
      • Sync
        • User Guide
          • Wallet
          • Ledger Device
          • Browser dApps and web
          • Interact with dApps
          • Activities
          • Settings
          • Report an Issue
          • Contributing
        • FAQ
    • EVM Compatibility
      • VeChain Modifications
      • Methodology
      • Test Coverage
        • Gas model
        • Raw transaction
        • hardhat specific
          • Ganache failures
          • evm_increaseTime
        • Failures in constructor
        • eth_sign
        • Contract address prediction
        • BadBeacon proxy address at 0x1
      • How to Recreate
      • Additional Information
        • Using Governance Contracts
        • ERC1820/ERC777 Testnet
        • Delegate Options
    • Account Abstraction
      • UserOperation
      • Bundler
      • EntryPoint Contract
      • Account Factory Contract
      • Paymaster Contract
    • Token Bound Accounts
  • How to run a node
    • Nodes
    • How to run a Thor Solo Node
    • Custom Network
    • Connect Sync2 to a Thor Solo Node
  • Developer Resources
    • Getting Started
    • How to build on VeChain
      • Connect to the Network
      • Read Data
        • Read Blocks
        • Read Transactions
        • Read Accounts
        • States & Views
        • Events & Logs
        • VET Transfers
      • Write Data
        • Transactions
        • Fee Delegation
      • Listen to Changes
        • Events
        • VET Transfers
        • Transactions
        • Blocks
        • Beats
      • Build with Hardhat
      • Utilities
        • BigInt and Unit-Handling
        • Name Service Lookups
    • Example dApps
      • Buy me a Coffee
      • Token Bound Accounts
      • PWA with Privy and Account Abstraction
    • EVM Compatibility for Developers
      • Key Architectural Differences and Optimizations
      • Practical Implications for Developers: Key Considerations
      • RPC Methods (Detailed Breakdown)
      • Frequently Asked Questions (FAQs)
      • VeChain Blockchain Specifications
      • Key Differences Between VeChain and Ethereum (Summary)
      • Best Practices for Developing on VeChainThor
    • How to verify Address-Ownership
      • Next.js Session Verification
    • Debug Reverted Transactions
    • Account Abstraction
    • VIP-191: Designated Gas Payer
      • How to Integrate VIP-191 (I)
      • How to Integrate VIP-191 (II)
      • How to Integrate VIP-191 (III)
    • Index with Graph Node
      • Setup with Docker
      • Index with OpenZeppelin
        • Create Subgraph Project
        • Configure Contracts
        • Deploy Subgraph and start Indexing
        • Track Subgraph Indexing
        • Access Subgraph
        • Update Subgraph
    • SDKs & Providers
      • SDK
        • Architecture
        • Accounts
        • Bloom Filter
        • Certificates
        • Contracts
        • Cryptography
        • Debug
        • Encoding
        • Polls
        • Subscriptions
        • Thor Client
        • Transactions
      • Thor DevKit
        • Installation
        • Usage
          • Cryptography
          • Accounts
          • Encoding
          • Transactions
          • Certificates
          • Bloom Filter
      • DApp Kit
        • v2
          • Installation
          • React
            • Installation
            • Usage
          • Vanilla JS
            • Installation
            • Usage
          • Core
            • Installation
            • Usage
          • Theme Variables
          • i18n
        • v1
          • Installation
          • React
            • Installation
            • Usage
          • Vanilla JS
            • Installation
            • Usage
          • Core
            • Installation
            • Usage
          • Theme Variables
          • i18n
          • Node Polyfills
          • V0 to V1
        • v0
          • Installation
          • Usage
          • React
            • Installation
            • Usage
          • Vanilla (UI)
            • Installation
            • Usage
          • Styles (UI)
          • i18n
      • DevPal
      • Web3-Providers-Connex
        • Installation
        • Usage
      • Connex
        • Installation
        • API Specification
    • Frameworks & IDEs
      • Hardhat
      • Remix
    • Built-in Contracts
    • VORJ
    • Useful Links
  • How to contribute
Powered by GitBook
On this page
  • Proof of Authority (PoA)
  • When
  • Who
  • AM Status Updating
  • Trunk

Was this helpful?

  1. Introduction to VeChain
  2. About the VeChain blockchain

Consensus Deep Dive

A deeper dive into our PoA consensus mechanism.

PreviousAbout the VeChain blockchainNextGovernance

Last updated 11 months ago

Was this helpful?

Proof of Authority (PoA)

Designing a consensus algorithm for a public blockchain network is a critical decision that influences how participants agree on the blockchain's growth and embodies the governance model of the network. VeChainThor implements the PoA consensus algorithm, aligning with our governance philosophy:

"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 Buffett

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Δ=10, which is based on our estimation of the usage of VeChainThor. Let t0t_{0}t0​ be the timestamp of the genesis block. The timestamp of the block with height h>0h > 0h>0 and tht_{h}th​,must satisfy h=t0+mΔ_h = t_{0} + m\Deltah​=t0​+mΔ where m∈N+m \in \mathbb{N}^{+}m∈N+ and ⩾h\geqslant h⩾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)(h,t) with height hhh(uint32) and timestamp ttt(uint64). Here ttt must satisfy (t−t0)modΔ=0(t - t_{0})mod\Delta = 0(t−t0​)modΔ=0. We first define the DPRP to generate a pseudo-random number γ(h,t)\gamma(h,t)γ(h,t) as:

AM Status Updating

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.

γ(h,t)=DPRP(h,t)=hash(h∘t)\gamma(h,t) = DPRP(h,t) =hash(h \circ t)γ(h,t)=DPRP(h,t)=hash(h∘t)

where ∘\circ∘ denotes the operation that concatenates two byte arrays.

Let ABA_{B}AB​ denote the sorted set of AMs with the “active” status in the state associated with block BBB. 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}AB​. To verify whether aaa is the legitimate AM for producing B(h,t)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 aAB(h,t)a​=sort(APA(Bh,t))​)∪a

where PA(⋅)PA(\cdot)PA(⋅) returns the parent block. We then compute index ia(h,t)i^{a}(h,t)ia(h,t)as:

ia(h,t)=γ(h,t)mod∥AB(h,t)a∥i^{a}(h,t) = \gamma(h,t) mod \parallel A^{a}_{B(h,t)} \parallelia(h,t)=γ(h,t)mod∥AB(h,t)a​∥

AM aaa is the legitimate producer of B(h,t)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)] = aAB(h,t)a​[ia(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.

Given the latest block B(h,t1)B(h,t_{1})B(h,t1​) and its parent B(h−1,t0)B(h - 1,t_{0})B(h−1,t0​), for any t0<t<t1t_{0} < t < t_{1}t0​<t<t1​ and (t−t0)modΔ=0(t - t_{0}) mod \Delta = 0(t−t0​)modΔ=0, the system computes AM ata_{t}at​ such that

AB(h,t1)at[iat(h,t)]=atA^{a_{t}}_{B(h,t_{1})}[i^{a_{t}}(h,t)] = a_{t}AB(h,t1​)at​​[iat​(h,t)]=at​

and mark ata_{t}at​ as "inactive" in the state associated with B(h,t1)B(h,t_{1})B(h,t1​). In addition, the system always sets the status of the AM that generates B(h,t1)B(h,t_1)B(h,t1​) as "active". Note that we set all the AMs as "active" from the beginning.

To do that, we compute the accumulated witness number (AWN), π\piπ, for block B(h,t)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πB(h,t)​=πPA(B(h,t))​+∥AB(h,t)​∥

with πBgenesis=0\pi_{B_{genesis}} = 0πBgenesis​​=0. Since ∥AB(h,t)∥\parallel A_{B(h,t)} \parallel∥AB(h,t)​∥ computes the number of AMs with “active” status associated with B(h,t)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)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}<B1​ and B2\mathcal{B}_{2}B2​ with their latest blocks B1(h1,t1){B}_{1}(h_{1},t_{1})B1​(h1​,t1​) and B2(h2,t2){B}_{2}(h_{2},t_{2})B2​(h2​,t2​), respectively, we first calculate their AWNs πB1\pi_{B_{1}}πB1​​ and πB2\pi_{B_{2}}πB2​​. The system then makes the following decision: choose B1{B_{1}}B1​ as the trunk if πB1>πB2\pi_{B_{1}} > \pi_{B_{2}}πB1​​>πB2​​, or B2B_{2}B2​ if πB1<πB2\pi_{B_{1}} < \pi_{B_{2}}πB1​​<πB2​​. In case πB1=πB2\pi_{B_{1}} = \pi_{B_{2}}πB1​​=πB2​​, choose B1B_{1}B1​if h1<h2h_{1} < h_{2}h1​<h2​ or B2B_{2}B2​ if h1>h2h_{1} > h_{2}h1​>h2​. If h1=h2h_{1} = h_{2}h1​=h2​, keep the current trunk.