CFT consensus algorithm

When information is exchanged extensively in a corporate blockchain, consistency between the network elements that form a single blockchain is important. And the more participants are in the exchange, the more likely it is that an error will occur: a hardware failure by one of the participants, network problems, and so on. This can lead to forks of the main blockchain and, as a consequence, rollback of a block that seems to be already formed and included in the blockchain. In this case, the blocks subject to the rollback begin to be mined again and become unavailable in the blockchain for some time. This, in turn, can affect the business processes that use the blockchain. The CFT (Crash Fault Tolerance) consensus algorithm is designed to prevent such situations.

Algorithm description

The CFT consensus algorithm is based on the PoA with an added phase for voting of mining round validators: network participants that are automatically appointed by the consensus algorithm. This approach guarantees the following:

  • more than a half of participants (validators) are familiar with a definite block and have validated it;

  • the block will not be rollbacked and will be published in the blockchain;

  • there will be no parallel chain in the network.

This is achieved by the finalization of a produced block. The finalization itself is based on the consensus of majority of round validators (50% + 1 vote). In accordance with this consensus, the decision of block broadcasting is taken. If this majority has not been achieved, mining will be stopped up to restoring of network cohesion.

Like PoA, CFT depends on a current time, starting and ending time of each mining round is calculated upon the basis of a genesis block timestamp. Basic parameters that form an algorithm that is used for appointment of a current block miner are also identical to the PoA parameters (see the section Algorithm description). For validation of blocks, the consensus block of the node configuration file has been expanded with two new parameters:

  • max-validators – limit of validators participating in a current round;

  • finalization-timeout – time period, during which a miner waits for finalization of the last block in a blockchain. After that time, the miner will return the transactions back to the UTX pool and start mining the round again.

The following terms are used for the following description of CFT functionality:

  • t - round duration in seconds (parameter of the node configuration file: round-duration).

  • tstart - round start time.

  • tsync - blockchain synchronization time (tstart + t).

  • tend - round end time.

  • tfin - time period during which a miner waits for finalization of the last block (parameter of the node configuration file: finalization-timeout).

  • Vmax - limit of validators taking part in voting (parameter of the node configuration file: max-validators).

Voting

Voting is performed in each round, nodes with the miner role can take part in it. Voting starts upon tsync and ends by tend + tfin . Within each time period defined for voting, voting of validators and voting of current round miner are performed. Each validator of a round can send multiple votes, but a miner can vote only once for its last microblock.

For voting, instance of a vote is used, which includes following parameters:

  • senderPublicKey – a public key of a validator which has formed a vote;

  • blockVotingHash – hash of a liquid block with votes confirmed by a validator;

  • signature – vote signature formed by a validator.

Defining of round validators and their voting

In order to define validators that can vote in a current round, a configurable node parameter max-validators (Vmax ) is used. If the number of active miners minus the current round miner does not exceed Vmax , each of them can take part in voting. Otherwise, in order to define validators of a current round, the pseudorandom selection algorithm is used which allows to exclude the influence of a particular miner on choices of voters.

Voting of validators start under two preconditions:

  • the next attempt to vote falls within the time interval required for voting;

  • the address of the current node is one of the defined validators of the round for voting.

After the end of the round validators voting, the miner voting is started.

Voting of current round miners

The miner’s vote is triggered under two conditions:

  • the next attempt to vote falls within the time interval required for voting;

  • the address of the current node is the miner of the round.

A vote is considered valid if it was issued by an address that is in a list of validators of the current round and has a correct signature. As soon as a miner gains the required number of votes, voting time slot is checked. Then the finalizing microblock with all votes is released. The block with votes is considered finalized.

Mining features

The basic rules of CFT consensus mining are identical to the PoA consensus rules. However, an additional mechanism has been introduced to ensure consensus fault tolerance.

With CFT consensus, another mining attempt is considered a failure in case the last received block has not been finalized - in other words, a microblock with valid votes has not been applied to the state. In this case, if the mining attempts exceed the tstart + tfin , the node decides to return all transactions from the last block back to the UTX pool, after that the round starts mining again.

In order to exclude returning of your transactions into the UTX pool, it is highly recommended to work not with the current (liquid) blockm but with a finalized one that has been already validated by the network participants.

Selecting a channel for synchronization

The PoS and PoA consensus algorithms use a module that selects the strongest chain for synchronization by comparing the data of the involved nodes. CFT uses a different selection mechanism, which also increases system fault tolerance: it selects a random channel from the channels that are active at the moment of synchronization. The list of active channels is constantly updated during the system operation, and the synchronization time with a particular channel is limited to evenly distribute the load of the network.

Changing consensus parameters

Like in the PoS and PoA consensus algorithms, the consensus parameters are configured in the node configuration file. The configuration example is stated below:

// specifying inside of the blockchain parameter
consensus {
  type = cft
  sync-duration = 10s
  round-duration = 60s
  ban-duration-blocks = 100
  max-validators = 16
  finalization-timeout = 5s
 }