# 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,:ref:rollback <rollback-glossary> 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 PoA. Like the PoA algorithm, CFT depends on a current time, and time of start and finish of each round is calculated with the use of a genesis block timestamp. CFT reduces the probability of blockchain branching and, consequently, block rollback. Also, the application of this algorithm allows the blockchain state to be fully consistent. All this is achieved through finalization of a released block, which excludes its rollback. Block finalization itself is based on majority consensus of blockchain participants (50% + 1), in accordance with which the decision to add the block to the network is made. In case of absence of such a majority, mining stops until the network is restored to cohesion.

Basic parameters for definition of a current block miner are similar to the PoA algorithm (refer to the section Algorithm description). For block validation, two new parameters were added to the consensus section of the node configuration file:

• 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.

## 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
}