Consensus algorithm

This section describes two important areas of the Lisk protocol which together are referred to as consensus algorithm.

The first part describes the protocol for deciding who is allowed to add a new block to the blockchain. Lisk uses Delegated Proof-of-Stake (DPoS), which means that every Lisk holder can vote for delegates, and depending on these votes certain delegates are allowed to add blocks to the blockchain in a certain order. Delegates are simply normal Lisk accounts, which performed a delegate registration transaction.

The second part of this section explains the Lisk-BFT consensus protocol. This protocol determines how delegates choose the chain to which they add a new block, and when a block (and all included transactions) is irrevocably deemed part of the blockchain. In addition, the security guarantees of the consensus protocol are also covered here.

Lisk DPoS

Delegates, voting and delegate weight

A delegate is an account which performed a delegate registration transaction. An account can vote for any delegate using a delegate vote transaction. A vote that a delegate account casts for themselves is further called a self-vote. Depending on the votes cast, every delegate has an associated delegate weight, which is an indicator for the support for this delegate in the network. Formally, the delegate weight is defined as the following:

minimum { 10 * selfVotes , totalVotes },

where selfVotes is the amount the delegate voted for themselves, and totalVotes is the sum of all vote amounts (including self-votes) for that specific delegate. This definition implies that the self-votes are always at least 10 % of the delegate weight and thus delegates always have substantial skin in the game.

Forging delegate selection

Blocks in the Lisk protocol are grouped together into batches of 103 consecutive blocks, which are referred to as a round. Every round has a forger list, which is an ordered list of 103 delegates that are allowed to forge a block in that round. Starting with the first delegate on the forger list, every delegate has a 10 second block slot window in which they can forge a block and broadcast it to the network. If every delegate on the list manages to forge a block in their block slot building on the block by the previous delegate, a round lasts 1030 seconds (around 17 minutes). It can happen that a delegate misses the block slot, meaning that there is no block added to the chain by the delegate in their designated block slot. Consequently, the end of the forger list is reached before 103 blocks are added to the chain. In this case, block slots are assigned again from the beginning of the forger list until 103 blocks are forged.

forgerList

In Lisk DPoS, the forger list is computed taking into account the delegate weights and some random values submitted by delegates as part of their block. The top 101 delegates by delegate weight are called active delegates, whereas all other delegates with a delegate weight of at least 1011 (1000 LSK in Lisk Mainnet) are referred to as standby delegates. Specifically, the forger list for a round is generated as follows:

  1. Compute two values randomSeed1 and randomSeed2 from the values provided by the delegates in the seedReveal property of the block headers of the previous 3 rounds.

  2. Add the 101 active delegates to the list. Moreover, add 2 standby delegates to the list using a random selection proportional to delegate weight. The random selection utilizes randomSeed1 and randomSeed2, respectively. The computation of 101 active delegates as well as the standby delegate selection is based on the delegate weights from two rounds before.

  3. Shuffle the list using randomSeed1.

The random selection of two standby delegates and the commit-reveal scheme that the seedReveal values provided by the delegates in the block header must follow are described in detail in LIP 0022.

During the bootstrap period defined in the genesis block the number of blocks per round and length of the forger list is still 103. However, the Lisk DPoS delegate selection is not used. Instead, the forger list is directly computed from the initial delegates specified in the genesis block, repeating delegates if needed to obtain a list of length 103.

Banning of unproductive delegates

As a fail-safe mechanism, a delegate that does not forge blocks for an extended period of time is banned. This is to avoid the situation where a delegate who is not running a node leads to frequent missed block slots. More specifically, a delegate is banned in case they miss 50 consecutive blocks, and the height of the last block they forged differs by more than 260,000 from the current height of the chain (the block is 30 days old). As soon as a delegate is banned, they are excluded from the delegate weight snapshots used for the forger list computation. The ban is permanent, but the delegate account holder can move their funds to a different account and register a new delegate.

Lisk-BFT

The Lisk-BFT protocol is formally defined in the related research paper "A lightweight BFT consensus protocol for blockchains" (arXiv). This section provides a high-level overview of the Lisk-BFT protocol and its security guarantees.

Consensus votes on blocks and fork choice rule

The Lisk-BFT protocol uses special consensus votes that the forging delegates cast for blocks. These consensus votes are necessary because there can be multiple valid chains and, in particular, multiple valid blocks at the same height due to network delays, for instance. In this case, the delegates and nodes in the network need a protocol to agree on one of the chains. The consensus votes are used to indicate what a forging delegate believes to be the correct block at a given height. They are completely unrelated to the votes used to determine the forging delegates.

There are two types of consensus votes, the first is called a prevote, and the second is called a precommit. Only the 101 current active delegates can cast these consensus votes for a block and therefore the number of prevotes or precommits for a block ranges from 0 to 101. The consensus votes are not sent explicitly, but are implied by the maxHeightPreviouslyForged property that delegates need to include in the blocks they forge. For this property, delegates are supposed to provide the largest height of any block they previously forged and thereby disclose if they previously forged on a different chain.

The fork choice rule defines to which chain a delegate is supposed to add a block in case there are multiple chains. In the Lisk-BFT protocol delegates choose the chain where the block at the tip of the chain has the largest maxHeightPrevoted value (and largest height value in case of a tie). The maxHeightPrevoted property of a block has to be equal to the largest height of an ancestor block with at least 68 prevotes (an ancestor block is a predecessor block in the chain).

Finality and security guarantees

As soon as one block has at least 68 precommits, the block and all its ancestor blocks are considered final. This means they are irrevocably deemed part of the blockchain and never reverted. Two blocks are called conflicting if they are part of different chains, i.e., none is an ancestor block of the other. The most important security property for a consensus algorithm is to guarantee that two conflicting blocks are never considered final, as otherwise a blockchain can be subject to double-spending attacks, for instance. For the case of a static set of 101 active delegates (i.e., the active delegates are not changing from round to round), the Lisk-BFT protocol provides the following security guarantees:

  • If at most 33 active delegates are Byzantine (malicious), and all other active delegates obey the rules of the Lisk-BFT protocol, two conflicting blocks are never finalized.

  • If the active delegates obey the rules of the Lisk-BFT protocol and at most 33 active delegates stop forging or casting consensus votes, new blocks can always be finalized.

  • A violation of the Lisk-BFT protocol by a delegate can be detected and the respective delegate can be punished, as outlined in the next section.

In case the set of active delegates changes over time, the security guarantees are only slightly weaker. For details, refer to the Lisk-BFT research paper (arXiv).

Punishment of Lisk-BFT protocol violations

If a delegate casts contradictory consensus votes due to an incorrect maxHeightPreviouslyForged in the block header or violates the fork choice rule, there must be two signed blocks by that delegate which are proof of the protocol violation. The signed block headers serve as a proof-of-misbehavior and can be submitted to the network by anyone as part of a delegate misbehavior report transaction. Once this transaction is included in the blockchain, the delegate that violated the Lisk-BFT consensus protocol and forged the two blocks is punished by setting the delegate weight to 0 for the next 780,000 blocks (approximately 3 month). Additionally, the unlocking period for self-votes is increased from 260,000 blocks to 780,000 blocks (from approximately 1 month to 3 months) for the respective delegate. This affects any vote amount that is used for self-voting or is still in the unlocking period at the inclusion height of the proof-of-misbehavior. Similarly, for all accounts voting for the punished delegate, the unlocking period for the votes for the punished delegate is increased from 2,000 blocks to 260,000 blocks (from approximately 5 hours to 1 month). Again, this affects any amount used by the account to vote for the punished delegate or amounts that were used for voting for the punished delegate, but were still in the unlocking period at the inclusion height of the proof-of-misbehavior. This means that both the delegate as well as the accounts voting for that delegate are punished by their tokens being locked for an extended amount of time.