Denial-of-Service Vulnerability of Hash-based Transaction Sharding: Attacks and Countermeasures
DDenial-of-Service Vulnerability of Hash-basedTransaction Sharding: Attacks and Countermeasures
Truc Nguyen
CISE DepartmentUniversity of FloridaGainesville, FL, 32611Email: truc.nguyen@ufl.edu
My T. Thai
CISE DepartmentUniversity of FloridaGainesville, FL, 32611Email: [email protected]fl.edu
Abstract —Since 2016, sharding has become an auspicioussolution to tackle the scalability issue in legacy blockchainsystems. Despite its potential to strongly boost the blockchainthroughput, sharding comes with its own security issues. Toease the process of deciding which shard to place transactions,existing sharding protocols use a hash-based transaction shardingin which the hash value of a transaction determines its outputshard. Unfortunately, we show that this mechanism opens up aloophole that could be exploited to conduct a single-shard floodingattack, a type of Denial-of-Service (DoS) attack, to overwhelm asingle shard that ends up reducing the performance of the systemas a whole.To counter the single-shard flooding attack, we proposea countermeasure that essentially eliminates the loophole byrejecting the use of hash-based transaction sharding. The counter-measure leverages the Trusted Execution Environment (TEE) tolet blockchain’s validators securely execute a transaction shardingalgorithm with a negligible overhead. We provide a formal specifi-cation for the countermeasure and analyze its security propertiesin the Universal Composability (UC) framework. Finally, aproof-of-concept is developed to demonstrate the feasibility andpracticality of our solution.
I. I
NTRODUCTION
Sharding, an auspicious solution to tackle the scalabilityissue of blockchain, has become one of the most trendingresearch topics and been intensively studied in recent years[1]–[5]. In the context of blockchain, sharding is the approachof partitioning the set of nodes (or validators) into multiplesmaller groups of nodes, called shard, that operate in par-allel on disjoint sets of transactions and maintain disjointledgers. By parallelizing the consensus work and storage,sharding reduces drastically the storage, computation, andcommunication costs that are placed on a single node, therebyscaling the system throughput proportionally to the number ofshards. Previous studies [2], [3], [5] show that sharding couldpotentially improve blockchain’s throughput to thousands oftransactions per second (whereas current Bitcoin system onlyhandles up to 7 transactions per second and requires 60 minutesconfirmation time for each transaction).Despite the incredible results in improving the scalability,blockchain sharding is still vulnerable to some severe securityproblems. The root of those problems is that, with partitioning,the honest majority of mining power or stake share is dispersedinto individual shards. This significantly reduces the size ofhonest majority in each shard, which in turn dramatically lowering the attack bar on a specific shard. Hence, a blockchainsharding system must have some mechanisms to prevent adver-saries from gaining the majority of validators of a single shard,this is commonly referred as single-shard takeover attack [6].In this paper, we take a novel approach by exploitingthe inter-shard consensus to identify a new vulnerability ofblockchain sharding. One intrinsic attribute of blockchainsharding is the existence of cross-shard transactions that,simply speaking, are transactions that involve multiple shards.These transactions require the involved shards to performan inter-shard consensus mechanism to confirm the validity.Hence, intuitively, if we could perform a Denial-of-Server(DoS) attack to one shard, it would also affect the performanceof other shards via the cross-shard transactions. Furthermore,both theoretical and empirical analysis [2], [5] show that mostexisting sharding protocols have 99% cross-shard transactions.This implies that attack on one shard could potentially impactthe performance of the entire blockchain. In addition, withthis type of attacks, the attacker is a client of the blockchainsystem, hence, this attack can be conducted even when we canguarantee the honest majority in every shard.Although existing work does have some variants of flood-ing attack that try to overwhelm the entire blockchain byhaving the attacker generate a superfluous amount of dusttransactions, however, it is unclear how we could conduct thisattack in a sharding system. In fact, we emphasize that a con-ventional transactions flooding attack on the entire blockchain(as opposed to a single shard) would not be effective for tworeasons. First, blockchain sharding has high throughput, hence,the cost of attack would be enormous to generate a hugeamount of dust transactions that is sufficiently much greaterthan the system throughput. Second, and more importantly,since the sharding system scales with the number of shards,it can easily tolerate such attacks by adding more shards toincrease throughput.To bridge this gap, we propose a single-shard floodingattack to exploit the DoS vulnerability of blockchain sharding.Instead of overwhelming the entire blockchain, an attackerwould strategically place a tremendous amount of transactionsinto one single shard in order to reduce the performance ofthat shard, as the throughput of one shard is not scalable.The essence of our attack comes from the fact that mostsharding proposals use hash-based transaction sharding [1]–[3]: a transaction’s hash value is used to determine whichshard to place the transaction (i.e., output shard). Since that a r X i v : . [ c s . CR ] J u l ash value (e.g., SHA-256) of a transaction is indistinguishablefrom that of a random function, this mechanism can efficientlydistribute the transactions evenly among the shards and thuswidely adopted. Therefore, an attacker can manipulate the hashto generate an excessive amount of transactions to one shard.As we argue that using hash values to determine theoutput shard is not secure, we propose a countermeasure toefficiently eliminate the attack for the sharding system. Bynot using the transaction’s hash value or any other attributesof the transaction, we can delegate the task of determiningthe output shard to the validators, then the adversary cannotcarry out this DoS attack. However, this raises two mainchallenges: (1) what basis can be used to determine the outputshard of a transaction, and (2) how honest validators canagree on the output of (1). For the first challenge, we need a transaction sharding algorithm to decide the output shard foreach transaction. OptChain [5] is an example algorithm whereit aims to minimize the number of cross-shard transactionand also balance the load among the shard. For the secondchallenge, a naive solution is to have the validators reachon-chain consensus on the output shard of every transaction.However, that would be very costly and reject the main conceptof sharding, that is, each validator only processes a subset oftransactions to parallelize the consensus work and storage.To overcome the aforementioned challenge, we establisha system for executing the transaction sharding algorithmoff-chain and attesting the correctness of the execution. Asblockchain validators are untrusted, we need to guaranteethat the execution of the transaction sharding algorithm istamper-proof. To accomplish this, we leverage the TrustedExecution Environment (TEE) to isolate the execution of thealgorithm inside a TEE module, shielding it from potentiallymalicious hosts. With this approach, we are not imposing anysignificant on-chain computation overhead as compared to thehash-based transaction sharding and also maintain the securityproperties of blockchain. Moreover, this solution can be easilyintegrated into existing blockchain sharding proposals, and asmodern Intel CPUs from 2014 support TEE, the proposedcountermeasure is compatible with current blockchain systems. Contribution.
Our main contributions are as follows: • We identify a new attack on blockchain sharding thatexploits the loophole of using hash-based transactionsharing, namely single-shard flooding attack. • To evaluate the potential impact of this attack onthe blockchain system, we develop a discrete-eventsimulator for blockchain sharding that can be usedto observe how sharding performance changes whenthe system is under attacked. Not only for our attackanalysis purposes, this simulator can also assist theresearch community in evaluating the performance ofa sharding system without having to set up multiplecomputing nodes. • We propose a countermeasure to the single-shardflooding attack by executing transaction sharding al-gorithms using TEE. In specific, we provide a formalspecification of the system and formally analyze itssecurity properties in the Universal Composability(UC) framework with a strong adversarial model. • To validate our proposed countermeasure, we developa proof-of-concept implementation of the system andprovide a performance analysis to demonstrate itsfeasibility.
Organization.
The rest of the paper is structured asfollows. Some background and related work are summarizedin Section II. Section III describes in detail the single-shardflooding attack with some preliminary analysis to demonstrateits practicality. In Section IV, we present the construction ofour simulator and conduct some experiments to demonstratethe damage of the attack. The countermeasure is discussed inSection V with a formal specification of the system. Section VIgives a security analysis of the countermeasure along with aperformance evaluation on the proof-of-concept implementa-tion. Finally, Section VII concludes our paper.II. B
ACKGROUND AND R ELATED W ORK
In this section, we establish some background on theblockchain sharding as well as examine some prior work thatis related to ours.
Blockchain sharding.
Several solutions [1]–[7] suggestpartitioning the blockchain into shards to address the scal-ability issue in blockchain. Typically, with sharding, theblockchain’s state is divided into multiple shards, each hastheir own independent state and transactions and is managedby the shard’s validators. By having multiple shards whereeach of them processes a disjoint set of transactions, thecomputation power is parallelized and sharding in turn helpsboost the system throughput with respect to the number ofshards. With the exception of Ethereum sharding [6], most ofexisting sharding protocols are developed on top of Bitcoinblockchain. Some main challenges of a sharding protocolinclude (1) how to securely assign validators to shards, (2)intra-shard consensus, (3) assigning transactions to shards, and(4) processing cross-shard transactions. Our proposed attackexploits the third and fourth challenges of sharding that dealwith transactions in a sharding system.In a simple manner, a transaction is cross-shard if itrequires confirmations from more than one shard. In theUnspent Transaction Outputs (UTXO) model used by Bitcoin[8], each transaction has multiple outputs and inputs where anoutput dictates the amount of money that is sent to a Bitcoinaddress. Each of the outputs can be used as an input to anothertransaction. To prevent double-spending, an output can be usedonly once. Denote tx as a transaction with two inputs tx and tx , this means tx uses one or more outputs from transaction tx and tx . Let S , S , and S be the shards containing tx , tx , and tx , respectively, we refer S and S as the inputshards of tx , and S as the output shard . If these three shardsare the same, tx is an in-shard transaction, otherwise tx iscross-shard.To determine the output shard of a transaction, mostsharding protocols use the hash value of the transaction tocalculate the id of the output shard. By leveraging the hashvalue, the transactions are effectively assigned to shards in auniformly random manner. However, in this work, we shallshow that this mechanism can be manipulated to perform aDoS attack.2 ig. 1. Processing cross-shard transaction tx . tx has input shards S , S ,and output shard S . tx has to wait to be confirmed in the input shards beforeit can be validated in the output shard To process cross-shard transactions, several cross-shardvalidation mechanisms have been proposed [2]–[4]. A cross-shard validation mechanism determines how input and outputshards can coordinate to validate a cross-shard transaction.This makes the process of validating cross-shard transactionsparticularly expensive since the transaction must wait forconfirmations from all of its input shard before it can bevalidated in the output shard. Fig. 1 illustrates this process. Ourattack takes advantage of this mechanism to cause a cascadingeffect that creates a negative impact on shards that are notbeing attacked.
Flooding attacks.
Over the years, we have observed theeconomic impact of this attack as Bitcoin has been floodedmultiple times with dust transactions by malicious users tomake legitimate users pay higher mining fees. In Novemberof 2017, the Bitcoin mempool size exceeded 115,000 uncon-firmed transactions, the value of these unconfirmed transac-tions sum up to 110,611 BTC, worth over 900 million USdollars, weighting about 36 MB [9]. In June 2018, the Bitcoin’smempool was flooded with 4500 unconfirmed dust transactionswhich eventually increased the mempool size to 45MB. Asa result, the mining fee was greatly increased and it causedlegitimate users to pay higher fee to get their transactionsconfirmed [10]. Therefore, it is extremely critical to study thisattack rigorously.There exists some variants of flooding attack that aim tooverwhelm an entire blockchain system [11], [12], not a singleshard. The main concept of the attack is to send a huge amountof transactions to overwhelm the mempool, fill blocks to theirmaximum size, and effectively delay other transactions. In atypical blockchain system, unconfirmed transactions are storedin the mempools managed by blockchain validators. In contrastto the limited block size, the mempool size has no size limit.This kind of attacks requires the attacker to flood theblockchain system at a rate that is much greater than thesystem throughput. Intuitively, such an attack is not effectiveon a sharding system because its throughput is exceedinglyhigh. In fact, a simple solution to the flooding attack is toadd more shards to increase the overall throughput since thesystem scales with the number of shards. In contrast, thethroughput of one shard is not scalable, thus, it would be morereasonable to attack a single shard and make it become theperformance bottleneck of the whole system. In this paper,we show how attackers can manipulate the transactionâ ˘A ´Zshash to overwhelm a single shard, thereby damaging the entire blockchain through cascading effects caused by cross-shardtransactions.
Blockchain on Trusted Execution Environment (TEE).
A key building block of our countermeasure is TEE. Memoryregions in TEE are transparently encrypted and integrity-protected with keys that are only available to the processor.TEE’s memory is also isolated by the CPU hardware fromthe rest of the host’s system, including high-privilege systemsoftware. Thus the operating system, hypervisor, and otherusers cannot access the TEEâ ˘A ´Zs memory. There have beenmultiple available implementations of TEE including IntelSGX [13], ARM TrustZone [14], and Keystone [15]. Intel SGXalso supports generating remote attestations that can be usedto prove the correct execution of a program running inside aTEE.There has been a recent growth in adopting TEEs toimprove blockchains [16]–[19], but not to sharding systems.Teechain [17] proposes an improvement over off-chain pay-ment network in Bitcoin using TEE to enable asynchronousblockchain access. BITE [16] leverages TEE to further enhancethe privacy of Bitcoin’s client. In [18], [19], the authors de-velop secure and efficient smart contract platforms on Bitcoinand Ethereum, respectively, using TEE as a module to executethe contract’s code.We argue that TEE can be used to develop an efficientcountermeasure for the single-shard flooding attack in whichtransaction sharding alogrithms can be securely executed insidea TEE module. However, since existing solutions are designedto address some very specific issues such as smart contractsor payment network, applying them to blockchain sharding systems are not straighforward.III. S
INGLE - SHARD FLOODING ATTACK
In this section, we describe our proposed single-shardflooding attack on blockchain sharding starting with the threatmodel and detail on performing the attack. Then, we presentsome preliminary analysis of the attack to illustrate its potentialimpact and practicality.
A. Threat Model
Attacker.
We use Bitcoin-based sharding systems, such asOmniLedger, RapidChain, and Elastico, as the attacker’s target.We consider an attacker who is a client of the blockchainsystem such that:1) The attacker possesses an enough amount of Bitcoinaddresses to perform the attack. In practice, Bitcoinaddresses can be generated at no cost.2) The attacker has spendable bitcoins in its wallet andthe balance is large enough to issue multiple trans-actions between its addresses for this attack. Each ofthe transactions is able to pay the minimum relay fee minRelayT xF ee . We will discuss the detail cost inthe next section.3) The attacker is equipped with a software that is capa-ble of generating transactions at a rate that is higherthan a shard’s throughput, which will be discussed inthe subsequent section.3) Since this is a type of DoS attack, to prevent frombeing blocked by the blockchain network, the attackercan originate the attack from multiple sources.
Goals of attacks.
By employing the concept of floodingattack, the main goal of the single-shard flooding attack isto overwhelm a single shard by sending a huge amount oftransactions to that shard. The impact of this attack has beenwidely studied on non-sharded blockchain like Bitcoin suchthat it can reduce the system performance by delaying theverification of legitimate transactions and eventually increasethe transaction fee.Furthermore, with the concept of cross-shard transactionswhere each transaction requires confirmation from multipleshards, an attack to overwhelm one shard could affect theperformance of other shards and reduce the system’s per-formance as a whole. For example, in Fig. 1, if S wereunder attack, the transaction validation would also be delayedin S . Analysis from previous work [2] shows that placingtransactions using their hash value could result in 99.98% ofcross-shard transactions. Since the throughput of one shardis limited, under our attack, it could effectively become theperformance bottleneck of the whole system. Therefore, tomake the most out of this scheme, the attacker would targetthe shard that has the lowest throughput in the system. How to perform attack.
In most Bitcoin-based shardingsystems, such as OmniLedger, RapidChain, and Elastico, thehash of a transaction determines which shard to put thetransaction. In specific, the ending bits of the hash valueindicate the output shard id. The main idea of our attackis to have the attackers manipulate the transaction’s hash inorder to place it into the shard that they want to overwhelm.To accomplish this, we conduct a brute-force generation oftransactions by alternating the output addresses of a transactionuntil we find an appropriate hash value.Let T be the target shard which the attacker wants to over-whelm. We define a "malicious transaction" as a transactionwhose hash was manipulated to be put in shard T . Denote tx as a transaction, tx.in is the set of input addresses, and tx.out is the set of output addresses. We further denote O as the set ofattacker’s addresses, I ⊆ O as the set of attacker’s addressesthat are holding some bitcoins. Let H ( · ) be the SHA-256 hashfunction (its output is indistinguishable from that of a randomfunction), Algorithm 1 describes how to generate a malicioustransaction in a system of N shards.Starting with a raw transaction tx , the algorithm randomlysamples a set of input addresses for tx.in from I such thatthe balance of those addresses is greater than the minimumrelay fee. It then randomly samples a set of output addressesfor tx.out from O and set the values for tx.out so that tx canpay the minimum relay fee. The hash value of the transactionis determined by double hashing the transaction’s data usingthe SHA-256 function. It checks if the final N bits indicate T ( & denotes a bitwise AND), if that is true, it outputs themalicious tx that will be placed into shard T . Otherwise, itre-samples another set of output addresses for tx.out from O . B. Preliminary Analysis1) Capability of generating malicious transactions:
In thissection, we demonstrate the practicality of the attack by assess-
Algorithm 1
Generate a malicious transaction
Input: I , O , N, T Output:
A malicious transaction tx tx ← raw transaction tx.in $ ← I while H ( H ( tx )) & (1 − N (cid:107) N ) (cid:54) = T do tx.out $ ← O Set values for tx.out to satisfy the minRelayT xF ee . end while Ret tx TABLE I. C
APABILITY OF GENERATING MALICIOUS TX WITH RESPECTTO THE NUMBER OF SHARDS USING AN I NTEL C ORE I LAPTOP WITH THREADS . No. of shards No. of malicious tx per sec2 823,5124 412,5438 205,97816 103,24632 52,36164 26,939 ing the capability of generating malicious transactions on a realmachine. Suppose we have N shards and a transaction tx , thatmeans we will use N ending bits of H ( tx ) to determine itsshard. Suppose we want to put all transactions into shard 0, weneed to generate some malicious transactions tx such that thelast N bits of H ( tx ) must be 0. We calculate the probability ofgenerating a malicious transaction as follows. As a SHA-256hash has 256 bits, the probability of generating a hash with N ending zero bits will be − N = N . Therefore, we expect toobtain 1 malicious transaction per generating N transactions.That means if we have 16 shards, we can obtain 1 malicioustransaction (i.e., the last 4 bits are zero) per generating 16transactions.To see the capability of generating malicious transactions,we conduct an experiment on an 8th generation Intel Corei7 laptop. The program to generate transactions is written inC++ and run with 8 threads. When the number of shards is 64,the program can generate up to 1,644,736 transaction hashesper second, of which there are 26,939 malicious transactions(8 ending bits are zero). In short, within 1 second, a laptopcan generate about 26,939 malicious transactions, which ispotentially much more than the throughput of one shard.Table I shows the number of malicious transactions generatedper second with respect to the number of shards. Note that, inpractice, an attacker can easily produce much higher numbersby using a more highly capable machine with faster CPU.
2) Cost of attacks:
The default value of minRelayT xF ee in Bitcoin is 1,000 satoshi per kB, which is about $0.10 (asof Feb 2020). Taking into account that the average transactionsize is 500 bytes, each transaction needs to pay $0.05 as the minRelayT xF ee . Our experiments below show that generat-ing 2500 malicious transactions is enough to limit the through-put of the whole system by that of the attacked shard. Hence,the attacker needs about $125 to perform the attack effectively.Furthermore, by paying the minimum relay fee without payingthe minimum transaction fee, the malicious transactions willstill be relayed to the attacked shard’s mempool but will notbe confirmed, thereby retaining the starting balance.4 ig. 2. Affected transactions by the single-shard flooding attack
3) Cascading effect of the single-shard flooding attack:
We estimate the portion of transactions that are affected by theattack. A transaction is affected if one of its input shards or theoutput shard is the attacked shard. In [7], the authors calculatethe ratio of transactions that could be affected when one shardis under attack. Specifically, when considering a system with n shards and transactions with m inputs, the probability ofa transaction to be affected by the attack is − ( n − n ) m +1 .The result is illustrated in Fig. 2. As can be seen, a typicaltransaction with 2 or 3 inputs has up to 70% chance of beingaffected with 4 shards. However, with 16 shards about 20%of the transactions are still affected. Note that this numberonly represents the transactions that are "directly" affectedby the attack, the actual number is higher when consideringtransactions that depends on the delayed transactions.Even though the analysis shows that the number of affectedtransactions is less at 16 shards than at 4 shards, in fact, theattack does much more damage to the 16-shard system. Theintuition of this scenario is that as we increase the numberof shards, we also increase the number of input shards pertransaction. Since a transaction has to wait for the confirma-tions from all of its input shards, an affected transaction in the16-shard system takes more time to be validated than that inthe 4-shard system. The experiments in the next section willillustrate this impact in more detail.IV. A NALYZING THE A TTACK ’ S I MPACTS
In this section, we present a detailed analysis of our attack,especially how it impacts the system performance as a whole.Before that, we describe the design of our simulator that isdeveloped to analyze the performance of a blockchain shardingsystem.
A. Simulator
Our implementation was based on SimBlock [20], adiscrete-event Bitcoin simulator that was designed to test theperformance of the Bitcoin network. SimBlock is able tosimulate the geographical distribution of Bitcoin nodes acrosssix regions (North America, South America, Europe, Asia,Japan, Australia) of which the bandwidth and propagationdelay are set to reproduce the actual behavior of the Bitcoinnetwork. Nevertheless, SimBlock fails to capture the role oftransactions in the simulation, which is an essential part inevaluation the performance of blockchain sharding systems.
Fig. 3. UML class diagram of the simulator
Our work improves SimBlock by taking into considera-tion the Bitcoin transactions and simulating the behavior ofsharding. Fig. 3 shows a simple UML class diagram depictingthe relations between components of our simulator. As can beseen later, our simulator can be easily used to evaluate theperformance of any existing or future sharding protocols.
1) Transactions:
The sole purpose of SimBlock was onlyto show the block propagation so the authors did not considertransactions. To represent Bitcoin transactions, we adopt theTransaction-as-Nodes (TaN) network proposed in [5]. Eachtransaction is abstracted as a node in the TaN network, thereis a directed edge ( u, v ) if transaction u uses transaction v as an input. In our simulator, each transaction is an instanceof a Transaction class and can be directly obtained from theBitcoin dataset. At the beginning of the simulation, a Clientinstance loads each transaction from the dataset and sendsthem to the network to be confirmed by Nodes. Dependingon the transaction sharding algorithm, each transaction couldbe associated with one or more shards.Furthermore, our simulator can also emulate real Bitcointransactions in case we need more transactions than whatwe have in the dataset or we want to test the system withdifferent set of transactions. With regard to sharding, the twoimportant factors of a transaction are the degree and the inputshards. From the Bitcoin dataset of more than 300 millionreal Bitcoin transactions, we fit the degree distribution witha power-law function as in Fig. 4 (black dots are the data,the blue line is the resulted power-law function). The resultingfunction is y = 10 . x − . . Fig. 5 shows the number of inputshards with 16 shards (using hash-based transaction sharding)that is also fitted with a power-law function. The resultingfunction is y = 10 . x − . . Hence, the Client can use thesedistributions to sample the degree and input shards whengenerating transactions that resemble the distribution of thereal dataset.
2) Sharding:
After the simulator generates Node instances,each of them is distributed into an instance of Shard. Allnodes in a shard share the same ledger and a mempoolof unconfirmed/pending transactions. In the class Node, weimplement a cross-shard validation algorithm that decides hownodes in different shards can communicate and confirm cross-shard transactions. In the current implementation, we use themechanism proposed in [3] to process cross-shard transactions.For each Node instance, upon receiving a transaction, itwill relay the transaction to the destination shard. When thetransaction reaches the shard, it will be stored in the mempoolof the Node instances in that shard. Each transaction in the5 ig. 4. Degree distribution of the Bitcoin transactions. The black dots arethe data, the blue line shows a fitted power-law y = 10 . x − . .Fig. 5. Distribution of Bitcoin transactions’ number of input shards. The blackdots are the data, the blue line shows a fitted power-law y = 10 . x − . . mempool is then validated using an intra-shard consensusprotocol.
3) Use cases of the simulator:
Besides being used to testthe impact of our proposed attack, researchers can also use thesimulator to evaluate the performance of multiple blockchainsharding systems. By far, most experiments on blockchainsharding have to be run on numerous rented virtual machines[1]–[4], this is notably costly and complicated to set up.Without having to build the whole blockchain system, oursimulator is particularly useful when researchers need to testvarious algorithms and system configurations on blockchainlong before deploying the real system.By using simulation, various setups can be easily evaluatedand compared, thereby making it possible to recognize andresolve problems without the need of performing potentiallyexpensive field tests. By exploiting a pluggable design, thesimulator can be easily reconfigured to work with differentalgorithms on transaction sharding, cross-shard validation,validators assignment, and intra-shard consensus protocol.
B. Experimental Evaluations
Our experiments are conducted on 10 million real Bitcointransactions by injecting them into the simulator at somefixed rates. We generate 4000 validator nodes and randomlydistribute them into shards. In the current Bitcoin setting, theblock size limit is 1 MB, the average size of a transactionis 500 bytes, hence, each block contains approximately 2000transactions. We evaluate the system performance with 4, 8,
Fig. 6. Impact on system throughput
12, and 16 shards, which are the number of shards that wereused in previous studies [2], [3], [5].
1) Throughput:
The experiment in this section illustrateshow malicious transactions affect the system throughput. Inorder to find out the best throughput of the system, wegradually increase the transactions rate (i.e., the rate at whichtransactions are injected to the system) and observe the finalthroughput until the throughput stops increasing. At 16 shards,the best throughput is about 4000 tps, which is achieved whenthe transactions rate is about 5000 tps. For this experiment,we fix the transactions rate at 5000 tps so that the system isalways at its best throughput with respect to the number ofshards.To perform the attack, the attacker runs Algorithm 1 togenerate some portions of malicious transactions into shard 0.For example, if 10% of transactions are malicious, then at eachsecond, 500 transactions will be put into shard 0, the rest 4500txs are distributed into shards according to their hash value.The results are shown in the Fig. 6.At 0%, the system is not under attack, the system achievesits best throughput with respect to the number of shards.The horizontal dashed line illustrates the throughput of 1shard, which is the lower bound of the system throughput.As can be seen, when we increase the number of malicioustransactions, the system throughput rapidly decreases. Thisbehavior can be explained as we have multiple cross-shardtransactions that associate with the attacked shard, their delayscould produce a severe cascading effect that end up hamperingthe performance of other shards. Thus, the throughput as awhole is diminished. Moreover, we can observe that highernumbers of shards are more vulnerable to the attack. With 16shards, the performance reduce exponentially as we increasethe portion of malicious transactions to 50%. Specifically, withonly 20% malicious transactions, the throughput was reducedby more than half. This behaviour essentially confirms ourprior preliminary analysis.Another interesting observation is that at 50% malicioustransactions, the throughput nearly reaches its lower bound,hence, the sharding system would not be any faster than usingonly 1 shard. At this time, the attacker has accomplished itsgoal, that is, making the attacked shard the bottleneck ofthe whole system. 50% malicious transactions translates to6 ig. 7. Impact on system latency
2) Latency:
In this experiment, we analyze the impact ofthe single-shard flooding attack on the system latency, whichis the average amount of time needed to validate a transaction.To avoid backlog when the system is not under attack, for eachnumber of shards, the transactions rate is set to match the bestsystem throughput. The results are shown in the Fig. 7. In thesame manner as the previous experiment, the attack effectivelyincreases the latency of the system as a whole. We shall seein the next experiment that the attack creates serious backlogin the mempool of the shards, thereby increasing the waitingtime of transactions and eventually raising the average latency.This experiment also corroborates the experiment on sys-tem throughput as greater numbers of shards are also morevulnerable to the attack. With 16 shards, although it providesthe fastest transaction processing when the system is not underattack, nevertheless, it becomes the slowest one even with only10% of malicious transactions. Additionally, when the attackergenerates 20% malicious transactions, the latency is increasedby more than 10 times. Therefore, we can conclude thatalthough adding more shards would help improve the systemperformance, under our attack, the system would become morevulnerable.
3) Queue/Mempool size:
In the following experiments, weinvestigate the impact of this single-shard flooding attackon the queue (or mempool) size of shard 0, which is theshard that is under attack. This gives us insights on howmalicious transactions cause backlog in the shard. Firstly, wefix the number of shards and vary the portion of malicioustransactions. Fig. 8 illustrates the queue size over time ofshard 0 with a system of 16 shards where each line representsthe portion of malicious transactions. When the system is notunder attack, the queue size is stable with less than 15,000transactions at any point in time. As we put in only 10%malicious transactions, the queue size reaches more than 2million transactions.Note that under our attack, the transactions are injected intoshard 0 as a rate that is much higher than its throughput, thus,the queue will keep on increasing until all transactions have
Fig. 8. Impact on the attacked shard’s queue size at 16 shardsFig. 9. Impact on the attacked shard’s queue size with 20% malicioustransactions been injected. At this point, transactions are no longer addedto the shard and the shard is still processing transactions fromthe queue, hence, the queue size decreases. This explains whythe lines (i.e., queue size) go down towards the end of thesimulation.The result also demonstrates that the congestion gets worseas we increase the malicious transactions. Due to the extremebacklog, transactions have to wait in the mempool for a sig-nificant amount of time, thereby increasing their waiting time.This explains the negative impact of malicious transactions onsystem throughput and latency.Next, we observe the queue size with different numberof shards. Fig. 9 presents the impact of the attack with 20%malicious transactions at different number of shards. As can beseen, when we increase the number of shards, the backlog oftransactions builds up much faster and greater due to the factthat we are having more cross-shard transactions. This resultconforms our previous claim that greater numbers of shardsare more vulnerable to the attack.
4) Summary:
The experiments presented in this sectionhave shown that our attack effectively reduce the performanceof the whole system by attacking only a single shard. Bygenerating malicious transactions according to Algorithm 1,the attacker easily achieves its goal of limiting the systemperformance to the throughput of one shard. Our preliminaryanalysis in Section III-B shows that the attacker is totally7apable of generating an excessive amount of malicious trans-actions at low cost, thereby demonstrating the practicality ofthe attack. V. C
OUNTERMEASURE
As we have argued that using hash values to determine theoutput shards is susceptible to the single-shard flooding attack,we delegate the task of determining the output shards withoutusing hash values to the validators. To achieve that task, weconsider the validators running a deterministic transactionssharding algorithm. The program takes the form of S out = txsharding ( tx, st ) in which it ingests as inputs a blockchainstate st and the transaction tx , and generates the output shardid S out of tx calculated at state st . Moreover, the algorithm txsharding is made public. The minimum requirement for anefficient txsharding is that it has to have a load-balancingmechanism to balance the load among the shards. Finally, weassume that txsharding does not use a transaction’s hash asthe basis for determining its output shard. At this time ofwriting, OptChain [5] is a suitable algorithm for txsharding .However, by the nature of blockchain, the validators areuntrusted. A straw-man approach is to run txsharding on-chain and let the validators reach consensus on the outputof txsharding . Hence, the validators would have to reachconsensus on every single transaction. Nonetheless, this alonedismisses the original idea of sharding, that is to improveblockchain by parallelizing the consensus work and storage,i.e., each validator only handles a disjoint subset of trans-action. To avoid costly on-chain consensus on the output of txshading , we need to execute the algorithm off-chain whileensuring that the operation is tamper-proof in the presence ofmalicious validators. To tackle this challenge, in this work, weleverage the Trusted Execution Environment (TEE) to securelyexecute the transaction sharding algorithm on the validators.TEE in a computer system is realized as a module thatperforms some verifiable executions in such a way that noother applications, even the OS, can interfere. Simply speaking,a TEE module is a trusted component within an untrustedsystem. An important feature of TEE is the ability to issueremote attestations which are digital signatures over the TEE’scode and the execution’s output. These signatures are signedby the private keys that are known only by the TEE hardware.Intel SGX [13] is a good implementation of TEE in whichremote attestation is well-supported. However, TEE does notoffer satisfactory availability guarantees as the hardware couldbe arbitrarily terminated by a malicious host or simply bylosing power.In this work, our goal is to use TEE as a computing unitinstalled in the validators that assists the clients in determiningthe transactions’ output shard with an attestation to prove thecorrectness of execution. Our overall concept of using TEE asa countermeasure for the attack is as follows: • Validators are equipped with TEE modules (mostmodern Intel CPUs from 2014 support Intel SGX). Atransaction sharding algorithm such as OptChain [5]is installed in the TEE module. • When a client issues a transaction to a validator, thevalidator will run its TEE module to get the output shard of that transaction, together with an attestation to prove the code’s integrity as well as the correctnessof the execution. • The client can verify the computation using the at-testation and then send the transaction together withthe attestation to the blockchain system in the samemanner as issuing an ordinary transaction. • The blockchain validators upon receiving that datafrom the client verify the attestation before relayingthe transaction to input and output shards.With this concept, we can rest assure that an attacker cannotmanipulate transactions to overwhelm a single shard. Addition-ally, we do not need the whole blockchain validators to reachconsensus on a transaction’s output shard, this computationis instead done off-chain by one or some small amount ofvalidators. However, there are some technical challenges whenusing TEE in an untrusted network: • A malicious validator can terminate the TEE as itsdiscretion, which results in losing its state. The TEEmodule must be designed to tolerate such failure. • Although the computation inside the TEE is trustedand verifiable via attestation, a malicious validator candeceive the TEE module by feeding it with fraud data.To overcome these challenges, we aim to design a state-less
TEE module where any persistent state is stored in theblockchain. To obtain the state from the blockchain, the TEEmodule acts as a blockchain client to query the block headersfrom the blockchain, thereby ensuring the correctness of thedata (this is how we can exploit the immutability of blockchainto overcome pitfalls of TEE modules). With this design, evenwhen some TEE modules are arbitrarily shut down, the securityproperties of the protocol are not affected.
A. System Overview and Security Goals
In this section, we present an overview of our system forthe countermeasure and establish some security goals.
1) System overview:
Our system considers two types ofentities: clients and validators • Clients are the end-users of the system who areresponsible for generating transactions. The clients arenot required to be equipped with a TEE-enabled plat-form. In fact, the clients in our system are extremelylightweight. • Validators in each shard maintain a distributed append-only ledger, i.e. a blockchain, of that shard withan intra-shard consens protocol. Validators require aTEE-enabled platform to run the transaction shardingalgorithm.For simplicity, we assume that a client has a list of TEE-enabled validators and it can send requests to multiple valida-tors to tolerate certain failures. Each TEE-enabled validator has txsharding installed in its TEE module. We also assume thatthe TEE module in each of the validators constantly monitorsthe blockchain from each shard, so that it always has the lateststate of the shards.8 ig. 10. System overview
Denoting
EN C k ( m ) as the encryption of message m underkey k and DEC k ( c ) as the decryption of ciphertext c under key k , the steps for computing the output shard for a transactionis as follows (Fig. 10):1) Client C sends the transaction tx to a TEE-enabledvalidators. C obtains the public key pk T EE of avalidator, computes inp = EN C pk TEE ( tx ) , andsends inp to the validator.2) The validator loads inp into its TEE module andstarts the execution of txsharding in TEE.3) The TEE decrypts the inp using its private key, andexecutes the txsharding using tx and the currentstate st of the blockchain. Then, the output S out is generated together with the state st upon which S out is determined, and a signature σ T EE provingthe correct execution.4) The validator then send ( S out , st, σ T EE , h tx ) to C where h tx is the hash of the transaction. C verifies σ T EE before sending ( σ T EE , tx ) to the blockchainnetwork for final validation. If C sends request tomore than one validator, C would choose the S out that reflects the latest state.Note that C could choose an outdated S out , however,other entities can validate if a pair ( S out , st ) is indeedthe output of a TEE. The blockchain system cansimply reject transactions whose S out was computedbased on an outdated st
5) Upon receiving ( σ T EE , tx ) , the validators again ver-ify σ T EE before proceeding with relaying and pro-cessing the transaction.In practice, TEE platforms like Intel SGX performs theremote attestation as follows. The attestation for a correctcomputation takes the form of a signature π from the output ofTEE. Suppose Intel SGX is the implementation of TEE and theexecution on TEE results in an output S out and an attestation σ T EE , as indicated in [18], the validator sends σ T EE to theIntel Attestation Service (IAS) provided by Intel. Then IASverifies σ T EE and replies with π = ( b, σ T EE , σ
IAS ) , where b indicates whether σ T EE is valid or not, and σ IAS is a signatureover b and σ T EE by the IAS. Since π is basically a signature,it can be verified without using TEE or having to contact theIAS.
2) Adversarial model and Security goals:
In the threatmodel in Section III-A, the attacker only plays the role ofa client, however, we stress that the countermeasure mustnot violate the adversarial model of blockchain, which isworking with malicious validators. Thus, in designing thecountermeasure system, we extend the previous threat modelas follows.In the same manner as previous work on TEE-enabledblockchain [17], [18], we consider an adversary who controlsthe operating system and any other high-privilege software onthe validators. Attackers may drop, interfere, or send arbitrarymessages at any time during execution. We assume that theadversary cannot break the hardware security enforcementof TEE. The adversary cannot access processor-specific keys(e.g., attestation and sealing key) and it cannot access TEE’smemory that is encrypted and integrity-protected by the CPU.The adversary can also corrupt an abitrary number ofclients. Clients are lightweight, they only send requests tothe validator the get the output shard of a transaction. Theycan verify the computation without TEE. We assume honestclients trust their platforms and softwares, but not that ofothers. We consider that the blockchain will perform prescribedcomputation correctly and is always available.With respect to the adversarial model, we define thesecurity notions of interest as follows:1) Correct execution: the output of a TEE module mustreflect the correct execution of txsharding withrespect to inputs tx and st , despite malicious host.2) The system is secure against the aforementionedsingle-shard flooding attack.3) Stateless TEE: the TEE module does not need toretain information regarding previous states or com-putation.
3) Blockchain sharding configuration:
For an ease of pre-sentation, we assume a sharding system that resembles theOmniLedger blockchain [3]. Suppose the sharding system has n shards, for each i ∈ { , , ..., n } , we denote BC i and BH i asthe whole ledger and block headers of shard S i , respectively.Furthermore, we assume that each shard S i keeps track ofits UTXO database, denoted by U i . Given a shard S i , eachvalidator in S i monitors the following database: BC i , BH j (cid:54) = i ,and U , ,...,n .As we use an Omniledger-like blockchain, each shardelects a leader who is responsible for accepting new transactionto the shard. For simplicity, we consider that the sharding sys-tem provides an API validate ( tx ) that takes a transaction tx as the input and performs the transaction validation mechanismon tx . validate ( tx ) returns true if tx is successfully committedto the blockchain, otherwise it returns false.Additionally, we consider the system uses a signaturescheme Σ( G, Sig, V f ) that is assumed to be EU-CMA secure(Existential Unforgeability under a Chosen Message Attack).ECDSA is a suitable signature scheme in practice [21]. More-over, the hash function H ( · ) used by the system is alsoassumed to be collision resistant: there exists no efficient algo-rithm that can find two inputs a (cid:54) = b such that H ( a ) = H ( b ) .Finally, we assume that each TEE generates a public/secretkey-pair and the public key is publicly available to all entities9unctionality F blockchain Store DB = { DB i | i ∈ { , , ..., n }} , each DB i is anappended database indexed by h tx . • On input read ( id, h tx ) from P i : return DB id [ h tx ] or ⊥ if not exists. • On input write ( id, tx ) from P i :1) If validate ( tx ) = 0 then output reject () .2) Otherwise, DB id = DB id (cid:107) tx and output accept () Fig. 11. Ideal blockchain F blockchain Functionality F T EE • On initialization ◦ Generate ( pk T EE , sk
T EE ) • On input install ( prog ) from P k : ◦ if prog is not stored then store ( prog ) • On input resume ( inp c ) from P k :1) If prog is not stored than return ⊥ .2) outp = prog ( inp c ) σ = Σ .Sig ( sk T EE , ( prog, outp ))
4) Return ( σ, outp ) to P k Fig. 12. Ideal TEE F TEE in the network. In practice, the public keys could be stored ina global identity blockchain.
B. Modeling Functionality of Blockchain and TEE
We specify the ideal blockchain F blockchain as an appendeddecentralized database as in Fig. 11. F blockchain stores DB = { DB i | i ∈ { , , ..., n }} which represents a set of blockchainsthat are hold by shard 1, 2, ..., n , respectively. Each blockchain DB i is indexed by the transactions’ hash value h tx . We assumethat by writing to the blockchain of a shard, all validators ofthe shard reach consensus on that operation.We also specify the ideal TEE F T EE that models a TEEmodule in Fig. 12, following the formal abstraction in [22]. Onstartup, F T EE generates a public/secret key pair, and only thepublic key is accessible by other parties. With the public key,other entities in the network are able to verify messages signedby F T EE ’s secret key. This represents the attestation service ina TEE-enabled platform. A TEE module is an isolated softwarecontainer that is installed with a program that, in this work,is a transaction sharding algorithm. F T EE abstracts a TEEmodule as a trusted third party for confidentiality, execution,and authenticity with respect to any entities that is a part ofthe system. prog is a program that is installed to run in a TEEmodule; the input and output of prog are denoted by inp and outp , respectively.On initialization, the TEE module needs to download andmonitor U i for i ∈ , , .., n . These data are encrypted usingthe TEE’s secret key and then stored in the host storage,which is also referred as sealing. By this way, the TEE willmake sure that its data on the secondary storage cannot be Program prog run in the TEE module Input: inp c
1) Request the current state st from the sealed database2) tx ← DEC sk TEE ( inp c ) S out = txsharding ( tx, st )
4) Return ( S out , st, H ( tx )) Fig. 13. Program prog run in the TEE module tampered with by a malicious host. To ensure that the TEEalways uses the latest version of the sealed UTXO database,rollback-protection systems such as ROTE [23] can be used.Fig. 13 defines the program prog that is installed inthe TEE module to be used in this work. As can be seen,the program decrypts the encrypted input inp c using thesecret key sk T EE . txsharding is implemented inside prog to securely execute the transaction sharding algorithm. Theprogram returns the output shard S out , the state st upon which S out was computed, and the hash of the transaction h tx . Thishash value is used to prevent malicious hosts from feeding theTEE module with fake transactions, which will be discussedin more detail in the next subsection.Upon running prog with the input inp c , the TEE moduleobtains the signature σ T EE over the output of prog and thecode of prog using its private key. Finally, the TEE modulereturns to the host validator σ T EE , and the output outp from prog . C. Formal Specification of the Protocol
Our proposed system supports two main APIs for the end-users: (1) newtx ( tx ) handles the secure computation of atransaction tx , and (2) read ( id, h tx ) returns the transactionthat has the hash value h tx from shard id .The protocol for validators is formally defined in Fig. 14,which relies on F T EE and F blockchain . The validator ac-cepts two function calls from the clients: request ( tx c ) and process ( S out , σ T EE , tx ) . request ( tx c ) takes as input a trans-action that is encrypted by the public key of TEE and send tx c to the TEE module. For simplicity, we assume that thevalidator is TEE-enabled, if not, the validator simply discardsthe request ( tx c ) function call. Since tx c is encrypted by pk T EE , a malicious host cannot tamper with the transaction.The validator waits until the TEE returns an output and relaysthat output to the function’s caller.Note that as the output of the TEE includes the transaction’shash h tx , the client can check that the TEE indeed processedthe correct transaction tx originated from the client. This ispossible because of the end-to-end encryption of tx betweenthe client and the TEE. Furthermore, since σ T EE protectsthe integrity of S out , the client can verify that S out was notmodified by a malicious validator.The function process ( S out , σ T EE , tx ) receives as input thetransaction tx , σ T EE , and output shard S out of tx . The val-idator also verifies σ T EE before making a call to F blockchain to start the transaction validation for tx .10rotocol for validators • On input request ( tx c ) from C i :1) Send resume ( tx c ) to F T EE
2) Wait to receive ( σ T EE , ( S out , st, h tx )) from F T EE
3) Return ( st, S out , σ T EE , h tx ) • On input process ( S out , σ T EE , tx ) from C i :1) Assert σ T EE is valid, if failed then return ⊥
2) Send write ( S out , tx ) to F blockchain
3) Wait to receive output from F blockchain
4) Return the received output to C i Fig. 14. Protocol for validators
Protocol for clients • On input newtx ( tx ) from environment Z :1) tx c ← EN C pk TEE ( tx )
2) Send request ( tx c ) to validator P k
3) Receive ( st, S out , σ T EE , h tx )
4) Assert H ( tx ) = h tx
5) Assert σ T EE using ( st, S out , txsharding, H ( tx )) , if fail thenreturn ⊥
6) Send process ( S out , σ T EE , tx ) to S out
7) Wait to receive accept () or ⊥ from P k
8) Forward the received data to Z• On input read ( id, idx ) from environment Z :1) Send read ( idx ) to F blockchain [ id ] and relayoutput to Z Fig. 15. Protocol for clients
Fig. 15 illustrates the protocol for the clients. To determinethe output shard of a transaction tx , a client invokes theAPI newtx ( tx ) . First, to ensure the integrity of tx , the clientencrypts tx using the pk T EE and send tx c to a TEE-enabledvalidator P k . Upon receiving ( st, S out , σ T EE , h tx ) from P k ,the client checks if the hash of tx is equal to h tx . This preventsa malicious validator from feeding a fake transaction to theTEE module to manipulate S out . The client also verifies ifthe attestation σ T EE is correct. Afterwards, the client sendsthe transaction together with S out and the attestation to thevalidators of the transaction’s input and output shards for finalvalidation. newtx ( tx ) finally outputs any data received fromthe validators. The API read ( id, h tx ) can be called when theclient wants to obtain the transaction information from theblockchain. The function also returns any data received from F blockchain .VI. S ECURITY A NALYSIS AND P ERFORMANCE E VALUATION
This section presents a detail security analysis of theproposed countermeasure under the UC-model and evaluatethe performance of the proof-of-concept implementation.
A. Security Analysis
We first prove that the proposed protocol (1) only requiresa stateless TEE and (2) is secure against the single-shardflooding attack, and then prove the correct execution security.By design, the txsharding installed in the TEE base solelyon the transaction tx , and the state st of the blockchain forcomputation. As tx is the input and st can be obtained byquerying from the UTXO database, the TEE does not need tokeep any previous states and computation, thus, it is stateless.When the system makes decision on the output shard ofa transaction, it relies on the txsharding program which isassumed to not base its calculation on transactions’ hash value.Therefore, as txsharding also balances the load among theshards, no attackers can manipulate transactions to overwhelma single shard, hence, the countermeasure is secure against thesingle-shard flooding attack.The correct execution security of our system is proven inthe Universal Composability (UC) framework [24]. We referthe readers to Appendix A for our proof. B. Performance Evaluation
This section presents our proof-of-concept implementationas well as some experiments to evalute its performance. Asour countermeasure is immune to the single-shard floodingattack, our goal is to evaluate the overhead of integrating thissolution to sharding. We implement the proof-of-concept usingIntel SGX that is available on most modern Intel CPUs. WithSGX, each implementation of the TEE module is referredas an enclave . The proof-of-concept was developed on Linuxmachines in which we use the Linux Intel SGX SDK 2.1 fordevelopment. We implement and test the protocol for validatorsusing a machine equipped with an Intel Core i7-6700, 16GBRAM, and an SSD drive.As we want to demonstrate the practicality of the counter-measure, the focus of this evaluation is three-fold: processingtime, communication cost, and storage. The processing timeincludes the time needed for the enclave to monitor theblock headers as well as to determine the output shard ofa transaction requested by a client. The communication costrepresents the network overhead incurred by the interactionbetween clients and validators to determine the output shards.Additionally, we measure the amount of storage needed whenrunning the enclave.In our proof-of-concept implementation, we use OptChain[5] as txsharding . As OptChain determines the output shardbased on the transaction’s inputs, when obtaining the state fromthe UTXO database, we only need to load those transaction’sinputs from the database. Our proof-of-concept uses Bitcoin asthe blockchain platform, and the enclave is connected to theBitcoin mainnet.
1) Processing time:
We calculate the processing time fordetermining the output shard by invoking the enclave with 10million Bitcoin transactions (encrypted with the TEE publickey) and measure the time needed to receive output from theenclave. This latency includes (1) decrypting the transaction,(2) obtaining the latest state from the UTXO database in thehost storage and (3) running txsharding . We observe thatthe highest latency recorded is only about 214 ms and it also11oes not vary much when running with different transactions.Consider that the average latency of processing a transactionin sharding is about 10 seconds [5], our countermeasure onlyimposes an additional 0.2 seconds for determining the outputshard.For a detail observation, we measure the latency separatelyfor each stage. The running time of txsharding is negligibleas the highest running time recorded is about 0.13 ms whenprocessing a 10-input transaction at 16 shards. Decrypting thetransaction is about 0.579 ms when using 2048-bit RSA, anda query to the UTXO database to fetch the current state takesabout 213.2 ms. Hence, fetching the state from the UTXOdatabase dominates the running time due to the fact that thedatabase is stored in the host storage.Another processing time that we take into considerationis the time needed for updating the UTXO database whena new block is added to the blockchain. With an averagenumber of 2000 transactions per block, each update takesabout 65.7 seconds. However, this latency does not affect theperformance of the system since we can set up two differentenclaves running in parallel, one for running txsharding , onefor monitoring the UTXO database. Therefore, the time neededto run txsharding is independent from updating the database.
2) Communication cost:
Our countermeasure imposessome communication overhead over hash-based transactionsharding since the client has to communicate with the val-idator to determine the output shard. In specific, the overheadincludes sending the encrypted transaction to the validator andreceiving response. The response comprises the state (repre-sented as the block number), output shard id, attestation, anda hash value of the transation. The communication overheadsum up to about 601 bytes needed for the client to get theoutput shard of a transaction. If we consider a communicationbandwidth of 10 Mbps, the transmission time would take lessthan half a millisecond.
3) Storage:
According to the proposed system for thecountermeasure, the enclave needs to store the UTXO databasein the host storage, which is essentially the storage of thevalidator. As of Feb 2020, the size of Bitcoin’s UTXO setis about 3.67 GB [25], which means that an additional 3.67GB is needed in the validator’s storage. However, consideringthat the validator’s storage is large enough to store the wholeledger, which is about 263 GB as of Feb 2020 [26], the extradata trivially accounts for 1.4%.
4) Summary:
By evaluating a proof-of-concept implemen-tation of our countermeasure, the result in this section showsthat our system imposes negligible overhead with comparedto the hash-based transaction sharding, which is susceptibleto the single-shard flooding attack. Particularly, by incurringinsignificant processing time, communication cost, and storage,our proposed countermeasure demonstrate the practicality asit can be integrated to existing sharding solutions withoutaffecting the system performance.VII. C
ONCLUSIONS
In this paper, we have identified a new attack in existingsharding solutions. Due to the use of hash-based transactionsharding, an attacker can manipulate the hash value of a transaction to conduct the single-shard flooding attack, whichis essentially a DoS attack that can overwhelm one shardwith an excessive amount of transactions. We have thoroughlyinvestigated the attack with multiple analysis and experimentsto illustrate its damage and practicality. Most importantly, ourwork has shown that by overwhelming a single shard, theattack creates a cascading effect that reduce the performanceof the whole system.We have also proposed a countermeasure based on TEEthat efficiently eliminate the single-shard flooding attack. Thesecurity properties of the countermeasure have been proven inthe UC framework. Finally, with a proof-of-concept implemen-tation, we have demonstrated that our countermeasure imposesneligible overhead and can be integrated to existing shardingsolutions. R
EFERENCES[1] L. Luu, V. Narayanan, C. Zheng, K. Baweja, S. Gilbert, and P. Saxena,“A secure sharding protocol for open blockchains,” in
Proceedings ofthe 2016 ACM SIGSAC Conference on Computer and CommunicationsSecurity . ACM, 2016, pp. 17–30.[2] M. Zamani, M. Movahedi, and M. Raykova, “Rapidchain: Scalingblockchain via full sharding,” in
Proceedings of the 2018 ACM SIGSACConference on Computer and Communications Security . ACM, 2018,pp. 931–948.[3] E. Kokoris-Kogias, P. Jovanovic, L. Gasser, N. Gailly, E. Syta, andB. Ford, “Omniledger: A secure, scale-out, decentralized ledger viasharding,” in .IEEE, 2018, pp. 583–598.[4] J. Wang and H. Wang, “Monoxide: Scale out blockchains with asyn-chronous consensus zones,” in { USENIX } Symposium on Net-worked Systems Design and Implementation ( { NSDI } , 2019, pp.95–112.[5] L. N. Nguyen, T. D. Nguyen, T. N. Dinh, and M. T. Thai, “Optchain:optimal transactions placement for scalable blockchain sharding,” in . IEEE, 2019, pp. 525–535.[6] Ethereum, “ethereum/sharding.” [Online]. Available: https://github.com/ethereum/sharding/blob/develop/docs/doc.md[7] A. Manuskin, M. Mirkin, and I. Eyal, “Ostraka: Secure blockchainscaling by node sharding,” arXiv preprint arXiv:1907.03331 . IEEE, 2019, pp. 285–292.[12] K. Baqer, D. Y. Huang, D. McCoy, and N. Weaver, “Stressing out:Bitcoin â ˘AIJstress testingâ ˘A˙I,” in International Conference on FinancialCryptography and Data Security . Springer, 2016, pp. 3–18.[13] R. Intel, “Software guard extensions programming reference,”
IntelCorporation { BITE } : Bitcoin lightweight client privacy using trustedexecution,” in { USENIX } Security Symposium ( { USENIX } Secu-rity 19) , 2019, pp. 783–800.
17] J. Lind, O. Naor, I. Eyal, F. Kelbert, E. G. Sirer, and P. Pietzuch,“Teechain: a secure payment network with asynchronous blockchainaccess,” in
Proceedings of the 27th ACM Symposium on OperatingSystems Principles , 2019, pp. 63–79.[18] R. Cheng, F. Zhang, J. Kos, W. He, N. Hynes, N. Johnson, A. Juels,A. Miller, and D. Song, “Ekiden: A platform for confidentiality-preserving, trustworthy, and performant smart contracts,” in . IEEE,2019, pp. 185–200.[19] P. Das, L. Eckey, T. Frassetto, D. Gens, K. Hostáková, P. Jauernig,S. Faust, and A.-R. Sadeghi, “Fastkitten: practical smart contracts onbitcoin,” in { USENIX } Security Symposium ( { USENIX } Security19) , 2019, pp. 801–818.[20] Y. Aoki, K. Otsuki, T. Kaneko, R. Banno, and K. Shudo, “Simblock:A blockchain network simulator,” in
IEEE INFOCOM 2019 - IEEEConference on Computer Communications Workshops (INFOCOM WK-SHPS) , April 2019, pp. 325–329.[21] D. Johnson, A. Menezes, and S. Vanstone, “The elliptic curve digi-tal signature algorithm (ecdsa),”
International journal of informationsecurity , vol. 1, no. 1, pp. 36–63, 2001.[22] R. Pass, E. Shi, and F. Tramer, “Formal abstractions for attestedexecution secure processors,” in
Annual International Conference onthe Theory and Applications of Cryptographic Techniques . Springer,2017, pp. 260–289.[23] S. Matetic, M. Ahmed, K. Kostiainen, A. Dhar, D. Sommer, A. Gervais,A. Juels, and S. Capkun, “ { ROTE } : Rollback protection for trusted ex-ecution,” in { USENIX } Security Symposium ( { USENIX } Security17) , 2017, pp. 1289–1306.[24] R. Canetti, “Universally composable security: A new paradigm forcryptographic protocols,” in
Proceedings 2001 IEEE International Con-ference on Cluster Computing cm : Ideal functionality of the countermeasure • On Initialization :1) DB i = ∅ , ∀ i ∈ [ N ] • On input newtx ( tx ) from any party P i :1) relay input to A
2) Request current state st from the UTXOdatabase3) S out = txsharding ( tx, st ) DB S out = DB S out || tx
5) Send delayed accept () to P i • On input read ( id, h tx ) from any party P i :1) If DB id [ h tx ] is not available then return ⊥
2) Otherwise, return DB id [ h tx ] Fig. 16. Ideal functionality of the countermeasure A PPENDIX
A. Proof of correct execution in the UC framework
In the UC framework, a real world involves parties runningthe proposed protocol, namely Π cm . On the other hand, anideal world consists of parties that interact with an idealfunctionality F cm , a trusted third party that implements theAPIs of the proposed protocol, i.e., newtx ( · ) and read ( · ) .Fig. 16 shows the definition of F cm . Any adversary A in thereal world is introduced in the ideal world by a simulator S with an adversary model defined in Section V-A2.To prove that the proposed protocol Π cm achieves correctexecution security, we show that: (1) F cm achieves the correctexecution security in the ideal world; and (2) the real andideal worlds are indistinguishable to an external environment Z . This implies that any attack violating security goals in thereal world is translatable to a corresponding attack in the idealone. This proves that the real world protocol also achieves thecorrect execution security.In F cm , whenever a party triggers newtx ( tx ) with atransaction tx , the execution of txsharding is performedinternally by the ideal functionality F cm based on tx and thecurrent state st to determine S out . Since F cm is trusted underUC, txsharding is guaranteed to be correctly executed. Fur-thermore, F cm also validates the transaction in the blockchainand returns only accept () or ⊥ to the party, an adversarydoes not have control over the output shard S out , hence, theadversary cannot tamper with S out . Therefore, F cm achievescorrect execution security.Let A be an adversary against the proposed protocol. PerCanetti [24], we say that Π cm UC-realizes F cm if there existsa simulator S , such that any environment Z cannot distinguishbetween interacting with the adversary A and Π cm or with thesimulator S and the ideal functionality F cm . By that definition,we prove the following theorem: Theorem 1.
The protocol Π cm in the ( F T EE , F blockchain ) hybrid model UC-realizes the ideal functionality F cm .Proof: We prove the indistinguishability between the realand ideal worlds through a series of hybrid steps as commonly done in previous work [17], [18]. These hybrid steps start at H - the real-world execution of Π cm in the ( F T EE , F blockchain ) hybrid model, and finally becomes the execution in the idealworld. The indistinguishability is proven in each step.Hybrid H is the real-world execution where parties run Π cm in the ( F T EE , F blockchain ) hybrid model.Hybrid H behaves in the same manner as H , exceptthat S emulates F T EE and F blockchain . First, S generates akey pair ( pk T EE , sk
T EE ) and publishes pk T EE . Whenever A interacts with F T EE , S records messages sent by A and em-ulates F T EE â ˘A ´Zs behavior. Likewise, S emulates F blockchain by storing DB internally. As the view of A in H is identicallysimulated in H , Z cannot distinguish between H and theexecution H .Hybrid H proceeds as H . However, every time A communicates with F blockchain , S identically emulates F blockchain â ˘A ´Zs behavior for A . As the view of A in H aresimulated when interacting with the ledger, then environment Z cannot distinguish between H and H .Hybrid H modifies H as follows. When A triggers F T EE with a message install ( prog ) , S records a tuple ( σ T EE , outp ) for all subsequent resume ( · ) calls, where outp is the output of prog and σ T EE is an attestation under sk T EE over outp and prog . S keeps a set of all such tuples. Whenever A sendsa tuple ( σ T EE , outp ) that has not been recorded by S to F blockchain or an honest party, S simply stops the execution.We can prove that Z cannot distinguish between H and H as follows. In H , if A sends forged attestations/signaturesto F blockchain or an honest party, signature verification by F blockchain or the honest party will fail with negligible prob-ability (as we assume the signature scheme Σ is EU-CMAsecure). If Z can distinguish H from H , we can constructan adversary using Z and A to win the game of signatureforgery.Hybrid H proceeds as H with one modification: S emulates the new transaction processing. In specific, honestparties send newtx to F cm . S emulates messages from F T EE and F blockchain as in H , i.e., recording tuples ( σ T EE , outp ) .If the party is corrupted, S sends newtx ( tx ) to F cm as P i . Itcan be seen that the view of A is the same as in H , as S canidentically emulate F T EE and F blockchain .It can be seen that H is identical to the ideal protocol.In H , while S interacts with F cm , it emulates A â ˘A ´Zs viewof the real-world. Now, S only needs to output to Z what A outputs in the real-world. Thus, there exists no environment Z that can distinguish between interaction between A and Π cm ,from interaction between S and F cmcm