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 receivePRE-PREPARE
messages.PRE-PREPARED
: The validator node receives the message and enters this state afterPRE-PREPARE
broadcasting the message.PREPARE
After that, the validator node waits for and receives+2/3
thePREPARE
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/3
message and enters this state afterPREPARE
broadcasting the message at the same time .COMMIT
After that, the validator node waits for and receives+2/3
the message.COMMIT
COMMITTED
+2/3
: The message received by the validator nodeCOMMIT
enters this state. At this point, the proposed block can be inserted into the blockchainFINAL 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 roundROUND CHANGE
: messages the validator node is waiting to receive+2/3
for 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-PREPARE
Stages: Each time a new round is entered, the first of the three stages, the stage, beginsPRE-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
PREPARE
Phase: In this phase, the validator node broadcastsPREPARE
messages to other validator nodes and waits for+2/3
a valid message to be received to enter the state.PREPARE
PREPARED
COMMIT
Phase: In this phase, the validator node broadcastsCOMMIT
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-PREPARED
2.1.3
PRE-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 thePRE-PREPARED
state: - 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 )PREPARED
2.1.3
PREPARE
+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
PREPARED
broadcasts aCOMMIT
message after entering the state.
PREPARED
-> : (corresponds to the stage in the section )COMMITTED
2.1.3
COMMIT
+2/3
The valid message received by the ValidatorCOMMIT
enters theCOMMITTED
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/3
the committed seal to theextraData
field 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.
- The Validator node adds
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
PREPREPARE
message - 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 CHANGE
message containing the target round value to be changed, while waiting to receive messages from other validator nodesROUND 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 B
can 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
B
commit
+2/3
B
PREPARE
PREPARED
commit
- 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/3
specified 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".commit
ROUND 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 + 1
a 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 extraData
field in the IstabulExtra structure, CommittedSeal
recalculates the extraData
field, 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_CODE
and 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
extraData
is 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.