Authors’ copy downloaded from: //sprite.utsa.edu/publications/articles/manshaeiAccess18.pdfthat can host and execute arbitrary distributed applications (commonly referred to as “smart

Authors’ copy downloaded from: https://sprite.utsa.edu/

Copyright may be reserved by the publisher.

https://sprite.utsa.edu/

Date of publication xxxx xx, 20xx, date of current version September 21, 2018.

Digital Object Identifier 00.0000/ACCESS.2018.DOI

A Game-Theoretic Analysis ofShard-Based PermissionlessBlockchainsMOHAMMAD HOSSEIN MANSHAEI1, MURTUZA JADLIWALA2, ANINDYA MAITI3, ANDMAHDI FOOLADGAR11Department of Electrical and Computer Engineering, Isfahan University of Technology, Isfahan 84156-83111, Iran2Department of Computer Science, University of Texas at San Antonio, USA3Institute for Cyber Security, University of Texas at San Antonio, USA

ABSTRACT Low transaction throughput and poor scalability are significant issues in public blockchainconsensus protocols such as Bitcoins. Recent research efforts in this direction have proposed shard-basedconsensus protocols where the key idea is to split the transactions among multiple committees (or shards),which then process these shards or set of transactions in parallel. Such a parallel processing of disjointsets of transactions or shards by multiple committees significantly improves the overall scalability andtransaction throughout of the system. However, one significant research gap is a lack of understandingof the strategic behavior of rational processors within committees in such shard-based consensus protocols.Such an understanding is critical for designing appropriate incentives that will foster cooperation withincommittees and prevent free-riding. In this paper, we address this research gap by analyzing the behavior ofprocessors using a game-theoretic model, where each processor aims at maximizing its reward at a minimumcost of participating in the protocol. We first analyze the Nash equilibria in an N -player static game modelof the sharding protocol. We show that depending on the reward sharing approach employed, processorscan potentially increase their payoff by unilaterally behaving in a defective fashion, thus resulting in asocial dilemma. In order to overcome this social dilemma, we propose a novel incentive-compatible rewardsharing mechanism to promote cooperation among processors. Our numerical results show that achieving amajority of cooperating processors (required to ensure a healthy state of the blockchain network) is easier toachieve with the proposed incentive-compatible reward sharing mechanism than with other reward sharingmechanisms.

INDEX TERMS Sharding, Blockchain, Game Theory, Cooperation, Incentive Design.

I. INTRODUCTION

A blockchain is an append-only, immutable distributeddatabase that records a time-sequenced history of facts calledtransactions. Transactions are typically grouped into blocks,and the blockchain protocol enables the construction andmaintenance of consistent copies of the cryptographic hash-chain of blocks in a distributed fashion. The first blockchainprotocol was introduced in 2009 by Satoshi Nakamoto to sup-port the Bitcoin cryptocurrency [1]. A key aspect of this pro-tocol is the consensus algorithm (also sometimes referred inthe literature as Nakamoto consensus) which enables agree-ment among a network of processors or miners on the state ofthe blockchain (identified by its cryptographic digest), under

the assumption that a fraction of them could be malicious orfaulty. In addition to this, as Bitcoin’s blockchain is permis-sionless, i.e., no trusted infrastructure to establish verifiableidentities for processors exists or is assumed, consensus onthe blockchain’s state cannot be achieved using standarddistributed Byzantine fault-tolerant consensus algorithms inthe literature. In such a permissionless setting, the blockchainprotocol selects (randomly and in an unbiased fashion) oneprocessor once every 10 minutes on average (epoch), and thisselected processor gets the right to commit (or append) a newblock onto the blockchain. The network (other processors)implicitly accept this block by building on top of it in thenext epoch or reject it by building on top of some other block

VOLUME 0, 2018 1

Manshaei et al.: A Game-Theoretic Analysis of Shard-Based Permissionless Blockchains

in the hash-chain.Consensus in Bitcoin is thus long-term, i.e., a block is said

to be included in the blockchain if it is part of the longestvalid blockchain and has received a significant number ofconfirmations1. The Bitcoin protocol uses a Proof-of-Work(PoW) mechanism to select the leader (processor with theright to commit a block) in each epoch in an unbiasedfashion, which is nothing but a hash puzzle that each pro-cessor attempts to solve - one that succeeds is selected andgets the right to propose the next block. As PoW involvessignificant computation, Bitcoin’s protocol includes a rewardmechanism to incentivize processors to compete (in a fairfashion) and to behave honestly. As of July 2018 [2], therewere a total of 1624 cryptocurrencies, a significant numberof which use the same code base as Bitcoin or are directly in-spired by Bitcoin’s distributed consensus algorithm. The useof blockchains and blockchain-based distributed consensus,however, is not just restricted to cryptocurrencies. Systemsthat can host and execute arbitrary distributed applications(commonly referred to as “smart contracts") over a singlepublic permissionless hash-chain, for example, Ethereum[3], have also become popular. Such systems also employ aBitcoin-like Proof-of-Work based consensus algorithm anda related cryptocurrency (e.g., Ether in Ethereum) to incen-tivize processors or miners to participate honestly in theconsensus process.

Despite its tremendous popularity, one significant short-coming of Bitcoin’s consensus protocol (and of similar publicpermissionless blockchain systems) is its low transactionthroughput and poor scalability. With an average inter-blocktime of 10 minutes and a maximum block size of 10 MB,Bitcoin’s transaction rate is currently only 7 transactions persecond [4]. Similarly, Ethereum can support only roughly 20transactions per second. This is significantly lower than thetransaction rates afforded by centralized transaction process-ing systems. For instance, PayPal can process more than 450transactions per second while VisaNet can process anywherebetween 1667 and 56,000 transactions per second [4]. It isclear that the current Bitcoin and Ethereum transaction ratesare not sufficient for many practical applications, and thus,there have been significant efforts towards improving theirtransaction throughputs, for example, BIP [5] and Bitcoin-NG [6] for Bitcoin and Raiden [7] for Ethereum.

Similarly, there have been other significant efforts withinthe research community towards improving the transac-tion throughput and scalability of public permissionlessblockchain protocols in general. One key outcome of thisline of research is sharding [8]–[10], which proposes to peri-odically partition the network of processors (in an unbiasedfashion) into smaller committees, each of which processes adisjoint set of transactions (also called a shard2) in parallelwith other committees. As each committee is reasonably

1Number of blocks added on top of the block in question in the longestvalid blockchain.

2Note that the committees are working inside shards in these protocols.Hence, we use the two terms interchangeably in the paper.

small, it can run a classical Byzantine consensus protocolsuch as PBFT [11] to agree on a set of transactions ratherthan the traditional Nakamoto consensus of Bitcoin, thusincreasing the overall transaction throughput of the system.Although the idea of parallelizing the tasks of transactionprocessing and reaching consensus (on a set of transactions)by partitioning the processor network into committees ispromising, existing sharding proposals [8]–[10] fail to clarifyhow processors will be incentivized to honestly participateand discharge their committee duties.

Two facts about existing sharding protocols are relevantto this discussion and should be highlighted: (i) the intra-committee consensus algorithms (e.g., PBFT) employed byexisting protocols are inherently fault-tolerant, i.e., they willoperate correctly even in the presence of a certain number offaulty or non-participating committee members, and (ii) theagreed (or consensus) set of transactions within each com-mittee is required to be ratified (or signed) by only a majorityof the committee members in order for those to be includedinto a block. Now as participation in committee tasks (suchas transaction validation, signature creation, etc.) impose acost on processors, it is possible that rational processorsmay choose not to participate in these tasks (and get awaywith it as the protocol may still succeed at the end) if theirremuneration is not appropriately determined. For example,if each processor within a committee is equally remunerated,a rational processor may choose to free-ride, i.e., get paidwithout participating in any committee work. In summary,one key research gap in this line of research is a lack ofunderstanding of the strategic behavior of rational processorsin shard-based consensus protocols for public permissionlessblockchains. Such an understanding is critical for designingappropriate incentives that will foster cooperation withincommittees and prevent free-riding. Our goal in this paperis to address this research gap.

In line with the above goal, we first model shard-basedprotocols, and the interaction between processors in suchprotocols, using a static non-cooperative game by systemati-cally quantifying processor strategies in such a game and theresulting payoffs. We show that in such a setting, if the totalreward (received at the end of the game when a new blockis successfully committed to the blockchain) is equally oruniformly distributed among all the participating processors,then the resulting strategic interactions can be characterizedusing a game with social dilemma, such as a public goodsgame. Consequently, we show that not participating in thecommittee tasks (by all processors) is a Nash equilibrium ofthe game. We further show that it is impossible to enforcea cooperative Nash equilibria in this setting unless certainimprobable conditions are met. Hence, we extend the currentgame model by considering fair sharing of rewards, instead ofequal sharing, where processors receive benefits only if theyhave cooperated within their shards. In this new system, wederive the Nash equilibria and conditions under which suchan equilibria can be achieved. Although this game is stilla public goods game, we were able to establish conditions

2 VOLUME 0, 2018


for achieving cooperation by processors towards executingthe committee tasks in this game. These conditions can bederived and verified by processors before they decide ontheir strategy to cooperate or defect in the game. Our resultsshow that it is possible to achieve a cooperative equilibiumin such a fair reward sharing system. Finally, we designthe incentive-compatible reward sharing protocol that furtherimproves upon the fair sharing protocol by introducing ashard coordinator who can guide individual processors tofollow the optimal strategy (cooperate or defect), based ona preview of the shard’s consensus status in each epoch.Our numerical analysis show that the incentive-compatibleprotocol can outperform both the uniform and fair rewardsharing protocols. To the best of our knowledge, this paperis the first to investigate the selfish behavior of processors,and its effect, in shard-based permissionless blockchains.

The rest of the paper is organized as follows. In Section II,we discuss the state of the art and present a generic sys-tem model for shard-based blockchain protocols, consideringrational processors. In Section III, we present the gamemodel and investigate all possible Nash equilibria underdifferent reward sharing schemes. In Section IV, we describethe proposed incentive-compatible reward sharing protocol,followed by numerical evaluations presented in Section V.Related research efforts efforts have been outlined in Sec-tion VI. We conclude the paper in Section VII.

II. SYSTEM MODELIn this section, we first generically outline details of a shard-based approach for achieving consensus in permissionlessblockchains. Then, we formally outline the various costsinvolved for participating processors. Lastly, we clarify therationality assumptions related to the processors.

A. SHARD-BASED CONSENSUS PROTOCOLConsider a network of N processors participating in a publicpermissionless blockchain. Processors in such a networkdo not have an identity assigned by a trusted third-partyor a public-key infrastructure, i.e., they use self-generatedpseudonyms as transient identifiers. For simplifying the ex-position, we assume that all processors are similar to eachother in terms of computational capabilities. Further, we as-sume that all processors are honest, but selfish (more detailson this will follow in section II-C).

Let time be divided into fixed-sized epochs. The networkaccepts transactions in blocks, i.e., at the end of each epochthe network accepts and commits a new block of transactions.Any block B is composed of (or can be partitioned into)k disjoint sets of transactions Bi, where Bi can be empty.Each such disjoint set Bi is referred to as a shard and can bedefined based on some property(ies) of transactions withinthat set, for example, least significant bits of the transactionhash. The number of shards (k) is a variable quantity andcan grow linearly with the size of the network. The networkdetermines a binary validation function V , which takes as aninput a transaction (belonging to any shard) and any other

data representing the current state of the blockchain andoutputs whether the input transaction is valid or not, and allprocessors have access to such a function V .

Now, given the above, a sharding or shard-based protocolis a protocol which is run among the processors and whichoutputs (at the end of each epoch) a block B containing kdisjoint shards Bi such that all honest processors agree on Bwith a very high probability and all transactions within theblock B are valid (i.e., all transactions satisfy the validationfunction V ). The protocol does this by splitting the networkof processors into multiple disjoint committees, where eachcommittee processes (validates and agrees on) a separateshard (Bi). The main steps in the protocol execution duringeach epoch is illustrated in Figure 1. Below, we summarizethe main steps involved in sharding by outlining a classicalprotocol called Elastico [8]. Recent research efforts such asOmniledger [10] provide some enhancements and additionalfunctionalities to the original sharding proposal in Elastico,but the key idea of partitioning the transactions into disjointshards and assigning a committee of processors to processeach shard in parallel remains the same in all shard-basedprotocols.

A sharding protocol proceeds in epochs and in each epochthe processors execute the following steps (in this order) [8]:

1) Committee Formation: First, each processor attemptsto generate a publicly verifiable identity by solvingsome Proof-of-Work (PoW) puzzle. In other words,each processor uses the solution of a PoW hash puz-zle (i.e., the message digest that lies within the pre-determined target) as an identity in that epoch. Thereare two advantages of using a PoW puzzle for identitycreation: (i) network (other processors) can verify theidentity and, (ii) number of malicious sybils can belimited due to the computation involved in solving thepuzzle. Each processor is then assigned to a committeecorresponding to its established identity (say, using thes least significant bits of the identity). Moreover, eachcommittee processes a distinct shard based on this s-bitidentifier.

2) Overlay Setup: Next is the community discovery stepwhere processors discover identities of other proces-sors in their committee by communicating with eachother. The outcome of this step is a fully-connectedoverlay for each committee in the network.

3) Intra-Committee Consensus: Next, processors run astandard byzantine agreement protocol such as PBFT[12] within their committees to agree on a set oftransactions. Each committee then sends its consensusset of transactions Bi (or shard) to a final committeefor inclusion in the new block B at the end of currentepoch. In order to be considered by the final committee,each shard Bi needs to be signed by a simple majority,i.e., by at least c2 +1 processors for a committee of sizec.

4) Final Consensus: A final committee (chosen basedon a designated s-bit final committee identifier) then

VOLUME 0, 2018 3


Nodes

…

Network Blockchain

Committee 1

in

Shard 1

Committee i

in

Shard i

Committee to Shard Assignments Committee k

in

Shard k

BFT BFT

…

Master Chain

Node

Committee Leader

Block header

Block body (Verified TXs)

TXs

Final Committee

BFT BFT

Shard 1 Shard (k-1) Shard k

Committee 1 Committee i Committee kSte

p (

1),

(2

)S

tep

(3

)S

tep

(4

), (

5)

BFT

FIGURE 1: Conceptual view of a shard-based consensusprotocol.

takes the consensus shards (Bi) from the previous stepand merges these to create a final block B, creates acryptographic digest or hash of B and broadcasts it tothe rest of the network. During the merge operation,each processor in the final committee first validates thateach shard Bi is signed by at least c

2 + 1 processorsin the correct committee and then computes a unionof all the shards to form the block B. After eachprocessor in the final committee computes a unionin this fashion, they then collectively run a byzantineagreement protocol such as PBFT [12] to arrive ata consensus on the final block B. The cryptographicdigest of the final consensus blockB needs to be signedby a simple majority of the final committee before itcan be broadcast on the network.

5) Randomness Generation for Next Epoch: In the finalstep of the protocol, the final committee generates aset of random strings and broadcasts it to the network.These random strings are used by the processors in theidentity creation and committee formation tasks of the

next epoch.

B. PROCESSOR COSTSWe now characterize the costs (including, computation andcommunication costs) borne by the processors in each timeepoch due to their participation in the sharding protocol. Itshould be noted that our goal here is not to arrive at a precisequantification of these costs, rather to characterize them suchthat they could be used to analyze the strategic behavior ofprocessors while participating in the protocol. The protocolsteps in each epoch, as outlined in the previous section,can be basically grouped into two phases: (1) organizationphase and, (2) committee participation phase. During theorganization phase, the processors create identities usingPoW puzzles, form committees and identify other processorsin their committee (i.e., execute steps 1 and 2 in the protocolabove), whereas in the committee participation phase theprocessors validate their respective shards and arrive at anagreement with other committee members (i.e., execute steps3, 4 and 5 in the protocol above).

It should also be clear from the protocol description abovethat the organization phase precludes the committee par-ticipation phase, and it is required or mandatory. In otherwords, if a processor does not go through the organizationphase, it does not have an identity nor it gets assigned toa committee, and so it cannot take part in the committeeparticipation phase. Similarly, it should also be clear thatthe committee participation phase is not mandatory for pro-cessors, i.e., a processor could choose to create a verifiableidentity and be assigned to a committee, but may choosenot to participate in tasks such as shard validation and intra-committee consensus. If some processors do not take partin the committee participation phase, it does not mean thatthe protocol will fail. The inherent fault-tolerance of intra-committee consensus protocols such as PBFT and the simplemajority rule employed in intra-committee voting impliesthat a certain number of non-participation can be tolerated bythe protocol. For the sake of convenience, we assume that ifmore than half (> c

2 ) of the processors within a committee ofsize c do not participate in the committee participation phase,the entire protocol for that epoch fails, i.e., no new block isproposed in that epoch.

Thus, we can characterize the total cost for a processor toparticipate in an epoch of the sharding protocol based on thecost for executing the above two phases. For the organizationphase, let’s assume that a processor bears a cost cm, which werefer to as the mandatory cost. It should be noted that cm isa fixed cost and is independent of the number of transactionsprocessed by the processor. Moreover, as solving the PoWpuzzle is the most significant activity during the organizationphase, cm can be approximated using the current difficulty ofthe PoW puzzle and the average computational power of allthe processors.

Accordingly, for executing the committee participationphase let’s assume that a processor bears an optional costco, depending on whether the processor fully participates

4 VOLUME 0, 2018


in it or not. Unlike the mandatory cost, the optional costco has two components: (i) a fixed component and, (ii)a transaction-dependent component. During the committeeparticipation phase, a processor performs activities such asparticipation in intra-committee consensus the cost of whichcan be bounded by a fixed average cost [12]. We representall these per-processor fixed costs during the committeeparticipation phase as cf . Another activity during this phasethat all processors are expected to perform is verifying thevalidity of all outstanding transactions (they have received)within their respective shards by using the validation functionV . Depending on the complexity of the validation functionV , this can be a significant cost (to a processor) which alsodepends on the number of outstanding transactions beingvalidated. We represent the cost to validate each transactionusing V by cv . Hence, we can compute the total optional costcoi for a processor Pi as:

coi = cf + |xji |cv (1)

where xji is the vector of transactions received and validatedby processor Pi. The average per-processor cost (cti) forparticipation in each epoch of the shard-based protocol canthus be characterized as cti = cm + cf + |xji |cv .

One point that needs further clarification is why a proces-sor may choose not to execute the committee participationphase after executing the organization phase. Our rationalityassumption, which we describe next, provides this clarifica-tion.

C. RATIONALITY ASSUMPTIONEarlier research efforts on sharding [8], [10] have assumeda byzantine adversary where processors controlled by theadversary can be arbitrarily malicious, i.e., malicious proces-sors could arbitrarily deviate from the correct execution ofthe protocol or could arbitrarily drop protocol messages. Inthis work, however, we assume that processors are honest butselfish. In other words, processors do not arbitrarily deviatefrom protocol execution or drop protocol messages, but de-cide against participation in the protocol only when there isan incentive (financial or otherwise) to do so. Let us furtherprovide a brief intuition of the notion of rationality in thissetup. All processors receive some rewards if the protocolexecution in an epoch is successful, for example, in termsof block rewards, transaction fees, etc. The precise natureof rewards depend on the specific system or applicationthat the blockchain protocol enables. Moreover, as discussedin the earlier section, all processors bear some costs forfully participating in both phases of the protocol. The totalbenefit or payoff received by processors in each epoch is thedifference between the obtained reward and the spent costsin that epoch. A selfish (or rational) processor will alwayschoose a protocol participation strategy that improves itsbenefit or payoff. If a processor does not execute the orga-nization phase, it does not get any reward as it is not a partof any committee. However, a rational processor’s strategycould be to execute the organization phase but refrain from

TABLE 1: List of Symbols.

Symbol Definitionk Number of shards (or committees)N Number of processorsxji Vector of received transactions by processor i in shard jyj Vector of transactions submitted by shard j to Blockchainc Minimum number of processors in each committeeτ Required number of processors in shard for consensusr The benefit for each transactionbi Benefit of processor i after adding the blockcti Total cost of computation for processor ico Total optional costs in each epochcm Mandatory costs in each epoch to enter the shardcv Cost of transaction verificationcf Fixed costs in optional costBR Block Rewardlj Number of cooperative processors in each shardL Total number of cooperative processors in all shards

Cljj The set of all cooperative processors in shard j

Dn−ljj The set of all defective processors in shard j

CL The set of all cooperative processorsDN−L The set of all defective processors

the committee participation phase. Such a selfish strategysaves on the optional cost co and may result in a rewardif enough other processors participate fully, and thus mayprovide more benefit or payoff to the rational processor. Weassume that a rational processor will always choose such aselfish strategy which provides more benefit or payoff, if itexists. In summary, the goal of each processor is to maximizeits individual payoff (received at the end of each epoch),without maliciously trying to deviate or disrupt the protocol.We assume that processors do not collude/coordinate in orderto jointly maximize their combined utility.

III. SHARD-BASED BLOCKCHAIN GAMEIn this section, we present the game-theoretic aspects of ashard-based blockchain protocol with multiple processors ina honest but selfish environment. We first introduce a non-cooperative N -Player game model that we refer to as theshard-based blockchain game G. Upon starting an epocht, processors must decide whether to collaborate with eachother, verify transactions, and make a block to be appendedto the chain (i.e., take part in the community participationphase), after the organization phase as we addressed in theprevious section. The key point of the game-theoretic anal-ysis is to consider the computation costs for processors whoverify transactions and participate in consensus mechanism,as presented in Section II-B and II-C, and the total benefitswhen they agree on a valid block. Therefore, using a game-theoretic analysis, we investigate whether block generationcan emerge in such a non-cooperative system. By means ofour game model and the related analysis, we would like to

VOLUME 0, 2018 5


show that with a uniform distribution of rewards in theseprotocols, the interactions between processors fall in a cat-egory of games, where there exists a social dilemma of all-defection behavior. We then propose a novel reward sharingprotocol and address the conditions for having a new class ofequilibrium, where a subset of processors will be forced tocooperate. Table 1 summarizes the notation used throughoutthe paper.

A. GAME MODELGame theory allows for modeling situations of conflict andfor predicting the behavior of participants when they interactwith each other. In our shard-based blockchain game G, pro-cessors must decide upon joining the shards whether to coop-erate and contribute to optional costs (as addressed in SectionII-B) or not. We model the shard-based blockchain gameas a static game, because all processors must choose theirstrategy simultaneously, after they have joined the shards.This modeling decision also keeps our analysis tractable,while conforming to a simple model of processor rationality.The game G is defined as a triplet (P,S,U), where P isthe set of players, S is the set of strategies and U is theset of payoff values. We also assume that at any time epocht, a game is played among all the processors in all shards,because the benefits of successfully adding a block is sharedamong all processors.• Players (P): The set of players P = {Pi}Ni=1 cor-

responds to the set of processors who have already joinedshards in a given epoch time t. In fact, all N processorsmust have already performed PoW and paid the mandatorycosts cm. Considering the number of shards in our systemmodel, i.e., k, we conclude that each shard has n = N/kcommittee members. During this epoch time in our game, weassume that each processor Pi in shard j receives the vectorxji of transactions to verify and participate in the consensusalgorithm.

As it is shown in Figure 2, we also assume that to performa consensus algorithm in each shard we need at least τprocessors who agree on a given list of transactions. Forexample, in Elastico protocol which uses PBFT, τ is equalto 2

3n. Finally, yj , j ∈ {1, ..., k} represents the result ofthe consensus algorithm including the list of transactions thatwould be added to the blockchain by shard j.• Strategy (S): Each processor Pi can choose between

two moves si: (i) Cooperate C, or (ii) Defect D. Hence theset of strategies in this game is S = {C,D}. The strategyof processor Pi determines whether Pi participates in alloptional tasks presented in Section II or not. In particular,if processor Pi plays C, it will accept and verify all receivedtransactions. In this case, it also cooperates in all consensusalgorithms and incurs cost co for its participation. Contraryto a cooperative behavior, a given processor can refuse alltransaction verifications and simply do nothing during thecommunity participation phase (i.e., play D).• Payoff (U): Without loss of generality, we assume that

each transaction will make r benefits, for example in form

1 j k

𝜏𝜏𝜏

CCC

C or D C or D C or D

𝑦 𝑦 𝑦

nprocessors

Final Block

FIGURE 2: In each shard at least τ processors among n pro-cessors must be cooperative to perform consensus algorithm.Each Shard j submits the final yj vector of transactions tomake the final block.

of a transaction or some other fee (a similar model existsin Bitcoin and other popular cryptocurrencies). Hence, thetotal benefit that a given shard j can make from transactionsis bj = r|yj |, where yj is the set of verified, signed, andaccepted transactions by shard j. This benefit term r forthe network is some function of the average transaction feeincluded in the transactions and number of committee (shard)members that have processed the transaction. A precise quan-tification of r is not trivial and is considered out of scopeof this work. Finally, the total benefits that are made by alltransaction fees in the final appended block can be calculatedas TF = r

∑kj=1 |yj |.

Recall that the total cost of cooperation for processor Pi isequal to cti = cm+coi = cm+cf+|xji |cv if the processor actshonestly and follows the protocol. All processors should paythe mandatory costs, i.e., cm in order to be in a committee andfinally receive the reward. But they can avoid paying optionalcost co, including the cost of verifications. In summary, wecan divide processors into two groups of cooperative anddefective processors, based on whether they contribute tooptional tasks (i.e., play C and pay ct) or not (i.e., play Dand pay only cm). Let Cljj and Dn−ljj denote the sets of ljcooperating players and n − lj defecting players in a givenshard j with n processors. Recall that in order to obtain aconsensus transaction vector yj in a given shard j, |Cljj | mustbe greater than or equal to τ (|Cljj | ≥ τ ).

After executing the protocol and inserting the computedblock to the blockchain at the end of the epoch, we assumethat the system receives two rewards. This assumption ismotivated from the observation in current public blockchainapplications such as Bitcoin and Ethereum. The first rewardis a fixed reward for adding a new block, called the blockreward (BR). The current block reward for Bitcoin, forexample, is 12.5 BTC [13]. The second reward is the sum oftransaction fees which is equal to TF = r

∑kj=1 |yj |. Note

that all following analyses are based on the assumption thateach shard has already provided a non-empty yj . Due to lackof clarity in shard-based blockchain proposals [8]–[10], weassume that if one or more shards fail to provide a yj in an

6 VOLUME 0, 2018


epoch, the system cannot compute and append a new blockin that epoch.

If we assume that all processors receive an equal share ofprofits after block computation (i.e., the existing protocol),we can calculate the reward share for each processor as

BR+ r∑ki=1 |yj |

N.

In other words, all processors receive equal share of therewards from block reward and total transaction fees. Hence,we can compute the payoff of processor Pi in shard j by

uji (C) = bi−cti =BR+ r

∑kj=1 |yj |

N−(cm+cf + |xji |c

v),

(2)if we assume that the processor Pi was cooperative, i.e.

Pi ∈ Cljj . Similarly, if Pi is defective, i.e., Pi ∈ D

n−ljj , its

payoff would be:

uji (D) =BR+ r

∑kj=1 |yj |

N− cm. (3)

Considering the above calculated payoffs, we analyze thegame G next.

B. GAME ANALYSISIn order to get an insight into the strategic behavior of theprocessors, we apply the most fundamental game-theoreticconcept, named Nash equilibrium, introduced by John Nash[14]:

Definition 1. In a Nash equilibrium strategy profile, none ofthe players can unilaterally change his strategy to increasehis utility.

In other words, if in a non-cooperative game all strategiesare mutual best responses to each other, then no player hasany motivation to deviate unilaterally from the given strategyprofile. Nash also proved that any finite game has at leastone Nash equilibrium strategy profile. In non-cooperativegame theory, Prisoner’s dilemma or PD, discovered by Floodand Dresher in 1950 and later formalized by Tucker [15],is a classical 2-player game which shows why two rationalindividuals might not cooperate, even if it appears that thecooperative strategy is more beneficial for both of them (i.e.,Pareto Optimality). In PD, each individual has two strategiesof cooperation and defection, and the defection strategystrictly dominates the cooperation strategy. Hence, the onlyNash equilibrium in PD, is a mutual defection.

More than 20 years later, Hamburger defined the analogousN -player version of PD game in [16]. This extension is calledpublic good game (PGG). In a PGG setting, each individualcan cooperate and pay a contribution of α or defect and donot pay anything. Then all contributions would be summedand multiplied by a reward factor γ > 1. Finally, the totalreward would be distributed among all users equally, whetherthey have cooperated or defected. In other words, if n agents

out of N cooperate, their payoff would be γαnN − α and the

defectors’ payoff is γαnN . Indeed, the total payoff of all users

is maximized when everyone contributes to the public good.However, it has been proved that the Nash equilibrium in thisgame is defection by all users. A complete survey of PGGsand related results is available in [17].

Following our definition for shard-based blockchain gameG, we show in the following theorem that G is a PGG. Inother words, the system fails to make any new block andremain in the same state if all processors defect initially.

Theorem 1. In each epoch of a shard-based blockchaingame G with N processors, if rewards are equally sharedamong all processors, then G reduces to a public goodsgame.

Proof. Let us consider the strategy profile where all proces-sors defect and do not pay optional cost co after joining tothe shards. We call this strategy profile All −D. The payoffof each processor i would be then ui = −cm. In this case,none of the processors can unilaterally change his strategy toincrease its payoff. Because, the only cooperative processorcannot obtain any reward without the contribution of at leastτ − 1 other processors in its shard, as addresses in SectionII. In other words, the new payoff of each processor whodeviates would be−cm−cf−|xji |cv which is indeed smallerthan −cm. Hence, All − D is a Nash equilibrium profile inthis game and G is a PGG.

Theorem 2 further shows that we can never enforce an all-cooperation strategy (All − C) in the game G, as it is not aNash Equilibrium.

Theorem 2. In each epoch of a shard-based blockchaingame G with N processors, if rewards are equally sharedamong all processors, we cannot establish All-Cooperationstrategy profile as a Nash equilibrium.

Proof. We first assume that all N processors have alreadycooperated in transaction verifications (i.e., All−C strategyprofile) and payed the optional cost co. We can compute thepayoff of each processor Pi by Equation (2). Hence, if a givenprocessor deviates from the cooperation and play defectionunilaterally, its payoff would be equal to Equation (3), whichis always greater than cooperative payoffs at Equation (2).Hence, each user has incentive to deviate unilaterally andincreases its payoff. Then, theAll−C strategy profile is nevera Nash equilibrium.

Finally, Theorem 3 shows the conditions under whichwe can enforce an equilibrium in game G, where someprocessors cooperate.

Theorem 3. Let Cljj and Dn−ljj denote the sets of lj coop-erating processors and n − lj defecting processors insideeach shard j with n processors. If L =

∑kj=1 lj is the total

number of cooperative processors, (CL,DN−L) representsa Nash equilibrium profile in each epoch of the game G, if

VOLUME 0, 2018 7


and only if lj = τ in all shards j, where CL =⋃j C

ljj and

DN−L =⋃j D

n−ljj .

Proof. If in all shards, there exist exactly lj = τ cooper-ative processors, any cooperative processor cannot deviateunilaterally to increase its payoff. Because, the deviationwill remove yj transaction fees from the benefits and con-sequently its payoff would be decreased. In the worst case,the system could even potentially fail to add a new block tothe chain and all benefits would be zero. Moreover, similar toprevious cases, there is no incentive to deviate for defectiveprocessors, since they must pay an extra charge for theircooperation, while this will not change the result of theconsensus algorithm.

The above theorems prove that if rewards are uni-formly distributed among processors, a cooperative equilibriacannot be enforced in shard-based public permissionlessblockchains. Hence, in the following section we define anew reward sharing approach, which promotes cooperationamong processors by providing appropriate incentives.

C. FAIR REWARD SHARINGIn this section, we extend our game model to include a fairreward sharing approach, where each processor receives areward if and only if it has already cooperated with otherprocessors within the shard. Let’s call this new game GF ,in which the payoff of cooperative processors in set Clj is

uji (C) =BR

klj+r|yj |lj− (cm + cf + |xji |c

v), (4)

Recall that we assume lj ≥ τ for the consensus algorithmand each shard j will submit a non-empty yj set to theblockchain. Analysis of the case where the processors cannotmake a consensus on a given vector of transactions can beeasily extended from our model, by assigning BR and r avalue of zero (no benefits). As Equation (4) shows, we firstassume that the BR is uniformly distributed among shardsand each cooperative processor can receive a share of it.Moreover, each shard j receives all fees for all transactionsthat it has submitted to the blockchain. Then, in each shardthis reward is uniformly distributed among all cooperativeprocessors. It is worth mentioning that |xji | may not alwaysbe equal to |yj |. It means that a processor Pi might becooperative but finally all other processors may agree ona vector of transactions yj that is different from xji . Thus,contrary to the standard shard-based protocols, in GF thedefective processors’ payoff can be calculated as

uDi = −cm, (5)

because the defective processors will not receive any benefit.It is easy to show that the conditions of Theorem 1 still holdin the new game GF and the game GF is PGG. However, wecan show that in this newly defined game G, it is easier toenforce users to cooperate at a Nash equilibrium profile. Wederive the conditions under which there exists a cooperative

Nash equilibrium profile in game GF , with the followingtheorem.

Theorem 4. Let Cljj and Dn−ljj denote the sets of lj coop-erating processors and n − lj defecting processors insideeach shard j with n processors, respectively. (CL,DN−L)represents a Nash equilibrium profile in each epoch of gameGF , if the following conditions are satisfied:

1) In all shards j, lj ≥ τ .2) If for a given processor Pi in shard j, xji = yj , then

the number of transactions |xji | must be greater than

θ1c =cf−BR

klj

r/lj−cv

3) If for a given processor Pi in shard j, xji 6= yj , thenthe number of transactions |xji | must be smaller than

θ2c =BRklj

+r|yj |lj−cf

cv .

Proof. The number of cooperative processors must be greaterthat the consensus threshold τ , otherwise the cooperativeprocessors will not receive any transaction and block rewardbenefits for their cooperation. Hence, they can increase theirpayoff by unilaterally deviating from cooperative strategy.

We now find the largest group of cooperative processors ljin each shard, where no processor in Dn−ljj can join Cljj toincrease its payoff. Let’s assume that l∗j is this largest set ofprocessors. If processor P ji is among the set of cooperativeprocessors, then it will not unilaterally deviate if its payoff(calculated by Equation (4)) is greater than −cm. Two possi-ble cases could happen in this case. First, P ji could be amongprocessors who have the same vector of transactions as theoutput of the shard, i.e., xji = yj . In this case, P ji will notdeviate from cooperation if:

BR

klj+r|xji |lj− (cm + cf + |xji |c

v) ≥ −cm, (6)

which shows that xji ≥ θ1c , where

θ1c =cf − BR

klj

r/lj − cv.

In the second case, processor P ji have cooperated withothers in Cljj , but its vector of transactions is different fromthe output of the shard, i.e., xji 6= yj . Hence, the followingcondition must be satisfy if this user wants to remain in thecooperative set.

BR

klj+r|yj |lj− (cm + cf + |xji |c

v) ≥ −cm, (7)

which shows that xji < θ2c , where

θ2c =

BRklj

+ r|yj |lj− cf

cv.

If l∗j represents the largest set of cooperative processors ineach shard, then (CL,DN−L) would be the unique coopera-tive Nash equilibrium of the game GF . Please note that this

8 VOLUME 0, 2018


NE is a unique cooperative equilibrium of the game, as wehave already found the largest set of cooperative processorsin all shards.

Note that by increasing the optional costs of computation(whether cf is in the numerator or cv in denominator of θC)and for any given number of transactions |xji |, processors willbe tempted to be more defective as the threshold θ1c will beincreased. This is in line with our intuition that processorsare not cooperative if the cost of cooperation is high. Onthe other hand, the calculated threshold shows that by in-creasing the number of processors N and consequently thenumber of shards k, the processors would be more defective.This is representing the case where the processors will notcooperate in the hope that other processors will participatein the transaction verifications and other optional tasks inthe defined protocol. Moreover, as the reward is smaller, theprocessor must obtain more benefits from the transactionfees to have positive payoff. In other words, cooperativeprocessors have less incentives to cooperate, because thenumber of participants is more and they will receive smallerreward.

Recall that the game GF is still a social dilemma game, butwith the new reward distribution approach we can provideenough incentives to enable processor cooperation. Our re-sults in this section showed that a shard-based permissionlessblockchain protocol could be potentially a PGG and pro-cessors could remain in All − D equilibrium without anyreward. We also showed that the cooperation can be enforcedunder some conditions where the number of transactions arelarge enough for the processors. Next we apply the resultsfrom Theorem 4 to design an incentive-compatible shardingprotocol for public permissionless blockchain.

IV. INCENTIVE-COMPATIBLE REWARD SHARINGAs discussed earlier, in any shard-based protocol, processorsmay not have enough incentives to cooperate and verifytransactions, which leads them to a social-dilemma. In otherwords, the decision of each processor (to cooperate or defect)exclusively depends on the number of received transactionscompared to a fixed threshold. Our game-theoretic evaluationallows us to design a more sophisticated protocol - theincentive-compatible reward sharing - that extends currentshard-based protocols by considering optimal strategies ofprocessors and enforcing cooperation in these protocols. Theincentive-compatible reward sharing protocol is based on ourresults for fair reward distributions presented in Section III.

Algorithm 1 outlines the main steps of our proposedprotocol. Comparing to the standard shard-based protocols,the main difference of our proposed incentive-compatibleprotocol is that we first announce to processors whetherthe cooperation would be in their interests. The protocolproceeds as follows. The processors first try to solve the PoWpuzzle and obtain an ID to participate in a committee. Aftercommittee formation and assignment, each processor Pi inshard j receives a list of xji transactions to verify.

Algorithm 1 Incentive-Compatible Protocolprocedure INITIALIZATION AND COMMITTEE CREATION

ID, Shard← ComputeID(epochRandomness, IP, PK)xi ← ShardTransactions(Shard)

end procedure5: procedure COOPERAIVE/DEFECTIVE NODE SELECTION

Pi sends H(xji ) to Coordinatorif Coordinator then

Receive H(xji )slj ←Maximum number of processors with

10: common transactionsif lj < τ then

return All −Delse

Prepare the list of lj processors Cljj15: Calculate θ1c and θ2c from Theorem 4

return θ1c , θ2c , and Cljjend if

end ifend procedure

20: procedure SHARD PARTICIPATION (CONSENSUS)if Pi ∈ C

ljj and |xji | ≤ θ

1c then

return Defectelse if Pi /∈ C

ljj and |xji | ≥ θ

2c then

return Defect25: end if

Verify transactions and create a set of verified transactions yj by allremaining cooperative processors

Consensus on verified transactionsSign BFT agreement resultreturn Signature, Agreed block’s header

30: end procedureprocedure VERIFICATION, REWARD, AND PUNISHMENT

Verify whether Pi ∈ CL have cooperated in each shardDistribute rewards among cooperative Pi according toEquation (4)

35: end procedure

At this stage, all processors calculate the H(xji ) andsubmit it to a coordinator, where H is a predefined hashfunction. Note that the coordinator could be potentially oneof the processors that has been selected randomly in eachshard. This coordinator could be a centralized trusted thirdparty as well, as it does not receive any sensitive information.The coordinator then finds the maximum subset of processorswith similar H(xji ). This will estimate lj and Cljj , which willbe then used to calculate the θ1c and θ2c .

As described in Algorithm 1, the incentive-compatibleprotocol assists processors in selecting the optimal strategyin a given epoch. We assume that the set of cooperativeprocessors Cljj and the set of defective processors Dn−ljj arepublicly announced in each shard. In each epoch, the protocoldefines publicly which rational processor must cooperate ordefect, by considering the number of received transactionsby all processors and based on the results in Theorem 4. Atthe end of committee participation phase, it is easy to verifyif a given processor Pi has already followed the recommen-dations by the incentive-compatible protocol or they havedeviated from the defined strategies. In case a processor inCljj has not cooperated in this phase, the incentive-compatibleprotocol will not give this processor any reward at the end ofthis epoch. This is also a novel punishment approach that hasbeen added to our proposed protocol compared to previous

VOLUME 0, 2018 9


ones.

V. NUMERICAL ANALYSISWe conduct a comprehensive set of numerical simulations,in order to validate how our proposed incentive-compatibleprotocol compares with uniform and fair reward sharing pro-tocols in shard-based blockchains. We first detail the experi-mental setup used to simulate a basic shard-based blockchainin Section V-A. Variants of the simulation were used toanalyze multiple parameters that may affect the strategy ofindividual processors, and thereby its effect on the successfuloperation of the blockchain network.

A. EXPERIMENTAL SETUPWe simulate a shard-based public permissionless blockchainwith approximately N (±1%) processors that are selfishlyfollowing a protocol to reach consensus in each shard, thencombine all shards to add the next block, and finally collecttheir reward at the end of each epoch. We assume committeesof size 100 (±1%), and the required number of processors ineach shard for consensus is τ ≈ 51. Also, the number ofcommittees (and shards) grow linearly w.r.t. the number ofprocessors in the network (k ≈ N

100 ). Each processor in thenetwork is assumed to receive |xji | ≈ |yj | (±1%) transac-tions corresponding to the shard it belongs to. As imperfectviews of the network is common occurrence in real-worldnetworks, we also assume that the number of processors withxji 6= yj is approximately 15%. We present mean resultsof 100 iterations for each combination of parameters (inFigures 3-6), i.e., every point in the graphs was obtained afteraveraging the results of 100 independent epochs with thatparticular set of parameters.

B. NUMBER OF TRANSACTIONSWe first analyze the effect of varying the average number oftransactions |xji | between 500 and 15000. The correspondingratios of cooperative and defective processors is plotted inFigure 3. As intuitive, the uniform reward sharing results inall defect (Figure 3a), and thus no block is ever added to theblockchain. In case of fair and incentive-compatible rewardsharing protocols (Figure 3b and 3c, respectively) we observethat processors opt for all defect strategy when the numberof transactions is low, but eventually change their strategyto cooperate as the number of transactions gets high enoughto make a profit. More importantly, the proposed incentive-compatible reward sharing protocol achieves a majority ofcooperative processors for lesser number of transaction thanin the case of fair sharing, which is favorable.

C. BLOCK REWARDWe next analyze the effect of varying the block reward BRbetween 1000 and 7000, and the corresponding ratios ofcooperative and defective processors is plotted in Figure 4.As before, the uniform reward sharing results in all defect(Figure 4a), regardless of the value of the block reward.In case of fair and incentive-compatible reward sharing

protocols (Figure 4b and 4c, respectively) we observe thatprocessors opt for all defect strategy when the block rewardis low, but eventually change their strategy to cooperate asthe block reward gets high enough to make a profit. Again,the proposed incentive-compatible reward sharing protocolachieves a majority of cooperative processors for lesser val-ued block reward than in the case of fair sharing, which isfavorable.

D. SIZE OF THE NETWORK

The number of processors in the network in a given epoch canvastly impact the strategy for individual processors, becauseif a small reward is shared between a large number of cooper-ative processors, it may not cover other costs associated withparticipation (such as cf ). We observe this intuition in effectin Figure 5, where N is varied between 100 and 6000. Boththe proposed incentive-compatible and fair reward sharingprotocols lose majority of cooperative processors when Nis increased significantly. However, the proposed incentive-compatible reward sharing protocol retains a majority ofcooperative processors for greater number of processors thanin the case of fair sharing, which is desirable. As before,the uniform reward sharing results in all defect (Figure 5a),regardless of the number of processors.

In order to better understand why cooperative processorsflip to being defective, we also plotted the correspondingweighted utility of processors in Figure 6. In case of bothfair and incentive-compatible protocols, the average utilitydrops significantly with increasing number of processors.The average utility gradually converges at about−cm (whichis −10 in our simulation). As utility by cooperation dropsbelow −cm, processors flip to being defective and incur only−cm. Also, in uniform reward sharing we see a constant−cmutility for all (defective) processors.

E. DISCUSSION AND LIMITATIONS

Our goal in this work was to design practical incentive mech-anisms for eliciting cooperation in shard-based blockchains.The above analytical and empirical results shows how ourproposed reward sharing mechanism promotes cooperation inshard-based blockchains, and thwarts free-riding processors.Nonetheless, there exists certain limitations in the proposedmechanism, discussed below, some of which we plan toaddress in the future.Inter-Shard Communication. Due to the lack of commu-nication between committees, cooperative processors in ashard where consensus is reached, can suffer when anothercommittee fails to reach consensus (because no block isadded to the blockchain if one or more shards fail). This canbe resolved if an inter-shard communication is established inAlgorithm 1, wherein coordinators can exchange consensusstatus and inform potentially cooperative processors aboutthe state of consensus in other shards as well. We plan toinclude inter-shard communication in our future work, andanalyze how the game changes due to it.

10 VOLUME 0, 2018


-0.1

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1.1

0 2500 5000 7500 10000 12500 15000

Rat

io o

f C

oo

per

ativ

e an

d

Def

ecti

ve

No

des

C

D

𝒚𝒋

(a) Uniform

-0.1

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1.1

0 2500 5000 7500 10000 12500 15000

Rat

io o

f C

oo

per

ativ

e an

d

Def

ecti

ve

No

des

C

D

𝒚𝒋

(b) Fair

-0.1

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1.1

0 2500 5000 7500 10000 12500 15000

Rat

io o

f C

oo

per

ativ

e an

d

Def

ecti

ve

No

des

C

D

𝒚𝒋

(c) Incentive-Compatible

𝑩𝑹 1000

𝒄𝒎 10

𝒄𝒇 6

𝒄𝒗 0.0005

𝒓 0.1

𝑷(𝒙𝒊𝒋≠ 𝒚𝒋) 15%

𝑵 ≈ 3000

𝒏 ≈ 100

𝒚𝒋 ≈ 500-15000

(d) Simulation Parameters

FIGURE 3: Ratio of cooperative and defective processors for different sizes of yj .

-0.1

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1.1

1000 3000 5000 7000

Rat

io o

f C

oo

per

ativ

e an

d

Def

ecti

ve

No

des

Block Reward (BR)

C

D

(a) Uniform

-0.1

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1.1

1000 3000 5000 7000

Rat

io o

f C

oo

per

ativ

e an

d

Def

ecti

ve

No

des

Block Reward (BR)

C

D

(b) Fair

-0.1

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1.1

1000 3000 5000 7000

Rat

io o

f C

oo

per

ativ

e an

d

Def

ecti

ve

No

des

Block Reward (BR)

C

D


𝑩𝑹 1000-7000

𝒄𝒎 10

𝒄𝒇 6

𝒄𝒗 0.001

𝒓 0.1


𝑵 ≈ 1000

𝒏 ≈ 100

𝒚𝒋 ≈ 10000


FIGURE 4: Ratio of cooperative and defective processors for different values of BR.

-0.1

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1.1

0 2000 4000 6000

Rat

io o

f C

oo

per

ativ

e an

d

Def

ecti

ve

No

des

Number of Processors (N)

C

D

(a) Uniform

-0.1

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1.1

0 2000 4000 6000

Rat

io o

f C

oo

per

ativ

e an

d

Def

ecti

ve

No

des


C

D

(b) Fair

-0.1

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1.1

0 2000 4000 6000

Rat

io o

f C

oo

per

ativ

e an

d

Def

ecti

ve

No

des


C

D


𝑩𝑹 10000

𝒄𝒎 10

𝒄𝒇 6

𝒄𝒗 0.001

𝒓 0.1


𝑵 ≈ 100-6000

𝒏 ≈ 100

𝒚𝒋 ≈ 10000


FIGURE 5: Ratio of cooperative and defective processors for different values of N .

Inclusion of Malicious Processors. In this work we consideronly honest but greedy (or selfish) processors (each trying tomaximize its utility) who would follow the instructions of acoordinator. However in real-world, malicious processor(s)may also exist whose sole objective may be to disrupt theblockchain network. Such malicious processors may misbe-have at various stages of the protocol, such as reporting falseH(xji ) or not following coordinator’s instruction to cooperate(or defect). As part of our future work, we plan to includemalicious processors in the game and re-analyze the game.

Parametric Values. The parametric values chosen for ournumerical analysis was primarily to showcase the trendsobservable across the three different reward sharing mech-anisms. They may or may not be reflective of values in areal shard-based blockchain network, but we did our best toestablish the inequalities between parameters as completelyas possible.

VI. RELATED WORK

In this section, we briefly outline the efforts in the literaturetowards improving the scalability and transaction rate ofconsensus protocols in public permissionless blockchains.For an exhaustive survey of blockchain consensus protocolsin the literature, readers are referred to [18]. The originalNakamoto consensus protocol [1] of Bitcoin which em-ployed a leader selection using PoW puzzles (to commit thenext block) suffered from poor scalability and transactionthroughput. Bitcoin-NG [6] attempted to improve Bitcoin’sperformance by employing microblocks. In Bitcoin-NG, sim-ilar to Bitcoin, a leader is selected using PoW in each epoch.However, unlike Bitcoin, the leader can continue to appendmicroblocks (containing transactions) to the blockchain forthe duration of its epoch, until a new leader is elected.

As leader or single node based (implicit) consensus al-gorithms such as Nakamoto consensus and Bitcoin-NG stillsuffer from poor performance, fault-tolerance and consis-tency issues, the community’s focus shifted on designingblockchain consensus protocols using a committee of nodes,

VOLUME 0, 2018 11


-20

0

20

40

60

80

100

120

0 2000 4000 6000

Wei

gh

ted

Av

erag

e U

tili

ty


C

D

(a) Uniform

-20

0

20

40

60

80

100

120

0 2000 4000 6000

Wei

gh

ted

Av

erag

e U

tili

ty


C

D

(b) Fair

-20

0

20

40

60

80

100

120

0 2000 4000 6000

Wei

gh

ted

Av

erag

e U

tili

ty


C

D


𝑩𝑹 10000

𝒄𝒎 10

𝒄𝒇 6

𝒄𝒗 0.001

𝒓 0.1


𝑵 ≈ 100-6000

𝒏 ≈ 100

𝒚𝒋 ≈ 10000


FIGURE 6: Weighted average utility of cooperative and defective processors for different values of N .

rather than a single node (or leader). While committee-based consensus algorithms were introduced more than twodecades ago [19], much recently Decker et al. [20] proposedone of the first committee-based consensus protocols for pub-lic blockchains, named PeerCensus. However, PeerCensusdid not clarify how committee formation is done and howan honest majority can be ensured within the committee.Follow up works [21]–[24] in similar direction improvedthe practicality of such single committee-based consensusprotocols by proposing different strategies on how unbiasedcommittees can be formed.

Although single committee consensus algorithms providesignificantly improved performance compared to single nodeor leader-based consensus algorithms, one major limitationof such techniques is that they do not scale well. Moreover,increasing committee size in such techniques comes at theexpense of a decreased throughput. This motivated the designof blockchain consensus protocols that employ multiple com-mittees. The main idea in these protocols is to split the trans-actions among multiple committees (or shards), which thenprocess these shards or set of transactions in parallel. Thisalso improves the overall scalability of the system. RSCoin[25] was proposed as a shard-based blockchain technique forcentrally-banked cryptocurrencies, while Elastico [8] was thefirst shard-based consensus protocol for public blockchains.Omniledger [10] and Rapidchain [9] are some of the recentlyproposed shard-based public blockchain protocols that at-tempt to address the scalability and security issues of Elas-tico. Despite the recent interest in shard-based protocols forimproving transaction throughput and scalability in publicblockchains, there have been no prior efforts in the literature,until this one, that study the rational behavior of processorsor miners in such a multiple committee approach.

VII. CONCLUSIONS

In this paper, we comprehensively studied the problem ofselfishness in shard-based permissionless blockchains. Wefirst introduced a system model to capture the main opera-tional parameters in current shard-based blockchain proto-cols. Next, we evaluated the strategic behavior of processorsin such protocols by employing concepts from game theory.Specifically, we modeled shard-based blockchain protocolsas n-player non-cooperative games using different reward

sharing scenarios and obtain the Nash equilibria (NE) strat-egy profile for each scenario. Based on our analytical resultsunder different reward sharing scenarios, we designed anincentive mechanism for shard-based blockchain protocolswhich would enforce cooperation among processors by guar-anteeing optimal incentive distribution. Our numerical anal-ysis also validated that the proposed reward sharing mecha-nism outperforms uniform reward sharing and provides moreincentive for cooperation when the block reward or numberof transactions is small. This work is the first step towards adeeper understanding of the effect of non-cooperative behav-ior in shard-based blockchains.

REFERENCES[1] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” bit-

coin.org, 2009.[2] “All Cryptocurrencies.” https://coinmarketcap.com/all/views/all/, July

2018.[3] “Ethereum project.” https://ethereum.org/, July 2018.[4] “Scalability - Bitcoin Wiki.” https://en.bitcoin.it/wiki/Scalability/, July

2018.[5] J. Garzik, “Bitcoin Improvement Proposal 102.” https://github.com/

bitcoin/bips/blob/master/bip-0102.mediawiki, 2015.[6] I. Eyal, A. E. Gencer, E. G. Sirer, and R. Van Renesse, “Bitcoin-ng: A

scalable blockchain protocol.,” in NSDI, pp. 45–59, 2016.[7] “The Raiden Network.” https://raiden.network/, July 2018.[8] L. Luu, V. Narayanan, C. Zheng, K. Baweja, S. Gilbert, and P. Saxena, “A

secure sharding protocol for open blockchains,” in Proceedings of the 2016ACM SIGSAC Conference on Computer and Communications Security,pp. 17–30, ACM, 2016.

[9] M. Zamani, M. Movahedi, and M. Raykova, “RapidChain: A FastBlockchain Protocol via Full Sharding.” Cryptology ePrint Archive, Re-port 2018/460, 2018. https://eprint.iacr.org/2018/460.

[10] E. Kokoris-Kogias, P. Jovanovic, L. Gasser, N. Gailly, E. Syta, and B. Ford,“Omniledger: A secure, scale-out, decentralized ledger via sharding,” in2018 IEEE Symposium on Security and Privacy (SP), pp. 19–34, 2018.

[11] M. Castro and B. Liskov, “Practical byzantine fault tolerance and proactiverecovery,” ACM Trans. Comput. Syst., 2002.

[12] M. Castro, B. Liskov, et al., “Practical byzantine fault tolerance,” in OSDI,vol. 99, pp. 173–186, 1999.

[13] “Blockchain explorer.” https://www.blockchain.com/explorer, July 2018.[14] J. Nash, “Non-Cooperative Games,” Annals of Mathematics, 1951.[15] A. Tucker, “A Two-Person Dilemma,” Rasmusen, E., Readings in Games

and Information, pp. 7–8, 1950.[16] H. Hamburger, “N-Person Prisoner’s Dilemma,” Journal of Mathematical

Sociology, vol. 3, no. 1, pp. 27–48, 1973.[17] M. Archetti and I. Scheuring, “Game Theory of Public Goods in One-Shot

Social Dilemmas Without Assortment,” Journal of theoretical biology,vol. 299, pp. 9–20, 2012.

[18] S. Bano, A. Sonnino, M. Al-Bassam, S. Azouvi, P. McCorry, S. Meik-lejohn, and G. Danezis, “Consensus in the age of blockchains,” CoRR,vol. abs/1711.03936, 2017.

12 VOLUME 0, 2018


[19] G. Bracha, “An o (log n) expected rounds randomized byzantine generalsprotocol,” Journal of the ACM (JACM), vol. 34, no. 4, 1987.

[20] C. Decker, J. Seidel, and R. Wattenhofer, “Bitcoin meets strong consis-tency,” in Proceedings of the 17th International Conference on DistributedComputing and Networking, p. 13, ACM, 2016.

[21] I. Abraham, D. Malkhi, K. Nayak, L. Ren, and A. Spiegelman, “Solida: Ablockchain protocol based on reconfigurable byzantine consensus,” CoRR,vol. abs/1612.02916, 2017.

[22] R. Pass and E. Shi, “Hybrid consensus: Efficient consensus in the permis-sionless model,” in LIPIcs-Leibniz International Proceedings in Informat-ics, 2017.

[23] E. K. Kogias, P. Jovanovic, N. Gailly, I. Khoffi, L. Gasser, and B. Ford,“Enhancing bitcoin security and performance with strong consistencyvia collective signing,” in 25th USENIX Security Symposium (USENIXSecurity 16), pp. 279–296, 2016.

[24] Y. Gilad, R. Hemo, S. Micali, G. Vlachos, and N. Zeldovich, “Algorand:Scaling byzantine agreements for cryptocurrencies,” in Proceedings of the26th Symposium on Operating Systems Principles, 2017.

[25] G. Danezis and S. Meiklejohn, “Centrally banked cryptocurrencies,”CoRR, vol. abs/1505.06895, 2015.

MOHAMMAD HOSSEIN MANSHAEI receivedthe BSc degree in electrical engineering and theMSc degree in communication engineering fromthe Isfahan University of Technology in 1997 and2000, respectively. He received another MSc de-gree in computer science and the PhD degree incomputer science and distributed systems fromthe University of Nice Sophia-Antipolis, France,in 2002 and 2005, respectively. He did his thesiswork at INRIA, Sophia-Antipolis, France. He is

currently an Associate Professor at the Isfahan University of Technology,Iran. From 2006 to 2011, he was a senior researcher and lecturer at theSwiss Federal Institute of Technology in Lausanne (EPFL). He held visitingpositions at the UNCC, the NYU, the VTech, and the UTSA. His researchinterests include wireless networking, wireless security and privacy, compu-tational biology, and game theory.

MURTUZA JADLIWALA is currently an Assis-tant Professor in the Department of ComputerScience at the University of Texas at San Antonio,USA. Prior to that, he was an Assistant Professorin the Department of Electrical Engineering andComputer Science at the Wichita State Univer-sity, USA from 2012-2017 and a Post-doctoralResearch Fellow in the Department of Computerand Communication Sciences at the Swiss FederalInstitute of Technology in Lausanne (EPFL) from

2008-2011. He also served as a Summer Faculty Fellow at the US Air ForceResearch Lab - Information Institute in Rome, NY, USA from June-August2015. His educational background includes a Bachelors degree in ComputerEngineering from Mumbai University, India and a Doctorate degree inComputer Science from the State University of New York at Buffalo, USA.His current research is focused towards overcoming security and privacythreats in networked computer and cyber-physical systems.

ANINDYA MAITI is a Postdoctoral Fellow at theUniversity of Texas at San Antonio, USA. His cur-rent research is primarily focused towards uncov-ering and solving privacy and security problems insmart home and other IoT devices. Previously, heobtained a PhD degree in Electrical Engineeringand Computer Science, and a MS degree in Elec-trical Engineering, from Wichita State University,USA.

MAHDI FOOLADGAR is currently M.S. studentin software engineering at the Isfahan Univer-sity of Technology, Department of Electrical andComputer engineering, working under the super-vision of Dr. Manshaei. He also accomplished hisB.S. in Software engineering at IUT, working onBlockchain based voting protocols. His currentresearch interests include Blockchain, Game The-ory, and Security Protocols.

VOLUME 0, 2018 13

Documents

Authors’ copy downloaded from: //sprite.utsa.edu/publications/articles/manshaeiAccess18.pdfthat can host and execute arbitrary distributed applications (commonly referred to as “smart