Consensus

​

Key Concepts

Consensus algorithm is a mechanism to ensure that multiple nodes in a blockchain network reach an agreement. Byzantine Fault Tolerance (BFT) algorithm is one of the important consensus algorithms widely adopted in the blockchain industry. BFT-based algorithms achieve consensus through multi-round voting or message exchanges, ensuring the liveness and security of blockchain systems even in the presence of a small number of faulty or malicious nodes.

​

dBFT

​

Overview of dBFT

Practical Byzantine Fault Tolerance (PBFT) is a consensus algorithm based on BFT principles. PBFT enables fast and secure confirmation of transactions and is widely used in public blockchains. However, native PBFT suffers from issues such as predictable primary nodes and poor scalability. To solve these concerns, AxiomLedger has optimized and improved PBFT, implementing the Delegated Byzantine Fault Tolerant (dBFT) algorithm.

​

Basic Process

The transaction process within the consensus module of AxiomLedger is outlined as follows:

1. The TxPool receives validated transactions from P2P and API sources.
2. The TxPool sorts transactions based on tx account nonce, categorizing them into a set of ready transactions(priorityTx) and a set of unready transactions(parkingLotTx). Transactions in the priorityTx set can be packed by proposers but are not yet included, while transactions in the parkingLotTx set cannot be included temporarily (usually storing transactions with higher nonces during high concurrency).
3. The proposer of the current term, based on the packaging strategy, retrieves a certain number of transactions from the priorityTx set in the TxPool, collect these transactions into a block, and propose a consensus proposal for the current block.
4. All validators in the node consensus network participate in multi-round voting to reach a consensus for the block proposal, and once conmmited, the block is sent to the executor for transaction execution.

​

State Checkpoint Mechanism

After the executor completes the execution of transactions within a block, the block is persisted. Simultaneously, the consensus module is notified of the execution results of the current block (including the block hash containing state root, receipt root, block height, etc.). When the block reaches a checkpoint, validators start consensus on the latest block’s information to ensure ledger consistency (e.g., a checkpoint interval of 10 blocks results in an account state confirmation every 10 blocks). Once a sufficient consensus on checkpoint information is received, Validators can continue with block consensus.

Moreover, to prevent delayed block heights from reaching checkpoint, validators will set a timeout mechanism. When the timer triggers, validators actively consensus on the latest block information.

The state checkpoint mechanism guarantees eventual ledger consistency. Validators do not need to start consensus on every block execution results during the block packaging process, effectively improving consensus performance.

​

Epoch Change

​

WRF Algorithm

WRF (Weighted Random Function) is a method for random selection based on assigned weights. When a node joins the network, each node is assigned a different weight. All node weights are mapped onto an interval. Then, using the provided random number seed, a random number generator generates a random number. The node is selected based on the interval where the random number falls. Nodes with higher weights occupy a larger portion of the interval and are more likely to be selected.

In AxiomLedger, both the selection of the validator set and the proposer use the WRF algorithm. However, the allocation of random number seeds differs.

• Validator Set Selection : Latest block hash (previous checkpoint’s block), current epoch information recorded by the epoch contract, number of validators selected.
• Proposer Selection : Information from the last checkpoint, current epoch information recorded by the epoch contract, current term number.

The advantages of the WRF algorithm include:

• Flexibility and Customization : The WRF algorithm can allocate different weights to each node based on specific requirements (e.g., stake ratio, governance allocation), flexibly controlling the probability distribution for random selection.
• Efficiency : As random number seeds are contents that already achieved through consensus, no additional round of consensus is needed for the random seed. Only basic mathematical calculations are involved.
• Security : Since confirmation of the random number seed requires waiting for the last block to be produced in the checkpoint, it’s impossible to predict the random number in advance, hence the validator set cannot be predetermined. Similarly, as proposers are selected from the validator set, the block proposer of the current term cannot be known in advance.

​

Main Process

Epoch changes are executed through the built-in epoch management contract, which includes epoch number, epoch interval, term interval, and other information. The epoch management contract is responsible for confirming validator sets and candidate sets for each epoch. The epoch management contract stores validator sets and candidate sets for each epoch, and updates are carried out using the WRF algorithm.

Each term interval corresponds to a checkpoint interval. Within this interval, a proposer is assigned. If a proposer encounters abnormal states such as downtime during this interval, an exceptional term transition will be triggered. It is important to note that after an exceptional term transition, the term interval is not a checkpoint interval, it is the checkpoint interval minus the previous exceptional term interval (e.g., term 3 + term 4 = term interval).