PlatONE is a blockchain alliance created by Universal Blockchain and eco Partners to support private computing. The consensus algorithm used by PlatONE is the highly optimized BFT algorithm. This paper introduces the implementation of the consensus algorithm in PlatONE in detail.

1. An overview of the

Consensus in PlatONE is a highly optimized BFT consensus algorithm with a fault tolerance rate of 1/3, which greatly improves the degree of decentralization while retaining the key features of Instant finality. Consensus ensures that the block on the chain is deterministic, that is, the chain does not bifurcate, and that every valid block is inserted into the chain.

PlatONE’s consensus supports over 100 consensus nodes. PlatONE’s consensus is a significant performance improvement over some other common BFT consensus. In the case of 10 consensus nodes, TPS approaches 1000.

The parameters of PlatONE’s consensus run can be flexibly configured, and the set of consensus nodes in PlatONE’s consensus can be flexibly updated. Recent plans support the pluginization of consensus and the auditability of consensus.

PlatONE consensus is conducted on round. On a particular round, a block-maker node is selected using a preset policy. There are two types of block proposer selection policies: Round Robin and sticky proposer.

After the block-maker node proposes a block, all consensus nodes reach a consensus. Consensus is divided into three stages, of which the last two stages are voting stages to ensure Safety. PlatONE consensus uses round change in combination with locking and unlocking to ensure consensus LIVENESS. By optimizing the unlocking mechanism, the problem of consensus deadlock in several well-known projects in the industry is solved.

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

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

The consensus algorithm in PlatONE is described below.

2. Consensus node selection mechanism

  • The type and status of a node

There are two types of nodes: Consensus validator and observer node. For a consensus node, there are two states: normal and isolated. Only consensus nodes in their normal state can participate in consensus and packaged blocks.

  • Selection mechanism of consensus node

NodeManager System contracts are designed to store and manage node information. You can apply for the registration of a consensus node through the NodeRegister system contract. After the approval, the type of the applied node will be updated to a consensus node. 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 required to determine whether the consensus node can join the consensus.

  • The collection of consensus nodes

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

3. Consensus process

3.1. Normal process

3.1.1. Define

Here are some definitions of important terms or concepts.

  • Plus 2/3 means “more than 2/3”.

  • NEW ROUND: A NEW ROUND will determine a NEW block proposer (for example, using the ROUND Robin algorithm). When the NEW ROUND starts, each consensus node waits to receive the pre-prepare message.

  • Pre-prepared: The validator node enters the PREPARED state after receiving the pre-prepare message and broadcasting the PREPARE message. After that, the Validator node waits and receives a +2/3 PREPARE or COMMIT message. (Note: Some Validator nodes are locked in the proposed block and broadcast a COMMIT message after receiving the pre-prepare message. Therefore, the Validator node waits and receives a PREPARE or COMMIT message.)

  • PREPARED: The validator node entered the PREPARED state after receiving a PREPARE message of +2/3 and broadcasting a COMMIT message. After that, the Validator node waits and receives +2/3 COMMIT messages.

  • COMMITTED: The Validator node receives +2/3 COMMIT messages and enters this state. At this point, the proposed block can be inserted into the blockchain

  • FINAL COMMITTED: The Validator node enters this state when a new block is successfully linked. At this point, the node is ready to enter the next round

  • ROUND CHANGE: The Validator waits to receive the ROUND CHANGE message of +2/3 for the same proposed ROUND

3.1.2. Rules for selecting proposer

  • Round Robin algorithm (currently used)

  • Sticky proposer

3.1.3. Consensus Process (Three-stage agreement)

The consensus process consists of three phases: pre-prepare, PREPARE, and COMMIT.

  • PRE-PREPAREStages: Each time a new round is entered, the first of the three stages, i.ePRE-PREPAREPhase. In this phase,ProposerThe block Proposer node generates a proposal block and broadcasts it to all validator nodes. The Proposer node then enters the pre-prepared state. The other Validator node received a validPRE-PREPAREMessage after entering intoPRE-PREPAREDState.
  • PREPAREPhase: In this phase, the Validator node broadcastsPREPAREThe message is sent to the other Validator node and waits for receipt+ 2/3The effectivePREPAREThe message entersPREPAREDState.
  • COMMITPhase: In this phase, the Validator node broadcastsCOMMITThe message is sent to the other Validator node and waits for receipt+ 2/3The effectiveCOMMITThe message entersCOMMITTEDState.

After the completion of the above three stages, the entire consensus process will be successfully completed.

3.1.4. State Migration:

The following diagram depicts the state transition process for PlatONE’s consensus process.

  • NEW ROUND -> PRE-PREPAREDCorrespond to2.1.3In the sectionPRE-PREPAREPhase)
    • Proposer collects transactions from a TXpool.
    • ProposerGenerate a proposal block and broadcast it to the other Validator nodes, then enterPRE-PREPAREDState.
    • eachvalidatorThe node receives packets that meet the following conditionsPRE-PREPAREAfter the message is entered intoPRE-PREPAREDStatus:
    • Proposal blocks come from a valid proposer node.
    • Block header validity
    • The proposed block’s sequence (height) is the same as the current state of the Round and Validator nodes.
    • ValidatorNode broadcastingPREPAREMessage to other Validator nodes.
  • PRE-PREPARED -> PREPAREDCorrespond to2.1.3In the sectionPREPAREPhase)
    • ValidatorTo receive+ 2/3The effectivePREPAREMessage, thereby entering intoPREPAREDState. A valid message must meet the following conditions:
    • Sequence is consistent with round
    • Block hash is consistent
    • The message comes from a known Validator node
    • ValidatorThe node is enteringPREPAREDStatus after broadcastCOMMITThe message.
  • PREPARED -> COMMITTEDCorrespond to2.1.3In the sectionCOMMITPhase)
    • ValidatorTo receive+ 2/3The effectiveCOMMITMessage, thereby entering intoCOMMITTEDState. A valid message must meet the following conditions:
    • Sequence is consistent with round
    • Block hash is consistent
    • The message comes from a known Validator node
  • COMMITTED -> FINAL COMMITTED:
    • ValidatorNode will+ 2/3Commitment signature (Committed Seal) added to the block headerextraDataField, and try to insert the block into the blockchain.
    • Once the blockchain is up,ValidatorThe node entersFINAL COMMITTEDState.
  • FINAL COMMITTED -> NEW ROUND:

    • Each Validator node selects a new proposer node and starts a new round timer.

3.2. Round change mechanism

ROUND CHANGE can be triggered by three conditions:

  • The Round change timer timed out. Procedure

  • Invalid PREPREPARE message

  • Block upchain failure

3.2.1. Process of Round Change

  • When a Validator detects that one of the preceding round change trigger conditions is met, it broadcasts the Round change message containing the target round value and waits for the Round change message from other Validators. The value of the target round is selected based on the following conditions:

  • If the Validator node has received ROUND CHANGE messages from other peer nodes, the validator node selects the largest ROUND value from all ROUND CHANGE messages whose number reaches F + 1

  • Otherwise, set the value of the target round to the current value of the round +1

  • Any time a Validator node receives F + 1 round CHANGE messages with the same target round value, it compares that round value with its own. If the received value is larger, the Validator node broadcasts the ROUND CHANGE message again, and the ROUND value in the message is the same as the received value.

  • If the Validator node receives a 2F + 1 Round CHANGE message with the same number of rounds, it completes the round CHANGE loop, determines a NEW proposer, and enters the NEW Round state.

  • Another condition that triggers a Validator node to exit the round change cycle is when it synchronizes to the validated block via p2p synchronization.

3.3. Block locking mechanism

  • Trigger conditions for locking blocks

The node is locked in block B and round number R means that the current node can only vote commit for block B. A node enters PREPARED after receiving +2/3 PREPARE votes for block B. At this point, the node is locked and waits to receive the COMMIT voting information from other nodes. The locked round is the current round.

  • Mechanism for locking blocks

In addition to the initial consensus phase, when synchronous data for a higher block is received, or when a currently highly successful block is generated and consensus is reached, the lock is reset to an unlocked state and a new round of consensus for a higher block is initiated. Round CHANGE is triggered if +2/3 of the specified rounds and block commit votes are not received during the lock period. In addition, in certain scenarios, the original locking and unlocking mechanism will also be deadlocked, so we have optimized the relevant unlocking implementation at the code level. See “2. Optimization of the Istanbul Lock unlocking Mechanism” for details.

3.4. Current storage mechanism of Consensus Proof

Before blockchain, each Validator node needs to collect 2F + 1 COMMITTED SEAL to form a consensus proof. Once the Validator node receives enough committed SEALS, it stores them in the CommittedSeal field of the IstabulExtra structure in the extraData field of the block header, recalculates the extraData field, and inserts the block into the blockchain.

The Committed SEAL calculation process is as follows:

  • Calculation of Committed SEAL:

Each Validator node uses its private key to sign COMMIT_MSG_CODE, which is Committed seal: COMMIT_MSG_CODE

  • Committed seal: SignECDSA(Keccak256(CONCAT(Hash, COMMIT_MSG_CODE)), PrivateKey)

  • CONCAT(Hash, COMMIT_MSG_CODE): cascade the block Hash with the COMMIT message code COMMIT_MSG_CODE

  • PrivateKey: PrivateKey of the validator node for signing

  • Mentioned above extraData is a block of a field, the following data: EXTRA_VANITY | ISTANBUL_EXTRA, including | to separate EXTRA_VANITY and ISTANBUL_EXTRA fixed index (not an actual separator characters).

  • The types of IstabulExtra structures are defined as follows:

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

+ Validators: indicates the list of Validators that participate in the consensus. + Seal: indicates the signature of the Proposer to a numbered block. The number is 65 bytes. Stores the committed SEAL list collected by the Validator node.