Summarizing the Lightcurve’s Proposal for a BFT Consensus Algorithm

Jan Hackfeld is a Cryptographer at Lightcurve and he is responsible for researching ways to improve different aspects of the current Lisk protocol. He recently released a blog post where he described the main features and benefits of the Byzantine Fault Tolerance consensus algorithm.
Here we recap the focal points of his essay.

Thanks to this new consensus algorithm, delegates could not only forge blocks, but also vote on the correct block at every height. This guarantees that a block is never reverted, assuming a certain fraction of honest delegates.
In the current Lisk scenario, when not all nodes in the network receive a block due to latency or attacks on the network, there can be multiple child blocks of the same parent block and separate growing chains. In such a case, there are multiple valid chains and nodes choose the longest one, considering also the number of nodes in the network that have the same chain.
This rule is working well on Lisk blockchain, but does not guarantee that a certain block is never reverted in all theoretically possible network situations (for instance, during a long network split).

Introducing the BFT consensus algorithm, it is possible to assume that most of the blockchain is immutable. This feature is very important for both crypto exchanges and future value transfers between chains in the Lisk ecosystem.
As delegates vote for the correct block, a threshold is set but it should not be too lower nor to higher, otherwise the attacker is able to pursue its interests or a block is never finalized. After many simulations, Lightcurve concludes that a threshold of at least 68 out of 101 delegates allows for up to 33 delegates to not participate in voting and still a new block can still be finalized.

As there can be delays in the network, 68 delegates could vote in both chains. It is therefore necessary to introduce two rounds of voting and only finalize a block after two rounds are completed successfully.
Votes in the first round of voting are called prevotes, while those in the second round of voting are precommits. Only after a block receives at least 68 prevotes, a delegate is allowed to cast precommits for it and the block is finalized after have received 68 precommits.
The full formal description of this consensus algorithm, referred to as Lisk-BFT, and the correctness proofs are given in the related paper. The detailed specifications how this consensus algorithm could be introduced to Lisk is given in the “Introduce BFT consensus” LIP.
Every block will additionally contain the height of the block with at least 68 prevotes, so with only two additional integers in blocks it’s possible to have a robust BTF consensus algorithm.

In Tendermint, voting phases are separated and the process is slower, while in the Ethereum evolution (Casper) participants do not vote for every single block, but only at specific checkpoints.

———————————————-
Lisk Magazine is a project supported by Lisk Italian Group.
Support our work, vote for Lisk Magazine.