Correctness and Fairness of Tendermint-core Blockchains

05/22/2018
by   Yackolley Amoussou-Guenou, et al.
0

Tendermint-core blockchains offer strong consistency (no forks) in an open system relying on two ingredients (i) a set of validators that generate blocks via a variant of Practical Byzantine Fault Tolerant (PBFT) consensus protocol and (ii) a rewarding mechanism that dynamically selects nodes to be validators for the next block via proof-of-stake, a non-energy consuming alternative of proof-of-work. It is well-known that in those open systems the main threat is the tragedy of commons that may yield the system to collapse if the rewarding mechanism is not adequate. At minima the rewarding mechanism must be f air, i.e. distributing the rewards in proportion to the merit of participants. The contribution of this paper is twofold. First, we provide a formal description of Tendermint-core protocol and we prove that in eventual synchronous systems (i) it verifies a variant of one-shot consensus for the validation of one single block and (ii) a variant of the repeated consensus problem for multiple blocks. Our second contribution relates to the fairness of Tendermint rewarding mechanism. We prove that Tendermint rewarding is not fair. However, a small twist in the protocol makes it eventually fair. Additionally, we prove that there exists an (eventual) fair rewarding mechanism in repeated consensus-based blockchains if and only if the system is (eventually) synchronous.

READ FULL TEXT VIEW PDF

page 1

page 2

page 3

page 4

10/22/2019

On Fairness in Committee-based Blockchains

Committee-based blockchains are among the most popular alternatives of p...
01/31/2020

Tenderbake – Classical BFT Style Consensus for Public Blockchains

Our work has been originally motivated by Tezos, a public blockchain whi...
07/24/2022

Approach to Alleviate Wealth Compounding in Proof-of-Stake Cryptocurrencies

Due to its minimal energy requirement the PoS consensus protocol has bec...
05/28/2021

SoK: Achieving State Machine Replication in Blockchains based on Repeated Consensus

This paper revisits the ubiquitous problem of achieving state machine re...
02/21/2019

Rationals vs Byzantines in Consensus-based Blockchains

In this paper we analyze from the game theory point of view Byzantine Fa...
09/26/2018

Dissecting Tendermint

In this paper we analyze Tendermint proposed in [7], one of the most pop...
01/06/2021

Highway: Efficient Consensus with Flexible Finality

There has been recently a lot of progress in designing efficient partial...

1 Introduction

Blockchain is today one of the most appealing technologies since its introduction in the Bitcoin White Paper [37] in 2008. Blockchain systems, similar to P2P systems in the early 2000, take their roots in the non academical research. After the releasing of the most popular blockchains (e.g. Bitcoin [37] or Ethereum [43]) with a specific focus on economical transactions, their huge potential for various other applications ranging from notary to medical data recording became evident. In a nutshell, Blockchain systems maintain a continuously-growing history of ordered information, encapsulated in blocks. Blocks are linked to each other by relying on collision resistant hash functions, i.e., each block contains the hash of the previous block. The Blockchain itself is a distributed data structure replicated among different peers. In order to preserve the chain structure those peers need to agree on the next block to append in order to avoid forks. The most popular technique to decide which block will be appended is the proof-of-work mechanism of Dwork and Naor [18]. The block that will be appended to the blockchain is owned by the node (miner) having enough CPU power to solve first a crypto-puzzle. The only possible way to solve this puzzle is by repeated trials. The major criticisms for the proof-of-work approach are as follows: it is assumed that the honest miners hold a majority of the computational power, the generation of a block is energetically costly, which yield to the creation of mining pools and finally, multiple blockchains that coexist in the system due to accidental or intentional forks.

Recently, the non academic research developed alternative solutions to the proof-of-work technique such as proof-of-stake (the power of block building is proportional to the participant wealth), proof-of-space (similar to proof-of-work, instead of CPU power the prover has to provide the evidence of a certain amount of space) or proof-of-authority (the power of block building is proportional to the amount of authority owned in the system). These alternatives received little attention in the academic research. Among all these alternatives proof-of-stake protocols and in particular those using variants of Practical Byzantine Fault-Tolerant consensus [10] became recently popular not only for in-chain transaction systems but also in systems that provide cross-chain transactions. Tendermint [34, 8, 32, 35] was the first in this line of research having the merit to link the Practical Byzantine Fault-Tolerant consensus to the proof-of-stake technique and to propose a blockchain where a dynamic set of validators (subset of the participants) decide on the next block to be appended to the blockchain. Although, the correctness of the original Tendermint protocol [34, 8, 32] has never been formally analyzed from the distributed computing perspective, it or slightly modified variants became recently the core of several popular systems such as Cosmos [33] for cross-chain transactions.

In this paper we analyse the correctness of the original Tendermint agreement protocol as it was described in [34, 8, 32] and discussed in [35, 28]. The code of this protocol is available in [42]. One of our fundamental results proved in this paper is as follows:

In an eventual synchronous system, a slightly modified variant of the original Tendermint protocol implements the one-shot and repeated consensus, provided that (i) the number of Byzantine validators, , is where is the number of validators participating in each single one-shot consensus instance and (ii) eventually a proposed value will be accepted by at least processes (Theorem 7 and Theorem 11).

More in detail, we prove that the original Tendermint verifies the consensus termination with a small twist in the algorithm (a refinement of the timeout) and with the additional assumption stating that there exists eventually a proposer such that its proposed value will be accepted, or voted, by more than two-third of validators.

We are further interested in the fairness of Tendermint-core blockchains because without a glimpse of fairness in the way rewards are distributed, these blockchains may collapse. Our fairness study, in line with Francez definition of fairness [23], generally defines the fairness of protocols based on voting committees (e.g. Byzcoin[31], PeerCensus[14], RedBelly [12], SBFT [25] and Hyperledger Fabric [3] etc), by the fairness of their selection mechanism and the fairness of their reward mechanism. The selection mechanism is in charge of selecting the subset of processes that will participate to the agreement on the next block to be appended to the blockchain, while the reward mechanism defines the way the rewards are distributed among processes that participate in the agreement. The analysis of the reward mechanism allowed to establish our second fundamental result with respect to the fairness of repeated-consensus blockchains as follows:

There exists a(n) (eventual) fair reward mechanism for repeated-consensus blockchains if and only if the system is (eventual) synchronous (Theorem 16).

Moreover, we show that even in an eventual synchronous setting, the original Tendermint protocol is not eventually fair, however with a small twist in the way delays and commit messages are handled it becomes eventually fair.

Note that our work is the first to analyze the fairness of protocols based on voting committees elected by selection mechanisms as proof-of-stake.

The rest of the paper is organized as follows. Related works are discussed in Section 2. Section 3 defines the model and the formal specifications of one-shot and repeated consensus. Section 4 formalizes the original Tendermint protocol through pseudo-code and proves the correctness of the One-Shot Consensus anf the Repeated Consensus algorithms. In Section 5 we present a full descriptions of the counter-example that motivates the modification of the original algorithm and the additioinal assumptions needed for the correctness. Section 6 discusses the necessary and sufficient conditions for a protocol based on repeated consensus to achieve a fair rewarding.

2 Related Work

Interestingly, only recently distributed computing academic scholars focus their attention on the theoretical aspects of blockchains motivated mainly by the intriguing claim of popular blockchains, as Bitcoin and Ethereum, that they implement consensus in an asynchronous dynamic open system. This claim is refuted by the famous impossibility result in distributing computing [22].

In distributed systems, the theoretical studies of proof-of-work based blockchains have been pioneered by Garay et al [24]. Garay et al. decorticate the pseudo-code of Bitcoin and analyse its agreement aspects considering a synchronous round-based communication model. This study has been extended by Pass et al. [38] to round based systems where messages sent in a round can be received later. In order to overcome the drawbacks of Bitcoin, [20]

proposes a mix between proof-of-work blockchains and proof-of-work free blockchains referred as Bitcoin-NG. Bitcoin-NG inherits the drawbacks of Bitcoin: costly proof-of-work process, forks, no guarantee that a leader in an epoch is unique, no guarantee that the leader does not change the history at will if it is corrupted.

On another line of research Decker et al. [14] propose the PeerCensus system that targets linearizability of transactions. PeerCensus combines the proof-of-work blockchain and the classical results in Practical Byzantine Fault Tolerant agreement area. PeerCensus suffers the same drawbacks as Bitcoin and Byzcoin against dynamic adversaries.

Byzcoin [31] builds on top of Practical Byzantine Fault-Tolerant consensus [10] enhanced with a scalable collective signing process. [31] is based on a leader-based consensus over a group of members chosen by a proof-of-membership mechanism. When a miner succeeds to mine a block, it gains a membership share, and the miners with the highest shares are part of the fixed size voting member set. In the same spirit, SBFT [25] and Hyperledger Fabric [3] build on top of [10].

In order to avoid some of the previously cited problems, Micali [36] introduced (further extended in [6, 11]) sortition based blockchains, where the proof-of-work mechanism is completely replaced by a probabilistic ingredient.

The only academic work that addresses the consensus in proof-of-stake based blockchains is authored by Daian et al. [13], which proposes a protocol for weakly synchronous networks. The execution of the protocol is organized in epochs. Similar to Bitcoin-NG [20] in each epoch a different committee is elected and inside the elected committee a leader will be chosen. The leader is allowed to extend the new blockchain. The protocol is validated via simulations and only partial proofs of correctness are provided. Ouroboros [29] proposes a sortition based proof-of-stake protocol and addresses mainly the security aspects of the proposed protocol. Red Belly [12] focuses on consortium blockchains, where only a predefined subset of processes are allowed to append blocks, and proposes a Byzantine consensus protocol.

Interestingly, none of the previous academic studies made the connection between the repeated consensus specification [5, 16, 15] and the repeated agreement process in blockchain systems. Moreover, in terms of fairness of rewards, no academic study has been conducted related to blockchains based on repeated consensus.

The closest works in blockchain systems to our fairness study (however very different in its scope) study the chain-quality. In [24], Garay et al. define the notion of chain-quality as the proportion of blocks mined by honest miners in any given window and study the conditions under which the ratio of blocks in the chain mined by malicious players over the total number of blocks in a given window is bounded. Kiayias et al. in [29] propose Ouroboros [29] and also analyse the chain-quality property. Pass et al. address in [39] one of the vulnerabilities of Bitcoin studied formally in Eyal and Sirer [21]. In [21] the authors prove that if the adversary controls a coalition of miners holding even a minority of the computational power, this coalition can gain twice its share. Fruitchain [39] overcomes this problem by ensuring that no coalition controlling less than a majority of the computational power can gain more than a factor by not respecting the protocol, where is a parameter of the protocol. In [19], Eyal analyses the consequences of attacks in systems where pools of miners can infiltrate each other and shows that in such systems there is an equilibrium where all pools earn less than if there were no attack. In [26], Guerraoui and Wang study the effect of message propagation delays in Bitcoin and show that, in a system of two miners, a miner can take advantage of the delays and be rewarded exponentially more than its expectation. In [27], Gürcan et al. study the fairness from the point of view of users that do not participate to the mining. A similar work is done by Herlihy and Moir in [28] where the authors study the users fairness and consider as an example the original Tendermint [34, 8, 32]. The authors discussed how processes with malicious behaviour can violate fairness by choosing transactions, then they propose modifications to the original Tendermint to make those violations detectable and accountable.

3 System model and Problem Definition

The system is composed of an infinite set of asynchronous sequential processes, namely ; is called the index of . Asynchronous means that each process proceeds at it own speed, which can vary with time and remains unknown to the other processes. Sequential means that a process executes one step at a time. This does not prevent it from executing several threads with an appropriate multiplexing. As local processing time are negligible with respect to message transfer delays, they are considered as being equal to zero.

Arrival model. We assume a finite arrival model [1], i.e. the system has infinitely many processes but each run has only finitely many. The size of the set of processes that participate in each system run is not a priori-known. We also consider a finite subset of validators. The set may change during any system run and its size is a-priori known. A process is promoted in based on a so-called merit parameter, which can model for instance its stake in proof-of-stake blockchains. Note that in the current Tendermint implementation, it is a separate module included in the Cosmos project [33] that is in charge of implementing the selection of .

Communication network. The processes communicate by exchanging messages through an eventually synchronous network [17]. Eventually Synchronous means that after a finite unknown time there is a bound on the message transfer delay.

Failure model. There is no bound on processes that can exhibit a Byzantine behaviour [40] in the system, but up to validators can exhibit a Byzantine behaviour at each point of the execution. A Byzantine process is a process that behaves arbitrarily: it can crash, fail to send or receive messages, send arbitrary messages, start in an arbitrary state, perform arbitrary state transition, etc. Byzantine processes can control the network by modifying the order in which messages are received, but they cannot postpone forever message receptions. Moreover, Byzantine processes can collude to “pollute” the computation (e.g., by sending messages with the same content, while they should send messages with distinct content if they were non-faulty). A process (or validator) that exhibits a Byzantine behaviour is called faulty. Otherwise, it is non-faulty or correct or honest. To be able to solve the consensus problem, we assume that .

Communication primitives. In the following we assume the presence of a broadcast primitive. A process broadcasts a message by invoking the primitive , where TAG is the type of the message, and its content. To simplify the presentation, it is assumed that a process can send messages to itself. The primitive is a best effort broadcast, which means that when a correct process broadcasts a value, eventually all the correct processes deliver it. A process receives a message by executing the primitive . Messages are created with a digital signature, and we assume that digital signatures cannot be forged. When a process delivers a message, it knows the process that created the message.

Let us note that the assumed broadcast primitive in an open dynamic network can be implemented through , i.e. each process sends the message to current neighbors in the underlying dynamic network graph. In these settings the finite arrival model is a necessary condition for the system to show eventual synchrony. Intuitively, a finite arrival implies that message losses due to topology changes are bounded, so that the propagation delay of a message between two processes not directly connected can be bounded [4].

Problem definition. In this paper we analyze the correctness of Tendermint protocol against two abstractions in distributed systems: consensus and repeated consensus defined formally as follows.

Definition 3.1 (One-Shot Consensus).

We say that an algorithm implements One-Shot Consensus if and only if it satisfies the following properties:

  • Termination. Every correct process eventually decides some value.

  • Integrity. No correct process decides twice.

  • Agreement. If there is a correct process that decides a value , then eventually all the correct processes decide .

  • Validity[12]. A decided value is valid, it satisfies the predefined predicate denoted .

The concept of multi-consensus is presented in [5], where the authors assume that only the faulty processes can postpone the decision of correct processes. In addition, the consensus is made a finite number of times. The long-lived consensus presented in [16] studies the consensus when the inputs are changing over the time, their specification aims at studying in which condition the decisions of correct process do not change over time. None of these specifications is appropriate for blockchain systems. In [15], Delporte-Gallet et al. defined the Repeated Consensus as an infinite sequence of One-Shot Consensus instances, where the inputs values may be completely different from one instance to another, but where all the correct processes have the same infinite sequence of decisions. We consider a variant of the repeated consensus problem as defined in [15]. The main difference is that we do not predicate on the faulty processes. Each correct process outputs an infinite sequence of decisions. We call that sequence the output of the process.

Definition 3.2 (Repeated Consensus).

An algorithm implements a repeated consensus if and only if it satisfies the following properties:

  • Termination. Every correct process has an infinite output.

  • Agreement. If the value of the output of a correct process is , then is the value of the output of any other correct process.

  • Validity. Each value in the output of any correct process is valid, it satisfies the predefined predicate denoted .

4 Tendermint Formalization

4.1 Informal description of Tendermint and its blockchain

Tendermint protocol [34, 8] aims at building a blockchain without forks relying on a variant of PBFT consensus. When building the blockchain, a subset of fixed size of processes called validators should agree on the next block to append to the blockchain. The set of validators is deterministically determined by the current content of the blockchain, referred as the history. We note that this subset may change once a block is appended. The mechanism to choose the validators from a given history is further referred as selection mechanism. Note that in the current Tendermint implementation, it is a separate module included in the Cosmos project [33] that is in charge of implementing the selection mechanism. Intuitively, such mechanism should be based on the proof-of-stake approach but its actual implementation is currently left open. Let us recall that Tendermint agreement protocol relies on the assumption that the selection mechanism, for each block, selects up to Byzantine processes from the current history.

The first block of Tendermint blockchain, called the genesis block, is at height . The height of a block is the distance that separates that block to the genesis block. Each block contains: (i) a Header which contains a pointer to the previous block and the height of the block, (ii) the Data which is a list of transactions, and (iii) a set LastCommit which is the set of validators that signed on the previous block. Except the first block, each block refers to the previous block in the chain. Given a current height of Tendermint blockchain, a total ordered set of validators is selected to add a new block. The validators start a One-Shot Consensus algorithm. The first validator creates and proposes a block , then if more than of the validators accept , will be appended as the next block, otherwise the next validator proposes a block, and the mechanism is repeated until more than of the validators accept a block. For each height of Tendermint blockchain, the mechanism to append a new block is the same, only the set of validators may change. Therefore, Tendermint applies a Repeated Consensus algorithm to build a blockchain, and at each height, it relies on a One-Shot Consensus algorithm to decide the block to be appended.

Although the choice of validators is managed by a separate module (see Cosmos project [33]) the rewards for the validators that contributed to the block at some specific height are determined during the construction of the block at height . The validators for that get a reward for are the ones that validators for “saw” when proposing a block. This mechanism can be unfair, since some validator for may be slow, and its messages may not reach the validators involved in , implying that it may not get the rewards it deserved.

4.2 Tendermint One-Shot Consensus algorithm

Function consensus; %One-Shot Consensus for the super-round with the set of processes% Init: (1) ; ; ; ; (2) ; ; (3) ; ; ;  ———————————————————————————————————————————————– while do (4) ;  ———————————————————— Propose step ———————————————————— (5) if then (6) if then ; ; (7) else ; (8) endif (9) trigger broadcast ; (10)  else (11) set to ; (12) wait until (( expired; (13) if expired then (14) ; (15) endif (16) endif  ———————————————————— Prevote step ———————————————————— (17) if then (18) wait until ; (19) if then ; endif (20) endif (21) if ( then trigger broadcast ; (22)  else if (isValid then trigger broadcast ; endif (23)  else trigger broadcast ; (24) endif (25) wait until ); %Delivery of any 2n/3 prevotes for the round % (26) if then (27) set to ; (28) wait until ( expired); (29) if expired then ; endif  ———————————————————— Precommit step ——————————————————– (30) if then (31) ; (32) trigger broadcast ; (33) ; (34)  else if then (35) ; ; (36) trigger broadcast ; (37)  endif (38)  else trigger broadcast ; (39) endif (40) wait until ) endwhile

Figure 1: First part of Tendermint One-shot Consensus algorithm at correct process .

upon event delivery : (41) if then (42) ; (43) ; (44) trigger broadcast ; (45) endif  ———————————————————————————————————— upon event delivery : (46) if then (47) ; (48) trigger broadcast ; (49) if and then (50) ; (51) goto Prevote step ; (52) endif (53) endif  ———————————————————————————————————— upon event delivery : (54) if then (55) ; (56) trigger broadcast ; (57) if and then (58) ; (59) goto Precommit step ; (60) endif (61) endif  ———————————————————————————————————— when : (62) return B’;%Terminate the consensus for the super-round by deciding %

Figure 2: Second part of Tendermint One-shot Consensus algorithm at correct process .

4.3 Correctness of Tendermint One-Shot Consensus

In this section we prove the correctness of Tendermint One-Shot Consensus algorithm (Fig. 2) for a height under the assumption that during the synchronous period there exists eventually a proposer such that its proposed value will be accepted by at least processes.

Lemma 1 (One-Shot Integrity).

In an eventual synchronous system, Tendermint One-Shot Consensus Algorithm verifies the following property: No correct process decides twice.

Proof The proof follows by construction. A correct process decides when it returns (line 2).

Lemma 2 (One-Shot Validity).

In an eventual synchronous system, Tendermint One-Shot Consensus Algorithm verifies the following property: A decided value is valid, if it satisfies the predefined predicate denoted .

Proof

Let be a correct process, we assume that there exists a value , such that decides . We show by construction that if decides on a value , then is valid.

If decides , then (line 2), since the signature of the messages are unforgeable and by hypothesis, then more than of those precommits for round are from correct processes. This means that for each of those correct processes , (lines 1 - 1), and thus at least of those prevotes are from correct processes.

Let be one of the correct processes which prevoted on during the round . prevotes on a value during a round in two cases: Case a, during , is not locked on any value or Case b: is already locked on and does not checks its validity (lines 1 - 1).

  • Case a: If is not locked on any value than before prevoting it checks the validity of and prevotes on if is valid (line 1);

  • Case b: If was locked on , it did not check the validity of , it means that was locked on during the round ; which means that there was a round such that had a PoLC for for the round (lines 1 - 1), by the same argument, there is a round which happened before where was locked or is valid.

    Since a process locked during a round smaller than the current one, and that there exists a first round where all correct processes are not locked (line 1), there is a round where was not locked on but prevoted , as in Case a, checks if is valid and then prevotes on if is valid (lines 1).

A value prevoted by a correct process is thus valid. Therefore a decided value by a correct process is valid since more than correct processes prevote that value.

Lemma 3.

In an eventual synchronous system, Tendermint One-Shot Consensus Algorithm verifies the following property: If correct processes locked on the same value during a round then no correct process can lock during round on a value .

Proof We assume that correct processes are locked on the same value during the round , and we denote by the set of those processes. We first prove by induction that no process in will unlock or lock on a new value. Let let .

  • Initialization: round . At the beginning of round , all processes in are locked on . Moreover, we have that , since locks on round (line 1). Let be the proposer for round . If , it means that is also locked on , since there cannot be a value such that , for that to happen, at least processes should prevote both and during round , which means that at least a correct process prevoted two times in the same round, which is not possible, since it is correct, and the protocol does not allow to vote two times in the same round (lines 1 - 1). Three cases can then happen:

    • locked on a value during the round . This means that during the round (line 1). the proposer proposes a value along with (lines 1 - 1). Since , does not unlock and prevotes for the round , and so are all the other processes in (lines 1 - 1). The only value that can have more than prevotes is then . So is still locked on at the end of .

    • If is not locked, the value it proposes cannot unlock processes in because , and they will prevote on (lines 1 - 1). The only value that can have more than prevotes is then . So is still locked on at the end of .

    • locked on a value during the round , the proposer proposes a value along with (lines 1 - 1). Since , does not unlock and prevotes for the round , and so are all the other processes in (lines 1 - 1). The only value that can have more than prevotes is then . So is still locked on at the end of .

    At the end of round , all processes in are still locked on and it may happen that other processes are locked on for round at the end of the round.

  • Induction: We assume that for a given , the processes in are still locked on at each round between and . We now prove that the processes in will still be locked on at round .

    Let be the proposer for round . Since the processes in were locked on for all the rounds between and , no new value can have more than of prevotes during one of those rounds, so where . Moreover, if proposed the value along with a , since the processes in are already locked on , they do not unlock and prevote (lines 1 - 1). The proof then follows as in the Initialization case.

Therefore all processes in will stay locked on at each round after round . Since processes will stay locked on the value on rounds , they will only prevote on (lines 1 - 1) for each new round. Let be a value, we have that if then .

Lemma 4 (One-Shot Agreement).

In an eventual synchronous system, Tendermint One-Shot Consensus Algorithm verifies the following property: If there is a correct process that decides a value , then eventually all the correct processes decide .

Proof Let be a correct process. Without loss of generality, we assume that is the first correct process to decide, and it decides at round . If decides , then (line 2), since the signature of the messages are unforgeable by hypothesis and , then delivers more than of those precommits for round from correct processes, and those correct process are locked on at round (line 1). broadcasts all the precommits it delivers (line 2), so eventually all correct processes will deliver those precommits, because of the best effort broadcast guarantees.

We now show that before delivering the precommits from , the other correct processes cannot decide a different value than . by hypothesis, so we have that at least correct processes are locked on for the round . By Lemma 3 no correct process can lock on a value different than . Let , since correct processes lock only when they precommit (lines 1 - 1), no correct process will precommit on for a round bigger than , so for all since no correct process will precommit on . No correct process cannot decide a value (line 2) once decided. Eventually, all the correct processes will deliver the signed precommits delivered and broadcasted, thanks to the best effort broadcast guarantees and then will decide .

Lemma 5.

In an eventual synchronous system, and under the assumption that during the synchronous period eventually there is a correct proposer such that , Tendermint One-Shot Consensus Algorithm verifies the following property: Eventually a correct process decides.

Proof Let be the round where the communication becomes synchronous and when all the messages broadcasted by correct processes are delivered by the correct processes within their respective step. The round exists, since the system is eventually synchronous and correct processes increase their time-outs when they did not deliver enough messages (lines 1 - 1, 1 - 1 and 1). If a correct process decides before , that ends the proof. Otherwise no correct process decided yet. Let be the proposer for the round . We assume that is correct. Let be the value such that proposes , we have three cases:

  • Case 1: No correct process is locked on a value before . such that is correct, .

    Correct processes delivered the proposal before the Prevote step (lines 1, 2 - 2). Since the proposal is valid, then all correct processes will prevote on that value (line 1), and they deliver the others’ prevotes and broadcast them before entering the Precommit step (lines 1 - 1 and 2). Then for all correct process , we have . The correct processes will lock on , precommit on (lines 1 - 1) and will broadcast all precommits delivered (line 2). Eventually a correct process will have then will decide (line 2).

  • Case 2: Some correct processes are locked and if is a correct process, .

    Since for all correct processes , then the correct processes that are locked will unlock (line 1) and the proof follows as in the Case 1.

  • Case 3: Some correct processes are locked on a value, and there exist a correct process such that .

    • (i) If (which means that even without the correct processes that are locked in a higher round than the proposer , there are more than other correct processes unlock or locked in a smaller round than ), then as in the case 2, a correct process will decide.

    • (ii) If , then during the round , , in fact correct processes only precommit once in a round (lines 1 - 1). Eventually, thanks to the additional assumption, there exists a round where the proposer is correct and at round , . The proof then follows as case (3.i).

If is Byzantine and more than correct processes delivered the same message during the proposal step, and the proposal is valid, the situation is like was correct. Otherwise, there are not enough correct processes that delivered the proposal, or if the proposal is not valid, then there will be less than processes that will prevote that value. No value will be committed. Since the proposer is selected in a round robin fashion, a correct process will eventually be the proposer, and a correct process will decide.

Lemma 6 (One-Shot Termination).

In an eventual synchronous system, and under the assumption that during the synchronous period eventually there is a correct proposer such that , Tendermint One-Shot Consensus Algorithm verifies the following property: Every correct process eventually decides some value.

Proof By construction, if a correct process does not deliver a proposal during the proposal step or enough prevotes during the Prevote step, then that process increases its time-outs (lines 1 - 1 and 1 - 1), so eventually, during the synchrony period of the system, all the correct processes will deliver the proposal and the prevotes from correct processes respectively during the Propose and the Prevote step. By Lemma 5, a correct process decides a value, and then by the Lemma 4, every correct process eventually decides.

Theorem 7.

In an eventual synchronous system, and under the assumption that during the synchronous periods eventually there is a correct proposer such that : Tendermint One-Shot Algorithm implements the One-Shot Consensus.

Proof The proof follows directly from Lemmas 1, 2, 4 and 6.

4.4 Tendermint Repeated Consensus algorithm

Function repeatedConsensus; %Repeated Consensus for the set of processes% Init: (1) %%; %Set of validators%; (2) ; ;  ————————————————————————————————————— while do (3) (4) %Application and blockchain dependant% (5) if then (6) %Consensus function for the height % (7) trigger broadcast ; (8)  else (9) wait until ; (10) ; (11) endif (12) (13) (14) (15) endwhile  ————————————————————————————————————— upon event delivery : (16) if then (17) ; (18) ; (19) trigger broadcast ; (20) endif

Figure 3: Tendermint Repeated Consensus algorithm at correct process .

For a given height, the set of validators does not change. Note that each height corresponds to a block. Therefore, in the following we refer this set as the set of validators for a block.

Data structures. The integer is the height where is called a One-Shot Consensus instance. is the current set of validators. is the block to be appended. is the set containing all the commits delivered for the height . is the set containing the validators from which delivered commits for the height . represents the time a validator has for collecting commits after an instance of consensus. is set to .

Functions.

  • is an application dependent and deterministic selection function which gives the set of validators for a given height w.r.t the blockchain history. We have .

  • is the One-Shot Consensus instance presented in 4.2.

  • is the application-dependent function that creates a valid block (w.r.t. the application) from the One-Shot Consensus.

  • is a predicate which checks if there is at least of commits of the given block in the given set.

  • is the same predicate as in the One-shot Consensus, which checks if a block is valid or not.


Detailed description of the algorithm. In Fig. 3 we describe the algorithm to solve the Repeated Consensus as defined in Section 3. The algorithm proceeds as follows:

  • computes the set of validators for the current height;

  • If is a validator, then it calls the consensus function solving the consensus for the current height, then broadcasts the decision, and sets to that decision;

  • Otherwise, if is not a validator, it waits for at least commits from the same block and sets to that block;

  • In any case, it sets the timer to for receiving more commits and lets it expire. Then decides and goes to the next height.

Whenever delivers a commit, it broadcasts it (lines 3 - 3). Note that the reward for the height is given during the height , and to a subset of validators who committed the block for (line 3).

4.5 Correctness of Tendermint Repeated Consensus

In this section we prove the correctness of Tendermint Repeated Consensus algorithm in Figure 3. We now show that Tendermint Repeated Algorithm (Fig. 3) implements the Repeated Consensus.

Lemma 8 (Repeated Termination).

In an eventual synchronous system, and under the additional assumption that during the synchronous period eventually there is a correct proposer such that , Tendermint Repeated Consensus Algorithm verifies the following property: Every correct process has an infinite output.

Proof By contradiction, let be a correct process, and we assume that has a finite output. Two scenarios are possible, either cannot go to a new height, or from a certain height it outputs only .

  • If cannot progress, one of the following cases is satisfied:

    • The function does not terminate (line 3), which is a contradiction due to Lemma 6; or

    • waits an infinite time for receiving enough commits (line 3), which cannot be the case because of the best effort broadcast guarantees and the eventual synchronous assumption, all the correct validators terminate the One-Shot Consensus and broadcast their commit.

  • If decides at each height (line 3), it means that from a certain height , only outputs . That means that: (i) either is a validator for and the function is only returning for all (lines 3 and 3), or (ii) is not a validator for but delivered at least commits for (lines 3 and 3).

    • (i): Since returns the value , that means by Lemma 2 that , which is a contradiction with the definition of the function .

    • (ii): Since only the validators commit, and each of them broadcasts its commit (lines 3 - 3), and because , it means that delivered a commit from at least one correct validator (process). By Lemma 2, correct processes only decide/commit on valid value, and is not valid, which is a contradiction.

We conclude that if is a correct process, then it has an infinite output.

Lemma 9 (Repeated Agreement).

In an eventual synchronous system, Tendermint Repeated Consensus Algorithm verifies the following property: If the value of the output of a correct process is , then is the value of the output of any other correct process.

Proof We prove this lemma by construction. Let and be two correct processes. Two cases are possible:

  • and are validators for the height , so they call the function (lines 3 and 3). By Lemma 4 and decide the same value and then output that same value (line 3).

  • At least one of and is not a validator for the height . Without loss of generality, we assume that is not a validator for the height . Since all the correct validators commit the same value, let say , thanks to Lemma 4, and since they broadcast their commit (line 3), eventually there will be more than of commits for . So no other value can be present at least times in the set . So outputs the same value as all the correct validators (line 3). If is a validator, that ends the proof. If is not a validator, then by the same argument as for , outputs the same value . Hence and both output the same value .

Lemma 10 (Repeated Validity).

In an eventual synchronous system, Tendermint Repeated Consensus Algorithm verifies the following property: Each value in the output of any correct process is valid, it satisfies the predefined predicate denoted .

Proof We prove this lemma by construction. Let be a correct process, and we assume that the value of the output of is . If decides a value (line 3), then that value has been set during the execution and for that height (line 3).

  • If is a validator for the height , then is the value returned by the function , by the Lemma 2 we have that .

  • If is not a validator for the height , it means that it delivered more than signed commits from the validators for the value (lines 3 - 3 and 3 - 3), hence at least one correct validator committed , and by Lemma 2 we have that .

So each value that a correct process outputs satisfies the predicate .

Theorem 11.

In an eventual synchronous system, Tendermint Repeated Consensus algorithm implements the Repeated Consensus. In an eventual synchronous system, and under the additional assumption that during the synchronous period eventually there is a correct proposer such that , Tendermint Repeated Consensus algorithm implements the repeated consensus.

Proof The proof follows directly from Lemmas 8, 9 and 10. we showed that Tendermint protocol satisfies respectively the Termination property, the Agreement property and the Validity property.

5 Bugs in the original Tendermint

5.1 Addition of line 1 on Fig. 2

The line 1 allows the correct process to increase its time-out to catch up the communication delay in the network. If the correct processes never increase their , even when the system becomes synchronous, the correct process may never deliver enough prevotes at time. Thus it can never precommit. To decide, a correct process needs more than precommits for the same value for the same round (and so more that precommits from correct processes) to decide (line 2), no correct process ever decides, which does not satisfies the One-Shot Termination property. When a process increases its whenever it does not deliver enough messages, it will eventually catch-up the delay, and during the synchronous period, there will be a time from when it will deliver prevotes from all correct processes.

5.2 Modification of line 1 on Fig. 2

Originally, the line 1 was

In that version, it is possible that if a process is locked on a value during a round , a process locked on the same value during a round makes unlock, but does not ensure that locks again. That is a problem since it causes a violation of the Agreement property.

In the following, we exhibit a problematic scenario. Assume that there are processes in the network. correct processes and a Byzantine process .

  1. Round 1: is the proposer and proposes . All process deliver the proposal and prevote on from round 1.

    and deliver all prevotes for , and then lock and precommit on .

    delivers the precommit of and from for and then it decides . Neither and delivers enough precommit to decide.

    The state is: decides and left. is locked on , is not locked, is Byzantine so we do not say anything about its state.

  2. Round 2: exit, and do not take part any more. and do not deliver the precommit for .

    is the proposer. Since is locked on , it proposes along with where it locked. and deliver the proposal. does not unlock since it locked at round and prevote on . is not locked, but since it delivered the proposal, it prevotes on . sends a prevote on only to such that delivers all the prevotes during this step but not , so during the precommit step, locked on but for the round .

    The state is: already decided. is locked on , is locked on , is Byzantine so we do not say anything about its state.

  3. Round 3: and do not deliver the precommit for from round 1.

    is the proposer. Since is locked on , it proposes along with where it locked. and deliver the proposal. unlocks since it receives but was locked at and prevote the proposal . does not unlock since it locked exactly at round and prevote on . sends a prevote on such that delivers all the prevotes during its step but not , so during the precommit step, locked on but for the round .

    The state is: already decided .