Introduction to the consensus algorithm mechanism (IBFT) of the underlying blockchain platform PlatONE and its implementation method

I. Overview

The consensus in the blockchain alliance chain "PlatONE" that supports privacy computing jointly created by Wanxiang Blockchain and ecological partners is a highly optimized BFT-type consensus algorithm with a fault tolerance rate of 1/3. While the key features of instant finality), it greatly improves the degree of decentralization. Consensus can ensure that the blocks on the chain are deterministic, that is to say, the chain will not fork, and every valid block will be inserted into the chain.

 

PlatONE's consensus supports more than 100 consensus nodes. Compared with some other common BFT consensus, the performance of PlatONE consensus has been significantly improved. With 10 consensus nodes, TPS is close to 1000.

 

The relevant parameters of the consensus operation of PlatONE can be flexibly configured, and the set of consensus nodes in the consensus of PlatONE can be flexibly updated. In the near future, it is planned to support the pluggability of consensus and the auditability of consensus.

 

PlatONE consensus is conducted on round. On a specific round, a block producer node is selected through a preset strategy. The selection strategy of block producer node currently supports two types: round robin and sticky proposer.

 

After the block producer node proposes a block, each consensus node reaches a consensus. The consensus is divided into three stages, of which the last two stages are voting stages to ensure Safety. The PlatONE consensus uses a round change mechanism combined with a locking and unlocking mechanism to ensure the liveness of the consensus. By optimizing the unlocking mechanism, the consensus deadlock problem existing in many well-known projects in the industry has been solved.

 

The PlatONE consensus will generate a consensus proof for each block on the chain, that is, a valid signature of each consensus node for the block, so the block can be self-verified and can also support light nodes.

 

A block that does not contain transactions is called an empty block. PlatONE currently does not support empty blocks, that is, all blocks on the chain contain transactions. The mechanism of not emptying blocks can effectively save the storage space occupied by the blockchain.

 

The following describes the consensus algorithm in PlatONE in detail.

 

2. Consensus Node Selection Mechanism

• Node type and state

Nodes are divided into two types: consensus nodes (validators) and observer nodes. For consensus nodes, there are two states: normal and isolated. Only consensus nodes in a normal state can participate in consensus and package blocks.

 

• Consensus Node Selection Mechanism

The NodeManager system contract is designed to store and manage node information. You can apply to register a consensus node through the NodeRegister system contract. After the approval, the type of the application node will be updated to a consensus node, and the updated node information will be stored in the node management contract and can be queried.

 

The administrator can update the status of the consensus node as needed to decide whether the consensus node can participate in the consensus.

 

• Obtaining a set of consensus nodes

Every time a new block is generated on the chain, the latest node information in the node management contract will be read, and the latest set of consensus nodes will be saved and read and used by the consensus engine.

 

3. Consensus process

3.1. Normal Process

3.1.1. Definitions

Below are definitions of some important terms or concepts.

• +2/3 Means "more than 2/3".
• NEW ROUND: A new block proposer will be determined in the new round (for example, the round robin algorithm is used). At the beginning of the new round, each consensus node waits to receive PRE-PREPAREmessages.
• PRE-PREPARED: The validator node receives the message and enters this state after PRE-PREPARE broadcasting the message. PREPAREAfter that, the validator node waits for and receives +2/3the PREPARE OR message. (Note: Some validator nodes will broadcast the message directly after receiving the message because they are locked on the proposed block . Therefore, the validator node here waits and receives the or message) COMMIT PRE-PREPARE COMMIT PREPARE  COMMIT 
• PREPARED: The validator node receives the +2/3message and enters this state after PREPAREbroadcasting the message at the same time . COMMITAfter that, the validator node waits for and receives +2/3the message. COMMIT 
• COMMITTED+2/3: The message received by the validator node COMMIT enters this state. At this point, the proposed block can be inserted into the blockchain
• FINAL COMMITTED: After the new block is successfully uploaded to the chain, the validator node enters this state. At this point, the node is ready to enter the next round
• ROUND CHANGE: messages the validator node is waiting to receive +2/3for the same proposal roundROUND CHANGE

 

3.1.2. Rules for selecting proposer

• Round robin algorithm (currently used)

• Sticky proposer

 

3.1.3. Consensus process (three-phase protocol)

The consensus process consists of three phases: PRE-PREPARE, and , also known as the three-phase protocol. PREPARE COMMIT

• PRE-PREPAREStages: Each time a new round is entered, the first of the three stages, the stage, begins PRE-PREPARE. In this phase, the Proposer (block proposer) node generates a proposed block and broadcasts it to all validator nodes. Then the Proposer node enters the PRE-PREPARED state. Other validator nodes enter the state after receiving valid messages. PRE-PREPARE PRE-PREPARED 
• PREPAREPhase: In this phase, the validator node broadcasts PREPAREmessages to other validator nodes and waits for +2/3 a valid message to be received to enter the state. PREPARE PREPARED
• COMMITPhase: In this phase, the validator node broadcasts COMMIT messages to other validator nodes and waits for +2/3 a valid message to be received to enter the state. COMMIT  COMMITTED 

 

After the above three stages are completed, the entire consensus process is successfully completed.

 

3.1.4. State Migration:

The following figure describes the state transition process of PlatONE's consensus process.

 

 

• NEW ROUND -> : (corresponds to the stage in the section )  PRE-PREPARED2.1.3PRE-PREPARE
  • Proposer collects transactions from txpool .
  • Proposer generates a proposed block and broadcasts it to other validator nodes, and then enters the PRE-PREPARED state.
  • After each validator node receives a PRE-PREPARE message that meets the following conditions, it enters the PRE-PREPAREDstate:
  • Proposed blocks come from valid proposer nodes.
  • block header is valid
  • The sequence (height) of the proposed block is consistent with the current state of the round and validator nodes.
  • Validator nodes broadcast PREPARE messages to other validator nodes.
• PRE-PREPARED -> : (corresponds to the stage in the section )  PREPARED2.1.3PREPARE
  • +2/3 The valid message received by the Validator enters the state. A valid message needs to meet the following conditions: PREPARE PREPARED
  • sequence and round are consistent
  • Block Hash Consistent
  • The message comes from a known validator node
  • The Validator  node PREPAREDbroadcasts a COMMITmessage after entering the state.
• PREPARED -> : (corresponds to the stage in the section )  COMMITTED2.1.3COMMIT
  • +2/3 The valid message received by the ValidatorCOMMIT  enters the COMMITTED state. A valid message needs to meet the following conditions:
  • sequence and round are consistent
  • Block Hash Consistent
  • The message comes from a known validator node
• COMMITTED ->:  FINAL COMMITTED
  • The Validator node adds +2/3the committed seal to the extraDatafield of the block header and attempts to insert the block into the blockchain.
  • After the blockchain is successfully uploaded, the Validator node enters the FINAL COMMITTED state.
• FINAL COMMITTED ->:  NEW ROUND
  • Each Validator node selects a new proposer node and starts a new round timer.

 

3.2. Round change mechanism

The following three conditions will trigger ROUND CHANGE:

• Round change timer timeout triggers
• invalid PREPREPAREmessage
• Blockchain failed

 

3.2.1. Process of round change

• When a validator node detects that one of the above round change trigger conditions is met, it will broadcast a ROUND CHANGEmessage containing the target round value to be changed, while waiting to receive messages from other validator nodes ROUND CHANGE. The value of the target round is chosen based on the following conditions:
• If the validator node has received messages from other peer nodes , it selects the largest value from the round values ​​contained in all the reached messages. ROUND CHANGE F + 1 ROUND CHANGE 
• Otherwise, set the value of the target round to: the current round value + 1
• Any time a validator node receives F + 1 a message with the same target round value , it compares that round value to its own. If the received value is greater, the validator node broadcasts the message again, and the round value in the message is the same as the received one. ROUND CHANGE ROUND CHANGE 
• Once the validator node receives 2F + 1 a message with the same round value , it ends the round change cycle, determines the new proposer node, and then enters the state. ROUND CHANGE NEW ROUND
• Another condition that triggers the validator node to exit the round change cycle is that it is synchronized to the verified block through the p2p synchronization mechanism.

 

3.3. Block Locking Mechanism

• Trigger condition for locked block

The meaning of the node 锁定in the block means that the current node Bcan only vote on the information of the block . When a node receives a vote for a block , it enters the state. At this point, the node is locked, waiting to receive voting information from other nodes, and the locked round is the current round;round number R Bcommit+2/3BPREPAREPREPAREDcommit

• The mechanism for locking blocks

In addition to the consensus start stage, when the synchronization data of the higher block is received, or the block is successfully generated at the current height and a consensus is reached, the lock is reset to the unlocked state, and a new round of higher blocks is started. consensus. Triggered if a vote for the +2/3specified round and block is not received during the lock-in period . In addition, in certain scenarios, the original locking and unlocking mechanism will still have deadlocks, and we have also optimized the relevant unlocking implementation at the code level. For details, please refer to "2. Optimization of Istanbul's lock and unlock mechanism".commitROUND CHANGE

 

3.4. The current storage mechanism of Consensus proof

Before the block is put on the chain, each validator node needs to collect 2F + 1a committed seal to form a consensus proof. Once the validator node receives enough committed seals, it stores it in the field of the block header in the extraDatafield in the IstabulExtra structure, CommittedSeal recalculates the extraDatafield, and inserts the block into the blockchain.

The calculation process of Committed seal is as follows:

• Calculation of Committed seal:

Each validator node uses its private key to sign the result of the commit message code on the block hash cascade, COMMIT_MSG_CODEand the signature obtained is the Committed seal:

• Committed seal: SignECDSA(Keccak256(CONCAT(Hash, COMMIT_MSG_CODE)), PrivateKey)
• CONCAT(Hash, COMMIT_MSG_CODE)COMMIT_MSG_CODE : Concatenate block hash and commit message code

• PrivateKey: The private key of the validator node for signing

• The above mentioned extraDatais a field of the block header whose data composition is: EXTRA_VANITY | ISTANBUL_EXTRA, where | is used to represent a fixed index (not an actual separator character) separating EXTRA_VANITY and ISTANBUL_EXTRA.

• The type definition of the IstabulExtra structure is as follows:

 

  type IstanbulExtra struct {
  Validators    []common.Address    //Validator addresses
  Seal          []byte          //Proposer seal 65 bytes
  CommittedSeal [][]byte            //Committed seal, 65 * len(Validators) bytes
  }

 

The meaning of each field is as follows: + Validators: List of validator nodes participating in the consensus + Seal: Proposer node's signature on the block, with a length of 65 bytes + CommittedSeal: Used to store the committed seal list collected by the validator node.

{{o.name}}

{{m.name}}