On Scaling Decentralized BlockchainsA Position PaperKyle Croman0,1, Christian Decker4, Ittay Eyal0,1, Adem Efe Gencer0,1, Ari Juels0,2,Ahmed Kosba0,3, Andrew Miller0,3, Prateek Saxena6, Elaine Shi0,1, Emin GunSirer0,1, Dawn Song0,5, and Roger Wattenhofer40 Initiative for CryptoCurrencies and Contracts IC31 Cornell 2 Jacobs, Cornell Tech 3 UMD 4 ETH 5 Berkeley 6 NUSAbstract. The increasing popularity of blockchain-based cryptocurren-cies has made scalability a primary and urgent concern. We analyze howfundamental and circumstantial bottlenecks in Bitcoin limit the abil-ity of its current peer-to-peer overlay network to support substantiallyhigher throughputs and lower latencies. Our results suggest that repa-rameterization of block size and intervals should be viewed only as a firstincrement toward achieving next-generation, high-load blockchain proto-cols, and major advances will additionally require a basic rethinking oftechnical approaches. We offer a structured perspective on the designspace for such approaches. Within this perspective, we enumerate andbriefly discuss a number of recently proposed protocol ideas and offerseveral new ideas and open challenges.1 IntroductionIncreasing adoption of cryptocurrencies has raised concerns about their abil-ity to scale. Since Bitcoin is a self-regulating system that works by discoveringblocks at approximate intervals, its highest transaction throughput is effectivelycapped at maximum block size divided by block interval. The current trend ofever increasing block sizes on Bitcoin portends a potential problem where the sys-tem will reach its maximum capacity to clear transactions, probably by 2017 [47].As a result, the cryptocurrency community has been discussing techniques forimproving scalability of blockchains in general, and Bitcoin in particular, forsome time. These debates have been vigorous, and at times acrimonous, and ledto splits within the community, without a clear path forward on which technicalmeasures ought to be deployed to address the scalability problem.Today’s representative blockchain such as Bitcoin takes 10 min or longerto confirm transactions, achieves 7 transactions/sec maximum throughput. Incomparison, a mainstream payment processor such as Visa credit card confirms atransaction within seconds, and processes 2000 transactions/sec on average, witha peak rate of 56,000 transactions/sec [11]. Clearly, a large gap exists betweenwhere Bitcoin is today, and the scalability of a mainstream payment processor.Therefore, the key questions are,Can decentralized blockchains be scaled up to match the perance of amainstream payment processor What does it take to get thereThis paper aims to place exploration of blockchain scalability on a scientificfooting. We note that “scalability” is not a well-defined, singular property of asystem, but a term that relates several quantitative metrics to each other.We offer three contributions that illuminate the problem of scaling Bitcoinand blockchains generally to achieve high-perance, decentralized systemsMeasurement study and exploration of reparametrization. We presentexperimental measurements of a range of metrics that characterize the resourcecosts and perance of today’s operational Bitcoin network. As a first step to-ward better scalability in Bitcoin, the community has put forth various proposalsto modify the key system parameters of block size and block interval. Throughfurther experimental investigation, we show that such scaling by reparametriza-tion can achieve only limited benefits given the network perance inducedby Bitcoin’s current peer-to-peer overlay network protocol while maintaining itscurrent degree of decentralization, as measured by number of functioning peersin the overlay network.Our results hinge on the key metric of effective throughput in the overlaynetwork, which we define here as which blocks propagate within an averageblock interval period the percentage of nodes to. If the transaction rate exceedsthe 90 effective throughput, then 10 of the nodes in the network would beunable to keep up, potentially resulting in denied services to users and reducingthe network’s effective mining power. To ensure at least 90 of the nodes in thecurrent overlay network have sufficient throughput, we offer the following twoguidelines– [Throughput limit.] The block size should not exceed 4MB, given today’s10 min. average block interval or a reduction in block-interval time. A 4MBblock size corresponds to a maximum throughput of at most 27 transaction-s/sec.– [Latency limit.] The block interval should not be smaller than 12s, if fullutilization of the network’s bandwidth is to be achieved.We stress that the above guidelines seem somewhat intuitive especially inhindsight. The community has thus also proposed radically different scalingapproaches, and introduced mechanisms such as Corallo’s relay network, a cen-tralized block-propagation mechanism. One of our contributions, however, is toquantify Bitcoin’s current scalability limits within its decentralized components.Note that as we consider only a subset of possible metrics due to difficulty inaccurately measuring others, our results on reparametrization may be viewedas upper bounds additional metrics could reveal even stricter limits.Painting a broad design space for scalable blockchains. Our findings leadus to the position that fundamental protocol redesign is needed for blockchainsto scale significantly while retaining their decentralization. We compile and re-view various technical approaches that can help blockchains scale. We lay outa broad design space that encompasses not just incremental improvements, butalso radical rearchitecture. We frame a structured discussion of new protocol de-sign strategies in terms of a partitioning blockchain systems into distinct planes,namely Network, Consensus, Storage, View, and Side Planes. We discuss theproperties of each plane and both recent and new proposals to improve each; wealso discuss open research challenges.Posing open challenges. Another goal of our paper is to articulate open chal-lenges in the service of i better understanding of scalability bottlenecks; and iithe design of more scalable blockchains. As mentioned earlier, scalability is not asingular metric, but captures the tension between various perance and secu-rity metrics. So far, measurement and understanding of many important metricse.g., fairness and mining power utilization [26] are lacking partly becausemonitoring and measuring a decentralized blockchain from only a few vantagepoints poses significant challenges. We call for better measurement techniquessuch that we could continuously monitor the health of decentralized system suchas Bitcoin, and answer key questions such as “To what extent can we push sys-tem parameters without sacrificing security” “How robust is the system whenunder attack” Finally, although we paint the broader design space for a scal-able blockchain, instantiating and combining these ideas to build a full-fledgedsystem with ally provable security is a non-trivial challenge.Additional results. Due to space restrictions, we relegate many detail of ourexperiments to [10].2 Bitcoin Scalability Today A Reality CheckWe analyze some of the key metrics of the Bitcoin system as it exists today.Maximum throughput. The maximum throughput is the maximum rate atwhich the blockchain can confirm transactions. Today, Bitcoin’s maximum through-put is 3.3–7 transactions/sec [1]. This number is constrained by the maximumblock size and the inter-block time.Latency. Time for a transaction to confirm. A transaction is considered con-firmed when it is included in a block, roughly 10 minutes in expectation.1Bootstrap time. The time it takes a new node to download and process thehistory necessary to validate the current system state. Presently in Bitcoin, thebootstrap time is linear in the size of the blockchain history, and is roughly fourdays averaged over five fresh t2.medium Amazon EC2 nodes that we connectedto the network running the most recent master software.Cost per Confirmed Transaction CPCT. The cost in USD of resourcesconsumed by the entire Bitcoin system to confirm a single transaction. TheCPCT encompasses several distinct resources, all of which can be further decom-posed into operational costs mainly electricity and capital equipment costs1. Mining Expended by miners in generating the proof of work for each block.1 Although we define latency in Bitcoin as the time to obtain a single confirmation,some payment processors accept “zero-confirmation” transactions, while others fol-low common advice to wait for 6 confirmations before accepting a payment.2. Transaction validation The cost of computation necessary to validate thata transaction can spend the outputs referenced by its s, dominated bycryptographic verifications.3. Bandwidth The cost of network resources required to receive and transmittransactions, blocks, and metadata.4. Storage The cost 1 of storing all currently spendable transactions, which isnecessary for miners and full nodes to per transaction validation, and 2of storing the blockchain’s much larger historical data, which is necessaryto bootstrap new nodes that join the network.Table 1 presents our estimates of these various costs. As the table shows, themajority of the cost is attributable to mining. Our calculation suggests that, atthe maximum throughput, the cost per confirmed transaction is 1.4 – 2.9,where 57 is electricity consumption for mining. If the de facto Bitcoin through-put is assumed, the CPCT is as high as 6.2. We proceed to explain our cost-estimation ology.To measure the cost per transaction for Bitcoin, we per a back-of-the-envelope calculation by summing up the electricity consumed by the networkas a whole, as well as the hardware cost of mining equipment. We project ourestimates based on the AntMiner S5 mining hardware [8], which is the currentlyavailable hardware that has the highest hash rate per joule, and the highest hashrate per dollar according to this comparison as of October 2015 [2]. We assumea 1 year effective lifetime for the hardware, and that the average hashing rateof the network is 450,000,000 GH/s based on statistics from October 2015 [3].Based on the power consumption of the selected hardware 0.445 W/GH, thetotal power consumed by the network will be about 200 MegaWatt. Furthermore,we assume the average price per KWh is 0.1 [49].There are two interesting scenarios The first scenario is when the Bitcoinnetwork is operating at maximum throughput, namely 3.3–7 transactions/sec.This maximum throughput is mainly constrained by Bitcoin’s 1MB maximumblock size and the variable transaction size. The lower bound of the maximumthroughput is inferred from the current average transaction size, about 500 bytes,while the upper bound is based on an oft-cited estimate from [1] which corre-sponds to unusually small 250 byte transactions. The second scenario is the defacto average throughput for the Bitcoin network, which is, based on statisticscollected in October 2015, 1.57 transactions/sec [4].Table 1 shows ballpark estimates for the transaction validation, storage,and bandwidth costs. These estimates are attained assuming that the entirenetwork contains 5400 full nodes a coarse-grained estimate obtained fromhttps//bitnodes.21.co/. We assume that each full node incurs roughly therunning cost of an EC2 micro-instance ∼ 0.01/hour to validate transactions;alternatively, assuming a 500 processor with a 5-year life-time would yield thesame ballpark estimate. We assume that transactions are stored on an SSD drivewith a 5-year lifetime, costing about 0.3/GB today. We also assume all nodesstore the entire history, to maintain the system’s security. We assume each nodemaintains a home-grade Internet connection about 100/month whose cost isat max throughput at de facto throughputcost/tx percentage cost/tx percentageMining proof-of-work ∼ 0.8 − 1.7 ∼ 56 ∼ 3.6 ∼ 56Mining hardware ∼ 0.6 − 1.3 ∼ 42 ∼ 2.7 ∼ 42Transaction validation ∼ 0.002 ∼ 0.2 ∼ 0.008 ∼ 0.2Bandwidth ∼ 0.02 ∼ 2 ∼ 0.08 ∼ 2Storage running cost ∼ 0.0008/5yearsTable 1 Bitcoin cost breakdown. Includes cost incurred by all nodes.amortized over all transactions. We stress that an EC2 micro instance and ahome-grade Internet connection provide sufficiently large computation/networkbandwidth at the operating scale of today’s Bitcoin.We note that it is a fallacy to assume that transaction costs necessarily haveto be offset by transaction fees. In particular, the operational costs of running fullnodes may be offset by financial externalities, such as being able to confirm one’sown transactions without trusting third parties, or by network effects, such asselling items whose costs factor in the cost of operating a node. Miners, however,are bereft of these two factors and need to be compensated in the steady state,especially as the block subsidy is reduced over time.Other metrics. The above is of course not an exhaustive list of potentiallyinteresting metrics. For example, while we have focused on Bitcoin’s role as atransaction medium, it also serves as a store of value. We might therefore considerthe cost per stored dollar as an alternative to CPCT. Many other metrics are ofinterest and it is an open research question which can best in technical andpolicy decisions.3 Scaling by Parameter Tuning and Fundamental LimitsThe Bitcoin community has several propositions under discussion for increas-ing the maximum block size or to remove the limit altogether [43]. Bitcoin Im-provement Proposals BIPs 100, 101, 102, and 103, all involve a fork, triggeredby a combination of time and miner buy-in as reflected in the blockchain [14,24, 27, 28, 51]. These proposals differ primarily on the initial date of the firstincrease, the block size change strategy none vs. linear vs repeated doublings vsoptional reductions, and the percent of miner buy-in to trigger a change. Thesegregated witness proposal [24] amends the blocksize by less than a factor of2 through a “soft fork” implementation, wherein legacy nodes do not need toupgrade, but end up implicitly trusting the miners with transaction validation.The developer community has been further fragmented into various proposalsCore, XT, Classic and Unlimited that embody different combinations of fea-tures and rollout schedules. There is, as of yet, no clear winner, partly becauseit is difficult to determine, a priori, which change schedule will best fit futurechanges in node provisioning. It is an open question whether reparametrizationalone can adequately address the growth needs of a medium-to-large transactionprocessing system. In the rest of this section, we explore its limitations.3.1 Measurement StudyA critical reference point for Bitcoin’s perance is Decker and Watten-hofer’s 20