We might walk together, but I run faster: Network Fairness and Scalability in Blockchains

02/08/2021 ∙ by Anurag Jain, et al. ∙ IIIT Hyderabad 0

Blockchain-based Distributed Ledgers (DLs) promise to transform the existing financial system by making it truly democratic. In the past decade, blockchain technology has seen many novel applications ranging from the banking industry to real estate. However, in order to be adopted universally, blockchain systems must be scalable to support a high volume of transactions. As we increase the throughput of the DL system, the underlying peer-to-peer network might face multiple levels of challenges to keep up with the requirements. Due to varying network capacities, the slower nodes would be at a relative disadvantage compared to the faster ones, which could negatively impact their revenue. In order to quantify their relative advantage or disadvantage, we introduce two measures of network fairness, p_f, the probability of frontrunning and α_f, the publishing fairness. We show that as we scale the blockchain, both these measures deteriorate, implying that the slower nodes face a disadvantage at higher throughputs. It results in the faster nodes getting more than their fair share of the reward while the slower nodes (slow in terms of network quality) get less. Thus, fairness and scalability in blockchain systems do not go hand in hand. In a setting with rational miners, lack of fairness causes miners to deviate from the "longest chain rule" or undercut, which would reduce the blockchain's resilience against byzantine adversaries. Hence, fairness is not only a desirable property for a blockchain system but also essential for the security of the blockchain and any scalable blockchain protocol proposed must ensure fairness.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

This week in AI

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

1. Introduction

Blockchain-based Distributed Ledgers (DLs) promise to transform the existing financial system. The idea behind such a transformation is to replace centralized institutions that govern the system by a decentralized peer-to-peer network of nodes. The key idea in such a DL system is that the system offers the right incentives to the nodes to act honestly according to the blockchain protocol’s rules. Thus, any node can voluntarily choose to participate in the system and incur a computational cost in the expectation of being rewarded. We call such participants in the DL nodes or agents 111We use nodes and agents interchangeably. We refer to them as nodes when we consider them as a part of a network and agents when we consider them as players in a mining game.. We believe that such a system can be truly democratic since anyone can choose to participate.

If a decentralized system is not fair, i.e., the agents do not receive proportionate incentives, they will prefer not to join the system. Consequently, the system will not remain democratic and decentralized if it excludes some agents. In this work, we analyze the fairness characteristics of blockchain-based DLs for which, we consider all the agents being honest but with different network capacity. Although the fairness properties that we describe appear to be healthy for current blockchain systems, they deteriorate quickly as we scale the system to higher throughputs.

1.1. Overview

Although cryptocurrencies like Bitcoin and Ethereum are quite popular today, they still lag behind centralized payment systems like Visa in terms of transaction rates and time to finality. As of October 2020, Bitcoin’s and Ethereum’s network processes an average of 3-4 and 10 transactions per second (TPS), respectively. In contrast, Visa’s global payment system handled a reported 1,700 TPS and claimed to be capable of handling more than 24,000 TPS (Visa Inc., ). For a cryptocurrency to be adopted universally, it must be able to scale to process transactions at much higher throughput, i.e., TPS rate. Hence, blockchain protocols must be scalable to be suitable for widespread adoption.

However, there are many challenges on the road to scaling block-chain based DLs. Garay et al. (Garay et al., 2014) and Kiyayas et al. (Kiayias and Panagiotakos, 2015) show that existing blockchain protocols suffer from a loss of security properties as we scale the system. These security properties are fundamental to the operation of a robust DL. (Garay et al., 2014) and (Kiayias and Panagiotakos, 2015) consider a model with two types of agents, honest and adversarial where the adversary tries to attack the ledger by strategically forking the blockchain. A successful fork would allow the adversary to perform a double-spending attack.

In this paper, first, we consider a setting in which all agents are honest and show that disparities in the connection to the peer-to-peer network can make the system unfair. In such a case, nodes with a better internet connection will be able to grab a larger share of the reward while those with slower connections might lose out. We show that this disparity significantly increases as we increase the throughput of the system. Notice that improving the quality of the overlay network may be more complicated than making protocol-level changes that may be implemented by merely updating the software clients.

In literature, it is typically assumed that all the agents have equal access to the network, albeit with some finite delay. However, this is seldom the case in practice where some nodes may have better internet connections than others. For the first time, we introduce asymmetry in modeling network connections by assuming different delays for different nodes. Hence, faster nodes would have shorter delays, while slower nodes would have longer delays which in turn results in asymmetry in the rewards collected by these agents. We first analyse consequences of this model in a setting with honest agents and then extend our discussion to rational agents.

In order to analyze and quantify network fairness, we introduce two measures of fairness based on network events associated with broadcasting a transaction and broadcasting a block. First, we introduce frontrunning, an event associated with a node receiving a transaction. Frontrunning (that we deal with in this paper) occurs when a node confirms a transaction before someone else hears about the transaction. We measure , the probability of this event happening between two fractions of the network. If is high, the faster nodes would consistently be able to grab high-value transactions while the slower ones would only be able to pick low-value ones left out by others. Thus, a high would negatively impact some agents’ revenue. We show that if we try to scale a Bitcoin-like system to the throughput offered by the likes of Visa, approaches to nearly 1, which implies that the slower nodes in the system will rarely be able to mine any high-value transactions that would result in these nodes receiving minimal reward in exchange for their mining efforts.

We then consider the process of broadcasting a block through the network. Publishing fairness quantifies the advantage a node might have over other nodes in broadcasting a block. If a node is able to propagate its block faster than other nodes, in case of an eventual fork, its fork would have a higher probability of being accepted. Since we know that at higher throughputs forks become more common, faster nodes would be able to get more blocks accepted while those of slower nodes would frequently be orphaned. Thus, the slower nodes, would not be able to even gather the fixed block rewards.

As both of these measures deteriorate as with increased throughput, small variations in network access may lead to the system becoming unfair for the slower nodes. This would result in some agents gaining more than their fair share of reward while some agents earn less. This could certainly impact the profitability of the agents that earn less since they still need to pay for the costs associated with mining. Thus, it may lead to drop in the agents maintaining the DL since agents that are unable to accumulate enough reward to break even the mining costs might shut down their mining operation or they might adopt strategic behavior to collect more rewards than that obtained by following the protocol honestly, either of which would reduce the security of the blockchain.

We discuss possible behavior that a lack of network fairness could elicit from rational agents. Their behavior could potentially hurt the stability of the system and reduce the effective throughput of the system. We use simulations to show that as the fairness reduces, the default strategy mining on top of the longest chain does not remain the dominant strategy which means that rational agents gain more reward by intentionally forking the longest chain. This could have adverse effect on the resilience of the blockchain against byzantine adversaries, making it less secure222A byzantine adversary typically tries to defraud the users of the payment system by trying to create double-spending transactions.. Hence, even though we scale the system to increase the throughput, we might not find much practical advantage due to these issues.

Thus, the potential of blockchain technology is hindered by the capabilities of the underlying networking infrastructure.

Hence, in this work, we:

  1. Introduce a notion of network fairness in blockchains and highlight its importance. (Section 3) In particular, we introduce frontrunning (Definition 3.2) and publishing fairness (Definition 3.3) in the context of network fairness and analyze them for existing blockchain systems.

  2. Study the effect of increasing throughput on network fairness. (Section 4) and provide bounds on frontrunning as well as publishing fairness (Theorems 4.1 and 4.2)

  3. Discuss a few consequences of a lack of fairness in terms of creating strategic deviations that may be detrimental to the security of the blockchain. (Section 5)

2. Preliminaries

A distributed ledger (DL) is a database replicated and shared across multiple nodes in consensus. Blockchain is a type of append-only ledger. When a node wants to append a transaction to the ledger, it broadcasts it to other nodes. All nodes vote by a consensus algorithm to invalidate the existing ledger and replace it with the updated one. (In case of Bitcoin, once a new block is added to the longest chain, the original chain is not considered valid in the presence of the longer chain (Nakomoto, ))

2.1. Proof-of-Work

Nodes in a proof-of-work blockchain system vote on changes to the DL via their CPU (or GPU in some cases) by trying to mine a block. The chain having the most blocks and correspondingly the maximum proof-of-work is selected as the consensus value. In order to mine a block, the player must successfully find a “nonce” value that, along with the other contents of a block, hashes to a value less than a given target. Due to the nature of the hash function, this is a random process, and miners must repeatedly sample different nonce values to mine a block successfully.

Definition 2.1 (Fail Function).

We define as the probability of fraction of the network failing to mine a block in units of time.

where is the probability of a query being successful and is the cummulative hash rate of the entire network. A more detailed explanation for this is provided in Section A of the supplementary material.
For convenience, we sometimes use , the probability of fraction of the network failing to mine a block in a unit of time.

2.2. Throughput of a Blockchain-based DL

The throughput of the blockchain-based DL system depends on two parameters: (i) the Block Creation Rate and (ii) the Block Size with the throughput being proportional to .

Although we can increase any of the two parameters to increase the throughput, we suffer consequences due to the limitations of the underlying peer-to-peer network.

Effect of increasing the block creation rate

By increasing the block creation rate, we risk a node mining a block before it receives the latest block mined by the network.

Effect of increasing the block size

According to observations by Decker and Wattenhofer (Decker and Wattenhofer, 2013), there exists a linear relationship between the block size b and the time taken by the block to be propagated throughout the network. Hence, if we increase the block size, the time taken by it to propagate increases.

Increasing the block size or increasing the block creation rate lead to the deterioration of security properties in Bitcoin-like linear blockchain protocols, as shown by Sompolinsky and Zohar (Sompolinsky and Zohar, 2013). Our contribution is parallel to them since we show that they also cause a loss of fairness. In this paper, we consider settings with honest players and settings with rational players independently, we also define adversarial players here to show that they can pose threat to security of the blockchain.

Definition 2.2 (Honest Agent).

An agent is said to be an honest player if and only if it does not deviate from the protocol rules.

Definition 2.3 (Rational Agent).

An agent is said to be a rational player if it may strategically deviate from the protocol rules if the deviation is expected to yield a higher reward.

Definition 2.4 (Adversarial Agent).

An agent is said to be an adversarial player (and sometimes also known as “Byzantine” in the literature) may also strategically deviate from the protocol. However, the adversary’s goal is to disrupt the operation of the protocol, and it does not try to maximize its reward.

2.3. Reward Model

There are two principal ways of rewarding the nodes in a blockchain system:

  1. Block Reward - The reward miners can assign to themselves for mining a block. This reward mints new currency, adding to the total amount of currency in circulation.

  2. Transaction Fees - This is the fee offered by the users for miners’ services by providing incentives to include their transactions in the blocks. Typically, the users are allowed to decide the transaction fees they wish to offer while creating a transaction.

2.3.1. Other sources of Reward

Although we consider only block rewards and transaction fees to be the contributors of reward to the miners, miners might earn additional revenue from implicit sources as well. For instance, Daian et al. (Daian et al., 2020) show that there is considerable miner value in Order Optimization in Decentralized Exchanges, where the miners can rearrange transactions and potentially insert their own in a block to yield a higher reward. In this case, the miners that frontrun can gain additional revenue by grabbing revenue from order optimization.

2.4. Network Model

Typically, the nodes participating in the blockchain communicate with each other using the internet. They form a peer-to-peer network where each node is connected to a few other nodes (which we refer to as neighbors). We assume that the communication between two nodes has a finite delay. This communication delay may vary significantly depending upon numerous factors such as network congestion, network outages, and ISP bottlenecks, but for the sake of analysis, we abstract out these factors.
In this paper, we are concerned with the following two actions over the network:

  1. Broadcasting a Transaction: when a user wishes to make a transaction on the ledger, he/she cryptographically signs a transaction and sends it to a small number of nodes. Each node in the network propagates the transaction to its neighbors. Therefore, a transaction reaches all the nodes in the network after some time.

  2. Broadcasting a Block: Similarly, when a node mines a new block, it sends it to its neighbors, who then propagate it further. Therefore, a block reaches all the nodes in the network after some time.

There are some delays associated with both processes. We assume the delay of receiving a transaction and broadcasting a block to be dependent upon both the quality of a node’s connection and the quality of the overall peer-to-peer network. We quantify this delay as refers to the total time taken for any broadcast by a node to reach all nodes in the network.

3. Different Notions of Fairness

3.1. -approximate fairness

Pass and Shi (Pass and Shi, 2017) defined -approximate fairness as follows 333In their original paper, Pass et al. used the term -approximate fairness however we use a different symbol to distinguish it from the delay we use throughout the paper:

Definition 3.1 (-approximate fairness).

(Pass and Shi, 2017) A blockchain protocol has -approximate fairness if, with overwhelming probability, any honest subset controlling fraction of the compute power is guaranteed to get at least a fraction of the blocks in a sufficiently long window.

The intuition behind this is that in a fair protocol, a agent that controls a fraction of the computational resources should receive a fraction of the rewards. Though -approximate fairness has its own merit and importance, the definition manages to capture the intuition only if the reward for each block is similar. In DLs that operate at a slower speed, this variation may not be significant. However, at higher throughputs, the block reward may vary significantly among the blocks. In which case, we should also factor in the reward that the agents get for their blocks. Secondly, this definition does not capture the disparity among different nodes, i.e., which nodes gain more than their fair share and which nodes get less. The measures that we define compare different nodes or sets of nodes to highlight which ones are at a relative advantage and which ones are at a disadvantage.

Here, we wish to analyze network fairness and establish measures independent of the computational power of the nodes we are comparing. Hence, we base our definitions on network events instead.

3.2. Frontrunning ()

In some cases, it might be easier to analyze and quantify “unfairness” rather than fairness. Since only the transaction that comes first is said to be the valid one, any subsequent blocks that include a copy of the transaction lose out on the transaction fees and waste their space, which could have accommodated an unconfirmed transaction. For every transaction, we can imagine a race among the nodes to grab its transaction fees by mining a block that includes it. We can say that the node that manages to win the race by mining a block containing the transaction before everyone else wins the race and has successfully frontrun everyone else444As we discuss in later sections, this may not be the only way to win the race. In some cases agent can change the results of the race by strategically deviating from the protocol.555We borrow the term from Wall Street jargon where the term originates from the era when stock market trades were executed via paper carried by hand between trading desks. The routine business of hand-carrying client orders between desks would normally proceed at a walking pace. However, a broker could run in front of the walking traffic to reach the desk and execute his order first. (Wikipedia contributors, 2020). The system will be fair if every node has an equal probability of winning the race.

We define the event frontrun_1 for a node ( here, stands for Loser) as the event in which he loses the race described earlier. In this case, the node does not gain any reward since he failed to mine the block before everyone else.
We define the event frontrun_2 for as the event in which some other node manages to win the race even before starts the race. That is, some other node mined a block containing the transaction before receives the transaction. Clearly, .

To capture it more formally,

Definition 3.2 ().

We call the probability of the event frontrun_2 between the top percentile of the nodes and the bottom percentile of the nodes in terms of network delays. That is the probability that some node in the top percentile (in terms of network speed) manages to frontrun_2 all nodes in the bottom percentile.

Ideally, since all nodes should start at the same time (this being a race). However, as we analyze in Section 4.1, this probability may become significantly high due to varying network speeds.

3.3. Publishing Fairness ()

Faster internet speed can not only provide an advantage in receiving new transactions but also yield an upper hand in broadcasting blocks. Consider two nodes A and B that mine a block simultaneously. We define as the ratio of the probability that the majority accepts A’s block to the probability that the majority accepts B’s block. Thus, it quantifies the advantage of A in terms of publishing a block and claiming the associated reward. A lack of publishing fairness implies that not only slower nodes are less likely to receive reward transaction fees in the mined block but the are also less likely to receive the fixed block reward associated with mining a new block. The intuition behind this definition is that over multiple rounds, this would be the ratio of their conflicting blocks getting accepted.

Remark 1 Like , is also a measure of “unfairness” rather than fairness, i.e., higher implies lesser fairness in the system. The ideal value of is 1, when the blocks mined simultaneously by both the nodes are equally likely to get accepted.

Remark 2 only accounts for the events in which both A and B mine their blocks simultaneously since both the probabilities are conditioned on the blocks being mined simultaneously.

Remark 3 Ideally should be close to 1. The high value of indicates that the faster agent can collect more block rewards than the slower agent even though they both do exert the same amount of computation.

4. Analyzing Network Fairness

A node that can hear new transactions and propagate blocks faster than other nodes gains an unfair advantage over its peers. In this section, we analyze and quantify the advantage. We believe that the results presented in 4.1.1 and 4.2.2 to be a significant insight offered by our paper.

4.1. Analyzing Frontrunning

Consider a node with a poor network connection that receives a transaction with a significant delay as compared to others that do not. We now analyze the probability of the event frontrun_2 happening for the node. For the Bitcoin Network, according to (4) it takes less than 4 seconds for a transaction to reach the 50th percentile but more than 15 seconds to reach the 90th percentile. It is likely that the slower nodes only hear about a transaction once a faster node has already confirmed it. Let us consider the probability of nodes in the top percentile in terms of network speed being able to confirm the transaction before the bottom of the nodes receive it.666We make an additional assumption here that all nodes should have equal computing power. This is ideal from the expectation that the system should be decentralized. Hence, computational power should be ideally distributed equally among the nodes.

Let be the advantage offered to the top fraction of the nodes in terms of time (in our example, this amounts to 11 seconds), is the probability of query being successful, and be the hash rate of the network.

Theorem 4.1 (Lower bound of ).

Proof.

We show that the probability of the event that fraction of the network manages to mine a block in time increases with the block creation rate . A formal proof is provided in Section B of the supplementary material. ∎

Theorem 4.1 shows that increases monotonically with increasing the block creation rate since its lower bound increases monotonically. One can observe that in order to keep the probability of this event sufficiently low, must be reduced while increasing to scale the blockchain. Although, it may seem that the lower bound is independent of the bottom percentile selected but this would have been incorporated in since increases as decreases.

4.1.1. Practical Significance of Theorem 4.1

As of October 2020, approximates to for the Bitcoin Network. However, if we were to scale the Bitcoin Network to a throughput similar to offered by the likes of Visa Network by increasing the block creation rate to 566 blocks every 10 minutes (by reducing the difficulty and keeping the block size same) goes up to 777We assume there are no significant improvements in the peer-to-peer overlay network

. Unfortunately, since at the time of writing, statistics on transaction propagation times in Ethereum were not published, we estimate

for Ethereum by using the same delays as Bitcoin. We find that the estimated value of (as of October 2020) is around , which is considerably higher than that of Bitcoin. In Figure 1, we plot the variation of with increase in the throughput.

Figure 1. Variation of as we scale the blockchain

4.1.2. Variation in Block Rewards

Our analysis in Section 4.1 shows that as we scale the blockchain to higher throughputs, some agents would be able to grab high-value transactions before others consistently. This means that some agents would be producing blocks with higher rewards, while others would produce blocks with lower rewards. Hence, a lack of network fairness may be able to induce a greater variation in block rewards. We discuss further implications of this variation in Section 5.

Lack of incentive for information propagation

The inability of the peer-to-peer network to keep up with the ledger’s desired throughput is further exacerbated by the fact that the nodes do not have any incentive to participate in broadcasting information. In fact, they have an incentive to keep the knowledge of transactions to themselves, as shown by Babaioff et al. (Babaioff et al., 2012). By broadcasting a transaction to other nodes, a agent is potentially increasing the number of nodes competing to include the transaction in their blocks and collect the corresponding transaction fees. Thus, offering additional incentive to agents for propagating transactions may speed up the the broadcast of a transaction.

4.2. Publishing Fairness in Broadcasting Blocks

Figure 2. Fraction of nodes accepting a block vs rounds

Let us assume that the execution happens in “rounds” in which the nodes make queries each to the Hash Function. At the boundaries of rounds, the nodes can communicate with their neighboring nodes. In our example here, we assume the duration of a round to be 1 second. If a node succeeds in mining a block in a round, it will begin broadcasting it to its neighbors when the round ends. Similarly, if a node receives a block at the beginning of a round, it will broadcast it to its neighbors at the end of that round.

We assume that there are nodes, and all nodes are honest. Hence, they follow the Bitcoin protocol’s strategy of picking the oldest block in case of a tie and publishing a block as soon as it is mined.

Consider the event in which exactly two nodes, A and B mine a block simultaneously in the same round. Let and (, without loss of generality) be the delay associated with broadcasting the blocks to the entire network. At a time , the network will be split into two fractions:

  • : The fraction of nodes in the network which claim to have received the block mined by A before the block mined by B.

  • : The other fraction of nodes in the network which claim to have received the block mined by B before the block mined by A.

Since by , all nodes in the network would have received the blocks mined by A and B, .

Let and be the fraction of network accepting A and B at the round. Then, can be approximated by Theorem 4.2.

Theorem 4.2 (Approximation of ).
(1)

where

Proof.

The proof of follows from first finding the probability of A being successful to getting its block accepted in round conditioned on the probability that neither of the blocks gain majority till the round. We then use Baye’s Theorem to find out the total probability. A formal proof is presented in Section C of the supplementary material. ∎

4.2.1. Calculating

If we assume the propagation of the block in the network to be linear888Although, we expect it to be exponential in practice due to the GOSSIP algorithm, a linear assumption is rather optimistic and our results would be more pronounced in the exponential case., then by the end of , and . Accordingly, the plot of and will be as shown in Figure 2. We then calculate according to Theorem 4.2 and plot for varying network delays as well as varying throughputs.

4.2.2. Results on

In Figures 4.2 and 4.2, we plot the variation of with the increase in for different values of . We find that grows exponentially with an increase in or a decrease in , which implies that even small differences in network delays can make the system unfair.

In Figure 4.2, we plot the variation of as we increase throughput for a fixed and . We find that grows with an increase in the block creation rate , which implies that as we scale the system, it becomes more unfair (from Remark 3.3). However, the increases slowly after a certain . We must note that the probability of simultaneously mining a block still keeps increasing exponentially, which is not factored in (from Remark 3.3). Hence, the overall ratio of blocks that A is able to include in the blockchain as compared to B still keeps increasing.

4.3. A Few Tips and Tricks

Improving the delays associated with broadcasting transactions and blocks for a node may not be as simple as improving the quality of a node’s internet connection. A significant factor of the delay also depends upon the structure of the peer-to-peer network, the number of neighbors, and their delays. Decker and Wattenhofer (Decker and Wattenhofer, 2013) suggest pipelining of information propagation to reduce the latency. However, we are more concerned with the changes a single node can implement to reduce its delay. Stathakopoulou et al. (Stathakopoulou, 2015) suggest implementing a Content Distribution Network that connects to nodes based on their geographic proximity. There have also been a few high-speed alternative “relay” networks developed to broadcast information quickly among a subset of nodes part of the network ((Corallo, ), (Basu et al., ) and (Klarman et al., 2018)). However, there are many concerns raised about the centralized nature of these networks. A node that is a part of such a network could undoubtedly gain an advantage over others. However, doing so may lead to further centralization, defeating the purpose of having a distributed ledger.

5. Fairness and Strategic Deviations

A lack of fairness causes some agents to gain more than their fair share of rewards, whereas some agents gain less than their fair share of rewards. Since all agents have similar underlying costs related to mining, it would make mining less profitable or even loss-making for some agents. We believe that this might open up the pandora’s box of strategic deviations that might be not only unfair to the honest players but also detrimental to the health of the blockchain. Until now, we had considered that all players were honest and will not deviate from the protocol. However, the players may choose to deviate from the protocol if the deviation cannot be detected or penalized. When mining is not fair to some agents, they may have an incentive not to accept the consensus and depart from the honest strategy. This disagreement could possibly be reflected by forks that cause the agents in the system to split their votes. These deviations might be harmful to the health of a blockchain and make it less secure against adversaries. We now briefly discuss a few possibilities if they act rationally to maximize their expected reward.

Carlsten et al. (Carlsten et al., 2016)

had shown that when there is a large variance in the reward earned from blocks, it might be profitable to intentionally fork blocks with high rewards.

Petty mining (Carlsten et al., 2016) is a strategy in which, given a fork, the petty miner picks the fork, which has collected lesser transaction fees and, hence, offers the agent an opportunity to include transactions from the other fork and collect more transaction fee. Undercutting (Carlsten et al., 2016) is a strategy in which a agent intentionally forks a block with a high reward in order to collect some of the rewards while offering the rest of the reward to the petty agents that choose to mine on top of it. A slow node that does not have enough high-value transactions in its mempool might have an incentive to either fork the block mined by a frontrunner (undercutting) or given a fork pick the fork that offers an opportunity to collect a higher transaction fee (petty mining). If we assume that all agents are rational and hence petty miners since this strategy strictly dominates honest mining. Undercutting would allow a slower node to overcome both frontrunning and lack of publishing fairness. A slower node could fork a block mined by a faster node containing many high-value transactions due to frontrunning and include those transactions in its own block while leaving some of the transactions for others to include. Secondly, even if a node receives the block mined by a slower node later, it would drop the previous block and mine on top of this instead since it offers a higher reward. 999In fact, undercutting might even occur in case of an unintentional fork between a faster node and a slower node (since the block mined by a faster node will contain more high-value transactions). The probability of such forks increases along with and In this case, it might not be in the best interest of the frontrunner to always pick the transactions offering higher rewards.

5.1. Modelling Bitcoin Mining As A Game

We divide the network into two portions: slow and fast. The fast nodes can receive messages broadcasted by any node in the previous round, but the slow nodes have higher communication delays with certain nodes. Each node can choose from the following strategies:

  1. petty: The petty mining strategy described in (Carlsten et al., 2016), it is same as the default strategy in case of no forks. It weakly dominates the default compliant strategy prescribed by Bitcoin but it is not harmful to the security of the blockchain on its own.

  2. minor_undercutting: A node will undercut if the longest chain’s reward is below a certain threshold. However, it would leave out a small constant reward as an incentive for the subsequent agents that pick the block.

  3. : A node will undercut if the longest chain’s reward is below a certain threshold. However, it would leave out a significant portion of the reward () as an incentive for the subsequent agents that pick the block.

The resulting game could be analyzed as a two-player bi-matrix game.

5.2. Simulation-based Analysis

5.2.1. Simulator Details

In order to study undercutting based strategic deviations in blockchains at high throughputs, we developed a lightweight simulator (described in Algorithm 1).

Input: Distance matrix , Number of rounds , Strategy
Result: Expected reward of each player
/* Set of mined blocks */
Initialize
Initialize
for  to  do
        for  to  do
               if  wins a lottery in round  then
                     
                     
                      for  do
                             if  satisfies strategy and  then
                                   
                                   
                                   
                             end if
                            
                      end for
                     for  do
                             if  then
                                   
                                   
                                   
                                   
                                    if  then
                                          
                                          
                                          
                                   else if  then
                                           /* A small quantity */
                                          
                                          
                                          
                                   else
                                          
                                    end if
                                   
                                   
                                   
                             end if
                            
                      end for
                     
               end if
              
        end for
       
end for
Return: Expected reward of each player averaged over all chains with length = longest_chain
Algorithm 1 Simulator

We tested the following strategies:
(a) (), (b) (), (c) minor_undercutting(), and (d) petty(). We assigned different strategies to slow and fast nodes to produce the payoff matrix in Table 1101010Due to computational constraints, we produced results for times that of Bitcoin which would yield a throughput 60% that of the Visa Network but we expect the results to be even more pronounced as we scale the blockchain further..

(75.22, 19.13) (71.72, 23.12) (74.29, 21.54) (73.75, 22.17)
(75.22, 19.86) (76.05, 19.56) (72.17, 24.24) (74.99, 21.74)
(63.30, 33.17) (63.35, 33.84) (66.90, 30.68) (74.02, 23.6)
(63.41, 33.06) (64.04, 33.29) (56.66, 40.78) (67.54, 30.26)
Table 1. Payoff Matrix averaged over 100 simulations

The utilities shown here are the percentage of total reward grabbed by the fast and slow sets collectively. (They do not add up to 100% since some blocks may be underutilized)

The strategies which would be removed by iterated removal of dominant strategies (with tolerance of are shown in blue.

5.2.2. Equilibrium Analysis

Definition 5.1 (Weakly Dominated Strategy).

(Osborne and Rubinstein, 1994) A strategy is said to be weakly dominated if for an agent if

where is the payoff for agent if he/she chooses the strategy

and the other agents’ vector of strategies is

Definition 5.2 (Mixed Strategy Nash Equilibrium (MSNE)).

(Osborne and Rubinstein, 1994) A strategy profile is called a Mixed Strategy Nash Equilibrium (MSNE) for agents, if for each agent , is the best response to . That is, ,

where is the mixed strategy played by the player in which he/she chooses strategy with probability .

By applying Iterated Removal of Dominated Strategies on the Payoff Matrix, we discard strategies and from the solution set of fast agents and discard from the solution set of slow agents. We then find the following two mixed strategy nash equilibria among the remaining set of strategies:

  1. Fast agents choose with probability of and rest of the time, while slow agents choose with probability of and rest of the time.

  2. Fast agents choose with probability of and rest of the time, while slow agents always pick .

We make the following additional remarks based on the payoff matrix:

  1. The blockchain system would have been secure against any strategic deviations if had been an equilibrium strategy. However, we observe that it is dominated by nearly all undercutting strategies for slower nodes. Hence, it would always be more profitable for the slower nodes to undercut. A lack of publishing fairness could explain this.

  2. If the slow nodes choose minor_undercutting, it would be more profitable for the faster nodes to choose
    major_undercutting.

  3. If all the nodes choose major_undercutting the total revenue gathered by the network reduces to roughly 94.3% from 97.8% indicating that fewer transactions are being added to the longest chain. This means that the throughput is being under-utilized.

  4. The equilibria strategies are even worse for the slower nodes in terms of fairness since they grab an even smaller share of reward as compared to the strategy where all players act honestly.

Thus, if agents act rationally not only would security of the blockchain be adversely affected, the lack of fairness among the rewards received by the slower miners would be exacerbated.

6. Related and Future Work

Garay et al.(Garay et al., 2014) and Kiyayas et al. (Kiayias and Panagiotakos, 2015) show that existing blockchain protocols suffer from a loss of security properties as we scale the system. These security properties are fundamental to the operation of a robust DL. (Garay et al., 2014) and (Kiayias and Panagiotakos, 2015) consider a model with two types of players, honest and adversarial. They consider that the adversary tries to attack the ledger by forking the blockchain. A successful fork would allow the adversary to perform a double-spending attack. We, on the other hand, analyze the issues that may arise even if all players are honest. We show that as we scale the system, not only do the security properties suffer, but fairness also suffers, and hence, our work is parallel to theirs.

Further, there have been many novel blockchain protocols proposed to scale blockchain without losing the security properties, e.g., OHIE (Yu et al., 2020), IOTA (Popov, ), GHOST (Sompolinsky and Zohar, 2013), GhostDAG/Phantom (Sompolinsky et al., 2018), and many more coming up every day. We believe that our fairness measures are generalized enough also to be applied to them. However, the analysis may vary according to the design of the protocol. Even though many of the DAG-based blockchain protocols manage to solve the issue of publishing fairness by allowing “off-chain” blocks to be considered as a part of the blockchain, the frontrunning issue persists. Due to unfairness in frontrunning, we find that they suffer from a different style of undercutting attacks. We demonstrate an example of such attack in a blockchain protocol known as OHIE in Section D of the supplementary material.

Researchers have been analyzing blockchain systems from a lens of game theory, Chen et al.

(Chen et al., 2020) use game-theory to establish the tradeoff between full verification, scalability, and finality-duration. However, they do not consider network delays in their model, and hence, their bounds are quite optimistic. (Amoussou-Guenou et al., 2020) study the consensus in a setting with rational as well as honest agents. (Lavi et al., 2019) analyze Bitcoin’s transaction fees using auctions. (Siddiqui et al., 2020) study fairness in the transaction fees collected by the nodes in a transaction fee only model and propose a fair transaction processing protocol.

(Pass and Shi, 2017) define -approximate fairness and propose a blockchain protocol that satisfies -approximate fairness in the case where players have symmetric network access, whereas we study the case where players have asymmetric network access.

7. Conclusion

In this paper, we introduced a notion of network fairness, investigated the factors that influence network fairness, and studied its impact on the agent’ revenue. We assumed a model in which players have asymmetric network connections, i.e., some players may have a faster connection while others may have a slower connection and described two mechanisms via which this asymmetry could result in a loss of fairness in the system. We considered two events associated with the mining process, frontrunning and block publishing, and measured fairness for these events. We showed that fairness can be quantified via and . is a measure of frontrunning due to network delays in broadcasting a transaction. or publishing fairness is the ratio of blocks of one node that get accepted due to network delays over blocks of another node. We found that both of them deteriorate as we increase the throughput of existing protocols. Hence, even though it might look like the agents walk together (or the system is fair) while the throughput is low, at higher speeds, some agents may run faster (or gain more than their fair share of rewards).

We also discussed that not only does a lack of fairness impacts the revenue of some agents, it might also create an incentive for them to deviate from the honest mining strategy, which might impact the security of the blockchain system and further exacerbate lack of fairness in rewards.

Thus, we conclude that even though blockchain is an ambitious technology, its potential is hindered by the underlying network infrastructure.

References

  • Y. Amoussou-Guenou, B. Biais, M. Potop-Butucaru, and S. Tucci-Piergiovanni (2020) Rational vs byzantine players in consensus-based blockchains. In Proceedings of the 19th International Conference on Autonomous Agents and MultiAgent Systems, AAMAS ’20, Richland, SC, pp. 43–51. External Links: ISBN 9781450375184 Cited by: §6.
  • M. Babaioff, S. Dobzinski, S. Oren, and A. Zohar (2012) On bitcoin and red balloons. In Proceedings of the 13th ACM conference on electronic commerce (ACM EC’12), pp. 56–73. Cited by: §4.1.2.
  • [3] S. Basu, I. Eyal, and E. G. Sirer Falcon - a fast bitcoin backbone. External Links: Link Cited by: §4.3.
  • [4] (2017 (accessed June 4, 2020)) BitcoinStats. Note: http://bitcoinstats.com/network/propagation/ Cited by: §4.1.
  • M. Carlsten, H. Kalodner, S. M. Weinberg, and A. Narayanan (2016) On the instability of bitcoin without the block reward. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pp. 154–167. Cited by: §D.1, Appendix D, item 1, §5.
  • L. Chen, L. Xu, Z. Gao, K. Kasichainula, and W. Shi (2020) Nonlinear blockchain scalability: a game-theoretic perspective. arXiv preprint arXiv:2001.08231. Cited by: §6.
  • [7] M. Corallo FIBRE - fast internet bitcoin relay engine. External Links: Link Cited by: §4.3.
  • P. Daian, S. Goldfeder, T. Kell, Y. Li, X. Zhao, I. Bentov, L. Breidenbach, and A. Juels (2020) Flash boys 2.0: frontrunning in decentralized exchanges, miner extractable value, and consensus instability. In 2020 IEEE Symposium on Security and Privacy (SP), Vol. , Los Alamitos, CA, USA, pp. 585–602. External Links: ISSN 2375-1207, Document, Link Cited by: §2.3.1.
  • C. Decker and R. Wattenhofer (2013) Information propagation in the bitcoin network. In IEEE P2P 2013 Proceedings, pp. 1–10. Cited by: §2.2, §4.3.
  • J. Garay, A. Kiayias, and N. Leonardos (2014) The bitcoin backbone protocol: analysis and applications. Note: Cryptology ePrint Archive, Report 2014/765https://eprint.iacr.org/2014/765 Cited by: §1.1, §6.
  • A. Kiayias and G. Panagiotakos (2015) Speed-security tradeoffs in blockchain protocols. Note: Cryptology ePrint Archive, Report 2015/1019https://eprint.iacr.org/2015/1019 Cited by: §1.1, §6.
  • U. Klarman, S. Basu, A. Kuzmanovic, and E. G. Sirer (2018) Bloxroute: a scalable trustless blockchain distribution network whitepaper. IEEE Internet Things J.. Cited by: §4.3.
  • R. Lavi, O. Sattath, and A. Zohar (2019) Redesigning bitcoin’s fee market. In The World Wide Web Conference, WWW ’19, New York, NY, USA, pp. 2950–2956. External Links: ISBN 9781450366748, Link, Document Cited by: §6.
  • [14] S. Nakomoto Bitcoin: a peer-to-peer electronic cash system. Note: https://bitcoin.org/bitcoin.pdf Cited by: §2.
  • M. J. Osborne and A. Rubinstein (1994) A course in game theory. MIT press. Cited by: Definition 5.1, Definition 5.2.
  • R. Pass and E. Shi (2017) Fruitchains: a fair blockchain. In Proceedings of the ACM Symposium on Principles of Distributed Computing, pp. 315–324. Cited by: §3.1, Definition 3.1, §6.
  • [17] S. Popov The tangle. Cited by: §6.
  • S. Siddiqui, G. Vanahalli, and S. Gujar (2020) BitcoinF: achieving fairness for bitcoin in transaction fee only model. In Proceedings of the 19th International Conference on Autonomous Agents and MultiAgent Systems, AAMAS ’20, Richland, SC, pp. 2008–2010. External Links: ISBN 9781450375184 Cited by: §6.
  • Y. Sompolinsky, S. Wyborski, and A. Zohar (2018) PHANTOM and ghostdag: a scalable generalization of nakamoto consensus. Note: Cryptology ePrint Archive, Report 2018/104https://eprint.iacr.org/2018/104 Cited by: §6.
  • Y. Sompolinsky and A. Zohar (2013) Accelerating bitcoin’s transaction processing. fast money grows on trees, not chains. Note: Cryptology ePrint Archive, Report 2013/881https://eprint.iacr.org/2013/881 Cited by: §2.2, §6.
  • C. Stathakopoulou (2015) A faster bitcoin network. Cited by: §4.3.
  • [22] Visa Inc. VisaNet booklet. Note: https://usa.visa.com/dam/VCOM/download/corporate/media/visanet-technology/visa-net-booklet.pdfAccessed: 5-3-2019 Cited by: §1.1.
  • Wikipedia contributors (2020) Front running — Wikipedia, the free encyclopedia. Note: https://en.wikipedia.org/w/index.php?title=Front_running&oldid=944160433[Online; accessed 12-June-2020] Cited by: footnote 5.
  • H. Yu, I. Nikolic, R. Hou, and P. Saxena (2020) OHIE: blockchain scaling made simple. In 2020 IEEE Symposium on Security and Privacy (SP), Los Alamitos, CA, USA, pp. 112–127. External Links: ISSN 2375-1207, Document, Link Cited by: §D.2, §6.

Appendix A Fail Function

Let us denote to be the probability of a nonce being successful and to be the rate of queries to the hash function. In time , the miner will be able to make such queries.

The probability of a query being unsuccessful will be .

the probability of such queries being unsuccessful will be .

For players (the total number of players in the system), the number of queries in the same duration will be

the probability of these nodes failing to mine a block will be .

The value is known as the hash rate of the system, denoted by .

Let us denote the probability of fraction of the network failing to mine a block by the function .

For convenience, we sometimes use , the probability of fraction of the network failing to mine a block in a unit of time.

Appendix B Proof of Theorem 4.1

[Lower bound of ]

Proof.

Let denote the event that top fraction of nodes succeed in mining the block before the transaction reaches the bottom fraction.

Appendix C Proof of Theorem 4.2

(2)

where

(3)
Proof.

The proof follows from first finding the probability of A being successful in getting its block accepted in round conditioned on the probability that neither of the blocks gain majority till the round. We then use Bayes’ Theorem to find out the total probability.

The block mined by A will get accepted if the chain that includes A’s block becomes longer than the one that includes B. As soon as the longer chain is received by a node that had previously accepted B, the node must reject B and accept A instead. We assume that as soon as the chain mined by either fraction becomes longer than that of their counterpart, their counterpart will switch to the longer chain. Let and be the fraction of network accepting A and B at the round. We slightly abuse notation here to use A and B to refer to the blocks mined by A and B, respectively.

(4)

The network fails to decide in the round if the length of the chains remain equal, i.e., either both fractions mine a block (which is highly unlikely), or both fractions fail to mine a block.

(5)

Appendix D Frontrunning in OHIE

In this section, we describe a strategic deviation for the OHIE Protocol based on frontrunning. OHIE is a permissionless blockchain protocol that aims to achieve high throughput while tolerating up to 50% of the computational power being controlled by the adversary.

OHIE composes (e.g., ) parallel instances or “chains” of Nakamoto consensus. Each chain has a distinct genesis block, and the chains have ids from to (which can come from the lexicographic order of all the genesis blocks). For each chain, Bitcoin’s longest-chain-rule is followed. The miners in OHIE extend the chains concurrently. They are forced to split their computational power across all chains evenly.

The total block ordering in OHIE is generated according to the increasing order of ranks and breaking ties by picking one with a lower chain id earlier. The miner of a block picks the rank of the block that follows it in a chain, i.e., the . Notice that the chains may not be equal in length and might have different s at their last positions. This implies that if a block is mined in a chain having lower than another chain, the block might end up earlier in the Total Block Ordering than a block that has already been mined.

According to the specifications of the protocol, a miner should pick the highest possible in order to ensure that the chain the block becomes a part of, catches up to the longest chain. A miner can also choose which blocks to mine on top of. If a rational agent wishes to insert his block earlier in the total ordering, he can choose a block that has picked a lower over one with a higher . We describe a rational deviation based on this fact.

This deviation is similar to undercutting in Bitcoin, described by Carlsten et al. (Carlsten et al., 2016) We assume that at least some agents are rational and follow a petty compliant strategy. The agents still choose to mine on top of the longest chains, but in case of a tie or fork, they pick the block offering lower . Doing so provides an opportunity for strategic frontrunning by possibly achieving a lower rank (and hence include the high-value transactions of already published blocks of higher rank).

d.1. Expected Reward of Including Transactions

In our case, the frontrunning is not guaranteed to be successful. The block could end up on the chain from which the transaction was included. In which case, it will end up losing the transaction fees since it will not precede the original block from which the transaction was included. The block is equally likely to become a part of the chains. Therefore we define the expected reward of including a transaction as follows:

The probability of the succeeding to frontrun a block will be:

(6)

We can expect a rational agent to include the transactions from the mempool as well as transactions from other blocks that offer the highest expected reward.

Similar to (Carlsten et al., 2016) we find that for a petty compliant miner frontrunning is a better strategy since it guarantees as much reward as the honest node’s strategy. As we try to scale the system to higher throuputs by increasing the number of chains, the number of possible blocks to frontrun will also increase (due to a higher probability of some chains being longer in length). Thus, the probability of strategic frontrunning also increases as we try to scale the system.

d.2. Undercutting Agents

Now consider if a more aggressive agent does not mind forking a chain. In the following example (modified version from the original paper (Yu et al., 2020)):

Figure 3. Example initial state of an OHIE execution with . Each block is marked with a tuple .

In the example initial state, the chains are of unequal length. (Such an event is possible since the blocks extend chains at random, some chains can receive more blocks than others)

Figure 4. The state after the honest node extends Chain 0. A dotted arrow denotes the trailing pointer.

Let us say that an honest node mines the next block on Chain 0. Since the node follows the default strategy of setting the to be the maximum among all chains, it sets the to be 5. The mechanism by which the is specified is by including a trailing pointer to the last block on Chain 1. Hence, the of this block is implicitly set to the of the block that the trailing pointer points to.

Figure 5. The block formulated by an aggressive miner for undercutting. The dotted arrow denotes the trailing pointer. The three solid arrows point to the Merkle tree of pointers to preceding blocks.

Consider a agent that tries to undercut aggressively. It picks the blocks it wants to drop (in this case on Chain 0 and , , and on Chain 1) and then picks the trailing pointer to . However, it could have picked on any chain as the trailing pointer, in which case it would have been assigned a of . This deviation would have easily been detected since its trailing pointer would have lesser than the block it precedes, indicating the deviation. In our case, the agent tries to deviate in a manner that is not distinguishable from a fork. In order to do so, it selects a that is greatest among the blocks in its Merkle tree.

Figure 6. The three possible cases that could arise if the undercutter’s mining is successful

If the undercutter is able to mine the block successfully, it may end up on one of the three chains depending upon the last bits of the hash. We consider these three cases separately:

  • If the block ends up on Chain 0, the new block forks the chain. Since the two forks are equal it is upto the nodes in the network to choose the fork they wish to extend. Choosing the undercutter’s block in this case would be a better option for the petty compliant agents since it offers a lower . If the majority of the agents are petty compliant, then the undercutter is successful.

  • If the block ends up on Chain 1, the new block forks the chain. Since the undercutter’s fork is shorter than the original chain, it would be orphaned by all agents. In this case, the undercutter is unsuccessful.

  • If the block ends up on Chain 2, the new block extends the original chain. All agents will prefer to mine on top of undercutter’s block. In this case, the undercutter is successful.

Hence, in 2 out of 3 cases, i.e., with a probability of , the undercutter is successful. Therefore, the agent may undercut if the reward obtained by picking transactions from the blocks it drops is times more than the reward by mining honestly. That is, if the then undercutting may be a better strategy.