Get Started

Introduce about QBFT

GoQuorum implements the QBFT proof of authority consensus protocol (opens in a new tab). QBFT is the recommended enterprise-grade consensus protocol for private networks. You can create a private network using QBFT (opens in a new tab).

In QBFT networks, approved accounts known as validators validate transactions and blocks. Validators take turns to create the next block. Before inserting a block onto the chain, a super-majority (greater than or equal to 2/3) of validators must first sign the block.

Existing validators propose and vote to add or remove validators (opens in a new tab). Adding or removing a validator requires a majority vote (greater than 50%) of validators.

Configure QBFT consensus

Genesis file

To use QBFT, GoQuorum requires a genesis file (opens in a new tab). The genesis file defines properties specific to QBFT and to your specific network.

Example QBFT genesis file

  {
    "config": {
      "chainId": 1337,
      "homesteadBlock": 0,
      "eip150Block": 0,
      "eip150Hash": "0x0000000000000000000000000000000000000000000000000000000000000000",
      "eip155Block": 0,
      "eip158Block": 0,
      "byzantiumBlock": 0,
      "constantinopleBlock": 0,
      "qbft": {
        "epochlength": 30000,
        "blockperiodseconds": 2
        "requesttimeoutseconds": 4
        "policy": 0,
        "ceil2Nby3Block": 0,
        "validatorcontractaddress": "0x0000000000000000000000000000000000007777"
      },
      "txnSizeLimit": 64,
      "maxCodeSize": 0,
      "isQuorum": true
    },
    "nonce": "0x0",
    "timestamp": "0x5f1663fc",
    "extraData": "0xf87aa00000000000000000000000000000000000000000000000000000000000000000f8549493917cadbace5dfce132b991732c6cda9bcc5b8a9427a97c9aaf04f18f3014c32e036dd0ac76da5f1894ce412f988377e31f4d0ff12d74df73b51c42d0ca9498c1334496614aed49d2e81526d089f7264fed9cc080c0",
    "gasLimit" : "0xf7b760",
    "difficulty": "0x1",
    "mixHash": "0x63746963616c2062797a616e74696e65206661756c7420746f6c6572616e6365",
    "coinbase": "0x0000000000000000000000000000000000000000",
    "alloc": {},
    "number": "0x0",
    "gasUsed": "0x0",
    "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000"
  }

The properties specific to QBFT are in the qbft section:

• epochlength - Number of blocks that should pass before pending validator votes are reset.
• blockperiodseconds - The minimum block time, in seconds.
• requesttimeoutseconds - The timeout for each consensus round before a round change, in seconds.
• policy - Proposer selection policy, which is 0 (Round Robin) or 1 (Sticky). 'Round Robin' is where validators take turns in proposing blocks, and 'Sticky' is where a single validator proposes blocks until they go offline or are unreachable.
• ceil2Nby3Block - Sets the block number from which to use an updated formula for calculating the number of faulty nodes. For new networks, we recommended setting this to 0 to use the updated formula immediately.
• validatorcontractaddress - Address of the validator smart contract. Required only if using a contract validator selection. This option can also be used in the transitions configuration item if swapping validator management methods in an existing network.
• extraData - RLP encoded string with a list of validators. RLP encoding is a space-efficient object serialization scheme used in Ethereum.

Block time

When the protocol receives a new chain head, the block time (blockperiodseconds) timer starts. When blockperiodseconds expires, the round timeout (requesttimeoutseconds) timer starts and the protocol proposes a new block. The default is 1 second.

If requesttimeoutseconds expires before adding the proposed block, a round change occurs, with the block time and timeout timers reset. The timeout period for the new round is two times requesttimeoutseconds. The timeout period continues to double each time a round fails to add a block.

Usually, the protocol adds the proposed block before reaching requesttimeoutseconds. A new round then starts, resetting the block time and round timeout timers. When blockperiodseconds expires, the protocol proposes the next new block.

Add and remove validators

QBFT provides two methods to manage validators:

• Block header validator selection (opens in a new tab) - Existing validators propose and vote to add or remove validators using the JSON-RPC API methods.

• Contract validator selection (opens in a new tab) - Use a smart contract to specify the validators used to propose and validate blocks.

You can use transitions to swap between block header validator selection and contract validator selection in an existing network.

For block header validator selection, initial validators are configured in the genesis file's extraData property, whereas the initial validators when using the contract validator selection method are configured in the genesis file's validatorcontractaddress section.

Minimum number of validators

QBFT requires four validators to be Byzantine fault tolerant. Byzantine fault tolerance is the ability for a blockchain network to function correctly and reach consensus despite nodes failing or propagating incorrect information to peers.

Add and remove validators using a smart contract

Users can create their own smart contracts to add or remove validators based on their organizational requirements. View the example smart contract for more information on how to create and deploy the smart contract.

You can pre-deploy the validator smart contract in a new QBFT network by specifying the contract details in the genesis file.

Reference from Consensys Quorum (opens in a new tab)