# A computational study on fairness of the Tendermint blockchain protocol

Nicolas Lagaillardie, Mohamed Aimen Djari, Onder Gürcan

► To cite this version:

Nicolas Lagaillardie, Mohamed Aimen Djari, Onder Gürcan. A computational study on fairness of the Tendermint blockchain protocol. Information, 2019, 10, pp.378. 10.3390/info10120378. cea-04503020

HAL Id: cea-04503020

https://cea.hal.science/cea-04503020

Submitted on 13 Mar 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Article

# A Computational Study on Fairness of the Tendermint Blockchain Protocol

Nicolas Lagaillardie†, Mohamed Aimen Djari and Önder Gürcan

CEA, LIST, Point Courrier 174, F-91191 Gif-sur-Yvette, France; nicolas.lagaillardie@etu.ese.fr (N.L.); Mohamed-Aimen.DJARI@ca.fr (M.A.D.)

* Correspondence: onder.gurcan@cea.fr; Tel.: +33-1-69-08-00-07

† Current address: Imperial College London, London SW7 2AZ, UK.

Received: 1 November 2019; Accepted: 25 November 2019; Published: 30 November 2019

<figure><img src="image_1.png" /></figure>

check for
updates

**Abstract:** Fairness is a crucial property for blockchain systems since it affects the participation: the ones that find the system fair tend to stay or enter, the ones that find the system unfair tend to leave. While current literature mainly focuses on fairness for Bitcoin-like blockchains, little has been done to analyze Tendermint. Tendermint is a blockchain technology that uses a committee-based consensus algorithm, which finds an agreement among a set of block creators (called validators), even if some are malicious. Validators are regularly selected to the committee based on their investments. When a validator does not have enough asset to invest, it can increase it with the help of participants that delegate their assets to the validators (called delegators). In this paper, we implement the default Tendermint model and a Tendermint model for fairness in a multi-agent blockchain simulator where participants are modeled as rational agents who enter or leave the system based on their utility values. We conducted experiments for both models where agents have different investment strategies and with various numbers of delegators. In the light of our experimental evaluation, we observed that while, for both models, the fairness decreases and the system shrinks in the absence of delegators, the fairness increases, and the system expands for the second model in the presence of delegators.

**Keywords:** blockchain; tendermint; fairness; simulation

## 1. Introduction

Bitcoin, introduced by Satoshi Nakamoto [1], is the core of blockchain systems—decentralized transactional systems that are based on blockchain protocols. Participants following blockchain protocols can create together a distributed, economical, social and technical system where anyone can join and leave and perform transactions in between without either needing to trust each other or having a trusted third party. It is a very attractive technology since it maintains a *public*, *immutable* and *ordered* log of transactions that guarantees an *auditable* ledger accessible by anyone. The security and sustainability of blockchains, however, are not trivial and require increased participation, since each participant validates the diffused data, and keeps a replica of the entire blockchain. Participants consider it worthwhile to join and stay in the system over time if they find it fair.

Generally speaking, a blockchain system is an open and distributed system composed of participants called users and block creators. Users create transactions and broadcast across the blockchain network for being confirmed. Note that, due to the characteristics of the network, every participant will receive in different orders and also some transactions might be lost during communication. In this sense, block creators are responsible for ordering transactions totally as blocks for appending to the blockchain in an immutable manner. Block creators (based on the consensus algorithm used and the blockchain technology, block creators are named as miners [1], validators Ref [2], bakers [3], committee members [4,5], and so on, respectively.) agree on how and who to create a block
Article

# A Computational Study on Fairness of the Tendermint Blockchain Protocol

Nicolas Lagaillardie†, Mohamed Aimen Djari and Önder Gürcan

CEA, LIST, Point Courrier 174, F-91191 Gif-sur-Yvette, France; nicolas.lagaillardie@etu.ese.fr (N.L.); Mohamed-Aimen.DJARI@ca.fr (M.A.D.)

* Correspondence: onder.gurcan@cea.fr; Tel.: +33-1-69-08-00-07

† Current address: Imperial College London, London SW7 2AZ, UK.

Received: 1 November 2019; Accepted: 25 November 2019; Published: 30 November 2019

<figure><img src="image_2.png" /></figure>

check for
updates

**Abstract:** Fairness is a crucial property for blockchain systems since it affects the participation: the ones that find the system fair tend to stay or enter, the ones that find the system unfair tend to leave. While current literature mainly focuses on fairness for Bitcoin-like blockchains, little has been done to analyze Tendermint. Tendermint is a blockchain technology that uses a committee-based consensus algorithm, which finds an agreement among a set of block creators (called validators), even if some are malicious. Validators are regularly selected to the committee based on their investments. When a validator does not have enough asset to invest, it can increase it with the help of participants that delegate their assets to the validators (called delegators). In this paper, we implement the default Tendermint model and a Tendermint model for fairness in a multi-agent blockchain simulator where participants are modeled as rational agents who enter or leave the system based on their utility values. We conducted experiments for both models where agents have different investment strategies and with various numbers of delegators. In the light of our experimental evaluation, we observed that while, for both models, the fairness decreases and the system shrinks in the absence of delegators, the fairness increases, and the system expands for the second model in the presence of delegators.

**Keywords:** blockchain; tendermint; fairness; simulation

## 1. Introduction

Bitcoin, introduced by Satoshi Nakamoto [1], is the core of blockchain systems—decentralized transactional systems that are based on blockchain protocols. Participants following blockchain protocols can create together a distributed, economical, social and technical system where anyone can join and leave and perform transactions in between without either needing to trust each other or having a trusted third party. It is a very attractive technology since it maintains a *public*, *immutable* and *ordered* log of transactions that guarantees an *auditable* ledger accessible by anyone. The security and sustainability of blockchains, however, are not trivial and require increased participation, since each participant validates the diffused data, and keeps a replica of the entire blockchain. Participants consider it worthwhile to join and stay in the system over time if they find it fair.

Generally speaking, a blockchain system is an open and distributed system composed of participants called users and block creators. Users create transactions and broadcast across the blockchain network for being confirmed. Note that, due to the characteristics of the network, every participant will receive in different orders and also some transactions might be lost during communication. In this sense, block creators are responsible for ordering transactions totally as blocks for appending to the blockchain in an immutable manner. Block creators (based on the consensus algorithm used and the blockchain technology, block creators are named as miners [1], validators Ref [2], bakers [3], committee members [4,5], and so on, respectively.) agree on how and who to create a block
(consensus) either by themselves (Proof-of-Work [6], Proof-of-Stake, Delegated Proof-of-Stake, etc.) or by a committee (Practical Byzantine Fault-Tolerance [7], etc.)—see [8] for a review. Blockchain systems are usually classified with respect to their consensus algorithms as *Bitcoin-like blockchains* (Since Bitcoin came up by Proof-of-Work, blockchains using Proof-of-something algorithms are classified as Bitcoin-like.) (e.g., Bitcoin [1], Ethereum [2]), *committee-based blockchains* (e.g., Tendermint [4], RedBelly Ref [9]) and *hybrid blockchains* (e.g., PeerCensus [10], Byzcoin [11]). Considering Bitcoin-like blockchains, several studies have been conducted so far analyzing and improving fairness both for block creators Ref [12–20] and for users [21–23]. However, fairness in committee-based blockchains has not been studied much yet.

Based on this observation, in this paper, we study the fairness of the committee-based blockchain Tendermint [4]. We have chosen Tendermint because, in [24], it has been shown by mathematical analyzes that Tendermint, as a closed system, is *unfair* for some of its participants. However, we consider Tendermint as an open system and thus aim to study its fairness by computational analyzes. To this end, we modeled each participant, like in [21], as a *rational agent* who finds the system *fair* if the total satisfaction of its expectations is above a certain degree. We, then, realized two implementations of Tendermint: (1) as proposed by Buchman et al. [4], which we call the *Tendermint Default protocol* and (2) as proposed by us, which we call the *Tendermint Fairness protocol*. We conducted various simulation experiments with different initial conditions and different agent strategies.

## 1.1. Contributions

The contributions of this study are as follows:

* A *fairness* improvement for the Tendermint protocol;

* A *computational* analysis of the fairness in the Tendermint protocol.

## 1.2. Organization

The organization of this paper is as follows. Section 2 provides background about the Tendermint protocol. Section 3 provides a formalization of the existing Tendermint protocol. Section 4 improves this formalization by improving fairness of the behaviors for participants. In Section 5, make simulation analyzes of both models. Results and discussion are presented in Section 6. Section 7 presents the related work and, finally, Section 8 concludes the paper.

# 2. Background

In this section, we give background information about the Tendermint blockchain protocol. Tendermint is a *committee-based* blockchain protocol that uses an adaptation of the Practical Byzantine Fault Tolerance (PBFT) algorithm [7] as its consensus algorithm. In the following, we first describe the PBFT algorithm (Section 2.1) and then we describe the Tendermint protocol (Section 2.2).

## 2.1. *Practical Byzantine Fault Tolerance*

The PBFT algorithm [7] is a variant of traditional Byzantine Fault Tolerant (BFT) consensus algorithms that are resilient to both byzantine and crash failures and generally work under partial synchrony assumptions and bounded communication latency. In PBFT, an agreement among *n* nodes is reached through the transmission of *O*(n²) messages; it does so relying on a three phase round division where in each round a value (e.g., a block) is validated passing through a *pre-prepared, prepared* and *commit* steps. Each peer's proposal accesses to the next phase only with the 2/3 network approval. Therefore, the algorithm requires at least 2*f* + 1 honest replicas to tolerate *f* faulty nodes.

Figure 1 illustrates the normal operation of this protocol. Here, the line ‘C’ represents the operations of a peer requesting an agreement on something (in particular, sending a transaction in the context of the blockchain), and waiting for the reply. The lines ‘0–3’ represent the operation of peers running the PBFT protocol, ‘3’ is faulty and ‘0’ is called the *proposer*.
(consensus) either by themselves (Proof-of-Work [6], Proof-of-Stake, Delegated Proof-of-Stake, etc.) or by a committee (Practical Byzantine Fault-Tolerance [7], etc.)—see [8] for a review. Blockchain systems are usually classified with respect to their consensus algorithms as *Bitcoin-like blockchains* (Since Bitcoin came up by Proof-of-Work, blockchains using Proof-of-something algorithms are classified as Bitcoin-like.) (e.g., Bitcoin [1], Ethereum [2]), *committee-based blockchains* (e.g., Tendermint [4], RedBelly Ref [9]) and *hybrid blockchains* (e.g., PeerCensus [10], Byzcoin [11]). Considering Bitcoin-like blockchains, several studies have been conducted so far analyzing and improving fairness both for block creators Ref [12–20] and for users [21–23]. However, fairness in committee-based blockchains has not been studied much yet.

Based on this observation, in this paper, we study the fairness of the committee-based blockchain Tendermint [4]. We have chosen Tendermint because, in [24], it has been shown by mathematical analyzes that Tendermint, as a closed system, is *unfair* for some of its participants. However, we consider Tendermint as an open system and thus aim to study its fairness by computational analyzes. To this end, we modeled each participant, like in [21], as a *rational agent* who finds the system *fair* if the total satisfaction of its expectations is above a certain degree. We, then, realized two implementations of Tendermint: (1) as proposed by Buchman et al. [4], which we call the *Tendermint Default protocol* and (2) as proposed by us, which we call the *Tendermint Fairness protocol*. We conducted various simulation experiments with different initial conditions and different agent strategies.

## 1.1. Contributions

The contributions of this study are as follows:

* A *fairness* improvement for the Tendermint protocol;

* A *computational* analysis of the fairness in the Tendermint protocol.

## 1.2. Organization

The organization of this paper is as follows. Section 2 provides background about the Tendermint protocol. Section 3 provides a formalization of the existing Tendermint protocol. Section 4 improves this formalization by improving fairness of the behaviors for participants. In Section 5, make simulation analyzes of both models. Results and discussion are presented in Section 6. Section 7 presents the related work and, finally, Section 8 concludes the paper.

# 2. Background

In this section, we give background information about the Tendermint blockchain protocol. Tendermint is a *committee-based* blockchain protocol that uses an adaptation of the Practical Byzantine Fault Tolerance (PBFT) algorithm [7] as its consensus algorithm. In the following, we first describe the PBFT algorithm (Section 2.1) and then we describe the Tendermint protocol (Section 2.2).

## 2.1. *Practical Byzantine Fault Tolerance*

The PBFT algorithm [7] is a variant of traditional Byzantine Fault Tolerant (BFT) consensus algorithms that are resilient to both byzantine and crash failures and generally work under partial synchrony assumptions and bounded communication latency. In PBFT, an agreement among *n* nodes is reached through the transmission of *O*(n²) messages; it does so relying on a three phase round division where in each round a value (e.g., a block) is validated passing through a *pre-prepared, prepared* and *commit* steps. Each peer's proposal accesses to the next phase only with the 2/3 network approval. Therefore, the algorithm requires at least 2*f* + 1 honest replicas to tolerate *f* faulty nodes.

Figure 1 illustrates the normal operation of this protocol. Here, the line ‘C’ represents the operations of a peer requesting an agreement on something (in particular, sending a transaction in the context of the blockchain), and waiting for the reply. The lines ‘0–3’ represent the operation of peers running the PBFT protocol, ‘3’ is faulty and ‘0’ is called the *proposer*.
<figure><img src="image_2.png" /><figcaption>**Figure 1.** Normal execution of the Practical Byzantine Fault Tolerance (PBFT) protocol [7].</figcaption></figure>

## 2.2. Tendermint Protocol

Tendermint is a *committee-based* blockchain protocol that relies on the *proof-of-stake* (PoS) algorithm for the selection of the committee. The Tendermint protocol defines three types of participants [25]: the *users*, the *validators*, and the *delegators*; and two types of assets: the *balance* and the *stake*. Users create transactions, validators create blocks, and delegators invest in validators. For each new block, a committee is *selected* among the validator, a validator can only create a block if it is in the committee. Each participant keeps an account balance on the blockchain data structure. All participants can use their balances to send or receive assets to or from other participants. Validators and delegators can *invest* their balances in stakes, and stakes can be *withdrawn* into balances. The more stakes a validator has, the higher its chance to become a *block creator* (i.e., PoS). The delegators, on the other hand, do not directly enter into the committee and create blocks, but invest in validators they choose to increase their chance to be in the committee. In general, validators who are aware that they do not have enough stakes to be selected as block creators become delegators. All participants can switch roles at any moment: the amount of personal stakes and where they are determined the role.

For each new block that needs to be created, a committee is *selected* among the validators. The selection of validators for the committee is a deterministic process: each participant knows the committee size and can compute the stakes of the validators thanks to its own local copy of blockchain for selecting the wealthiest. During this process, if a participant acts incorrectly and this is detected by the others, its stakes and the stakes of the delegators which invested in it are *slashed*, i.e., the stakes are burnt and remain unusable.

When a committee is selected, its members go through a PBFT process as explained in Section 2.1. This process is illustrated in Figure 2 (even though in the original Tendermint paper [7] the consensus protocol steps are named *propose*, *prevote*, *precommit*, and *commit*, hereafter, in this paper, we prefer to use *prepropose*, *propose*, *vote*, and *commit*, respectively, as proposed in [7].) At round *r*, the *r*th validator, modulo the size of the committee, is considered as the *proposer*. The proposer sends a *prepropose message* containing a *block proposal* to all validators in the committee, including itself. It can propose a block that has already been proposed in a different round for the same height. Validators check the proposal, and, if they found it valid, they send a *propose message* containing the proposal to the other validators.

When a validator receives at least 2/3 of the proposed messages containing the same valid block, it broadcasts to the whole blockchain system a *vote message* containing the proposal. When at least 2/3 of the vote messages containing the same valid block are received by a participant, it *commits* the block: i.e., it appends it to its own blockchain. Otherwise, it considers the block invalid and moves to a new round with a new proposer. A block can be proposed more than once in different rounds for the same height. Upon a successful creation of a new block, the committee members are rewarded. However, unlike Bitcoin-like blockchains where block creators are rewarded directly by themselves, in Tendermint, block creators (committee members) are rewarded by the following committee.
<figure><img src="image_3.png" /><figcaption>**Figure 1.** Normal execution of the Practical Byzantine Fault Tolerance (PBFT) protocol [7].</figcaption></figure>

## 2.2. Tendermint Protocol

Tendermint is a *committee-based* blockchain protocol that relies on the *proof-of-stake* (PoS) algorithm for the selection of the committee. The Tendermint protocol defines three types of participants [25]: the *users*, the *validators*, and the *delegators*; and two types of assets: the *balance* and the *stake*. Users create transactions, validators create blocks, and delegators invest in validators. For each new block, a committee is *selected* among the validator, a validator can only create a block if it is in the committee. Each participant keeps an account balance on the blockchain data structure. All participants can use their balances to send or receive assets to or from other participants. Validators and delegators can *invest* their balances in stakes, and stakes can be *withdrawn* into balances. The more stakes a validator has, the higher its chance to become a *block creator* (i.e., PoS). The delegators, on the other hand, do not directly enter into the committee and create blocks, but invest in validators they choose to increase their chance to be in the committee. In general, validators who are aware that they do not have enough stakes to be selected as block creators become delegators. All participants can switch roles at any moment: the amount of personal stakes and where they are determined the role.

For each new block that needs to be created, a committee is *selected* among the validators. The selection of validators for the committee is a deterministic process: each participant knows the committee size and can compute the stakes of the validators thanks to its own local copy of blockchain for selecting the wealthiest. During this process, if a participant acts incorrectly and this is detected by the others, its stakes and the stakes of the delegators which invested in it are *slashed*, i.e., the stakes are burnt and remain unusable.

When a committee is selected, its members go through a PBFT process as explained in Section 2.1. This process is illustrated in Figure 2 (even though in the original Tendermint paper [7] the consensus protocol steps are named *propose*, *prevote*, *precommit*, and *commit*, hereafter, in this paper, we prefer to use *prepropose*, *propose*, *vote*, and *commit*, respectively, as proposed in [7].) At round *r*, the *r*th validator, modulo the size of the committee, is considered as the *proposer*. The proposer sends a *prepropose message* containing a *block proposal* to all validators in the committee, including itself. It can propose a block that has already been proposed in a different round for the same height. Validators check the proposal, and, if they found it valid, they send a *propose message* containing the proposal to the other validators.

When a validator receives at least 2/3 of the proposed messages containing the same valid block, it broadcasts to the whole blockchain system a *vote message* containing the proposal. When at least 2/3 of the vote messages containing the same valid block are received by a participant, it *commits* the block: i.e., it appends it to its own blockchain. Otherwise, it considers the block invalid and moves to a new round with a new proposer. A block can be proposed more than once in different rounds for the same height. Upon a successful creation of a new block, the committee members are rewarded. However, unlike Bitcoin-like blockchains where block creators are rewarded directly by themselves, in Tendermint, block creators (committee members) are rewarded by the following committee.
## 3.2. Fairness Model

We model fairness based on the fairness model proposed in [21]. In this sense, we model all nodes in the blockchain network G as rational agents. A rational agent behaves according to its local perceptions and local knowledge, models uncertainty via expected values of variables or actions, and always chooses to perform the actions with the optimal expected outcome (among all feasible actions) for maximizing its utility [26]. Each rational agent $n \in N$ has a set of actions $A_n$ and a utility function $U_n$. Using $A_n$ and $U_n$, $n$ uses a decision process where it identifies the possible sequences of actions to execute. We call these sequences rational behaviors of $n$ and denote as $\beta$. The objective of $n$ is to choose the behaviors that selfishly keep $U_n$ as high as possible.

We model the utility function of a rational agent $n \in N$ as $U_n = u_0 + \sum_{i=1}^k U(\beta_i)$, where $u_0$ is the initial utility value, $k \ge 0$ is the number of behaviors executed so far, and $U(\beta_i)$ is the utility value of the behavior $\beta_i$. A utility value $U(\beta_i)$ can also be interpreted as the degree of satisfaction experienced by the realization of $\beta_i$. The utility value $U(\beta_i)$ is calculated as $R(\beta_i) - C(\beta_i)$, where $R(\beta_i)$ is the overall reward gained and $C(\beta_i)$ is the overall cost spent for the execution of $\beta_i$.

**Fairness:** A rational agent $n \in N$ finds a system (i.e., the blockchain network) G fair, if the total satisfaction of its expectations $U_n$ is above a certain degree $\tau_n$, where $\tau_n < u_0$.

If, at any time, an agent $n$ finds G unfair ($U_n \le \tau_n$), it may decide to leave G if, from its points of view, it will not be possible to increase its overall utility above $\tau_n$ by calculating the expected values of its possible future behaviors. In other words, $n$ may decide to leave G if $U_n + \sum_{j=k}^{m} \mathcal{E}(\beta_j) \le \tau_n$ where $\beta_k, ..., \beta_m$ are sufficiently enough desired future behaviors of $n$.

## 3.3. Blockchain Model

We model the blockchain ledger of an agent $n$ as a dynamic append-only linked list $B_n = \{b_0 \leftarrow r_0, b_1 \leftarrow r_1, ..., \leftarrow r_{h-1}, b_h\}$, where each block $b_i$ ($0 < i \le h$) contains a cryptographic reference $r_{i-1}$ to its previous block $b_{i-1}$, $h = |B_n|$ is the depth of $B_n$, $b_0$ is the root block which is also called the *genesis block*, and $b_h$ is the furthest block from the genesis block, which is referred to as the *blockchain head*.

We denote a block as $b_i = \langle h_i, x \Psi_i \rangle$ where $h_i$ is the block header and $x \Psi_i$ is the block data. The block data $\Psi_i$ contains all the transactions organized as a Merkle tree [27]. Basically, the copies of each transaction are hashed, and the hashes are then paired, hashed, paired again, and hashed again until a single hash remains, the Merkle root of a Merkle tree. We denote a Merkle tree and its root as $\Psi_i$ and $\psi_i$, respectively. A Merkle tree $\Psi_i$ is created using the action of the form $\text{createMerkleTree}(X_{i-1}, \theta_v)$, where $X_{i-1}$ is the set of coinbase transactions that reward the validator agents $V$ and the delegator agents $d \in D$ of the previous block $b_{i-1}$ with a total block reward $\gamma$ for their work, $\theta_v \subseteq \Theta_v$ is the set of candidate transactions chosen for this block. The set of candidate transactions $\theta_v$ is selected using the action of the form $\text{selectTransactions}(\Theta_v) : \theta_v$, where $\Theta_v$ is the memory pool of the validator.

The block header is denoted as $h_i = \{v_n, \mathcal{H}(h_{i-1}), \mathcal{H}(h_i), t_{b_i}, \psi_i\}$, where $v_n$ is the version number of the protocol used by $n$, $\mathcal{H}(\cdot)$ is the cryptographic hash function, $\mathcal{H}(h_{i-1})$ is the cryptographic hash code of the header of the previous block $b_{i-1}$ ($i > 0$), $\mathcal{H}(h_i)$ is the cryptographic hash code of $h_i$ generated by $m, t_{b_i}$ is the current timestamp, and $\psi_i$ is the root of the Merkle tree.

We model a transaction as $tx = \langle I, O \rangle$ where $I$ is a list of inputs ($I \ne \emptyset$) and $O$ is a list of outputs ($O \ne \emptyset$). We model the outputs as $o_i = \langle m, c_{o_i} \rangle$, where $m \in N$ is the receiver of the coins $c_{o_i}$ ($c_{o_i} \ge 0$). All inputs of a transaction have to be spent in that transaction and the total input coins $c_I$ has to be greater than or equal to the total output coins $c_O$. The fee $f_{tx}$ of a transaction $tx$ is then modeled as $f_{tx} = c_I - c_O$. Depending on the fee to be paid, if there are still some coins left to be spent, the sender can add an output that pays this remainder to itself.

A coinbase transaction $tx \in X_i$ is a special transaction that collects and spends any transaction fees paid by transactions included in a block and exceptionally it does not have any input set ($I = \emptyset$). It is the first transaction in a block and can only be created by a validator when it is proposing a block.
## 3.2. Fairness Model

We model fairness based on the fairness model proposed in [21]. In this sense, we model all nodes in the blockchain network G as rational agents. A rational agent behaves according to its local perceptions and local knowledge, models uncertainty via expected values of variables or actions, and always chooses to perform the actions with the optimal expected outcome (among all feasible actions) for maximizing its utility [26]. Each rational agent $n \in N$ has a set of actions $A_n$ and a utility function $U_n$. Using $A_n$ and $U_n$, $n$ uses a decision process where it identifies the possible sequences of actions to execute. We call these sequences rational behaviors of $n$ and denote as $\beta$. The objective of $n$ is to choose the behaviors that selfishly keep $U_n$ as high as possible.

We model the utility function of a rational agent $n \in N$ as $U_n = u_0 + \sum_{i=1}^k U(\beta_i)$, where $u_0$ is the initial utility value, $k \ge 0$ is the number of behaviors executed so far, and $U(\beta_i)$ is the utility value of the behavior $\beta_i$. A utility value $U(\beta_i)$ can also be interpreted as the degree of satisfaction experienced by the realization of $\beta_i$. The utility value $U(\beta_i)$ is calculated as $R(\beta_i) - C(\beta_i)$, where $R(\beta_i)$ is the overall reward gained and $C(\beta_i)$ is the overall cost spent for the execution of $\beta_i$.

**Fairness:** A rational agent $n \in N$ finds a system (i.e., the blockchain network) G fair, if the total satisfaction of its expectations $U_n$ is above a certain degree $\tau_n$, where $\tau_n < u_0$.

If, at any time, an agent $n$ finds G unfair ($U_n \le \tau_n$), it may decide to leave G if, from its points of view, it will not be possible to increase its overall utility above $\tau_n$ by calculating the expected values of its possible future behaviors. In other words, $n$ may decide to leave G if $U_n + \sum_{j=k}^{m} \varepsilon(\beta_j) \le \tau_n$ where $\beta_k, ..., \beta_m$ are sufficiently enough desired future behaviors of $n$.

## 3.3. Blockchain Model

We model the blockchain ledger of an agent $n$ as a dynamic append-only linked list $B_n = \{b_0 \leftarrow r_0, b_1 \leftarrow r_1, ..., \leftarrow r_{h-1}, b_h\}$, where each block $b_i$ ($0 < i \le h$) contains a cryptographic reference $r_{i-1}$ to its previous block $b_{i-1}$, $h = |B_n|$ is the depth of $B_n$, $b_0$ is the root block which is also called the *genesis block*, and $b_h$ is the furthest block from the genesis block, which is referred to as the *blockchain head*.

We denote a block as $b_i = \langle h_i, x \Psi_i \rangle$ where $h_i$ is the block header and $x \Psi_i$ is the block data. The block data $\Psi_i$ contains all the transactions organized as a Merkle tree [27]. Basically, the copies of each transaction are hashed, and the hashes are then paired, hashed, paired again, and hashed again until a single hash remains, the Merkle root of a Merkle tree. We denote a Merkle tree and its root as $\Psi_i$ and $\psi_i$, respectively. A Merkle tree $\Psi_i$ is created using the action of the form $\text{createMerkleTree}(X_{i-1}, \theta_v)$, where $X_{i-1}$ is the set of coinbase transactions that reward the validator agents $V$ and the delegator agents $d \in D$ of the previous block $b_{i-1}$ with a total block reward $\gamma$ for their work, $\theta_v \subseteq \Theta_v$ is the set of candidate transactions chosen for this block. The set of candidate transactions $\theta_v$ is selected using the action of the form $\text{selectTransactions}(\Theta_v) : \theta_v$, where $\Theta_v$ is the memory pool of the validator.

The block header is denoted as $h_i = \{v_n, \mathcal{H}(h_{i-1}), \mathcal{H}(h_i), t_{b_i}, \psi_i\}$, where $v_n$ is the version number of the protocol used by $n$, $\mathcal{H}(\cdot)$ is the cryptographic hash function, $\mathcal{H}(h_{i-1})$ is the cryptographic hash code of the header of the previous block $b_{i-1}$ ($i > 0$), $\mathcal{H}(h_i)$ is the cryptographic hash code of $h_i$ generated by $m, t_{b_i}$ is the current timestamp, and $\psi_i$ is the root of the Merkle tree.

We model a transaction as $tx = \langle I, O \rangle$ where $I$ is a list of inputs ($I \ne \emptyset$) and $O$ is a list of outputs ($O \ne \emptyset$). We model the outputs as $o_i = \langle m, c_{o_i} \rangle$, where $m \in N$ is the receiver of the coins $c_{o_i}$ ($c_{o_i} \ge 0$). All inputs of a transaction have to be spent in that transaction and the total input coins $c_I$ has to be greater than or equal to the total output coins $c_O$. The fee $f_{tx}$ of a transaction $tx$ is then modeled as $f_{tx} = c_I - c_O$. Depending on the fee to be paid, if there are still some coins left to be spent, the sender can add an output that pays this remainder to itself.

A coinbase transaction $tx \in X_i$ is a special transaction that collects and spends any transaction fees paid by transactions included in a block and exceptionally it does not have any input set ($I = \emptyset$). It is the first transaction in a block and can only be created by a validator when it is proposing a block.
### 3.4. Validator Model

An agent $v \in V$, where $V \subseteq N$, is said to be a *validator* if it is capable of participating in the creation of blocks (consensus) for confirming the transactions in its memory pool $\Theta_v$. To do so, $v$ can use its actions of the form `prepropose()`, `propose()`, `vote()` and `commit()` (see Algorithm 1). When $v$ receives a message $m$, it handles it using the action `handleMessage(m)` to store $m$ into one of the corresponding received messages list, i.e., $M_{pre}$, $M_{pro}$ and $M_{vote}$.

<caption>**Algorithm 1** The actions of a validator agent $v$ for creation of the $i$th block</caption>

1: **action prepropose()**
2:     $b_i \leftarrow createBlock()
3:     send(\langle v, "prepropose", b_i \rangle, C_i)
4:
5: **action propose()**
6:     **if** (valid($b_i$)) **then**
7:         send(\langle v, "propose", b_i \rangle, C_i)
8:     **else**
9:         send(\langle v, "propose", nil \rangle, C_i)
10:    **endif**
11:
12: **action vote()**
13:     **if** ($|M_{pro}^{b_i}| > 2/3 |C_i|$) **then**
14:         send(\langle v, "vote", $b_i$ \rangle, C_i)
15:     **else**
16:         send(\langle v, "vote", nil, $n$ \rangle, C_i)
17:    **endif**
18:
19: **action commit()**
20:     **if** ($|M_{vote}^{b_i}| > 2/3 |C_i|$) **then**
21:         $B_v \leftarrow B_v \cup \{b_i\}$
22:     **else**
23:         newRound()
24:     **endif**
25:
26: **action createCoinbaseTxs()**
27:     **for each** ($z \in C_{i-1}$) **do**
28:         **for each** ($d \in D(z)$) **do**
29:             $\gamma_d = \frac{\gamma_{i-1}}{|C_{i-1}|} \times \frac{s_z}{s_z}$
30:             $X_{i-1} \leftarrow \{d, \gamma_d\}$
31:         **endfor**
32:         $\gamma_z = \frac{\gamma_{i-1}}{|C_{i-1}|} \times \frac{s_z}{s_z}$
33:     $X_{i-1} \leftarrow \{z, \gamma_z\}$

During the creation of block $b_{h+1}$, $v$ is said to be a committee member ($v \in C_{h+1}$ where $C_{h+1} \subseteq V$) if it has enough stakes $s_v$. If $v$ does not have enough stakes, it can invest a certain amount $a$ into stakes in order to be selected in the committee using the action `invest(a)` where $a \le \text{balance } \phi_v$. At any time, $v$ can withdraw a certain amount $a$ from its investment $s_v$ into its balance $\phi_v$ using the action `withdraw(a)`.

Blocks are created using the action `createBlock()`, and they contain the reward transactions for the last committee members and their delegators. These transactions are created using the action `createCoinbaseTxs()` that takes into account the personal stakes of the validator $v_i$, called $s_{v_i}^{v_i}$, the stakes
### 3.4. Validator Model

An agent $v \in V$, where $V \subseteq N$, is said to be a *validator* if it is capable of participating in the creation of blocks (consensus) for confirming the transactions in its memory pool $\Theta_v$. To do so, $v$ can use its actions of the form `prepropose()`, `propose()`, `vote()` and `commit()` (see Algorithm 1). When $v$ receives a message $m$, it handles it using the action `handleMessage(m)` to store $m$ into one of the corresponding received messages list, i.e., $M_{pre}$, $M_{pro}$ and $M_{vote}$.

<table><caption>**Algorithm 1** The actions of a validator agent $v$ for creation of the $i$th block</caption><tr><td>1:</td><td><b>action prepropose()</b></td><td>33:</td><td>X<sub>i-1</sub> &larr; {z, &gamma;<sub>z</sub>}</td></tr><tr><td>2:</td><td><b>b<sub>i</sub></b> &larr; <b>createBlock()</b></td><td>34:</td><td><b>endfor</b></td></tr><tr><td>3:</td><td><b>send</b>((&#x2192;,&quot;prepropose&quot;, <b>b<sub>i</sub></b>), <b>C<sub>i</sub></b>)</td><td>35:</td><td><b>return</b> X<sub>i-1</sub></td></tr><tr><td>4:</td><td><b>endfor</b></td><td>36:</td><td></td></tr><tr><td>5:</td><td><b>action propose()</b></td><td>37:</td><td><b>action createBlock()</b></td></tr><tr><td>6:</td><td><b>if</b> (valid(<b>b<sub>i</sub></b>)) <b>then</b></td><td>38:</td><td>&theta;<sub>v</sub> &larr; selectTransactions(&Theta;<sub>v</sub>)</td></tr><tr><td>7:</td><td><b>send</b>((&#x2192;,&quot;propose&quot;, <b>b<sub>i</sub></b>), <b>C<sub>i</sub></b>)</td><td>39:</td><td>X<sub>i-1</sub> &larr; createCoinbaseTxs()</td></tr><tr><td>8:</td><td><b>else</b></td><td>40:</td><td>&Psi;<sub>i</sub> &larr; createMerkleTree(X<sub>i-1</sub>, &theta;<sub>v</sub>)</td></tr><tr><td>9:</td><td><b>send</b>((&#x2192;,&quot;propose&quot;, <b>nil</b>), <b>C<sub>i</sub></b>)</td><td>41:</td><td><b>b<sub>i</sub></b> &larr; (&#x2192;h<sub>i</sub>, &Psi;<sub>i</sub>)</td></tr><tr><td>10:</td><td><b>endif</b></td><td>42:</td><td><b>return</b> <b>b<sub>i</sub></b></td></tr><tr><td>11:</td><td><b>endfor</b></td><td>43:</td><td></td></tr><tr><td>12:</td><td><b>action vote()</b></td><td>44:</td><td><b>action invest(a)</b></td></tr><tr><td>13:</td><td><b>if</b> (<b>M<sup>b<sub>i</sub></sup><sub>pro</sub></b> &gt; 2/3 |C<sub>i</sub>|) <b>then</b></td><td>45:</td><td><b>if</b> (<b>&phi;<sub>v<sub>i</sub></sub></b> &ge; a) <b>then</b></td></tr><tr><td>14:</td><td><b>send</b>((&#x2192;,&quot;vote&quot;, <b>b<sub>i</sub></b>), <b>C<sub>i</sub></b>)</td><td>46:</td><td>&phi;<sub>v<sub>i</sub></sub> &larr; &phi;<sub>v<sub>i</sub></sub> &minus; a</td></tr><tr><td>15:</td><td><b>else</b></td><td>47:</td><td><b>s<sub>v<sub>i</sub></sub></b> &larr; <b>s<sub>v<sub>i</sub></sub></b> + a</td></tr><tr><td>16:</td><td><b>send</b>((&#x2192;,&quot;vote&quot;, <b>nil</b>, <b>n</b>), <b>C<sub>i</sub></b>)</td><td>48:</td><td><b>endif</b></td></tr><tr><td>17:</td><td><b>endif</b></td><td>49:</td><td></td></tr><tr><td>18:</td><td><b>action withdraw(a)</b></td><td>50:</td><td><b>action withdraw(a)</b></td></tr><tr><td>19:</td><td><b>action commit()</b></td><td>51:</td><td><b>if</b> (<b>s<sub>v<sub>i</sub></sub></b> &ge; a) <b>then</b></td></tr><tr><td>20:</td><td><b>if</b> (<b>M<sup>b<sub>i</sub></sup><sub>vote</sub></b> &gt; 2/3 |C<sub>i</sub>|) <b>then</b></td><td>52:</td><td><b>s<sub>v<sub>i</sub></sub></b> &larr; <b>s<sub>v<sub>i</sub></sub></b> &minus; a</td></tr><tr><td>21:</td><td><b>B<sub>v</sub></b> &larr; <b>B<sub>v</sub></b> &cup; {<b>b<sub>i</sub></b>}</td><td>53:</td><td>&phi;<sub>v<sub>i</sub></sub> &larr; &phi;<sub>v<sub>i</sub></sub> + a</td></tr><tr><td>22:</td><td><b>else</b></td><td>54:</td><td><b>endif</b></td></tr><tr><td>23:</td><td><b>newRound()</b></td><td>55:</td><td></td></tr><tr><td>24:</td><td><b>endif</b></td><td>56:</td><td><b>action handleMessage(m)</b></td></tr><tr><td>25:</td><td><b>action createCoinbaseTxs()</b></td><td>57:</td><td><b>switch</b> (m)</td></tr><tr><td>26:</td><td><b>for each</b> (<i>z</i> &isin; C<sub>i-1</sub>) <b>do</b></td><td>58:</td><td><b>case</b> : "prepropose"</td></tr><tr><td>27:</td><td><b>for each</b> (<i>d</i> &isin; D(<i>z</i><sub>i</sub>)) <b>do</b></td><td>59:</td><td><b>M<sub>pre</sub></b> &larr; <b>M<sub>pre</sub></b> &cup; {m}</td></tr><tr><td>28:</td><td><b>for each</b> (<i>d</i> &isin; D(<i>z</i><sub>i</sub>)) <b>do</b></td><td>60:</td><td><b>case</b> : "propose"</td></tr><tr><td>29:</td><td><i>&gamma;<sub>d</sub></i> = (<i>&gamma;<sub>i-1</sub></i> / |C<sub>i-1</sub>|) &times; <sup>s<sub>v<sub>i</sub></sub></sup>&frasl;<sub>s<sub>v<sub>i</sub></sub></sub></td><td>61:</td><td><b>M<sub>pro</sub></b> &larr; <b>M<sub>pro</sub></b> &cup; {m}</td></tr><tr><td>30:</td><td><b>X<sub>i-1</sub></b> &larr; {<b>d</b>, <i>&gamma;<sub>d</sub></i>}</td><td>62:</td><td><b>case</b> : "vote"</td></tr><tr><td>31:</td><td><b>endfor</b></td><td>63:</td><td><b>M<sub>vote</sub></b> &larr; <b>M<sub>vote</sub></b> &cup; {m}</td></tr><tr><td>32:</td><td><i>&gamma;<sub>z</sub></i> = (<i>&gamma;<sub>i-1</sub></i> / |C<sub>i-1</sub>|) &times; <sup>s<sub>v<sub>i</sub></sub></sup>&frasl;<sub>s<sub>v<sub>i</sub></sub></sub></td><td>64:</td><td><b>endswitch</b></td></tr></table>

During the creation of block $b_{h+1}$, $v$ is said to be a committee member ($v \in C_{h+1}$ where $C_{h+1} \subseteq V$) if it has enough stakes $s_v$. If $v$ does not have enough stakes, it can invest a certain amount $a$ into stakes in order to be selected in the committee using the action `invest(a)` where $a \le$ balance $\phi_v$. At any time, $v$ can withdraw a certain amount $a$ from its investment $s_v$ into its balance $\phi_v$ using the action `withdraw(a)`.

Blocks are created using the action `createBlock()`, and they contain the reward transactions for the last committee members and their delegators. These transactions are created using the action `createCoinbaseTxs()` that takes into account the personal stakes of the validator $v_i$, called $s_{v_i}^{v_i}$, the stakes
invested by a delegator $d_i$ into a validator $v_i$, called $s_{v_i}^{d_i}$, and the global stakes of the validator $v_i$, which is the sum of its personal stakes and the stakes the delegators gave it, called $s_{v_i} = s_{v_i}^{d_i} + \sum s_{v_i}^{d_i}$.

### 3.5. Delegator Model

An agent $n \in D$, where $D \subseteq N$ and $D \cap V = \emptyset$, is said to be a *delegator* if it is capable of delegating a certain amount $a$ to a validator $v \in V$ for helping $v$ to enter into the committee using the action of the form `invest(a, v)` (see Algorithm 2). Hereafter, each time $v$ is rewarded for participating in a block creation, $n$ is also rewarded. At any time, $n \in D$ can withdraw a certain amount $a$ of its investments into its balance using the action `withdraw(a, v)`.

<caption>**Algorithm 2** The actions of a delegator agent $d$</caption>

1: **action invest(a, v)**
2:   **if** ($\phi_{v_i} \ge a$) **then**
3:     $\phi_{v_i} \leftarrow \phi_{v_i} - a$
4:     $s_{T_v} \leftarrow s_{T_v} + a$
5:     $s_i(d, v) \leftarrow s_i(d, v) + a$
6:   **endif**
7:   **end if**
8: **action withdraw(a, v)**
9:   **if** ($s_i(d, v) \ge a$) **then**
10:    $s_i(d, v) \leftarrow s_i(d, v) - a$
11:    $s_{T_v} \leftarrow s_{T_v} - a$
12:    $\phi_d \leftarrow \phi_d + a$
13: **endif**
14: **end if**

### 4. Tendermint Fairness Model

In this section, we improve the model given in Section 3 by improving the behaviors of validators in order to increase the fairness of the system. The improvements are as follows.

It has been shown in [24] that when there is less than $f$ Byzantines, and there is bad communication between some committee members, the block creation process can be frozen. To tackle this problem, rather than storing only the last valid proposed block, the committee members store all valid proposed blocks for creation block $h$. This way, if there is bad communication between the members and there are less than $f$ Byzantines, they can still remember the previously valid proposed blocks and vote for them when they are proposed once again.

As mentioned in Section 3, the committee rewards the previous one for successful creation of a new block. However, if there are Byzantines in the previous committee, the current committee will most probably not have enough time to detect this. This may cause unfair rewarding of the participants. To tackle this problem, we propose *delayed rewarding* of the committees where a previous committee is rewarded after a certain number of blocks. We model this improvement by modifying the actions `commit()` and `createCoinbaseTxS()` as shown in Algorithm 3. When a validator of a committee commits a block, it sends a message to the whole network that it has committed that block. The proposer of a following committee will add the related coinbase transactions to its proposal.
invested by a delegator $d_i$ into a validator $v_i$, called $s_{v_i}^{d_i}$, and the global stakes of the validator $v_i$, which is the sum of its personal stakes and the stakes the delegators gave it, called $s_{v_i} = s_{v_i}^{d_i} + \sum s_{v_i}^{d_i}$.

### 3.5. Delegator Model

An agent $n \in D$, where $D \subseteq N$ and $D \cap V = \emptyset$, is said to be a *delegator* if it is capable of delegating a certain amount $a$ to a validator $v \in V$ for helping $v$ to enter into the committee using the action of the form `invest(a, v)` (see Algorithm 2). Hereafter, each time $v$ is rewarded for participating in a block creation, $n$ is also rewarded. At any time, $n \in D$ can withdraw a certain amount $a$ of its investments into its balance using the action `withdraw(a, v)`.

<caption>**Algorithm 2** The actions of a delegator agent $d$</caption>

1: **action invest(a, v)**
2:   **if** ($\phi_{v_i} \ge a$) **then**
3:     $\phi_{v_i} \leftarrow \phi_{v_i} - a$
4:     $s_{T_v} \leftarrow s_{T_v} + a$
5:     $s_i(d, v) \leftarrow s_i(d, v) + a$
6:   **endif**
7:   **end if**
8: **action withdraw(a, v)**
9:   **if** ($s_i(d, v) \ge a$) **then**
10:    $s_i(d, v) \leftarrow s_i(d, v) - a$
11:    $s_{T_v} \leftarrow s_{T_v} - a$
12:    $\phi_d \leftarrow \phi_d + a$
13: **endif**
14: **end if**

### 4. Tendermint Fairness Model

In this section, we improve the model given in Section 3 by improving the behaviors of validators in order to increase the fairness of the system. The improvements are as follows.

It has been shown in [24] that when there is less than $f$ Byzantines, and there is bad communication between some committee members, the block creation process can be frozen. To tackle this problem, rather than storing only the last valid proposed block, the committee members store all valid proposed blocks for creation block $h$. This way, if there is bad communication between the members and there are less than $f$ Byzantines, they can still remember the previously valid proposed blocks and vote for them when they are proposed once again.

As mentioned in Section 3, the committee rewards the previous one for successful creation of a new block. However, if there are Byzantines in the previous committee, the current committee will most probably not have enough time to detect this. This may cause unfair rewarding of the participants. To tackle this problem, we propose *delayed rewarding* of the committees where a previous committee is rewarded after a certain number of blocks. We model this improvement by modifying the actions `commit()` and `createCoinbaseTxS()` as shown in Algorithm 3. When a validator of a committee commits a block, it sends a message to the whole network that it has committed that block. The proposer of a following committee will add the related coinbase transactions to its proposal.
<caption>**Algorithm 3** The actions of a validator agent v for creation of the ith block in the Fairness model</caption>

1: **action commit(b<sub>i</sub>)**
2:   **if** (|M<sub>vote</sub><sup>b<sub>i</sub></sup>| > 2/3 |C<sub>i</sub>|) **then**
3:     B<sub>v</sub> ← B<sub>v</sub> ∪ {b<sub>i</sub>}
4:     **if** (v ∈ C<sub>i</sub>) **then**
5:         send(v, "hascommit", b<sub>i</sub>), C<sub>i</sub>)
6:     **endif**
7:   **else**
8:     newRound()
9:   **endif**
10:
11:
12: **endfor**
13: **for each** (z ∈ hascommit(b<sub>i</sub>)) **do**
14:     **for each** (d ∈ D(z)) **do**
15:         γ<sub>d</sub> = γ<sub>i-1</sub> / (|C<sub>i-1</sub>|) × s<sub>d</sub>/s<sub>z</sub>
16:         X<sub>i-1</sub> ← {d, γ<sub>d</sub>}
17:     **endfor**
18:     γ<sub>z</sub> = γ<sub>i-1</sub> / (|C<sub>i-1</sub>|) × s<sub>z</sub>/s<sub>z</sub>
19:     X<sub>i-1</sub> ← {z, γ<sub>z</sub>}
20: **endfor**
21: **return** X<sub>i-1</sub>
22:

5. Simulations

To quantitatively analyze the aforementioned models in terms of fairness, we designed and conducted several simulation experiments. In the following, we first give the various simulation experiments we designed (Section 5.1) and then we present our experimental setup (Section 5.2).

5.1. Simulation Experiments

We designed experiments in order to analyze fairness of the Tendermint models given in Sections 3 and 4.

The assumptions we made for all the experiments are as follows:

• There are no Byzantines, i.e., there are no crashes or no erroneous messages.

• Each participant always plays the same role.

• The size of the committee is always 5.

• There are no fees for the transactions.

• All agents process the messages as soon as they receive them.

• The total block reward γ<sub>b</sub> is 50.

• There is no message transmission delay in the network.

• The reliability of the network is 100%, i.e., every message is received by its receivers.

• Starting from the creation of the first block, each 30 ticks, the simulator calculates the overall fairness of the system and adds new validators depending on the overall fairness according to

$$
w = \begin{cases} \log_2(\mathcal{K}), & \text{if } \mathcal{K} > 0, \\ 0, & \text{otherwise,} \end{cases} \tag{1}
$$

where $\mathcal{K} = \tau_n - \frac{1}{|N|} * \sum_{i=1}^{|N|} \mathcal{U}_i$.

• The initial balance for validators (α<sub>v</sub>) is calculated using a normal distribution between 50 and 100.

• The initial balance for delegators (α<sub>d</sub>) is calculated using a normal distribution between 25 and 75.

• The utility function of all agents is U<sub>n</sub> : N → N and for every agent n the threshold τ<sub>n</sub> = −10.

• ∀ agent n : u<sub>0</sub> = 0.

For each agent n, its utility follows the law:

$$
\mathcal{U}_n = \begin{cases} \mathcal{U}_n + 1, & \text{if } b_h \text{ rewards } n, \\ \mathcal{U}_n - 1, & \text{otherwise.} \end{cases} \tag{2}
$$

We define two different investment strategies for validators:
* $\beta_1$: investing all balance in stakes,

* $\beta_2$: investing random amounts from balance in stakes,

We define one investment strategy for delegators:

* $\beta_3$: investing random amount from their balance in one random validator at each new block.

Using the different validator strategies and different initial number of delegators, we designed eight different experiments (see Table 1).

<table><caption>Table 1. Settings of the experiments.</caption><thead><tr><td>Experiment #</td><td>Model</td><td>Validator Strategy</td><td>Initial # Validators</td><td>Initial # Delegators</td></tr></thead><tbody><tr><td>Ex 1</td><td>Default</td><td>β<sub>1</sub></td><td>10</td><td>0</td></tr><tr><td>Ex 2</td><td>Default</td><td>β<sub>1</sub></td><td>10</td><td>5</td></tr><tr><td>Ex 3</td><td>Default</td><td>β<sub>2</sub></td><td>10</td><td>0</td></tr><tr><td>Ex 4</td><td>Default</td><td>β<sub>2</sub></td><td>10</td><td>5</td></tr><tr><td>Ex 5</td><td>Fairness</td><td>β<sub>1</sub></td><td>10</td><td>0</td></tr><tr><td>Ex 6</td><td>Fairness</td><td>β<sub>1</sub></td><td>10</td><td>5</td></tr><tr><td>Ex 7</td><td>Fairness</td><td>β<sub>2</sub></td><td>10</td><td>0</td></tr><tr><td>Ex 8</td><td>Fairness</td><td>β<sub>2</sub></td><td>10</td><td>5</td></tr></tbody></table>

## 5.2. *Experimental Setup*

To study blockchain systems in general, we developed an agent-based simulator (the simulator is called Multi Agent eXperimenter (MAX) and has not been made public yet) based on the MaDKit (MaDKit, http://www.madkit.net/madkit/, last access on 9 September 2019.) framework. MaDKit is a lightweight Java library for designing and simulating multi-agent systems [28]. We run our experiments on an Ubuntu OS computer powered by an Intel® Core™ i7-8850H CPU @ 2.60 GHz x 12 threads and 32 GB of RAM (Gif-sur-Yvette, France).

We run each experiment five times until the 150th block is committed to the blockchain. We report and discuss the results of these executions in the following section.

# 6. Results and Discussion

In section, we report and discuss the results of the conducted simulations.

## 6.1. *Results*

In order to study our experiments, we first get the utilities of each agent of the experiments at each height. For each experiment, we compute the median of the utilities. Then, we compute the average of the medians. We compare the experiments by computing the difference of those results.

Figures 3 and 4 give an overview of the differences between the different models and settings. Figure 4 displays the number of agents over time. Figure 3 displays the median utilities of the experiments overtime.

## 6.2. *Discussion*

Figure 4 gives an overview of the differences between the different models and settings. This chart displays the number of agents overtime: the higher the numbers are, the better is the tested model. We can see that, in general, the Fairness model is usually more fair than the Default model after a certain amount of time. In the beginning, due to the presence or absence of delegators, there might be more or less agents in the system. However, as they are still agents, they might leave if they think the
* $\beta_1$: investing all balance in stakes,

* $\beta_2$: investing random amounts from balance in stakes,

We define one investment strategy for delegators:

* $\beta_3$: investing random amount from their balance in one random validator at each new block.

Using the different validator strategies and different initial number of delegators, we designed eight different experiments (see Table 1).

<table><caption>**Table 1.** Settings of the experiments.</caption><thead><tr><th>Experiment #</th><th>Model</th><th>Validator Strategy</th><th>Initial # Validators</th><th>Initial # Delegators</th></tr></thead><tbody><tr><td>Ex 1</td><td>Default</td><td>β<sub>1</sub></td><td>10</td><td>0</td></tr><tr><td>Ex 2</td><td>Default</td><td>β<sub>1</sub></td><td>10</td><td>5</td></tr><tr><td>Ex 3</td><td>Default</td><td>β<sub>2</sub></td><td>10</td><td>0</td></tr><tr><td>Ex 4</td><td>Default</td><td>β<sub>2</sub></td><td>10</td><td>5</td></tr><tr><td>Ex 5</td><td>Fairness</td><td>β<sub>1</sub></td><td>10</td><td>0</td></tr><tr><td>Ex 6</td><td>Fairness</td><td>β<sub>1</sub></td><td>10</td><td>5</td></tr><tr><td>Ex 7</td><td>Fairness</td><td>β<sub>2</sub></td><td>10</td><td>0</td></tr><tr><td>Ex 8</td><td>Fairness</td><td>β<sub>2</sub></td><td>10</td><td>5</td></tr></tbody></table>

## 5.2. *Experimental Setup*

To study blockchain systems in general, we developed an agent-based simulator (the simulator is called Multi Agent eXperimenter (MAX) and has not been made public yet) based on the MaDKit (MaDKit, http://www.madkit.net/madkit/, last access on 9 September 2019.) framework. MaDKit is a lightweight Java library for designing and simulating multi-agent systems [28]. We run our experiments on an Ubuntu OS computer powered by an Intel® Core™ i7-8850H CPU @ 2.60 GHz x 12 threads and 32 GB of RAM (Gif-sur-Yvette, France).

We run each experiment five times until the 150th block is committed to the blockchain. We report and discuss the results of these executions in the following section.

# 6. Results and Discussion

In section, we report and discuss the results of the conducted simulations.

## 6.1. *Results*

In order to study our experiments, we first get the utilities of each agent of the experiments at each height. For each experiment, we compute the median of the utilities. Then, we compute the average of the medians. We compare the experiments by computing the difference of those results.

Figures 3 and 4 give an overview of the differences between the different models and settings. Figure 4 displays the number of agents over time. Figure 3 displays the median utilities of the experiments overtime.

## 6.2. *Discussion*

Figure 4 gives an overview of the differences between the different models and settings. This chart displays the number of agents overtime: the higher the numbers are, the better is the tested model. We can see that, in general, the Fairness model is usually more fair than the Default model after a certain amount of time. In the beginning, due to the presence or absence of delegators, there might be more or less agents in the system. However, as they are still agents, they might leave if they think the
system is not fair enough. In addition, some experiments have the same settings, but different models, which means that we should first compare them before transiting to others.

<figure><img src="image_3.png" /><figcaption>**Figure 3.** Evolution of the utilities of the experiments by height.</figcaption></figure>

<figure><img src="image_4.png" /><figcaption>**Figure 4.** Evolution of the number of agents by height.</figcaption></figure>

We can also observe that most models seem to stabilize at a certain number of agents which is often close to the initial number of agents. This can be due to multiple factors. First, the utility threshold is, in our experiments, the same for every agent, which, in reality, is really different. Moreover, the utility is only based on *when* an agent is rewarded, not how much. In real life, an agent can be rewarded at every block, but the reward could be very low. Furthermore, because no agents withdraw their stakes, the stakes of each agent will always increase, mathematically speaking. Hence, a validator selected in a committee will have a huge chance to be selected at the following ones because the non selected validators do not have enough stakes at first. The two ways to change this are:
system is not fair enough. In addition, some experiments have the same settings, but different models, which means that we should first compare them before transiting to others.

<figure><img src="image_4.png" /><figcaption>**Figure 3.** Evolution of the utilities of the experiments by height.</figcaption></figure>

<figure><img src="image_5.png" /><figcaption>**Figure 4.** Evolution of the number of agents by height.</figcaption></figure>

We can also observe that most models seem to stabilize at a certain number of agents which is often close to the initial number of agents. This can be due to multiple factors. First, the utility threshold is, in our experiments, the same for every agent, which, in reality, is really different. Moreover, the utility is only based on *when* an agent is rewarded, not how much. In real life, an agent can be rewarded at every block, but the reward could be very low. Furthermore, because no agents withdraw their stakes, the stakes of each agent will always increase, mathematically speaking. Hence, a validator selected in a committee will have a huge chance to be selected at the following ones because the non selected validators do not have enough stakes at first. The two ways to change this are:
1. a non selected validator has a higher sum of balance and stakes than a selected one, but lower stakes at one height. Then, at a further height, this non-selected validator chooses to invest enough balance in stakes to have more assets than the selected one, hence being selected afterwards.

2. delegators invest enough stakes in non selected validators rather than selected validators to reverse the process.

The first option happens only with half of the experiments: those where the behavior of the validators is $\beta_2$. In real life, this can happen with a decreasing probability over time because the system enters in a *virtuous* circle for multiple validators and a *vicious* circle for the others. Indeed, the gap of the sum of the two assets, balance and stakes, between the validators will increase over time.

The second option happens only with half of the experiments too, but not the same ones. This is what is expected to happen in order to make the system more fair: thanks to this process, more agents would be rewarded. Of course, the delegators could invest only in the wealthiest validators, but if we refer to [26], the delegators could be less rewarded than investing in a little bit poorer validators, which could be then selected in a committee.

## 7. Related Work

One solution for solving *partially* the fairness issue in Bitcoin-like blockchains was found by its participants: the use of *mining pools* [16]. Those structures allow more agents to be involved in the system and be rewarded, even with small power. There are fees for being part of a pool, but they remain low enough to be profitable even with a low-powered machine. However, such mining pools are controlled by owners that reduce the distributed aspect of the Blockchain. Some Blockchain protocols proposed solutions, such as the *FruitChains protocol* [29], to distribute the block rewards in a more fair way. However, they still rely on energy consumption to secure the blockchain.

Other issues triggered by Bitcoin-like blockchain systems are summed up in [21]:

* There is no mechanism for a user to cancel an already issued transaction, i.e., once it decides to engage in the game, it can never abandon it. This implies expected values going to minus infinity. In decision theory terms, this would mean assuming a user having an infinite interest on a transaction, which is in fact hard to assume in real settings.

* Given different fees with their associated probabilities, more flexibility to guarantee fairness would have been reached by allowing the user (experiencing a long waiting time) to resend the transaction with a lower fee. This flexibility, on the other hand, is not achieved in Bitcoin-like blockchain systems mainly due to two reasons: (1) there is no deterministic guarantee that the system chooses a given copy of the transaction, it is only guaranteed with high probability that only one copy will be inserted into the blockchain, and (2) the miner behavior favors the transaction with the highest fee to get included in a block.

* The block size is a fixed parameter today. Obviously, if the volume of transactions increases over time, the space left for more transactions can become a scarce resource, and miners will be more apt to deliberately delaying a transaction with a low fee. This will dramatically drop the probabilities for low fees and their corresponding expected values by time.

* Fees are decided by the users, leading to a possible race among user fees. Such a situation would make the probabilities difficult to predict, and expected values of users might drop even faster.

* The fairness is a locally perceived concept, and it must indeed be tracked. This needs further detection mechanisms not included in the current systems.

In general, most of the work is focused on fairness to users, such as [21], but very few on block creators. There is even less about the Tendermint protocol. In [30], the fairness policy in Tendermint is discussed in order to correctly punish Byzantines. This aspect is crucial as the correct agents would find a system unfair if incorrect ones are rewarded. This paper also addresses Factom [31], Enigma [32], and Hawk [33], protocols which provide various ways of managing such policies. Jalalzai et al. [34] implemented and evaluated the performance of different BFT based protocols for blockchains under
1. a non selected validator has a higher sum of balance and stakes than a selected one, but lower stakes at one height. Then, at a further height, this non-selected validator chooses to invest enough balance in stakes to have more assets than the selected one, hence being selected afterwards.

2. delegators invest enough stakes in non selected validators rather than selected validators to reverse the process.

The first option happens only with half of the experiments: those where the behavior of the validators is $\beta_2$. In real life, this can happen with a decreasing probability over time because the system enters in a *virtuous* circle for multiple validators and a *vicious* circle for the others. Indeed, the gap of the sum of the two assets, balance and stakes, between the validators will increase over time.

The second option happens only with half of the experiments too, but not the same ones. This is what is expected to happen in order to make the system more fair: thanks to this process, more agents would be rewarded. Of course, the delegators could invest only in the wealthiest validators, but if we refer to [26], the delegators could be less rewarded than investing in a little bit poorer validators, which could be then selected in a committee.

## 7. Related Work

One solution for solving *partially* the fairness issue in Bitcoin-like blockchains was found by its participants: the use of *mining pools* [16]. Those structures allow more agents to be involved in the system and be rewarded, even with small power. There are fees for being part of a pool, but they remain low enough to be profitable even with a low-powered machine. However, such mining pools are controlled by owners that reduce the distributed aspect of the Blockchain. Some Blockchain protocols proposed solutions, such as the *FruitChains protocol* [29], to distribute the block rewards in a more fair way. However, they still rely on energy consumption to secure the blockchain.

Other issues triggered by Bitcoin-like blockchain systems are summed up in [21]:

* There is no mechanism for a user to cancel an already issued transaction, i.e., once it decides to engage in the game, it can never abandon it. This implies expected values going to minus infinity. In decision theory terms, this would mean assuming a user having an infinite interest on a transaction, which is in fact hard to assume in real settings.

* Given different fees with their associated probabilities, more flexibility to guarantee fairness would have been reached by allowing the user (experiencing a long waiting time) to resend the transaction with a lower fee. This flexibility, on the other hand, is not achieved in Bitcoin-like blockchain systems mainly due to two reasons: (1) there is no deterministic guarantee that the system chooses a given copy of the transaction, it is only guaranteed with high probability that only one copy will be inserted into the blockchain, and (2) the miner behavior favors the transaction with the highest fee to get included in a block.

* The block size is a fixed parameter today. Obviously, if the volume of transactions increases over time, the space left for more transactions can become a scarce resource, and miners will be more apt to deliberately delaying a transaction with a low fee. This will dramatically drop the probabilities for low fees and their corresponding expected values by time.

* Fees are decided by the users, leading to a possible race among user fees. Such a situation would make the probabilities difficult to predict, and expected values of users might drop even faster.

* The fairness is a locally perceived concept, and it must indeed be tracked. This needs further detection mechanisms not included in the current systems.

In general, most of the work is focused on fairness to users, such as [21], but very few on block creators. There is even less about the Tendermint protocol. In [30], the fairness policy in Tendermint is discussed in order to correctly punish Byzantines. This aspect is crucial as the correct agents would find a system unfair if incorrect ones are rewarded. This paper also addresses Factom [31], Enigma [32], and Hawk [33], protocols which provide various ways of managing such policies. Jalalzai et al. [34] implemented and evaluated the performance of different BFT based protocols for blockchains under
normal conditions as well as when byzantine failures are encountered in the network, and also
calculated the reliability of each protocol under the desired throughput.

8. Conclusions and Future Work

Tendermint introduces a class of Blockchain protocols which relies on committees, stakes, and delegators. It aims at solving different issues from the Bitcoin-like blockchains, including the fairness. In this paper, we show that we implemented a simulation model of Tendermint to analyze its fairness using MaDKit. We then highlight the strengths and weaknesses of Tendermint based on the results generated by the execution of this implementation. Thanks to its PBFT consensus, more agents are involved in the block creation process (and rewarded for their involvement) and thus the protocol is more fair compared to Bitcoin-like blockchains. We also show that the delegators play a crucial role by giving more importance to agents who want to be involved without having enough stakes. However, the Tendermint protocol suffers from flaws that exclude agents for various reasons, especially when they do not have enough information on time or do not adapt rapidly. We proposed to delay the rewarding and included the improvements proposed in [24]. Those modifications upgrade the original model as seen in the results.

In this paper, we did not study the security limits of the Tendermint protocol with incorrect agents.
We also did not study more *intelligent* agents who could take more profitable actions for them and the
system. For instance, the delegators could have *smarter* processes for selecting their validators and
how much they invest. We also did not study the influence of fees for the transaction selections and
rewarding. Indeed, the agents have to be rewarded as soon as their messages are received. In a more
realistic system, validated transactions can be chosen by the proposers and they may refuse some of
them. All those issues can be studied in further research.

**Author Contributions:** Conceptualization, Ö.G.; methodology, Ö.G.; software, M.A.D. and N.L.; validation, N.L., M.A.D. and Ö.G.; investigation, N.L., M.A.D. and Ö.G.; writing–original draft preparation, Ö.G.; writing–review and editing, N.L., M.A.D. and Ö.G.; visualization, M.A.D.; supervision, Ö.G.; project administration, Ö.G.

**Funding:** This research received no external funding.

**Conflicts of Interest:** The authors declare no conflict of interest. The funders had no role in the design of the study; in the collection, analyzes, or interpretation of data; in the writing of the manuscript, or in the decision to publish the results.

Abbreviations

The following abbreviations are used in this manuscript:

PBFT Practical Byzantine Fault Tolerance

PoS Proof-of-Stake

MAX Multi-Agent eXperimenter

MaDKit Multi-Agent Development Kit

References

1. Nakamoto, S. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008. Available online: http://www.bitcoin.org/bitcoin.pdf (accessed on 29 November 2019).

2. Wood, G. Ethereum: A Secure Decentralised Generalised Transaction Ledger. Available online: http://gavwood.com/Paper.pdf (accessed on 27 November 2019).

3. Goodman, L.M. Tezos – s Self-Amending crypto-ledger. White Paper. 2014. Available online: https://tezos.com/static/white_paper-2dc8c02267a8fb86bd67a108199441bf.pdf (accessed on 29 November 2019)

4. Buchman, E.; Kwon, J.; Milosevic, Z. The latest gossip on BFT consensus. *arXiv* **2018**, arXiv:1807.04938

5. Androulaki, E.; Barger, A.; Bortnikov, V.; Cachin, C.; Christidis, K.; Caro, A.D.; Enyeart, D.; Ferris, C.; Laventman, G.; Manevich, Y.; et al. Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains. *arXiv* **2018**, arXiv:1801.10228.
normal conditions as well as when byzantine failures are encountered in the network, and also
calculated the reliability of each protocol under the desired throughput.

8. Conclusions and Future Work

Tendermint introduces a class of Blockchain protocols which relies on committees, stakes,
and delegators. It aims at solving different issues from the Bitcoin-like blockchains, including
the fairness. In this paper, we show that we implemented a simulation model of Tendermint to analyze
its fairness using MaDKit. We then highlight the strengths and weaknesses of Tendermint based on
the results generated by the execution of this implementation. Thanks to its PBFT consensus, more
agents are involved in the block creation process (and rewarded for their involvement) and thus the
protocol is more fair compared to Bitcoin-like blockchains. We also show that the delegators play a
crucial role by giving more importance to agents who want to be involved without having enough
stakes. However, the Tendermint protocol suffers from flaws that exclude agents for various reasons,
especially when they do not have enough information on time or do not adapt rapidly. We proposed to
delay the rewarding and included the improvements proposed in [24]. Those modifications upgrade
the original model as seen in the results.

In this paper, we did not study the security limits of the Tendermint protocol with incorrect agents. We also did not study more *intelligent* agents who could take more profitable actions for them and the system. For instance, the delegators could have *smarter* processes for selecting their validators and how much they invest. We also did not study the influence of fees for the transaction selections and rewarding. Indeed, the agents have to be rewarded as soon as their messages are received. In a more realistic system, validated transactions can be chosen by the proposers and they may refuse some of them. All those issues can be studied in further research.

**Author Contributions:** Conceptualization, Ö.G.; methodology, Ö.G.; software, M.A.D. and N.L.; validation, N.L., M.A.D. and Ö.G.; investigation, N.L., M.A.D. and Ö.G.; writing—original draft preparation, Ö.G.; writing—review and editing, N.L., M.A.D. and Ö.G.; visualization, M.A.D.; supervision, Ö.G.; project administration, Ö.G.

**Funding:** This research received no external funding.

**Conflicts of Interest:** The authors declare no conflict of interest. The funders had no role in the design of the study; in the collection, analyzes, or interpretation of data; in the writing of the manuscript, or in the decision to publish the results.

Abbreviations

The following abbreviations are used in this manuscript:

PBFT Practical Byzantine Fault Tolerance

PoS Proof-of-Stake

MAX Multi-Agent eXperimenter

MaDKit Multi-Agent Development Kit

References

1. Nakamoto, S. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008. Available online: http://www.bitcoin.org/bitcoin.pdf (accessed on 29 November 2019).

2. Wood, G. Ethereum: A Secure Decentralised Generalised Transaction Ledger. Available online: http://gavwood.com/Paper.pdf (accessed on 27 November 2019).

3. Goodman, L.M. Tezos – s Self-Amending crypto-ledger. White Paper. 2014. Available online: https://tezos.com/static/white_paper-2dc8c02267a8fb86bd67a108199441bf.pdf (accessed on 29 November 2019)

4. Buchman, E.; Kwon, J.; Milosevic, Z. The latest gossip on BFT consensus. *arXiv* **2018**, arXiv:1807.04938

5. Androulaki, E.; Barger, A.; Bortnikov, V.; Cachin, C.; Christidis, K.; Caro, A.D.; Enyeart, D.; Ferris, C.; Laventman, G.; Manevich, Y.; et al. Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains. *arXiv* **2018**, arXiv:1801.10228.
6. Back, A. Hashcash-A Denial of Service Counter-Measure; Technical Report. 2002. Available online: http://www.hashcash.org/papers/hashcash.pdf (accessed on 29 November 2019).

7. Castro, M.; Liskov, B. Practical Byzantine Fault Tolerance. In Proceedings of the Third Symposium on Operating Systems Design and Implementation, New Orleans, LA, USA, 22–25 February 1999; USENIX Association: Berkeley, CA, USA, 1999; pp. 173–186.

8. Wang, W.; Hoang, D.T.; Hu, P.; Xiong, Z.; Niyato, D.; Wang, P.; Wen, Y.; Kim, D.I. A Survey on Consensus Mechanisms and Mining Strategy Management in Blockchain Networks. *IEEE Access* **2019**, *7*, 22328–22370. doi:10.1109/ACCESS.2019.2896108. [CrossRef]

9. Crain, T.; Gramoli, V.; Larrea, M.; Raynal, M. (Leader/Randomization/Signature)-Free Byzantine Consensus for Consortium Blockchains. Available online: http://csrg.redbellyblockchain.io/doc/ConsensusRedBellyBlockchain.pdf (accessed on 27 November 2019).

10. Decker, C.; Seidel, J.; Wattenhofer, R. Bitcoin Meets Strong Consistency. In Proceedings of the 17th International Conference on Distributed Computing and Networking Conference (ICDCN), Singapore, 4–7 January 2016.

11. Kokoris-Kogias, E.; Jovanovic, P.; Gailly, N.; Khoffi, I.; Gasser, L.; Ford, B. Enhancing Bitcoin Security and Performance with Strong Consistency via Collective Signing. In Proceedings of the 25th USENIX Conference on Security Symposium, Austin, TX, USA, 10–12 August 2016; USENIX Association: Berkeley, CA, USA, 2016; pp. 279–296.

12. Eyal, I.; Sirer, E.G. Majority is not enough: Bitcoin mining is vulnerable. In *International Conference on Financial Cryptography and Data Security*; Springer: Berlin, Germany, 2014; pp. 436–454.

13. Lewenberg, Y.; Sompolinsky, Y.; Zohar, A. Inclusive block chain protocols. In *International Conference on Financial Cryptography and Data Security*; Springer: Berlin, Germany, 2015; pp. 528–547.

14. Eyal, I. The miner's dilemma. In Proceedings of the 2015 IEEE Symposium on Security and Privacy, San Jose, CA, USA, 17–21 May 2015; pp. 89–103.

15. Sapirshtein, A.; Sompolinsky, Y.; Zohar, A. Optimal selfish mining strategies in bitcoin. In *International Conference on Financial Cryptography and Data Security*; Springer: Berlin, Germany, 2016; pp. 515–532.

16. Eyal, I.; Gencer, A.E.; Sirer, E.G.; Van Renesse, R. Bitcoin-NG: A Scalable Blockchain Protocol. In Proceedings of the 13th USENIX Symposium on Networked Systems Design and Implementation, Santa Clara, CA, USA, 16–18 March 2016; pp. 45–59.

17. Göbel, J.; Keeler, H.P.; Krzesinski, A.E.; Taylor, P.G. Bitcoin blockchain dynamics: The selfish-mine strategy in the presence of propagation delay. *Perform. Eval.* **2016**, *104*, 23–41. [CrossRef]

18. Pass, R.; Shi, E. FruitChains: A Fair Blockchain. Cryptology ePrint Archive, Report 2016/916. 2016. Available online: http://eprint.iacr.org/2016/916.pdf (accessed on 27 November 2019).

19. Carlsten, M.; Kalodner, H.; Weinberg, S.M.; Narayanan, A. On the instability of bitcoin without the block reward. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, Vienna, Austria, 24–28 October 2016; pp. 154–167.

20. Liu, J.; Li, W.; Karame, G.O.; Asokan, N. Towards Fairness of Cryptocurrency Payments. *arXiv* **2016**, *arXiv:1609.07256*.

21. Gürcan, Ö.; Del Pozzo, A.; Tucci-Piergiovanni, S. On the Bitcoin Limitations to Deliver Fairness to Users. In *On the Move to Meaningful Internet Systems. OTM 2017 Conferences*; Panetto, H., Debruyne, C., Gaaloul, W., Papazoglou, M., Paschke, A., Ardagna, C.A., Meersman, R., Eds.; Springer International Publishing: Cham, Switzerland, 2017; Volume 10573, pp. 589–606. doi:10.1007/978-3-319-69462-7_37. [CrossRef]

22. Gürcan, Ö.; Ranchal Pedrosa, A.; Tucci-Piergiovanni, S. On Cancellation of Transactions in Bitcoin-Like Blockchains. In *On the Move to Meaningful Internet Systems. OTM 2018 Conferences*; Panetto, H., Debruyne, C., Proper, H.A., Ardagna, C.A., Roman, D., Meersman, R., Eds.; Springer International Publishing: Cham, Switzerland, 2018; Volume 11229, pp. 516–533. doi:10.1007/978-3-030-02610-3_29. [CrossRef]

23. Gürcan, Ö. Multi-Agent Modelling of Fairness for Users and Miners in Blockchains. In Proceedings of the 2nd Workshop on Block Chain Technologies 4 Multi-Agent Systems (BCT4MAS), Co-Located with PAAMS 2019, Avila, Spain, 26–28 June 2019.

24. Amoussou-Guenou, Y.; Del Pozzo, A.; Potop-Butucaru, M.; Tucci-Piergiovanni, S. Correctness and Fairness of Tendermint-Core Blockchains; Research Report; LIP6 UMR 7606; UPMC Sorbonne Universités: Paris, France, 2018.
6. Back, A. Hashcash-A Denial of Service Counter-Measure; Technical Report. 2002. Available online: http://www.hashcash.org/papers/hashcash.pdf (accessed on 29 November 2019).

7. Castro, M.; Liskov, B. Practical Byzantine Fault Tolerance. In Proceedings of the Third Symposium on Operating Systems Design and Implementation, New Orleans, LA, USA, 22–25 February 1999; USENIX Association: Berkeley, CA, USA, 1999; pp. 173–186.

8. Wang, W.; Hoang, D.T.; Hu, P.; Xiong, Z.; Niyato, D.; Wang, P.; Wen, Y.; Kim, D.I. A Survey on Consensus Mechanisms and Mining Strategy Management in Blockchain Networks. *IEEE Access* **2019**, *7*, 22328–22370. doi:10.1109/ACCESS.2019.2896108. [CrossRef]

9. Crain, T.; Gramoli, V.; Larrea, M.; Raynal, M. (Leader/Randomization/Signature)-Free Byzantine Consensus for Consortium Blockchains. Available online: http://csrg.redbellyblockchain.io/doc/ConsensusRedBellyBlockchain.pdf (accessed on 27 November 2019).

10. Decker, C.; Seidel, J.; Wattenhofer, R. Bitcoin Meets Strong Consistency. In Proceedings of the 17th International Conference on Distributed Computing and Networking Conference (ICDCN), Singapore, 4–7 January 2016.

11. Kokoris-Kogias, E.; Jovanovic, P.; Gailly, N.; Khoffi, I.; Gasser, L.; Ford, B. Enhancing Bitcoin Security and Performance with Strong Consistency via Collective Signing. In Proceedings of the 25th USENIX Conference on Security Symposium, Austin, TX, USA, 10–12 August 2016; USENIX Association: Berkeley, CA, USA, 2016; pp. 279–296.

12. Eyal, I.; Sirer, E.G. Majority is not enough: Bitcoin mining is vulnerable. In *International Conference on Financial Cryptography and Data Security*; Springer: Berlin, Germany, 2014; pp. 436–454.

13. Lewenberg, Y.; Sompolinsky, Y.; Zohar, A. Inclusive block chain protocols. In *International Conference on Financial Cryptography and Data Security*; Springer: Berlin, Germany, 2015; pp. 528–547.

14. Eyal, I. The miner's dilemma. In Proceedings of the 2015 IEEE Symposium on Security and Privacy, San Jose, CA, USA, 17–21 May 2015; pp. 89–103.

15. Sapirshtein, A.; Sompolinsky, Y.; Zohar, A. Optimal selfish mining strategies in bitcoin. In *International Conference on Financial Cryptography and Data Security*; Springer: Berlin, Germany, 2016; pp. 515–532.

16. Eyal, I.; Gencer, A.E.; Sirer, E.G.; Van Renesse, R. Bitcoin-NG: A Scalable Blockchain Protocol. In Proceedings of the 13th USENIX Symposium on Networked Systems Design and Implementation, Santa Clara, CA, USA, 16–18 March 2016; pp. 45–59.

17. Göbel, J.; Keeler, H.P.; Krzesinski, A.E.; Taylor, P.G. Bitcoin blockchain dynamics: The selfish-mine strategy in the presence of propagation delay. *Perform. Eval.* **2016**, *104*, 23–41. [CrossRef]

18. Pass, R.; Shi, E. FruitChains: A Fair Blockchain. Cryptology ePrint Archive, Report 2016/916. 2016. Available online: http://eprint.iacr.org/2016/916.pdf (accessed on 27 November 2019).

19. Carlsten, M.; Kalodner, H.; Weinberg, S.M.; Narayanan, A. On the instability of bitcoin without the block reward. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, Vienna, Austria, 24–28 October 2016; pp. 154–167.

20. Liu, J.; Li, W.; Karame, G.O.; Asokan, N. Towards Fairness of Cryptocurrency Payments. *arXiv* **2016**, *arXiv:1609.07256*.

21. Gürcan, Ö.; Del Pozzo, A.; Tucci-Piergiovanni, S. On the Bitcoin Limitations to Deliver Fairness to Users. In *On the Move to Meaningful Internet Systems. OTM 2017 Conferences*; Panetto, H., Debruyne, C., Gaaloul, W., Papazoglou, M., Paschke, A., Ardagna, C.A., Meersman, R., Eds.; Springer International Publishing: Cham, Switzerland, 2017; Volume 10573, pp. 589–606. doi:10.1007/978-3-319-69462-7_37. [CrossRef]

22. Gürcan, Ö.; Ranchal Pedrosa, A.; Tucci-Piergiovanni, S. On Cancellation of Transactions in Bitcoin-Like Blockchains. In *On the Move to Meaningful Internet Systems. OTM 2018 Conferences*; Panetto, H., Debruyne, C., Proper, H.A., Ardagna, C.A., Roman, D., Meersman, R., Eds.; Springer International Publishing: Cham, Switzerland, 2018; Volume 11229, pp. 516–533. doi:10.1007/978-3-030-02610-3_29. [CrossRef]

23. Gürcan, Ö. Multi-Agent Modelling of Fairness for Users and Miners in Blockchains. In Proceedings of the 2nd Workshop on Block Chain Technologies 4 Multi-Agent Systems (BCT4MAS), Co-Located with PAAMS 2019, Avila, Spain, 26–28 June 2019.

24. Amoussou-Guenou, Y.; Del Pozzo, A.; Potop-Butucaru, M.; Tucci-Piergiovanni, S. Correctness and Fairness of Tendermint-Core Blockchains; Research Report; LIP6 UMR 7606; UPMC Sorbonne Universités: Paris, France, 2018.
25. Kwon, J. Tendermint: Consensus without Mining; White Paper. 2014. Available online: https://pdfs.semanticscholar.org/df62/a45f50aac8890453b6991ea115e996c1646e.pdf (accessed on 29 November 2019).

26. Russell, S.J.; Norvig, P. *Artificial Intelligence: A Modern Approach*, 3rd ed.; Prentice Hall Press: Upper Saddle River, NJ, USA, 2009.

27. Merkle, R.C. A Digital Signature Based on a Conventional Encryption Function. In *Advances in Cryptology—CRYPTO '87: Proceedings*; Pomerance, C., Ed.; Springer: Berlin/Heidelberg, Germany, 1988; pp. 369–378. doi:10.1007/3-540-48184-2_32. [CrossRef]

28. Gutknecht, O.; Ferber, J. The MadKit Agent Platform Architecture. In *Workshop on Infrastructure for Scalable Multi-Agent Systems at the International Conference on Autonomous Agents*; Springer: Berlin/Heidelberg, Germany, 2000; Volume 1887. doi:10.1007/3-540-47772-1_5. [CrossRef]

29. Pass, R.; Shi, E. *FruitChains: A Fair Blockchain*. In *Proceedings of the ACM Symposium on Principles of Distributed Computing, Washington, DC, USA, 25–27 July 2017*; ACM Press: New York, NY, USA, 2017; pp. 315–324. doi:10.1145/3087801.3087809. [CrossRef]

30. Herlihy, M.; Moir, M. Enhancing accountability and trust in distributed ledgers. *arXiv* **2016**, arXiv:1606.07490.

31. Snow, P.; Deery, B.; Kirby, P.; Johnston, D. Factom Ledger by Consensus. 2015. Available online: https://factomize.com/uploads/FactomLedgerbyConsensus.pdf (accessed on 29 November 2019).

32. Kosba, A.; Miller, A.; Shi, E.; Wen, Z.; Papamanthou, C. Hawk: The blockchain model of cryptography and privacy-preserving smart contracts. In *Proceedings of the 2016 IEEE symposium on security and privacy* (SP), San Jose, CA, USA, 22–26 May 2016; pp. 839–858.

33. Zyskind, G.; Nathan, O.; Pentland, A. Enigma: Decentralized computation platform with guaranteed privacy. *arXiv* **2015**, arXiv:1506.03471.

34. Jalalzai, M.M.; Richard, G.; Busch, C. An Experimental Evaluation of BFT Protocols for Blockchains. In *Blockchain—ICBC 2019; Joshi, J., Nepal, S., Zhang, Q., Zhang, L.J., Eds.*; Springer International Publishing: Cham, Switzerland, 2019; pp. 34–48.

<figure><img src="image_5.png" /></figure>

© 2019 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).
25. Kwon, J. Tendermint: Consensus without Mining; White Paper. 2014. Available online: https://pdfs.semanticscholar.org/df62/a45f50aac8890453b6991ea115e996c1646e.pdf (accessed on 29 November 2019).

26. Russell, S.J.; Norvig, P. *Artificial Intelligence: A Modern Approach*, 3rd ed.; Prentice Hall Press: Upper Saddle River, NJ, USA, 2009.

27. Merkle, R.C. A Digital Signature Based on a Conventional Encryption Function. In *Advances in Cryptology—CRYPTO '87: Proceedings*; Pomerance, C., Ed.; Springer: Berlin/Heidelberg, Germany, 1988; pp. 369–378. doi:10.1007/3-540-48184-2_32. [CrossRef]

28. Gutknecht, O.; Ferber, J. The MadKit Agent Platform Architecture. In *Workshop on Infrastructure for Scalable Multi-Agent Systems at the International Conference on Autonomous Agents*; Springer: Berlin/Heidelberg, Germany, 2000; Volume 1887. doi:10.1007/3-540-47772-1_5. [CrossRef]

29. Pass, R.; Shi, E. *FruitChains: A Fair Blockchain*. In *Proceedings of the ACM Symposium on Principles of Distributed Computing, Washington, DC, USA, 25–27 July 2017*; ACM Press: New York, NY, USA, 2017; pp. 315–324. doi:10.1145/3087801.3087809. [CrossRef]

30. Herlihy, M.; Moir, M. Enhancing accountability and trust in distributed ledgers. *arXiv* **2016**, arXiv:1606.07490.

31. Snow, P.; Deery, B.; Kirby, P.; Johnston, D. Factom Ledger by Consensus. 2015. Available online: https://factomize.com/uploads/FactomLedgerbyConsensus.pdf (accessed on 29 November 2019).

32. Kosba, A.; Miller, A.; Shi, E.; Wen, Z.; Papamanthou, C. Hawk: The blockchain model of cryptography and privacy-preserving smart contracts. In *Proceedings of the 2016 IEEE symposium on security and privacy* (SP), San Jose, CA, USA, 22–26 May 2016; pp. 839–858.

33. Zyskind, G.; Nathan, O.; Pentland, A. Enigma: Decentralized computation platform with guaranteed privacy. *arXiv* **2015**, arXiv:1506.03471.

34. Jalalzai, M.M.; Richard, G.; Busch, C. An Experimental Evaluation of BFT Protocols for Blockchains. In *Blockchain—ICBC 2019; Joshi, J., Nepal, S., Zhang, Q., Zhang, L.J., Eds.*; Springer International Publishing: Cham, Switzerland, 2019; pp. 34–48.

<figure><img src="image_6.png" /></figure>

© 2019 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).