The Paxos protocol introduced by Lamport in [lamport98] is the basis for most consensus protocols solving the Byzantine agreement or more generally the state machine replication problem. Starting with [castro02], there has been a multitude of different practical consensus protocols that adapt the basic Paxos protocol to improve various aspects such as the efficiency and the resistance against Byzantine faults. See [rutti10] for a classification of different consensus protocols.
In this paper, we introduce Lisk-Bft, a Byzantine fault tolerant consensus algorithm for the Lisk blockchain that follows this line of research. We assume that there is a set of block proposers that can add blocks to a block tree via a given proposal mechanism (e.g. round-robin). Ideally, we would like the block proposers to propose one block after another always referencing the previously proposed block via a directed edge and hence forming a tree with only one growing branch, i.e., a blockchain. However, due to the latency of communication between the block proposers or deliberate attacks on the network, there can be multiple child blocks of the same parent block and separate growing branches. We therefore need a consensus protocol for block proposers to agree on one block at every height of the block tree.
We distinguish between honest block proposers that correctly follow the consensus protocol and Byzantine block proposers that may behave arbitrarily. The consensus algorithm is supposed to allow block proposers to decide for exactly one block at every height of the block tree such that the following properties are satisfied:
Safety. Two honest block proposers never decide for conflicting blocks, i.e., blocks that are not contained in one branch of the block tree.
Liveness. An honest block proposer eventually decides for a block at any height.
Accountability. A block proposer can detect if a Byzantine block proposer violates the consensus protocol and can identify the Byzantine block proposer.
Note that the safety property implies that all decided blocks for an honest block proposer are in one branch of the block tree and for any height two honest block proposers never decide for distinct blocks.
In the case of Bitcoin [nakamoto08], consensus is reached by block proposers choosing the chain which required the most “work”. This rule does not satisfy both the safety and liveness property above because no matter how late a block proposer decides for a block , there is no guarantee that the block will be contained in the Bitcoin blockchain the Bitcoin network agrees on in the future. The reason is that there always can be a different branch of the Bitcoin block tree in the future with more “work” although for economic reasons it becomes increasingly unlikely the more blocks are added to the block tree as descendants of .
Tendermint [tendermint] is one of the first blockchain consensus protocols achieving the safety, liveness and accountability property above. Namely, Tendermint guarantees that as long as of the block proposers are Byzantine, both the safety and liveness property hold, which is optimal for the partially synchronous system model introduced in [dwork88]. The Tendermint protocol proceeds in three distinct phases. Once the three phases are completed successfully, the block proposers decide for a block and proceed with proposing and deciding for a descendant of . This way the block tree in Tendermint is simply a path as for every height the block proposers decide for a block before proceeding further. We call a consensus protocol with this property fork-free. In contrast to that, we refer to a consensus protocol as forkful if there is no requirement for block proposers to achieve consensus, i.e., decide for a block, before adding further blocks to the block tree.
The Lisk-Bft protocol is a forkful protocol, where the block proposal can independently progress before consensus is reached on blocks. This idea of using speculative Byzantine fault tolerance in order to decrease the overhead has already been considered in [kotla09] for the state machine replication problem. We also believe that a forkful protocol can achieve better performance in practice and significantly decrease the communication overhead as consensus can be reached independent of the block proposal at any later point in time. For a more detailed treatment of forkful versus fork-free consensus protocols and the message complexity involved, see [buterin18].
2 Model and definitions
In this section, we introduce the blockchain specific terminology as well as the underlying network model. We do not consider the general state machine replication problem, but instead assume that there is a block proposal mechanism, where time is divided into discrete slots and for every time slot there is a designated block proposer. We also change some of the state machine replication terminology to the blockchain specific context.
A block tree is a directed tree with a designated root vertex referred to as genesis block and a unique directed path from every vertex in the block tree to the genesis block. We refer to the vertices in the block tree as blocks. We assume that blocks can contain arbitrary data such as signatures or messages. Every block has a corresponding height, denoted by , which is the number of edges of the unique path from that block to the genesis block. Note that the genesis block has height 0. For a block in the block tree, we call a block ancestor if is distinct from and is on the directed path from to the genesis block. Moreover, is called a descendant of if is an ancestor of . If there is a directed edge from a block to a block , then is called the parent of and a child of . We further refer to the subgraph induced by a path from a block without child to the genesis block as a branch or a chain. For a given chain, the unique block without child block is referred to as the tip or head of the chain. Two blocks are called conflicting if they are not contained in one branch of the block tree, i.e., none is a descendant of the other.
We assume that there is a set of block proposers and a proposal mechanism for block proposers to add child blocks of existing blocks to the block tree. We distinguish between three types of proposers: A block proposer is honest if it follows the consensus protocol. A block proposer is further called offline or crashed if it does not participate in the consensus protocol, i.e., does not send any message to the network. Moreover, a Byzantine block proposer can behave arbitrarily, e.g., maliciously violate the consensus protocol or crash. Classic Byzantine fault tolerance consensus protocols typically yield guarantees assuming certain upper bounds on the number of Byzantine block proposers. In the case of blockchain, in particular proof-of-stake, we would rather have guarantees in terms of the stake represented by a certain set of block proposers. We can model this by associating a weight to every block proposer such that , where can be thought of as the relative stake in the case of a proof-of-stake blockchain. For the simplicity of exposition, we never explicitly use the weights of the block proposers but rather say that (or ) of the block proposers satisfy a property if the set of block proposers satisfying property has overall weight larger (or smaller) than , i.e., (). For instance, we regularly assume that of the block proposers are Byzantine. For the Lisk blockchain we have block proposers and uniform weights for all and the round-robin block proposal scheme currently used for the Lisk blockchain satisfies that block proposers are assigned slots proportional to their weight. The proposal mechanism could, however, also be based on randomized leader election proportional to stake, for instance.
We further assume that the block proposers communicate by exchanging messages via the underlying network. We model the network using the partially synchronous system model introduced in [dwork88]. The basic assumption of this model is that in general the network can behave arbitrarily badly, i.e., messages are lost or have a huge delay, but eventually, from a time GST onward, the network behaves nicely, i.e., all messages arrive reliably and with a delay of at most . The parameter GST is called the global stabilization time. Messages are further always signed so that a block proposer can not be impersonated by another block proposer. The block proposers are not required to know any bound on GST or . Note that the eventually synchronous network is only necessary to show the liveness of the consensus algorithm, but not for the safety. In fact, this assumption on the underlying network is stronger than needed for our consensus to work in practice and our results can easily be extended to a network model with regular long enough good time periods, where the messages arrive reliably and within time. These good periods only need to be long enough for block proposers to send enough messages to decide for blocks. For the ease of exposition, however, we use the partially synchronous system model.
Note that due to the impossibility results of Fischer et al. [fischer85, fischer86], stating that consensus is impossible without randomization in an asynchronous message-passing system with at least one Byzantine or crashing node, the partially synchronous system model is one of the weakest models where consensus without randomization is possible. Known consensus algorithms for asynchronous systems using randomization have worse guarantees in terms of maximum number of Byzantine block proposers, a large number of local computations or a larger number of messages [cachin05, king14].
3 General consensus algorithm framework
In this section, we define a general consensus protocol with two types of messages, which is later used as the basis for the Lisk-Bft protocol.
3.1 Protocol rules
We now describe the protocol rules of the general consensus framework. A proposer can send two types of messages, and , where and are blocks in the block tree such that or is a descendant of ( is typically the tip of the current chain of ). In an implementation, and can be block hashes and the public key and signature of the block proposer . We assume that both types of messages are added to the blocks so that we can refer to the prevotes and precommits included in the blockchain from the genesis block up to the tip . Moreover, we shortly write that a block proposer prevotes for if sends a message and equivalently that precommits for if it sends a message for a block . Next, we describe the protocol rules that must be satisfied when sending prevote and precommit messages and the conditions for block proposers to decide for blocks.
The prevotes and precommits send by a block proposer must obey the following rules:
For any two distinct messages and , it holds that .
For any message , the blockchain up to block must include both
[label = (), ref=2 ()]
one message and
messages by of the block proposers.
For any two messages and with at least one of the following conditions is satisfied:
[label = (), ref=3 ()]
is a descendant of .
The blockchain up to contains a block at height and messages by of the block proposers.
Let denote the decision threshold of a block proposer . Once proposer receives messages by of the proposers, proposer decides for block or finalizes block . This implies that also decides for all ancestors of .
The basic intuition behind the protocol rules is that prevotes must not contradict, so block proposers can cast only one prevote for every height by 1. Moreover, in order to send a precommit for a block, a proposer has to have send a prevote for that block and received prevotes by of the block proposers for it due to 2. Finally, the intuition behind 3 is that a block proposer cannot change to a different chain without a justification, i.e., after a precommit for block , all prevotes of larger height must be for descendants of or as a justification there is a block at height with prevotes that allows the block proposer to start sending prevotes on a different chain.
In the next subsection, we show how the decision threshold relates to the safety property of the protocol. Intuitively, the higher the decision threshold of the block proposers, the more block proposers can be Byzantine without losing the safety property. On the other hand, for the liveness property, the decision threshold cannot be too high as otherwise a proposer may never decide on a block.
In this section, we show that the safety property is fulfilled for the general consensus protocol assuming a bound on the overall weight of Byzantine block proposers that depends on the decision thresholds of the block proposers.
Theorem 3.2 (Safety).
If there are Byzantine block proposers for , then any two honest block proposers with decision threshold at least never decide for conflicting blocks.
Assume, for the sake of contradiction, that there are two conflicting blocks and as well as an honest block proposer with decision threshold deciding for and an honest block proposer with decision threshold deciding for . Without loss of generality let . Note that by assumption we have and .
If decides for , it must have received a messages by of the block proposers by definition. By assumption, and of the block proposers are Byzantine so that there is a set of honest block proposers that must have sent a message. In particular, by property 1, no proposer sends a message for a distinct block at height and hence no distinct block at height can receive prevotes. This also implies that we cannot have as there can only be prevotes for and hence no honest block proposer would send a message by 2. Thus, the threshold of precommit messages for block cannot be reached and we must have .
By 3, every block proposer is only allowed to send a prevote message for a block that is not a descendant of if there is a block at height with messages by of the block proposers. As all block proposers in are honest, there have to be prevotes for such a block by block proposers not in . This is a contradiction, as is a set of block proposers by assumption. Hence, no block that is not a descendant of can obtain prevotes and thus no honest block proposer sends a precommit for . This means that the decision threshold of precommit messages for block cannot be reached contradicting that the honest block proposer decided for . ∎
Note that for Byzantine block proposers consensus that guarantees both safety and liveness in the partially synchronous system model is impossible as shown in [dwork88]. This is also the case for the consensus framework above because Byzantine block proposers can for example not send any prevotes and thus prevent any decision for a block as the threshold of prevotes is not reached. In order to have both the liveness and safety property, we hence cannot have Byzantine block proposers. The purpose of the flexible subjective decision threshold is to allow for optimistic participants (those assuming a small fraction of Byzantine block proposers) to decide for blocks earlier by only requiring a small decision threshold . On the other hand, pessimistic participants can decide for a block only with a very high decision threshold (with the risk of never making a decision if too many block proposers are Byzantine or offline) with the guarantee that must violate the protocol rules for a conflicting block to be decided. In particular, in the case that slashing conditions are added to punish Byzantine proposers by burning their deposits, this allows to choose a decision threshold depending on the desired safety guarantee in terms of deposit at stake.
For proving the liveness condition of the consensus framework from Definition 3.1, we rely on the partially synchronous system model. Recall that the basic assumption is that after the global stabilization time of GST, all messages arrive reliably with a delay of at most . We assume that the time slots for block proposers to add blocks to the block tree have a duration of at least . This way the underlying network is fast enough for the message about a new block to reach every block proposer and all block proposers to send new prevote and precommit messages that reach every other block proposer before the next block is proposed. This way, all prevotes and precommits can be included in the next block and block proposers at regular times have the same information about the block tree (we assume that blocks, prevote and precommit messages that were lost before time GST are simply rebroadcast).
Additionally, for the liveness property to hold, block proposers need to follow the same fork choice rule, i.e., a rule that defines how the block proposers choose one branch of the block tree as their current chain. More precisely, a fork choice rule is a function that, given the block tree of block proposer (i.e., the block tree containing all blocks received by block proposer ) and the arrival times of all blocks as input, returns one branch of the block tree . We refer to this branch as the canonical chain of . We say that a block proposer follows a fork choice rule if it adds new proposed blocks to the canonical chain and only sends prevote and precommit messages for blocks in the canonical chain. For the liveness proof, we use the fork choice rule defined below.
Definition 3.3 (Longest-Chain).
Let be the current block tree of block proposer and be the largest height of a block in with prevotes by of the block proposers included in one branch of . Then the Longest-Chain fork choice rule returns the longest branch that contains a block at height and messages by of the block proposers. Ties are broken in favor of the complete chain received first.
The essential property that the fork choice rule needs to satisfy is that the branch returned always contains a block of largest height with prevote messages by of the block proposers. The reason is that by 3, once a block proposer casts a precommit for , it can only prevote and precommit for blocks on the same branch as (unless there is a block of height at least with prevotes). Thus, by requiring the canonical chain to include , the block proposers automatically satisfy 3 when casting prevotes and precommits. In general, other fork choice rules that satisfy that the canonical chain always contains are possible and yield the liveness property. An example is Immediate message-driven GHOST proposed for Ethereum [buterin18forkchoice].
If of the block proposers are Byzantine, there can be at most one block at a given height with prevotes by the the block proposers by 1. Thus, in this case in the definition above is unique. Further, note that the tie-breaking in favor of the chain seen first is rather arbitrary and also block hashes, i.e., identifiers associated with every block, can be used. The main point of the tie-breaking is to have a rule that quickly makes the block tree change to a state (by the new proposed blocks) where there are no more ties.
In the following theorem, we show liveness assuming a bound on the weight of crashed block proposers. The reason for not considering Byzantine block proposers is that this would require to make stronger assumptions on the block proposal mechanism. Furthermore, for a concrete application of the general consensus framework it is usually necessary to show liveness again for the concrete block proposal mechanism and additional rules how block proposers send prevote and precommit messages.
Theorem 3.4 (Liveness).
Assume that of the block proposers crash and all other block proposers honestly follow the general consensus protocol and Longest-Chain fork choice rule. Then for any , an honest block proposer with decision threshold will eventually decide on a block at height .
Consider an arbitrary set of blocks proposed and prevotes as well as precommits cast by all proposers with of the block proposers honestly following the consensus protocol from Definition 3.1. Assume that we have reached time . This means that all messages arrive reliably within time and all previously lost messages have been broadcast again and received by all proposers. In particular, the block tree at the beginning of every block proposal time slot is the same for every block proposer . Note that due to lost or delayed messages before time GST, there can initially be multiple chains of the same length that contain a block of largest height with prevotes by of the block proposers. Because of different arrival times of blocks, block proposers could decide for different canonical chains. However, after the first block is proposed, these ties are broken and the Longest-Chain rule yields the same canonical chain for every honest delegate.
Let and be the largest height that any honest block proposer cast a prevote for. We show that an honest block proposer with decision threshold will eventually decide on a block at height . The canonical chain of all honest block proposers continues growing until there are two consecutive blocks and added to the chain with for .
We first show that any honest block proposer can send a message. Assume previously cast a precommit message for a block . We show that the precommit for does not prevent to prevote for . By assumption, was added to the chain that contains the block of largest height for which of the block proposers cast prevotes (at the time when is added to the chain). If is on a branch not containing , then by 3 proposer can prevote for because we have as must have prevotes and is the block of largest height with prevotes. Note that there can be at most one block at every height with prevotes because of 1 and the fact that of the block proposers honestly follow the protocol. If is on the same branch as , then by the choice of either or is an an ancestor of . In both cases, the precommit for allows to prevote for any descendants of , in particular, for . Thus, can prevote for .
Therefore, all honest block proposers can send messages and these messages reach all block proposers before the next block is proposed because we assume that the block proposal time slots have duration . This means that the honest proposer of can include these prevote messages for into the block . After receiving , all honest block proposers can now send a messages. Hence, receives precommits by of the block proposers and any block proposer with decision threshold will decide for and all ancestors of . In particular, any honest block proposer will decide for a block at height since . This shows the claim. ∎
We assume that all messages and are signed by the block proposer . Using the current chain up to block , any block proposer can verify if the messages sent by a block proposer satisfy the consensus protocol rules 1–3. Note that we assume that it is impossible that a block proposer sends a message exclusively to one honest block proposer without all other block proposers eventually being able to learn about it, as the underlying peer-to-peer network will gossip the messages to all block proposers.
3.5 Lightweight consensus messages
In this section, we describe how multiple prevote and precommit messages can be concisely expressed via a single message, which we call an approve message. An message contains a block , two integers with and as well as the block proposer sending the message. In an implementation, can be the hash of the block and the public key and signature of the message by block proposer . Moreover, for the message to be valid, must be the height of the block of largest height that is an ancestor of and the chain up to includes prevotes by of the block proposers for . As a convention, we assume that the genesis block has prevotes by all block proposers. The height can be viewed as redundant information that can be derived from the chain up to block . However, it is essential for a simple expression of the protocol rules and short proofs of any violation of the protocol rules. We now state the rules that block proposers must satisfy when sending approve messages.
Definition 3.5 (Monotonicity-Rule).
The approve messages by a block proposer satisfy the Monotonicity-Rule if for any two distinct messages and with the following conditions are satisfied:
It holds that .
We have .
Let be the current chain of block proposer and for . Then the intuition behind an message is that approves the blocks . We require that holds, such that a non-empty set of blocks up to block is approved. Now, condition 1 of the Monotonicity-Rule requires two approve messages to be for blocks with disjoint sets of heights. Note that, in particular, we cannot have for two distinct messages as otherwise we would obtain . Moreover, 2 ensures that a block proposer only switches to another chain extending a different block with prevotes if that block has no smaller height.
We now describe how an approve message translates to prevote and precommit messages.
Let be one branch of the block tree of proposer . Then an message with implies the following prevotes and precommits:
casts a for every block .
Considering the prevotes and precommits included in the chain (given via approve messages), let
Then casts a for every block in the set that has (implied) prevotes by of the block proposers included in the chain .
The idea is that the block proposer approves the blocks by prevoting for them. Moreover, proposer sends a maximum number of precommits for blocks starting from its previous precommit while satisfying protocol rule 2. Note that for the precommits in 2, it is important that only the prevotes in the chain and not those cast in 1 are taken into account, so that for any we have . This property is needed in the proof of Lemma 3.7.
Next, we show that if a block proposer satisfies the Monotonicity-Rule for the approve messages, then the implied prevote and precommit messages satisfy the protocol rules from Definition 3.1.
Consider two messages Approve and Approve with . Because of condition 1 of the Monotonicity-Rule, we have and thus
Therefore all prevotes are cast for blocks at distinct heights, i.e., 1 is satisfied.
Next, consider an arbitrary that is cast according to the transformation of an message, where we use the notation from Definition 3.6. We then have , where . As , proposer must have cast a prevote for and by definition of the transformation there are messages by of the block proposers included in the chain up to . Hence, 2 is satisfied for all precommit messages.
Finally, consider a message and a message with . If is a descendant of , then 3a is satisfied. Otherwise, we must show that 3b is satisfied, i.e., there exists a block at height with messages by of the block proposers contained in the blockchain up to .
From now on, assume that 3a does not hold. Then both and cannot be implied by the same message , as otherwise is a descendant of . Thus, there have to be two distinct messages and such that the first implies the message and the second implies the message . As is implied by , we must have . For the sake of contradiction, let us assume that . Then the branch up to cannot contain any implied prevote by for a block at height , because we assume that this branch does not contain (otherwise again is a descendant of ), already send a message on a different branch and 1 is satisfied. Using the notation from Definition 3.6, this implies that for the chain up to . Therefore any precommit implied by the message must be for blocks at height larger than . This would mean , a contradiction. Hence, we must have .
As holds, we must have by condition 2 of the Monotonicity-Rule. Note that we must have as is the largest height of a block with prevotes by of the block proposers included in the chain up to . Let be the block at height that is an ancestor of . We have and there are messages by of the block proposers contained in the blockchain up to . Thus, 3 is also satisfied. ∎
By Lemma 3.7, the protocol rules 1–3 are satisfied when block proposers cast prevotes and precommits implicitly via approve messages. This means that also Theorem 3.2 holds for the case that block proposers only use approve messages for the consensus algorithm.
Assume for the consensus algorithm block proposers only use approve messages that are transformed according to Definition 3.6 and for any honest proposer the approve messages satisfy the Monotonicity-Rule. If there are Byzantine block proposers for , then any two honest block proposers with decision threshold at least never decide for conflicting blocks.
3.6 Dynamic set of block proposers
So far, we only considered a static set of block proposers . In blockchains, however, this set is typically changing over time as block proposers may want to stop participating in proof-of-stake and withdraw their deposit or different delegates get voted in the top ranks in a delegated proof-of-stake system. The interesting question is what the implications of a dynamically changing set of block proposers are for the safety and liveness guarantees from the last sections.
One approach is that a change of block proposers (e.g., because of withdrawals, deposits or votes) is always possible and comes into effect without requiring any finality, i.e., without requiring that the block or a descendant of the block containing the information of the change of block proposers receives precommits by a certain threshold of block proposers. We discuss this approach and prove some weaker safety guarantees for it.
Due to efficiency reasons, we only allow the set of block proposers to change at certain heights and group blocks into rounds. We assume there is a constant such that for every the set of integers are associated with one round. We then say that for a branch of the block tree, where has height , the blocks belong to round . We further refer to as the first block of round and to as the last block of round . Considering one branch of the block tree, the blocks of one round have an associated active set of block proposers , i.e., only a block proposer in the active set of block proposers for a round is allowed to propose blocks and cast prevotes and precommits for the blocks of round .
Furthermore, apart from a change in block proposers, it can happen that the weight associated with a block proposer changes (e.g., due to a change in stake). For the following results, we need to distinguish between the new and the unchanged block proposers. Hence, we model an increase of weight of block proposer from to by assuming that a new block proposer with weight is added to the new set of block proposers. Similarly, for a decrease of weight from to , we assume that the original set of block proposers contains two block proposers and with weights and , respectively. The change of weight in this case is then modeled by leaving the set of block proposers. This allows us to only consider a change in the set of block proposers and not additionally consider changes of weights. Note that for any active set of block proposers the weights always need to satisfy .
Definition 3.9 (Unconstrained change of block proposers).
We assume that there is an initial set of block proposers for round defined in the genesis block . Let be a constant describing the delay in rounds when changes of block proposers take into effect. For every round with , the set of active block proposers for round is defined by the information in the current chain up to the last block of round , i.e., block . Moreover, only the active block proposers at round can propose blocks at heights and send prevote and precommit messages for blocks at heights .
Note that for , the changes of block proposers take into effect immediately in the next round. Moreover, if block proposers cast prevotes and precommits implicitly via approve messages, then for a message to be valid we require to be active in the rounds associated to the blocks . This way any implied cast according to Definition 3.6 is for a block where is active. As a precommit is only implied if P previously made an implicit prevote, it holds that also all implied precommits are for blocks where is active.
We now show sufficient conditions for the safety and liveness property for the case of block proposers that change according to the mechanism described above.
Let be the sets of block proposers that are active in any round on any branch. Then the following properties hold:
If contains at least honest block proposers, then two honest block proposer in with decision threshold at least never decide for conflicting blocks (Safety).
Assume that of the block proposers in crash and all other block proposers in honestly follow the general consensus protocol and Longest-Chain fork choice rule. While the block proposers are active, it is possible for any block proposer with decision threshold to decide on new blocks assuming the global stabilization time is reached (Liveness).
The proof of the first part of the claim is similar to the proof of Theorem 3.2. Assume, for the sake of contradiction, that there are two conflicting blocks and as well as an honest block proposer with decision threshold deciding for and an honest block proposers with decision threshold deciding for . Let further be the set of active block proposers associated with block and similarly be the set of active block proposers associated with block . By assumption we have and . Hence, there must be messages cast by of the block proposers in and also messages cast by of the block proposers in .
Let be the set of honest block proposers that is contained in by assumption. In particular, we have . There are block proposers in that are not contained in and thus there are block proposers in that sent a message. Analogously, there are also block proposers in that must have sent a message.
Without loss of generality, we assume . Let be the subset of block proposers that send a precommit for . By 2, every proposer must have also cast a message. Thus, by 1, no proposer in sends a prevote for any other block at height . We must therefore have as otherwise cannot obtain prevotes because is contained in every active set of block proposers.
By 3, every block proposer is only allowed to send a prevote message for a block that is not a descendant of if there is a block at height with messages by of the block proposers. As all block proposers in are honest, there have to be prevotes for such a block by block proposers not in . This is a contradiction, as is a set of block proposers that is contained in any active set of block proposers. Hence, no block that is not a descendant of can obtain prevotes and thus no honest block proposer sends a precommit for . This means that the decision threshold of precommit messages for block cannot be reached contradicting that the honest block proposer decided for .
For the liveness property, the change of block proposers is not relevant and we obtain the result directly from Theorem 3.4. ∎
The above theorem shows that the safety guarantee is only slightly weaker if only a small fraction of the block proposers change. However, several changes of a small fraction of block proposers over time could amount to almost all block proposers changing. The following result shows that as long as the block proposers finalize blocks in between these changes of block proposers, we can improve the safety guarantee above.
Let and . Let be two blocks in one branch such that is the descendant of with minimal height such that the chain up to contains precommits for a descendant of . We assume that between all such pairs of blocks and in the block tree honest proposers in the active set of block proposers change. If there are honest block proposers in any active set of block proposers, then two block proposers with decision threshold at least never decide for conflicting blocks.
As the set of block proposers is changing over time, there can now be blocks at the same height which assume a different set of block proposers. For instance, one chain may contain the information regarding a change of block proposers, whereas another chain does not. Thus, we now associate a unique active set of block proposers to every block of the block tree, which is determined using the rule given in Definition 3.9.
Let us assume, for the sake of contradiction, that there are two conflicting blocks and such that an honest block proposer with decision threshold decides for and another honest block proposers with decision threshold decides for . Let be the block of largest height that is a common ancestor of and . Moreover, let be the first descendant of on the branch containing that has precommits contained in that branch. Similarly, let be the first descendant of on the branch containing that has precommits contained in that branch. The setting is shown in Figure 2. As , there must be at least precommits for contained in the branch containing and therefore we must have or is an ancestor of . The same holds for and . Without loss of generality let .
For , let be the set of block proposers associated with . By assumption, honest block proposers change before a block on a branch receives precommits and there are honest block proposers in any active set of block proposers. Thus, contains a subset of honest block proposers. Hence, must contain a subset of honest block proposers of weight that is also contained in the active set of proposers associated to any block on the path from to or the path from to . By assumption, there are by of the block proposers in the chain containing and contains proposers not contained in . Therefore, there must be a subset of honest block proposers that cast a precommit for . This also implies that we cannot have as there can only be prevotes for and hence no honest block proposer would cast a by 2. Thus, the threshold of precommits for block cannot be reached in this case and we must have .
By 3, every block proposer is only allowed to send a prevote message for a block that is not a descendant of if there is a block at height with messages by of the block proposers. As all block proposers in are honest, there have to be prevotes for such a block by block proposers not in . This is a contradiction, as is a set of block proposers that is contained in the active set of proposers associated with every block on the path from to . Hence, no block that is not a descendant of can obtain prevotes and thus no honest block proposers sends a precommit for . This means that the threshold of precommits for block cannot be reached, which is a contradiction. ∎
Theorem 3.11 outlines a way how we can maintain close to optimal safety guarantees while allowing dynamic block proposers. Assume that we only allow a change of block proposers with overall weight at a time, i.e., after a change of block proposers from to we require the new set of block proposers to finalize a block before another change of block proposers can occur. If we assume that we always have honest block proposers at any given time, then Theorem 3.11 yields that the safety property is satisfied.
Allowing an arbitrary large change of block proposers at a given time while preserving the safety property under the assumption that at any time of the block proposers are honest, requires a much more complex mechanism of two set of block proposers, i.e., both and , to vote on the same blocks. For the Casper the Friendly Finality Gadget consensus algorithm this approach is sketched in [buterin17].
4 Lisk-Bft consensus protocol
We now describe Lisk-Bft, a proposed consensus protocol for the Lisk blockchain, which is based on the general consensus framework from the last section. Lisk uses a delegated proof-of-stake system, where 101 block proposers, which are referred to as active delegates, are determined via voting. The delegates have uniform weights for all . The condition delegates therefore translates to at least delegates and threshold delegates to at most delegates. Moreover, consecutive blocks are grouped into one round in Lisk and block proposal slots of one round are assigned in a round-robin fashion.
Instead of using separate consensus messages, all prevotes and precommits are implied by two additional integers added to blocks using the same idea as the lightweight consensus messages introduced in the last section. Hence, the additional two integers in the block headers are the only overhead of the Lisk-Bft consensus protocol.
Definition 4.1 (Lisk-Bft).
Let be the current chain of delegate and be the height of the first block of the round since when has been continuously active delegate.
When proposes block as a child of , it adds the following information to the block header:
The largest height of a block that previously proposed (on any branch) and if has not proposed any block.
The height of the block of largest height with at least prevotes in the current chain .
In general, for a block we use the notation and to refer to the values above.
If holds, then the information in the block header of implies prevotes and precommits for blocks in the following order:
Let . Then the block header implies a for every block .
Considering the implied prevotes and precommits included in the chain (via the additional information in the block headers), let
Then the block header implies a for every block in the set that has prevotes by at least delegates included in the chain .
A block and all ancestors of are finalized if there are precommits for by at least delegates included in the chain .
The active delegates of round are determined taking all votes included in the blockchain up to the end of round into account (without requiring finality).
Delegates follow the Longest-Chain rule, where the block of largest height with at least 68 prevotes in a chain is computed taking only the prevotes implied by blocks , and not those implied by , into account.
The Lisk-Bft protocol is an application of the general consensus framework from the last section, where delegates only cast prevotes and precommits via the additional information in the block headers. The values and in the block header of block correspond to the delegate first proposing block and afterwards sending the message . However, the transformation of the header information to prevote and precommit messages above contains two modifications compared to the transformation for approve messages in Definition 3.6. First of all, we have instead of . The reason for enforcing is to ensure that the implied prevotes are only for blocks at heights where delegate was active. We further enforce for performance reasons so that it is sufficient to consider the last blocks when updating the number of prevotes for blocks. Note that the parameter is chosen due to the fact that a block can be finalized after additional blocks are added on top (see the liveness proof of Theorem 4.3), but depending on the ordering of delegates in a round, additional blocks are not always sufficient. Secondly, we have instead of . Again, this ensures that all implied precommits are for blocks where was active and also for performance reasons all precommits are only for a subset of the last 303 blocks. Overall, it is important to note that the prevotes and precommits implied by the transformation above are a subset of the prevotes and precommits implied according to Definition 3.6 when instead sending the message .
A subtlety of the transformation 2b above is that we consider only the prevotes implied by all blocks up to and not the prevotes implied by 2a. This is analogous to the transformation for approve messages in Definition 3.6.
We establish some basic properties of the Lisk-Bft protocol in the following lemma.
Let and be two distinct blocks proposed by an honest delegate according to the Lisk-Bft protocol. Then the following properties hold:
The Longest-Chain rule implies that a branch with tip is chosen over a branch with tip , if the following conditions are satisfied:
If is proposed before , then the following inequalities hold:
If is proposed before and holds, then we must have .
Block is proposed before if and only if
where is the lexicographical ordering.
According to the Longest-Chain rule, the first deciding factor is the largest height of a block with at least prevotes contained in some branch of the block tree. For a chain with tip , the largest height of a block with at least prevotes is given by because the prevotes implied by the block header of are not taken into account. If there are multiple chains that contain a block with at least prevotes of the same height, then the longer chain containing these prevotes has priority according to the Longest-Chain rule. This immediately yields the condition in the claim.
As is proposed after and the largest height of a block previously proposed is non-decreasing, we must have . As delegate follows the Longest-Chain rule, the tips of the canonical chain of satisfy that is non-decreasing by claim 1. Thus, we must have . Moreover, when proposing , the largest height of a block previously proposed must be at least . This implies .
By claim 1, every time delegate switches to a different chain, either is strictly increasing or it remains unchanged and the height of the tip strictly increases. The same holds every time a new child is added to the tip of the chain of delegate (either proposed by or another delegate). Thus, if holds, then we must have