Plian
English
English
  • Overview
  • Links
  • Downloads
  • FAQ
    • Node Status
    • Full Balance
    • Flow and FAQ on Becoming a Validator
    • Delegation
    • Staking Rewards
    • Monitor
    • PIScan
    • PIWallet
    • Cross-Chain Transactions
    • DApps
  • About The Blockchain
    • Multichain Framework
    • PDBFT 2.0 Consensus Algorithm
    • Validator Nodes
    • Building with Plian
  • Using The Blockchain
    • Overview
    • Delegating or Staking PI
    • Validator Node Guides
      • Express Node Setup Guide
      • Setting Up a Validator Node
      • Registering Your Node as Validator
      • Submitting Your Vote as Validator
      • Revealing Your Vote
      • Removing Your Node From the Candidate List
      • Alternate Installation Instructions
        • Building From the Source
        • Running Pchain in Docker
        • Installation Instructions for Ubuntu
        • Installation Instructions for Mac OS X
        • Installation Instructions for Windows 10
      • What is FullBalance
    • Token Swaps
    • Plian Javascript Console
    • PIwallet
      • Desktop Wallet
        • Light Wallet Mode
        • Local Node Mode
      • Mobile Wallets
      • How to Deploy a Smart Contract
    • PMetamask
    • MetaMask
      • How to import PIwallet address to MetaMask?
      • How to connect Metamask to Plian
      • How to import wallet address from MetaMask into PIWallet
      • How to deploy smart contract on Plian via Metamask + Remix
    • Advanced Features
      • Command Line Options
      • Management APIs
      • JSON RPC API
      • How to Sync and Run Testnet
    • How to buy Plian $PI
  • For Developers
    • PWeb3 Javascript API
    • How to Create Your Own Subchain
    • Writing Smart Contracts With Solidity
      • Introduction to Smart Contracts
      • Installing the Solidity Compiler
      • Solidity by Example
      • Solidity in Depth
        • Layout of a Solidity Source File
        • Structure of a Contract
        • Types
        • Units and Globally Available Variables
        • Expressions and Control Structures
        • Contracts
        • Solidity Assembly
        • Miscellaneous
      • Security Considerations
      • Resources
      • Using the compiler
      • Contract Metadata
      • Contract ABI Specification
      • Yul
      • Style Guide
      • Common Patterns
      • List of Known Bugs
      • Contributing
      • Frequently Asked Questions
      • LLL
      • Index
Powered by GitBook
On this page

Was this helpful?

  1. About The Blockchain

PDBFT 2.0 Consensus Algorithm

PDBFT2.0 is a Byzantine Fault Tolerance (BFT) protocol deployed in Plian, a multi-blockchain platform that is capable of processing over 100k smart contract transactions per second in a production environment.

PDBFT2.0 is based on the classic PBFT protocol, with 3 major improvements:

  • Linear Communication: PDBFT2.0 achieves linear worst-case communication volume, in contract to PBFT’s O(n4)

  • Random Leader Selection: The leader of each round in PDBFT2.0 is selected by a verifiable random function (VRF), which prevents the leader from being predictably attacked

  • Low Overhead: PDBFT2.0 involves only a single round of voting instead of two in PBFT, which reduces both communication overhead and confirmation time.

PBFT is a protocol with three phases: pre-prepare, prepare and commit. In phase prepare and commit, each validator has to broadcast its vote for the proposed block. Upon receiving 2f+1 commit votes, each validator finalizes the block. Due to the broadcasting of votes, the complexity of communication grows as the square of the number of nodes, O(n^2). To reduce this, PDBFT2.0 establishes a leader for each voting round to collect votes from all validators. In addition, PDBFT2.0 adopts BLS threshold signatures to achieve linear communication. An (n,t)-threshold signature on a message m is a single, constant-sized aggregate signature that passes verification if and only if at least t out of the n participants sign m. Note that the verifier does not need to know the identities of the t signers. Each collector derives an (n,2f+1)-threshold signature after collecting 2f+1 votes. The threshold signature can be seen as a single signature with constant size. After that, the collector broadcasts the threshold signature and each validator can confirm that more than 2f+1 validators have voted for the proposed block via verify threshold signature.

In classic PBFT, two rounds of voting are deployed to guarantee the safety and liveness of protocol. However, in PDBFT2.0, a single round of voting achieves this without losing safety or liveness. And as each vote for the current block specifies the hash of the previous block, each vote is the confirmation for the previous block as well. Hence, the vote for the current block is the prepare-vote and commit-vote for the current block and the previous block at the same time. If more than 2f+1 votes for the current block are collected by a validator, the previous block is finalized at once. Therefore, each block is finalized after just two rounds of voting which ensures the safety of the network.

Similar to PBFT, the view change subprotocol of PDBFT2.0 is triggered when the validators cannot reach consensus in a single round. This can be due to an asynchronous network (e.g., when more than 1/3n nodes are offline), or the presence of malicious collectors/leaders. PDBFT2.0 handles a view change with the Linear View Change (LVC) algorithm. The essence of LVC is that the leader of the next round sends its highest commit certificate instead of all commit certificates, which reduces transmission volume during a view change by a factor of O(n). In PBFT or tendermint, each leader is decided in a round-robin scheduling which can be predicted by the adversary. PDBFT2.0 avoids this situation by selecting collectors (leaders) randomly, using a VRF. A VRF is a pseudo-random generator whose output is verifiable (i.e., on whether a given number is indeed the output of the VRF), random, uniformly distributed, and unpredictable beforehand. With random leaders, the leader of the next round is unpredictable and the adversary can not attack the leader in advance.

PreviousMultichain FrameworkNextValidator Nodes

Last updated 4 years ago

Was this helpful?