Shulou(Shulou.com)06/01 Report--

This article shows you the consensus algorithm mechanism IBFT and its implementation of the underlying platform PlatONE of the blockchain. The content is concise and easy to understand, which can definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

I. Overview

The consensus in PlatONE, a blockchain chain that supports privacy computing jointly built by Universal Block chain and Ecological Partners, is a highly optimized BFT consensus algorithm with a fault tolerance of 1 beat 3, which greatly improves the degree of decentralization while retaining the key features of instant confirmation (instant finality). Consensus ensures that the upchain block is certain, that is, the chain will not bifurcate, and each valid block will be inserted into the chain.

The PlatONE consensus supports more than 100 consensus nodes. Compared with other common BFT consensus, the performance of PlatONE consensus has been significantly improved. In the case of 10 consensus nodes, TPS is close to 1000.

The parameters related to the consensus operation of PlatONE can be flexibly configured, and the set of consensus nodes in PlatONE consensus can be updated flexibly. In the near future, the plan supports the plug-in of the consensus and the auditability of the consensus.

The PlatONE consensus is carried out on round. On a specific round, a chunk node is selected through a preset policy. Currently, the selection strategy of chunk node supports two kinds: round robin and sticky proposer.

After the block maker node proposes the block, the consensus nodes reach a consensus. The consensus is divided into three stages, the latter two of which are voting stages to ensure Safety. The PlatONE consensus uses the round change mechanism combined with locking and unlocking mechanisms to ensure the consensus liveness. By optimizing the unlocking mechanism, the consensus deadlock problem in many well-known projects in the industry is solved.

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

If a block does not contain a transaction, it is called an empty block. PlatONE currently supports no empty blocks, that is, all uplink blocks contain transactions. The mechanism of not emptying blocks can effectively save the storage space occupied by the block chain.

The consensus algorithm in PlatONE is described in detail below.

Second, the mechanism of selecting consensus nodes

Type and status of the node

Nodes are divided into two types: consensus node (validator) and observer node. For consensus nodes, there are two states: normal and isolated. Only consensus nodes in the normal state can participate in consensus and packaging blocks.

The selection mechanism of consensus nodes

The Node Management (NodeManager) system contract is designed to store and manage node information. You can apply for registration of consensus nodes through the Node Application (NodeRegister) system contract. After the approval, the type of the application node will be updated to the consensus node, and the updated node information will be stored in the node management contract and can be queried.

Administrators can update the status of consensus nodes as needed to determine whether consensus nodes can participate in consensus.

Acquisition of consensus node set

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 set of consensus nodes will be saved and read and used by the consensus engine.

Third, the consensus process 3.1. Normal process 3.1.1. Define

The following are definitions of some important terms or concepts.

+ 2gam3 means "more than 2gamma 3".

NEW ROUND: a new block proponent is identified in the new round (such as using the round robin algorithm), and at the beginning of the new round, the consensus nodes wait to receive the PRE-PREPARE message.

PRE-PREPARED: the validator node receives the PRE-PREPARE message and broadcasts the PREPARE message and then enters this state. After that, the validator node waits and receives a PREPARE or COMMIT message from + 2 to 3. (note: because some validator nodes are locked on the proposed block, they will broadcast the PRE-PREPARE message directly after receiving the COMMIT message. Therefore, here the validator node waits and receives a PREPARE or COMMIT message)

PREPARED: the validator node receives a PREPARE message of + 2 to 3 and enters this state after broadcasting the COMMIT message. After that, the validator node waits and receives the COMMIT message of + 2Acer 3.

COMMITTED: the validator node receives a COMMIT message of + 2 to 3 and enters this state. At this point, the proposed block can be inserted into the block chain

FINAL COMMITTED: after the new chunk is successfully uploaded, the validator node enters this state. At this point, the node is ready to enter the next round

ROUND CHANGE: the validator node is waiting to receive a ROUND CHANGE message for the same proposal round from + 2bank 3.

3.1.2. Select the rules of proposer

Round robin algorithm (currently used)

Sticky proposer

3.1.3. Consensus process (three-phase agreement)

The consensus process consists of three phases: PRE-PREPARE, PREPARE and COMMIT, also known as three-stage protocols.

PRE-PREPARE phase: each time you enter a new round, the first of the three phases, the PRE-PREPARE phase, begins. In this phase, the Proposer (Block proposer) node generates a proposal block and broadcasts it to all validator nodes. Then the Proposer node enters the PRE-PREPARED state. Other validator nodes enter the PRE-PREPARED state after receiving a valid PRE-PREPARE message.

PREPARE phase: in this stage, the validator node broadcasts PREPARE messages to other validator nodes and waits to receive valid PREPARE messages from + 2 to 3 to enter the PREPARED state.

COMMIT phase: in this stage, the validator node broadcasts COMMIT messages to other validator nodes and waits to receive valid COMMIT messages from + 2 to 3 to enter the COMMITTED state.

After the completion of the above three stages, the whole consensus process is completed successfully.

3.1.4. State Migration:

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

NEW ROUND-> PRE-PREPARED: (corresponding to the PRE-PREPARE phase in Section 2.1.3)

Proposer collects transactions from txpool.

Proposer generates a proposal block, 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-PREPARED state:

The proposed block comes from a valid proposer node.

Block head is effective

The sequence (height) of the proposed block is consistent with the current state of the round and validator nodes.

The Validator node broadcasts PREPARE messages to other validator nodes.

PRE-PREPARED-> PREPARED: (corresponding to the PREPARE phase in Section 2.1.3)

Validator receives a valid PREPARE message from + 2amp 3 and enters the PREPARED state. Valid messages need to meet the following conditions:

Sequence is consistent with round.

Block hash is consistent

Message from a known validator node

After entering the PREPARED state, the Validator node broadcasts the COMMIT message.

PREPARED-> COMMITTED: (corresponding to the COMMIT phase in Section 2.1.3)

Validator receives a valid COMMIT message from + 2amp 3 and enters the COMMITTED state. Valid messages need to meet the following conditions:

Sequence is consistent with round.

Block hash is consistent

Message from a known validator node

COMMITTED-> FINAL COMMITTED:

The Validator node adds the commitment signature (committed seal) of + 2amp 3 to the extraData field of the block header and attempts to insert the block into the block chain.

After the block is successfully linked, 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 trigger ROUND CHANGE:

Round change timer timeout trigger

Invalid PREPREPARE message

Block winding failed

3.2.1. The process of round change

When a validator node detects that one of the above round change trigger conditions is met, it broadcasts a ROUND CHANGE message containing the target round value to be changed, while waiting to receive a ROUND CHANGE message from another validator node. 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, select the largest number of round values contained in all ROUND CHANGE messages up to F + 1

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

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

Once the validator node receives 2F + 1 ROUND CHANGE messages with the same round value, it ends the round change loop, identifies a new proposer node, and then enters the NEW ROUND state.

Another condition that triggers the validator node to exit the round change loop is that it is synchronized to the verified block through the P2P synchronization mechanism.

3.3. Block locking mechanism

Trigger conditions for locking blocks

The meaning of node locking in block B and round number R means that the current node can only vote commit on the information of block B. When a node receives + 2 PREPARE votes for block B, it enters the PREPARED state. At this point, the node is locked, waiting to receive commit voting information from other nodes, and the locked round is the current round.

Mechanism for locking blocks

In addition to the consensus initiation phase, when synchronous data for a higher block is received, or when a block is generated and a consensus is reached with a high degree of success, the locked state is reset to a non-locked state, and a new round of higher block consensus begins. ROUND CHANGE is triggered if commit votes for 3 specified round and chunks are not received during locking. Moreover, in a specific scenario, the original locking and unlocking mechanism will also occur deadlock, we also optimize the relevant unlocking implementation at the code level. Please refer to "2." Optimization of Istanbul locking and unlocking mechanism.

3.4. Consensus proof's current storage mechanism

Before the chunk is linked, each validator node needs to collect 2F + 1 committed seal to form a consensus proof (consensus proof). Once the validator node receives enough committed seal, it stores it in the CommittedSeal field in the IstabulExtra structure in the extraData field of the block header, recalculates the extraData field, and then inserts the block into the block chain.

The Committed seal calculation process is as follows:

Calculation of Committed seal:

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

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

CONCAT (Hash, COMMIT_MSG_CODE): concatenates the block hash with the commit message code COMMIT_MSG_CODE

PrivateKey: the private key of the signed validator node

The extraData mentioned above is a field of the chunk header, and its data composition is: EXTRA_VANITY | ISTANBUL_EXTRA, where | represents a fixed index (not an actual delimiter) that separates extra _ VANITY from 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}

Among them, the meaning of each field is as follows: + Validators: the list of validator nodes participating in the consensus + the signature of the Seal:Proposer node to the block, the length is 65 bytes + CommittedSeal: used to store the committed seal list collected by the validator node.

The above content is the consensus algorithm mechanism IBFT and its implementation of PlatONE, the underlying platform of blockchain. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.