A lightweight BFT consensus protocol for blockchains

03/27/2019 ∙ by Jan Hackfeld, et al. ∙ 0

We present a general consensus framework that allows to easily introduce a customizable Byzantine fault tolerant consensus algorithm to an existing (delegated) proof-of-stake blockchain. We prove the safety of the protocol under the assumption that less than 1/3 of the block proposers are Byzantine. The framework further allows for consensus participants to choose subjective decision thresholds in order to obtain safety even in the case of a larger proportion of Byzantine block proposers. Moreover, the liveness of the protocol is shown if less than 1/3 of the block proposers crash. Based on the framework, we introduce Lisk-BFT, a Byzantine fault tolerant consensus algorithm for the Lisk blockchain. Lisk-BFT integrates with the existing block proposal, requires only two additional integers in block headers and no additional messages. The protocol is simple and provides safety in the case of static proposers if less than 1/3 of the block proposers are Byzantine. For the case of dynamically changing proposers, we proof the safety of the protocol assuming a bound on the number of Byzantine proposers and the number of honest proposers that can change at one time. We further show the liveness of the Lisk-BFT protocol for less than 1/3 crashing block proposers.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

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.

Definition 3.1.

The prevotes and precommits send by a block proposer  must obey the following rules:

  1. [label=()]

  2. For any two distinct messages  and , it holds that .

  3. For any message , the blockchain up to block  must include both

    1. [label = (), ref=2 ()]

    2. one message and

    3. messages by  of the block proposers.

  4. For any two messages and with at least one of the following conditions is satisfied:

    1. [label = (), ref=3 ()]

    2. is a descendant of .

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

3.2 Safety

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.

Proof.

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 .

0

1

2

3

4

5
Figure 1: Block tree with two contradicting blocks  and .

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

Remark.

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.

3.3 Liveness

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 .

Proof.

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

3.4 Accountability

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 13. 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:

  1. [label=()]

  2. It holds that .

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

Definition 3.6.

Let be one branch of the block tree of proposer . Then an message with implies the following prevotes and precommits:

  1. [label=()]

  2. casts a for every block .

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

Lemma 3.7.

If the approve messages by a block proposer  satisfies the Monotonicity-Rule and sends no additional prevote or precommit messages, then the prevotes and precommits implied by the transformation in Definition 3.6 satisfy the protocol rules 13.

Proof.

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

Corollary 3.8.

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.

Theorem 3.10.

Let be the sets of block proposers that are active in any round on any branch. Then the following properties hold:

  1. [label=()]

  2. If contains at least  honest block proposers, then two honest block proposer in  with decision threshold at least  never decide for conflicting blocks (Safety).

  3. 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).

Proof.

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.

Theorem 3.11.

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.

Proof.

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 .

Figure 2: Block tree with two contradicting blocks  and .

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

Remark.

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.

  1. When proposes block  as a child of , it adds the following information to the block header:

    [style=multiline,leftmargin=2cm,font=]

    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.

  2. If holds, then the information in the block header of  implies prevotes and precommits for blocks in the following order:

    1. [label=(),ref=2 ()]

    2. Let . Then the block header implies a for every block .

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

  3. A block  and all ancestors of  are finalized if there are precommits for  by at least  delegates included in the chain .

  4. 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).

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

Lemma 4.2.

Let and be two distinct blocks proposed by an honest delegate  according to the Lisk-Bft protocol. Then the following properties hold:

  1. [label=()]

  2. The Longest-Chain rule implies that a branch with tip  is chosen over a branch with tip , if the following conditions are satisfied:

  3. If is proposed before , then the following inequalities hold:

  4. If is proposed before  and holds, then we must have .

  5. Block  is proposed before  if and only if

    (1)

    where is the lexicographical ordering.

  6. If any two blocks by delegate  satisfy the inequalities in 2, then the implied prevotes and precommits according to the Lisk-Bft protocol satisfy the conditions of the general consensus framework in Definition 3.1.

Proof.
  1. [label=()]

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

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

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