DeepAI
Log In Sign Up

On Fairness in Committee-based Blockchains

Committee-based blockchains are among the most popular alternatives of proof-of-work based blockchains, such as Bitcoin. They provide strong consistency (no fork) under classical assumptions, and avoid using energy-consuming mechanisms to add new blocks in the blockchain. For each block, these blockchains use a committee that executes Byzantine-fault tolerant distributed consensus to decide the next block they will add in the blockchain. Unlike Bitcoin, where there is only one creator per block with high probability, in committee-based blockchain any block is cooperatively created. In order to incentivize committee members to participate to the creation of new blocks rewarding schemes have to be designed. In this paper, we study the fairness of rewarding in committee-based blockchains and we provide necessary and sufficient conditions on the system communication under which it is possible to have a fair reward mechanism.

READ FULL TEXT VIEW PDF

page 1

page 2

page 3

page 4

12/18/2020

On Finality in Blockchains

There exist many forms of Blockchain finality conditions, from determini...
05/22/2018

Correctness and Fairness of Tendermint-core Blockchains

Tendermint-core blockchains offer strong consistency (no forks) in an op...
04/12/2021

Reward Mechanism for Blockchains Using Evolutionary Game Theory

Blockchains have witnessed widespread adoption in the past decade in var...
02/27/2018

Blockchain Abstract Data Type

Blockchains (e.g. Bitcoin, Algorand, Byzcoin, Hyperledger, RedBelly etc)...
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...
12/20/2017

Information Propagation on Permissionless Blockchains

Blockchain technology, as a decentralized and non-hierarchical platform,...
09/13/2019

A Random Network Model for the Analysis of Blockchain Designs with Communication Delay

This paper proposes a random network model for blockchains, a distribute...

1 Introduction

Blockchain technology is one of the most appealing technology since its introduction in the Bitcoin White Paper [bitcoinNakamoto] in 2008. A blockchain is a distributed ledger, where information are stocked in blocks and hashes link blocks in order to have a chain structure. Blockchains systems mostly use proof-of-work, where the first process that solves a crypto-puzzle can add a new block to the blockchain. First, this technique is highly energy consuming and second, it does not ensure consistency, i.e. conserving the chain structure. Forks may happen and lead to a tree structure. Some alternatives arisen to avoid at least one of these issues. For example, proof-of-stake based blockchains, where the probability of being able to add a block depends on the stake of a process; this alternative solves the energy consumption issue, but not the consistency; they are also subject to the nothing-at-stake problem, where processes try to produce blocks on all the forks, to ensure some reward, and by doing so, do not resolve the forks. However, in [Saleh19], Saleh shows that the nothing-at-stake problem is mitigated. Other alternatives tackle both issues, for example, committee-based blockhains. In committee-based blockchains, for each height/block, a committee is selected and that committee uses a consensus algorithm to decide on the next block to append in the blokchain. By construction, committee-based blockchains are not subject to nothing-at-stake, since the ensure consistency (no fork).

To motivate processes to add and maintain the blockchain, rewarding mechanisms are in place. Because committee members can be faulty, rewarding mechanisms are inherently more complex to handle and their properties must be studied. Ad minimum the rewarding mechanism must be fair, i.e. distributing the rewards in proportion to the merit of participants, where merit abstracts the notion of effort processes take for the construction of the blockchain [ADLPT19], for instance it models the hashing power in Bitcoin.

Informally, we say that a blockchain protocol is fair if any correct process (a process that followed the protocol throughout the whole execution) that has fraction of the total merit in the system will get at least fraction of the total reward that is given in the system. Our fairness analysis, in line with Francez’s definition of fairness [francez86], generally defines the fairness of protocols based on voting committees (e.g. Byzcoin[BizCoin], Hyperledger [hyperledger], PeerCensus[PeerCensus], RedBelly [redbelly17], SBFT [sbft18], etc.), actually studies fairness by separating 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 append in the blockchain, while the reward mechanism defines the way rewards are distributed among processes that participate to the agreement. We propose a formal definition of fairness of selection mechanisms, and then we study the fairness of some selection mechanisms. The analysis of the reward mechanism allowed to establish the following fundamental result and necessary conditions with respect to the fairness of committee-based blockchains as follows:

There exists a(n) (eventual) fair reward mechanism for committee-based blockchains if and only if the system is (eventual) synchronous and processes are detectable. (Theorems 1 and 2).

The rest of the paper is as follows. In Section 2, we compare the existing studies on fairness in blockchain systems; in Section 3, we define the system model; in Section 4, we give a generic idea of committee-based blockchain systems, and the consensus problems; in Section 5, we provide a formal definition of fairness in committee-based systems, and some analysis; in Section 6, we analyze some behaviors and the communication model impact on rewards; and in Section 7, we conclude.

2 Related Work

The closest work in blockchain systems to our fairness study (however very different in its scope) is the study of the chain-quality. In [GarayKL15], Garay et al. define the notion of chain-quality as the proportion of blocks mined by honest miners in any given window; Garay et al. study the conditions under which during a given window of time, there is a bounded ratio of blocks in the chain that malicious players produced, over the total blocks in the blockchain. Kiayias et al. in [KRDO17] proposes Ourobouros[KRDO17] and analyses the chain-quality property. In [PS17], Pass and Shi propose a notion of fairness which is an extension of the chain-quality property, they address one of the vulnerabilities of Bitcoin studied formally in [ES14, ES18]. In [ES14, ES18], Eyal and Sirer prove that if the adversary controls a coalition of miners holding even a minority fraction of the computational power, this coalition can gain twice its share. Fruitchain [PS17] overcomes this problem by ensuring that no coalition controlling less than a majority of the computing power can gain more than a factor by not respecting the protocol, where is a parameter of the protocol. We note that in their model, only one process creates a block in the blockchain, and that process have a reward for the created block. In [GW18], Guerraoui and Wang study the effect of the delays of messages propagation in Bitcoin, and show that in a system of two miners, a miner can take advantage of the delays and be rewarded exponentially more that its expectation. We extend the definition of [PS17] for systems where each block is produced by a subset of processes. This is the case of Tendermint [opodis18, netys19] or Hyperledger [hyperledger] for example, where for each block there is a subset of processes, a committee that produces that block.

In [GDT17, GRT18], Gürcan et al. study the fairness from the point of view of the processes that do not participate to the construction of the blockchain. Herlihy and Moir do a similar work in [HM16] where the authors study users’ fairness and consider as an example Tendermint. Herlihy and Moir discussed how processes with malicious behavior could violate fairness by choosing transactions, and then they propose modifications to the original Tendermint to make those violations detectable and accountable. In [LSKM19], Lev-Ari et al. study fairness on transactions in committee-based blockchains with synchronous assumptions by using a detectable communication abstraction allowing them to identify malicious participants. Our work does not study fairness in the point of view of users.

Recent works consider the distributions of rewards in proof-of-stake based blockchains. In particular, in [FKORVW18], Fanti et al. define equitability, which represents the evolution of the fraction of total stake of nodes, in particular, they compute the effect of so called compounding where reward are directly re-invest in stakes. Karakostas et al. define in [KKNZ19] egalitarianism. Egalitarianism means that nodes, no matter their stake fraction, win the election process to append a new block the same amount. In this work, we focus more on fairness, where nodes that have a higher merit should get more rewards. Our notion of fairness is different that egalitarianism, since egalitarianism’s goal is to have all nodes rewarded the same, no matter their merit.

3 System Model

The system is composed of an infinite set of sequential processes, namely ; is the index of . 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, we consider it as being equal to zero.

Arrival model. We assume a finite arrival model [aguilera2004], 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 committee-members. The set may change during any system run and its size is a priori known. A process is promoted in by a selection function. Such selection function can be based for instance on the stake in proof-of-stake blockchains, or computing power in proof-of-work blockchains.

Time assumptions on communication. The processes communicate by exchanging messages through an eventually synchronous network [DLS88]. Eventually Synchronous means that after a finite unknown time there is an a priori unknown bound on the message transfer delay. When and is known the network is synchronous.

Failure model. Some processes can exhibit a Byzantine behavior [RA80] in the system; we do not assume any bound on their number, but up to committee members can exhibit a Byzantine behavior at each point of the execution. A Byzantine process is a process that behaves arbitrarily. A process that exhibits a Byzantine behavior is called a Byzantine or a faulty process.

Let be a period during the execution. We say that a process is -correct, iff during the period , follows the protocol. A process is correct if , is -correct.

Communication primitives. In the following, we assume the presence of a broadcast primitive. 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 broadcast of a message by executing the primitive . Messages are created with a digital signature, and we assume that digital signatures are unforgeable. When a process delivers a message, it knows the process that created the message.

4 Committee-based Blockchains

Any committee-based blockchain uses instances of consensus, solving a form of repeated consensus. This way, each committee agrees on a single value to avoid forks. Anceaume et al. [ADLPT19] proved that consensus is required to avoid forks.

Each correct process outputs an infinite sequence of decisions called the output of the process. More formally, as described by Delporte-Gallet et al. [DDFPT08], and generalized to Byzantine failures in [opodis18], an algorithm implements a repeated consensus if and only if it satisfies the following properties: (i) Termination. Every correct process has an infinite output. (ii) Agreement. If the value of the output of a correct process is , and the value of the output of another correct process is , then . (iii) Validity. Each value in the output of any correct process is valid with respect to a predefined predicate.

ComputeCommitteeof

init:

- SolveConsensus- Send decision

Wait fordecision fromcommittee

- Wait to collectmore decision- Update

if the process is acommittee member

if the process is not acommittee member

If enough evidenceof a decision

Not enough evidenceof a decision

Figure 1: State Machine of a Repeated Consensus Algorithm to Build a Committee-based Blockchain.

Detailed Description of the Algorithm

We denote by the set of all blocks. A block contains, among other things, a header, and a list of transactions. Let , be a finite sequence of blocks. is the length (the number of blocks) of bc. We say that bc is a blockhain if , in the header of the block at position in bc, there is the hash of the block at position . If additionally, the list of transactions in each blocks in the blockchain is valid with respect to the given application, we say that bc is a valid blockchain. The block at position is the genesis block. Each process has a non-negative stake, which is the total amount of currency it has.

, let be the set of committee members for the height . , we assume that , the size of committee member is fixed and equal to .

The state machine of the algorithm is depicted in Fig. 1. The genesis block initializes the blockchain, selects the committee that will produce the block at position , describes how rewards will be distributed among committee members (which we call the reward mechanism), gives the initial distribution of stakes, and describes how processes will be selected for being part of committees with respect to the state of the blockchain (the selection mechanism). These information should be public, and known by all processes such that with the history of the blockchain, all processes can always compute deterministically the sets of committee members. For a height, processes not in the corresponding committee just wait for the decision from the committee members. The committee members for that height execute the consensus algorithm to decide upon the block for that height. Once a process decides on a block, it sends the decided block to the whole network, and moves to the next height. Non-committee members wait to collect enough times the same decided block from the committee members, in order to be tolerant to failures, and then move to the next height. When moving to the next height, processes wait a certain amount of time to collect more messages from committee members. These messages are the ones used to reward the previous committee members. Intuitively, if a process receives a decision message for the decided block by a committee member, then probably that committee member followed the protocol during that height111That is not true in general, since Byzantine processes for instance can send the decided value at the end without doing anything during the execution.. This allows to implement the repeated consensus. In [opodis18], the authors formalized and proved correct the Tendermint repeated consensus algorithm, an example of committee-based blockchain protocol.

In this paper, we analyse the fairness of committee-based blockchains as described in the following section.

5 Fairness of Committee-based Blockchains

Chain quality and Committee-based Blockchains

In the blockchain literature, chain quality has been defined by [GarayKL15], and extended by [PS17], to study fairness in Bitcoin-like systems. A blockchain system has the property of chain quality if the proportion of blocks produced by honest processes in any given window, is proportional to their relative mining power. Intuitively, chain quality ensures that malicious processes do not produce more blocks than in expectation, given their mining power. One of the main differences between Bitcoin-like system and the committee-based blockchains is that in the first, one process produces a block, whereas in committee-based blockchain, a committee (a set) of processes produces a block. A committee is not necessary composed only of correct processes, but can contain Byzantine or correct processes (with a correctness hypothesis of having some majority of members following the protocol). We cannot apply the definition of chain quality to committee-based blockchain. Instead of defining the fairness with the blocks, we will define it relative to the proportion of total rewards a process gets.

Informally, we say that a blockchain protocol is fair if any correct process (a process that followed the protocol) that has fraction of the total merit in the system will get at least fraction of the total reward that is given in the system. In order to tackle the fairness of a committee-based blockchain protocol such as HotStuff [hotstuff19], Hyperledger [hyperledger], Redbelly [redbelly17], SBFT [sbft18] or Tendermint [opodis18], we split the mechanism in two: the selection mechanism and the reward mechanism. We say that each process has a given merit, which represents the effort the process is putting to maintain the blockchain, for instance, it can represent the mining power of a process in proof-of-work blockchain. The selection mechanism selects for each new height the committee members (the processes that will run the consensus instance) for that height. The reward mechanism, is in charge to distribute rewards to committee members that produce a new block. Informally, if the selection mechanism is fair, then each process will become committee member proportionally to its merit; and if the reward mechanism is fair then for each height, only the correct committee members get a reward. By combining the two mechanisms, a correct process is rewarded at least a number proportional to its merit parameter over the infinite execution of the system.

5.1 Selection Mechanism

5.1.1 Definition and Fairness of Selection Mechanisms

In a system where the size of the committee is strictly lower than the size of the processes in the system, there should be a way to select the members of the committees. Always selecting the same processes is a way to centralize the system. That set of processes can exercise a power of oligarchy, and add in the blockchain only transactions they want.

Formally, a selection mechanism is the function , where is the size of committees, and represents the set of non-empty blockchains such that if bc is a blockchain, then:

where we recall that means the length of the blockchain , and is the set of committee members for height .

In the blockchain, some information can be saved, for instance the stakes of each process that represents their wealth. The selection mechanism can select, for instance, processes with the highest stakes, or processes with the lowest stakes, or always the same set of processes, or processes that were committee members less often, etc.

To abstract the notion of effort of a process, we denote by the merit parameter of at time proportionally to the total merit at time , such that .

If , we denote by the merit of the process . That means that the merits do not depend on the evolution of the blockchain, nor on it contents222With the analogy of proof-of work blockchains, it means that the computing power of each processes do not change with time.. Let be the number of times becomes committee member, proportionally to the number of blocks, so . We propose the following definition of fairness of selection mechanisms where merits are fixed and do not change over time. The definition allows all processes with positive merit to be member of committees infinitely often, and by doing so, respecting their merit.

Definition 1 (Fairness of Selection Mechanism).

Assume that the blockchain is built infinitely, so , there is a block at position . We say that a selection mechanism is fair if it respects the following properties:

  1. If then ; or equivalently,

  2. If then .

Informally, Condition 1 means that each process with a positive merit parameter should become a committee member infinitely often. Condition 2 means that a process with a low merit cannot be selected more than a process with a higher merit. Note that this definition depends only on the merit and not on the behavior of the processes (correct or Byzantine).

A definition of fairness of a generic selection mechanism (that does change over time) is still an open question, but such definition should encapsulate the Definition 1 as special case.

Remark 1.

If the total number of processes in the system is equal to the the size of committees, then all processes are always selected, so the selection mechanism in that case is trivially fair, although asking a huge set of processes to run the consensus is not scalable.

5.1.2 Examples of Selection Mechanisms

In this section, we briefly study different possible selection mechanisms. Let us assume that there are processes during the whole execution of the system. Let us assume that merits do not change over time, and that all processes have the same merit, .

In this analysis, we consider selection mechanisms that depends on the current state of the stakes and/or number of selections of processes. All processes are correct, and a committee member is rewarded once its committee produces a block.

For our analysis, we further consider that the processes are ordered by their stake and their id (public address for instance). Let us assume that at the beginning of the execution, all processes have the same amount of stake. Without loss of generality, and up to renaming, consider also that during the execution, if such that and have the same amount of stakes, then is selected before .

Select the processes with the highest stake

This selection mechanism works as follows: For any height , with respect to the blockchain up to height , the processes having the biggest amount of stakes are selected to be part of the committee. This mechanism lead to the situation where only the processes selected first will always be selected, and the other processes will never be. This mechanism is not fair, since Condition 1 is not satisfied. The processes not selected have by assumption a positive stake, and so they should be selected infinitely often.

Note that in the special case where there are at most processes with a positive stake, and these are all selected, then fairness is satisfied.

Select the processes with lowest stake

This selection mechanism works as follows: for any height , with respect to the blockchain up to height , the processes having the lowest amount of stakes are selected to be part of the committee. If all processes are part of the system since the beginning, the number of times each process has been selected after blocks, on average is selections. This mechanism is fair according to the Definition 1.

Remark 2.

An unfair selection mechanism can lead to a centralization of the system, by always letting the same processes decide on the next block. Although the assumption on the bound of Byzantine processes does not depend on the selection mechanism, we note that when a selection mechanism selected the processes with the lowest amount of stakes, and only correct processes in committees are rewarded, at some point processes that were non-correct will have the least stake, and thus be selected.

5.2 Reward Mechanism

5.2.1 Definition of Reward Mechanism

In blockchain systems, a process that produces and adds blocks to the blockchain are rewarded. In a committee-based blockchain, a committee is the producer of the block. Within that committee, some processes may not behave as prescribed. There may be different ways of rewarding members of committees. To do so, we define the reward mechanism. A reward mechanism consists of the reward function defined as follows: , where is the power set of all messages.

If bc is a blockchain and , . Otherwise, it assigns to each process a given reward, null or not. In , represents the set of messages received, the height of the blockchain bc where the reward of committee member is computed.

A reward is considered allocated if it is written in the blockchain. The second part of the reward mechanism is to choose when to allocate the rewards corresponding for a given height. If a reward has been allocated at a height , the process can use it after a certain number of blocks defined in the genesis block (e.g. [GarayKL15, ES18]). We consider that for each production of block its rewards are allocated in one block and not over different blocks, such that after the allocation of rewards a process knows if it has been rewarded or not. Note that once rewards are allocated, they cannot change any more. Some blockchains system adds a system of punishment, called slashing, to afflict, afterwards, some costs to a process if there is a proof of some misbehavior, as described in [OG19].

5.2.2 Fairness of Reward Mechanism

We define the following properties for characterizing the fairness of a reward mechanism. Let be a height. Recall that is considered -correct if during the period of height , followed the protocol. Each committee member has a boolean variable , which we call reward parameter defined as follows:

  1. If is a not a committee members for , then ,

  2. -completeness. If is a committee members for and is -correct, then ,

  3. -accuracy. If is a committee members for and is not -correct, then .

If , it means that is not rewarded for height , and if , has been rewarded for . The properties are inspired by classical properties of failure detectors [CT96].

Remark 3.

Note that we do not reward non-committee members. In this article, we do not consider delegations. When a process delegates to a committee member, once the committee member is rewarded, all of its delegates are rewarded proportionally to what they delegated. In future works, we may consider the case of committee-based blockchains with delegations. To do so, must contain more information and not just be a boolean variable.

Definition 2 (Complete Fairness of a Reward Mechanism).

Let be a reward mechanism. If , satisfies conditions 1 and -completeness (condition 2), we say that satisfies complete fairness.

If a reward mechanism satisfies complete fairness, it means that for all height , all -correct committee members are rewarded, and non-committee members are not.

Observation 1.

There always exists at least one reward mechanism satisfying complete fairness.

Once a block is in the chain, rewarding all committee members, in the next block, for that block and only them, satisfy conditions 1 and 2. Condition 1 is satisfied since for all height, non-committee members are not rewarded. Condition 2 also holds, for any given height , all committee members of are rewarded, in particular all -correct committee members.

Definition 3 (Accurate Fairness of a Reward Mechanism).

Let be a reward mechanism. If , satisfies conditions 1 and -accuracy (condition 3), we say that satisfies accurate fairness.

If a reward mechanism satisfies accurate fairness, it means that for all height , all non -correct committee members are not rewarded.

Observation 2.

There always exists at least one reward mechanism satisfying accurate fairness.

Never allocating rewards satisfies conditions 1 and 3. Condition 1 is satisfied since non-committee members are not rewarded. Condition 3 holds, since no process is rewarded. In particular for any given height , no non -correct committee members is rewarded.

Although simple and trivial to satisfy either complete fairness or accurate fairness, satisfying both at the same time is more complex and not always possible.

Definition 4 (Fairness of a Reward Mechanism).

Let be a reward mechanism. If , satisfies conditions 1, -completeness (condition 2) and -accuracy (condition 3), we say that is fair.

We say that a reward mechanism is fair when at each height , all and only -correct committee members are rewarded.

Remark 4.

If then for a reward mechanism to be (eventually) fair, rewards cannot be allocated directly in the block. For any height the set of -correct committee members cannot be known in advance. If , the reward can be directly given to the only committee member, so in the block at height .

Theorem 1.

There exists a fair reward mechanism in a committee-based blockchain protocol iff the system is synchronous.

Proof We prove this theorem by double implication.

  • If there exists a fair reward mechanism, then the system is synchronous.

    Let be a reward mechanism. By contradiction, we assume that is fair and that the system is not synchronous.

    is the set of committee members for the height . Let be the number of blocks to wait before distributing the rewards for . The reward is allocated by the committee , where . Since the system is not synchronous, the committee members of height , , may not receive all messages from before allocating the rewards.

    By conditions 1, and 2, since the reward mechanism is fair, by conditions 1 - 3, all and only the -correct committee members of the height have a reward parameter equal to . That means that the -correct committee members of know exactly who were the -correct committee members in , so they got all the messages before giving the reward. Contradiction, so the system is synchronous.

  • If the system is synchronous, then there exists a fair reward mechanism.

    We assume that the system is synchronous and , all messages sent by -correct processes at height are delivered before the block at height . Let be the following reward mechanism: let be a height. Rewards for a block at height are allocated at height by the committee .

    • If a process is not a committee member for height , set its reward parameter to , this is known since processes are already at height .

    • By combining the messages from committee member of processes, since the communication system is synchronous, it is possible to differentiate between -correct and non -correct committee members, and so set the reward parameter of -correct committee members of to ; and set the reward parameter of non -correct committee members of to .

    By construction, the committee members in allocates rewards to all and only -correct committee members, so is fair, because it satisfies all fairness conditions 1 - 3.

If there is no synchrony, then there cannot be a fair reward mechanism for committee-based blockchains. Our definition of fairness states that for any height conditions 1-3 are satisfied. At any time, processes receive all rewards they deserve. This definition can be weakened.

Definition 5 (Eventual Fairness of a Reward Mechanism).

Let be a reward mechanism. If , satisfies conditions 1, -completeness (condition 2) and -accuracy (condition 3), we say that is eventually fair.

A reward mechanism is eventually fair if after an unknown time, the rewards are allocated to and only to correct committee members.

We note that if a reward mechanism is fair, then it is eventually fair but the reverse (reciprocal) is not necessarily true.

Detectable Byzantine Processes

In synchronous systems, it is always possible to detect Byzantine processes, for example using the broadcast abstraction detectable all-to-all (DA2A) defined in [LSKM19]. Detecting Byzantine processes allows to not reward them, and then to satisfy condition 3. On the other hand, in eventual synchronous systems, the problem is more difficult. Kihlstrom et al., in [KMM03] distinguish between detectable and non-detectable Byzantine. The detectable Byzantine are the processes whose behavior can be detected, for instance by doing omission or commissions failures. Non-detectable Byzantine, are Byzantine processes whose fault cannot be detected, for example the processes that alter their internal state. In [GLAS12], Greve et al. further extend that approach to propose a failure detector for detectable Byzantine in dynamic networks. In line with [KMM03], we say that a Byzantine is detectable if it is possible for correct processes to detect it by combining information they have (e.g what they see during the execution).

Note that although Kihlstrom et al. proposed in [KMM03] a failure detector for solving consensus, our problem is not the same, and we cannot apply their failure detector as it is. In [KMM03], once a process has a detectable Byzantine behavior, it should be suspected forever. In our model, we do not want to punish indefinitely Byzantine processes. In fact, we want for any height to not reward only processes that were not -correct. For example, let be a process such that it is part of committees and , such that . Suppose also that during height , sends contradictory messages (and so is Byzantine), but follows the protocol during height . If has been detected and not rewarded for height , that should be taken into consideration of its work during height , and since it follows the protocol, it should be rewarded for height . The failure detector proposed by Kihlstrom et al., once a process has been suspected, marks such process as Byzantine forever.

Theorem 2.

There exists an eventual fair reward mechanism in a committee-based blockchain protocol iff the system is (eventually) synchronous and Byzantine processes are detectable.

Proof We prove this theorem by double implication.

  • If there exists an eventual fair reward mechanism, then the system is eventually synchronous or synchronous and Byzantine processes are detectable.

    Let be a reward mechanism. We assume that is eventually fair.

    If is fair, by Theorem 1, the communication is synchronous, which ends the proof. Otherwise, since is eventually fair, that means that there is a point in time from which all the rewards are correctly allocated, so for any height , -correct committee members of committees at height are able to distinguish between non-correct processes during the height they are distributing the rewards, the Byzantine are then detectable. If we consider as the beginning of the execution, then we have that is fair, and by Theorem 1, the message delay is upper bounded. We have that after , the message delay is upper bounded, so the communication is eventually synchronous. So the Byzantine are then detectable, and the communication is synchronous or eventually synchronous.

  • If the system is eventually synchronous or synchronous, and Byzantine processes are detectable, then there exists an eventual fair reward mechanism.

    If the system is synchronous, the proof follows directly from Theorem 1. Consider that the system is eventually synchronous, but not synchronous. Let be the following mechanism: Let be a height. Rewards for a block at height are allocated at height by the committee .

    • If a process is not a committee member for height , set its reward parameter to , this is known since processes are already at height .

    • By combining the messages from committee member of processes, if there is not sufficient information to detect the behavior of processes, reward only those detected as -correct and in , and the process proposing the distribution of reward increases the duration to wait before starting the next height ( in Fig. 1) . If there is enough information to detect the behavior of all processes in , then reward the -correct processes in and do not reward non -correct processes in .

    is eventually fair.

Corollary 1.

In an asynchronous system, there is no (eventual) fair reward mechanism in a committee-based blockchain tolerating Byzantine processes.

Proof Assume that the system is asynchronous, where there are good periods such that consensus can be reached. By contradiction, let be an eventual fair reward mechanism.

  • If there are non-detectable Byzantine processes in the system, then by Theorem 2, is not fair;

  • If all Byzantine processes are detectable, then by Theorem 2, the system must be synchronous, or eventually synchronous.

We have a contradiction, since the system is asynchronous. It is not possible to have an (eventual) fair reward mechanism in an asynchronous system.

Note that this result holds even if all the processes are correct, but not known in advance, and the protocol tolerates Byzantine faults. In fact, it is different of the FLP impossibility result of consensus in an asynchronous system with one faulty process [FLP].

6 Numerical Examples

In this section, we examine the impact of different communication models on the fairness of reward mechanisms through several numerical examples that confirm the results on the fairness of reward mechanisms from section 5.2.

Execution

In our analyses, processes run a committee-based blockchain protocol as described in section 4, and rewards for a block produced at a height are allocated in the block at height . Fig. 1 depicts the state machine of the execution. Note that the consensus module is Byzantine fault tolerant. We highlight the environment’s important characteristics: the communication system, the total number of processes in the system, the size of each committee, the different type of processes and their number at a given height, the rewarding mechanism, and the selection mechanism. We must choose the value of these parameters before launching the execution. We consider different communication systems, and rewards are allocated by the next committee by using messages they delivered from the previous height – use the combination of all messages and check if they correspond to the correct time and a possible value to send according to the state.

We consider a system where all processes are part of all consensus instances. For clarity, and without loss of generality, we consider a system with processes where all are selected. There is no impact from the selection mechanism. As stated in Remark 1, selecting all processes is a fair selection mechanism. We can now focus on the impact of the network on rewards. For any height , there can be at most non -correct processes in each committee. For a committee, a quorum of is needed for any decisions. In the case where there are for any height some non -correct processes, we assume that processes have enough information to detect it when distributing rewards. In particular, and for the experiment the Byzantine are specially tagged, and that tag is used only for allocating rewards. When an -correct receives a message from a non -correct, it suspects it, and broadcasts the information. When an -correct delivers at least suspicions for a process, it considers it as non -correct, and does not propose to reward it.

We use MATLAB [matlab] for our analysis. We consider three different communication models. First, we consider a synchronous communication, where there is no delay. Then we consider the two following semi-synchronous communication models (i) the system alternate between sufficiently good and bad periods where during good periods, messages delays are upper bounded (good/bad model), and (ii) from an unknown time message delays are upper bounded (eventually synchronous model).

In all these models, consensus can be reached. In the good/bad model, progress for consensus instances are guaranteed during the good periods. Note that in the eventually synchronous model, once the global stabilization time (GST) happens all message delays are upper bounded. If for a process, GST happens during height , then for all height , the message delays are upper bounded.

In each configuration of the communication model, we ran the experiment 50 times, and took the mean. We represent by if a process did not receive a reward, and if the process received a reward for the corresponding height.

6.1 Synchronous Model

In the synchronous system, we consider that processes receive messages instantly; there is no message delay.

When all processes are correct in a synchronous system, all processes are always rewarded. Since messages are received instantly, all processes always have the same information. If for a height , one process is non -correct, other processes have sufficient information to detect it, the non -correct is not rewarded, and it is true for all height. Since for all height , all -correct processes have a reward, and non -correct processes do not have a reward, the reward mechanism is fair. The conditions 1, -completeness (condition 2) and -accuracy (condition 3) of reward mechanisms are satisfied.

6.2 Good/Bad Periods Model

We consider a system where there are good and bad periods, where good periods are sufficiently long in order to achieve consensus. We also assume that in this setting all processes are correct throughout the whole execution. If the reward mechanism is (eventually) fair, then all processes should always be rewarded (from a time on), since they are all correct. That is not the case. For instance, consider the following scenario: the system is composed of processes, all correct. Moreover, all processes but one, , are well connected and such that consensus is always reached. eventually reaches consensus, but always after the other processes decide on the set of processes to reward. will never be rewarded, although it always participates correctly to each consensus instance. The -completeness condition 2 is never satisfied because of , so the mechanism is neither fair, nor eventually fair.

6.3 Eventually Synchronous Model

Figure 2: Evolution of Rewards in an Eventual Synchronous System, where Global Stabilization Time happens during height .

We consider an eventual synchronous model where all processes are correct, and part of each committee instances. Recall that eventual synchronous is a system where after a finite but unknown time (the Global Stabilization Time), message delay is upper bounded for the rest of the execution. In our examples, we consider that the Global Stabilization Time happens during height .

On Fig. 2

, we show the evolution of reward for each height. We draw the mean of the average reward of each participant (represented by the red curve). The blue and yellow curves represent the standard deviation. We can see the set in which the processes are rewarded. If the blue and yellow curves converge, it means that all processes have on average the same reward.

On Fig. 2, from height , the evolution of the reward is increasing. Approximately from height till the end, all processes are rewarded. Before height , there is a fluctuation in the evolution of rewards allocated because of the asynchronous periods, processes are not necessarily rewarded even if the participate. Their messages were not received on time. Once the global stabilization time happens, the message delays become upper bounded, but some processes still have a time-out shorter than the bound. These processes still increase their time-out until they receive all messages, or detect incorrect behavior. When all processes deliver messages during their corresponding rounds, they allocate the rewards to all correct processes. All processes being correct, it means that the reward mechanism is eventually fair, which happens in our example.

7 Conclusions and Future Works

The originality of our contribution is the study of the impact of network conditions on the fairness of the rewarding in committee-based blockchains prone to Byzantine behavior. We proved that the reward mechanism is (eventually) fair iff the system communication is (eventually) synchronous and Byzantine processes are detectable. Our study opens interesting future research directions in particular the extension to other types of behaviors such as rational or amnesic. Furthermore, we are interested in studying the impact of network attacks on the fairness of rewarding. Another interesting direction is the design of self-adaptative fair rewarding schemes.

Acknowledgment

The authors thank Ludovic Desmeuzes for his work on the numerical examples.

References