Harmony
Support ForumGithubTelegramDiscord
  • Welcome
  • 🎶General
    • Introduction
      • What is Harmony?‌
      • Roadmap
      • Strategy & Architecture
      • Study Materials
      • FAQ
    • Technology
      • Key Features
      • Randomness
      • Sharding
      • Consensus
      • Effective Proof-of-Stake
      • Tokenomics
      • Transactions
    • LayerZero Bridge
      • Important Notice
      • Bridge tutorial
      • FAQ
        • What token will I get after the bridge
        • How to find a bridged token address
    • Ecosystem
      • Wallets
        • 1Wallet
        • Gnosis Safe
        • Hardware Wallets
          • Trezor
          • Ledger Nano
            • Ledger with Metamask
            • Download & Setup
            • Ledger with HMY CLI
            • Ledger with Staking Dashboard
              • Sign In With Ledger
              • Sending transactions via Ledger
              • Staking Transactions via Ledger
          • Safepal
            • Download & setup
            • Create/import account
            • Send transaction
        • Browser Extension Wallets
          • Metamask
            • Installing MetaMask
            • Adding Harmony
            • Create a New Account
            • Sending & Receiving
            • Adding Custom Harmony Tokens
            • Import an Account
          • Math Wallet
            • Download & Setup
            • Create/Import/Export Wallet
            • Sending Transactions
            • Staking
            • Collecting Rewards
            • Undelegating
          • Harmony Chrome Extension Wallet
        • Desktop Wallets
          • Guarda Wallet
          • Staking4All Wallet
        • Mobile Wallets
          • Metamask Wallet
          • Blits Wallet
          • Cobo Wallet
          • Frontier Wallet
          • Guarda Wallet
          • Infinity Wallet
          • ONTO Wallet
          • Sef Wallet
          • Trust Wallet
          • Trustee Wallet
        • Web Wallets
          • Guarda Wallet
        • HMY CLI (Harmony Command Line Interface)
          • Download & Setup
          • Create or Import Wallet
          • Sending Transactions
          • Staking Transactions
          • Querying Balances
          • Querying the Blockchain
          • List of Transaction Error Messages
          • Cookbook
          • Other CLI References
      • DApps
        • User Guide
        • DeFi
          • Sushi
          • Onsen
        • CLI 1Wallet User Guide
        • Media
          • Timeless
        • FAQ
        • NFTs
      • Partners
        • Exchanges
        • Fiat Gateways
        • DeFi Protocols
      • Integrations
      • Cross-Border Finance
      • DAOs
        • Components & Tools
          • Snapshot
        • Community DAO
        • Validator DAO
        • Developer DAO
    • Community
  • 🏗️Developers
    • Getting Started
      • Network & Faucets
      • List of RPC Providers
      • Remix IDE
      • Dev Environment Setup
      • Ethereum Compatibility
    • Deploying on Harmony
      • Using Remix
        • Ethereum Remix
        • Harmony Remix
      • Using Truffle
      • Using Hardhat
      • Using Web3
      • Using Harmony-JS
        • Setup
        • Compile & Deploy
        • Demo: Deploying an Ethereum Smart Contract on Harmony
      • Deploy HRC20
      • Smart Contract Verification
    • SDK
      • Web3.js
        • Using Web3.js to Send Transactions on Harmony
        • Find the last transaction
      • JavaScript SDK
      • Go CLI
      • Java SDK
      • Python SDK
      • Harmony Ethers.js Wrapper
    • API
      • Methods
        • Account Methods
          • hmy_getBalanceByBlockNumber
          • hmy_getTransactionCount
          • hmy_getBalance
        • Filter Methods
          • hmy_getFilterLogs
          • hmy_newFilter
          • hmy_newPendingTransactionFilter
          • hmy_newBlockFilter
          • hmy_getFilterChanges
          • hmy_getLogs
        • Transaction Related Methods
          • hmy_getStakingTransactionByBlockHashAndIndex
          • hmy_getStakingTransactionByBlockNumberAndIndex
          • hmy_getStakingTransactionByHash
          • hmy_getCurrentTransactionErrorSink
          • hmy_getPendingCrossLinks
          • hmy_getPendingCXReceipts
          • hmy_getCXReceiptByHash
          • hmy_pendingTransactions
          • hmy_sendRawStakingTransaction
          • hmy_getTransactionsHistory
          • hmy_sendRawTransaction
          • hmy_getTransactionReceipt
          • hmy_getBlockTransactionCountByHash
          • hmy_getBlockTransactionCountByNumber
          • hmy_getTransactionByHash
          • hmy_getTransactionByBlockNumberAndIndex
          • hmy_getTransactionByBlockHashAndIndex
          • hmy_getBlockByNumber
          • hmy_getBlockByHash
          • hmy_getBlocks
        • Contract Related Methods
          • hmy_estimateGas
          • hmy_getStorageAt
          • hmy_call
          • hmy_getCode
        • Protocol Related Methods
          • hmy_isLastBlock
          • hmy_epochLastBlock
          • hmy_latestHeader
          • hmy_getShardingStructure
          • hmy_blockNumber
          • hmy_syncing
          • hmy_gasPrice
          • net_peerCount
          • hmy_getEpoch
          • hmy_getLeader
        • Staking Related Methods
          • hmy_getCirculatingSupply
          • hmy_getTotalSupply
          • hmy_getStakingNetworkInfo
          • hmy_getAllValidatorInformation
          • hmy_getAllValidatorInformationByBlockNumber
          • hmy_getCurrentUtilityMetrics
          • hmy_getDelegationsByValidator
          • hmy_getDelegationsByDelegatorAndValidator
          • hmy_getDelegationsByDelegator
          • hmy_getValidatorMetrics
          • hmy_getMedianRawStakeSnapshot
          • hmy_getElectedValidatorAddresses
          • hmy_getAllValidatorAddresses
          • hmy_getCurrentStakingErrorSink
          • hmy_getValidatorInformation
          • hmy_getValidators
          • hmy_getSignedBlocks
          • hmy_isBlockSigner
          • hmy_getBlockSigners
        • Tracing Methods
          • trace_block
          • trace_transaction
      • Sample Code
    • Tools
      • Harmony VRF
      • The Graph
      • Envio
      • Ganache
        • Harmony Ganache
      • Harmony-React
      • Oracles
        • Band Protocol
      • Smart Contract Verification
    • Tutorials
      • Deploying HRC20
      • Deploying HRC721/NFT
      • The Graph - Subgraphs
        • Building & Deploying Subgraph (local node)
      • Using Band Oracle
      • Using Crosschain API
        • Scripts
        • Testing
        • Webserver
      • Using Web3.py & Pyhmy
      • Using IPFS & Filecoin
        • Using IPFS
        • Using NFT.storage
      • Indexing HRC20 with Envio
      • Building a Simple Metaverse Contract
      • Building a Simple Bridge with Ethereum
      • Staking for Multisig
    • DApp Examples
      • DApp Samples
      • Games
        • Harmony Puzzle
      • Cross-Chain
      • DeFi
      • Hackathons
        • DevPost
        • Hack the Horizon
      • Others
    • Wallets
      • Metamask
        • Interacting With Metamask
        • Using Metamask with Harmony Smart Contracts
        • Add or Switch to Harmony chain on Metamask
      • Harmony Chrome Extension Wallet
      • Math Wallet
      • WalletConnect
    • Harmony Stack and Projects
  • 🌏Network
    • Governance
      • Network Governance
        • Voting via Governance App
        • Voting via HMY CLI
      • HRC-20 Governance
      • FAQ
    • Validators
      • Terms & Concepts
        • Validator, BLS key, Instance
          • Shard Assignment
        • Slots Bidding and Election
        • Effective Proof-of-Stake
        • Block Reward
        • Epoch Transition
        • Slashing
        • Undelegation
      • Server Setup
        • Requirements
        • Cloud Guides
          • Digital Ocean
          • Vultr
          • AWS
          • Google Cloud
        • Raspberry Pi Guide
      • Node Setup
        • 1. HMY CLI Download
        • 2. Setting up BLS Keys
        • 3. Syncing DB
        • 4. Installing & Updating
          • Installing A Node
            • Using Node Binary
            • (Deprecated) Using AutoNode
              • Install & Run
              • Update
              • Monitor
              • BLS Key Management
              • Collect Rewards
              • Maintenance
              • Troubleshoot
              • Extra
            • (deprecated) Using Node.sh
          • Upgrading A Node
            • Using Node Binary
            • Using AutoNode (deprecated)
            • Using Node.sh (deprecated)
          • Checking A Node
      • Creating A Validator
      • Managing A Validator
        • Checking Validator Information
        • Changing Validator Information
        • Delegating To A Validator
        • Undelegating From A Validator
        • Check Your Delegations
        • Collecting Rewards
        • Adding A Validator Logo
      • Staking Dashboard Basics
      • Validator Information Terms
      • Validator Security Tips
      • Slashing and Uptime
      • Monitoring
        • Node Sync
        • Prometheus & Grafana
        • Network Status
      • Troubleshooting
        • Why am i not Elected?
        • Frequently Asked Questions (FAQ)
      • Tools
        • Telegram Bots
        • Dashboards
        • Reward Calculators
        • Text User Interface (TUI)
        • HMY Bidder
        • Mobile Apps
          • One Validator Dashboard
          • Termux
    • Delegators
      • Introduction
      • Staking
        • Via Browser
          • Staking Dashboard
          • Staking Transactions
          • Sending Transactions
        • Via Mobile
        • FAQ
      • Redelegation
      • Informational Videos
Powered by GitBook
On this page
  • Fast Byzantine Fault Tolerance (FBFT)
  • Synchronous View Change

Was this helpful?

Export as PDF
  1. General
  2. Technology

Consensus

PreviousShardingNextEffective Proof-of-Stake

Last updated 4 years ago

Was this helpful?

Fast Byzantine Fault Tolerance (FBFT)

The consensus algorithm is a key component of any blockchain. It determines the security and performance of a blockchain and is often referred to as the "engine" of a blockchain. Harmony’s consensus algorithm is called Fast Byzantine Fault Tolerance (FBFT), which is an innovative upgrade on the famous PBFT algorithm. FBFT is one order of magnitude faster and more scalable than PBFT because BLS (Boneh–Lynn–Shacham) aggregate signature is used to significantly reduce the communication cost. Specifically, FBFT allows at least 250 validators to reach consensus within 2 seconds.

For every round of consensus in FBFT, one validator serves as the “leader” and there are three phases: the announce phase, the prepare phase and the commit phase. In the announce phase, the leader proposes a new block and broadcasts the block hash to all of the validators. In the prepare phase, validators verify the message and sign on the block hash, as well as sending the signature back to the leader. The prepare phase finishes when signatures with more than 2/3 of the voting power are collected. After that, the leader aggregated the collected signatures into a O(1)-sized BLS aggregate signature and then broadcast it with the whole block to start the commit phase. The commit phase involves validators verifying the block and doing a similar signing process as the prepare phase (i.e. 2/3 voting power collection). The consensus is reached after the commit phase is done. This whole process can be done within 2 seconds in mainnet.

Network communication during a single round of consensus.

Specifically, Harmony’s FBFT consensus involves the following steps:

  1. The leader constructs the new block and broadcasts the block hash to all validators. This is called the “announce” phase.

  2. The validators check the validity of the message, sign the block hash with a BLS signature, and send the signature back to the leader.

  3. The leader waits for valid signatures with more than 2/3 voting power from validators (including the leader itself) and aggregates them into a BLS aggregate signature. Then the leader broadcasts the new block and the aggregated signature along with a bitmap indicating which validators have signed. Together with Step 2, this concludes the “prepare” phase.

  4. The validators check that the aggregate signature has at least 2/3 of total voting power, verify the new block, sign the received block from Step 3, and send it back to the leader.

  5. The leader waits for valid signatures with more than 2/3 voting power (can be different signers from Step 3), aggregates them together into a BLS aggregate signature, and creates a bitmap for all the signers. Finally, the leader commits the new block with the aggregate signatures and bitmaps into local DB, and broadcasts the aggregate signature and bitmap for all validators to confidently commit the block too. Together with Step 4, this concludes the “commit” phase.

Synchronous View Change

One of the drawbacks of BFT-based consensus is the potential stallment of the consensus if the leader is malicious. The solution to this in PBFT algorithm is the additional view change protocol on top of the consensus which is able to switch leaders when the consensus is stalled. The view change in PBFT works well in the traditional distributed system setting but it fails in the more complicated blockchain space. Particularly, the view change in PBFT is relying on the timeout mechanism where the timer is triggered based on the live progress of the consensus. This works fine if the nodes are always online and are in sync with the consensus progress. However, this won’t be true in the real world situation where nodes can be down for extended time or restarted due to machine crash, which will make the nodes having inconsistent view IDs and not able to make progress in the view change.

We solve this problem by using an improved version of the view change protocol that’s fully synchronous based on the local clock rather than assuming the liveness of the nodes. Specifically, instead of setting the validator’s view ID based on the live progress of the consensus, the view ID is calculated based on the elapsed time of the last successfully committed block’s timestamp. Of course, there is no global clock to rely on in the calculation of elapsed time. Each validator will use their own local clock for that. However, this is totally fine as long as more than 2/3 of the validators maintain a relatively accurate local clock that’s not drifting by a few seconds. This is achievable in the protocol to make validators to periodically synchronize its local clock with NTP time.

This improvement makes our view change protocol fully robust and functional as long as more than 2/3 of the honest validators are online, guaranteeing the liveness of the FBFT consensus. Besides, BLS aggregate signatures are also used in the view change protocol to reduce network communication cost, making it a very efficient process which takes a few seconds to finish.

🎶