Skip to main content

On Scaling Decentralized Blockchains

(A Position Paper)

Part of the Lecture Notes in Computer Science book series (LNSC,volume 9604)

Abstract

The increasing popularity of blockchain-based cryptocurrencies has made scalability a primary and urgent concern. We analyze how fundamental and circumstantial bottlenecks in Bitcoin limit the ability of its current peer-to-peer overlay network to support substantially higher throughputs and lower latencies. Our results suggest that reparameterization of block size and intervals should be viewed only as a first increment toward achieving next-generation, high-load blockchain protocols, and major advances will additionally require a basic rethinking of technical approaches. We offer a structured perspective on the design space for such approaches. Within this perspective, we enumerate and briefly discuss a number of recently proposed protocol ideas and offer several new ideas and open challenges.

Keywords

  • Block Size
  • Overlay Network
  • Maximum Throughput
  • Network Plane
  • Effective Throughput

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

This is a preview of subscription content, access via your institution.

Buying options

Chapter
USD   29.95
Price excludes VAT (USA)
  • DOI: 10.1007/978-3-662-53357-4_8
  • Chapter length: 20 pages
  • Instant PDF download
  • Readable on all devices
  • Own it forever
  • Exclusive offer for individuals only
  • Tax calculation will be finalised during checkout
eBook
USD   59.99
Price excludes VAT (USA)
  • ISBN: 978-3-662-53357-4
  • Instant PDF download
  • Readable on all devices
  • Own it forever
  • Exclusive offer for individuals only
  • Tax calculation will be finalised during checkout
Softcover Book
USD   79.99
Price excludes VAT (USA)
Fig. 1.

Notes

  1. 1.

    Although we define latency in Bitcoin as the time to obtain a single confirmation, some payment processors accept “zero-confirmation” transactions, while others follow common advice to wait for 6 confirmations before accepting a payment.

  2. 2.

    Transactions in our experiments are 190 bytes long, all that is needed for a basic money transfer; given the roughly 500 byte average size of Bitcoin transactions, the system would achieve 1.7 k tx/sec.

  3. 3.

    We adapt the term “view” from its meaning in database theory, where it refers to the result set of a stored query.

References

  1. https://en.bitcoin.it/wiki/Scalability

  2. https://en.bitcoin.it/wiki/Mining_hardware_comparison

  3. https://blockchain.info/charts/hash-rate

  4. https://blockchain.info/charts/n-transactions-per-block

  5. https://bitnodes.21.co/dashboard/?days=365

  6. https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2

  7. Amazon EC2 pricing. http://aws.amazon.com/ec2/pricing/. Accessed 30 Oct 2015

  8. Antminer S5+ hardware. https://bitmaintech.com/productDetail.htm?pid=0002015081407532655504JMKzsM067B. Accessed 30 Oct 2015

  9. Litecoin, open source P2P digital currency. https://litecoin.org

  10. How a Visa transaction works (2015). http://web.archive.org/web/20160121231718/http://apps.usa.visa.com/merchants/become-a-merchant/how-a-visa-transaction-works.jsp

  11. NXT.org, Decentralized Financial Ecosystem (2015). http://nxt.org/

  12. Shelat, A., Pass, R.: Micropayments for peer-to-peer currencies. In: CCS (2015)

    Google Scholar 

  13. Andresen, G.: Increase maximum block size (BIP 101). https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki. Accessed Oct 2015

  14. Awerbuch, B., Scheideler, C.: Towards a scalable and robust DHT. In: SPAA (2006)

    Google Scholar 

  15. Back, A., Corallo, M., Dashjr, L., Friedenbach, M., Maxwell, G., Miller, A., Poelstra, A., Timón, J., Wuille, P.: Enabling blockchain innovations with pegged sidechains. https://www.blockstream.com/sidechains.pdf. Accessed 26 Nov 2015

  16. Ben-Sasson, E., Chiesa, A., Tromer, E., Virza, M.: Scalable zero knowledge via cycles of elliptic curves. In: Garay, J.A., Gennaro, R. (eds.) CRYPTO 2014, Part II. LNCS, vol. 8617, pp. 276–294. Springer, Heidelberg (2014)

    CrossRef  Google Scholar 

  17. Ben-Sasson, E., Chiesa, A., Tromer, E. Virza, M.: Succinct non-interactive zero knowledge for a von neumann architecture. In: Security (2014)

    Google Scholar 

  18. Bentov, I., Lee, C., Mizrahi, A., Rosenfeld, M.: Proof of activity: extending bitcoin’s proof of work via proof of stake. https://eprint.iacr.org/2014/452/

  19. Corallo, M.: High-speed Bitcoin relay network, December 2015. https://github.com/TheBlueMatt/RelayNode

  20. Decker, C., Wattenhofer, R.: Information propagation in the Bitcoin network. In: IEEE P2P, pp. 1–10. IEEE (2013)

    Google Scholar 

  21. Decker, C., Wattenhofer, R.: A fast and scalable payment network with bitcoin duplex micropayment channels. In: Pelc, A., Schwarzmann, A.A. (eds.) SSS 2015. LNCS, vol. 9212, pp. 3–18. Springer, Heidelberg (2015)

    CrossRef  Google Scholar 

  22. Dolev, S., Tzachar, N.: Spanders: distributed spanning expanders. Sci. Comput. Prog

    Google Scholar 

  23. Eric Lombrozo, P.W., Lau, J.: Segregated witness (consensus layer). https://github.com/CodeShark/bips/blob/segwit/bip-codeshark-jl2012-segwit.mediawiki

  24. Escriva, R., Wong, B., Sirer, E.G.: Warp: Lightweight Multi-Key Transactions for Key-Value Stores. http://arxiv.org/abs/1509.07815

  25. Eyal, I., Gencer, A.E., Sirer, E.G., van Renesse, R.: Bitcoin-NG: a scalable blockchain protocol. Technical report, CoRR (2015)

    Google Scholar 

  26. Garzik, J.: Block size increase to 2MB (BIP 102). https://github.com/bitcoin/bips/blob/master/bip-0102.mediawiki. Accessed Oct 2015

  27. Garzik, J.: Making decentralized economic policy. http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf. Accessed Oct 2015

  28. Georgiou, C., Gilbert, S., Guerraoui, R., Kowalski, D.R.: Asynchronous gossip. J. ACM 60(2) (2013)

    Google Scholar 

  29. Glendenning, L., Beschastnikh, I., Krishnamurthy, A., Anderson, T.: Scalable consistency in Scatter. In: SOSP (2011)

    Google Scholar 

  30. Guerraoui, R., Huc, F., Kermarrec, A.-M.: Highly dynamic distributed computing with byzantine failures. In: PODC (2013)

    Google Scholar 

  31. Johansen, H.D., Renesse, R.V., Vigfusson, Y., Johansen, D.: Fireflies: a secure and scalable membership and gossip service. ACM Trans. Comput. Syst. (2015)

    Google Scholar 

  32. Karp, R., Schindelhauer, C., Shenker, S., Vocking, B.: Randomized rumor spreading. In: FOCS (2000)

    Google Scholar 

  33. King, S., Nadal, S.: PPCoin: Peer-to-Peer Crypto-Currency with Proof-of-Stake, August 2012

    Google Scholar 

  34. Kosba, A., Zhao, Z., Miller, A., Qian, Y., Chan, H., Papamanthou, C., Pass, R., Shelat, A., Shi, E.: How to use snarks in universally composable protocols. Cryptology ePrint Archive, Report 2015/1093 (2015). http://eprint.iacr.org/

  35. Law, C., Siu, K.-Y.: Distributed construction of random expander networks. In: IEEE INFOCOM, pp. 2133–2143 (2003)

    Google Scholar 

  36. Lewenberg, Y., Sompolinsky, Y., Zohar, A.: Inclusive block chain protocols. In: FC (2015)

    Google Scholar 

  37. Maxwell, G.: https://bitcointalk.org/index.php?topic=314467#msg3371194

  38. Minsky, Y., Trachtenberg, A., Zippel, R.: Set reconciliation with nearly optimal communication complexity. IEEE Trans. Inf. Theory (2003)

    Google Scholar 

  39. Nakamoto, S.: Bitcoin: A Peer-to-Peer Electronic Cash System (2009). http://bitcoin.org/bitcoin.pdf

  40. Parno, B., Howell, J., Gentry, C., Raykova, M.: Pinocchio: nearly practical verifiable computation. In: S&P (2013)

    Google Scholar 

  41. Poon, J., Dryja, T.: The bitcoin lightning network. https://lightning.network/lightning-network-paper.pdf. Accessed 26 Nov 2015

  42. Rizun, P.: A transaction fee market exists without a block size limit (2015)

    Google Scholar 

  43. Sen, S., Freedman, M.J.: Commensal cuckoo: secure group partitioning for large-scale services. SIGOPS Oper. Syst. Rev. (2012)

    Google Scholar 

  44. Shin, L.: Bitcoin blockchain technology in financial services: how the disruption will play out. Forbes, 14 September 2015

    Google Scholar 

  45. Sompolinsky, Y., Zohar, A.: Secure high-rate transaction processing in bitcoin. In: FC (2015)

    Google Scholar 

  46. TradeBlock. Bitcoin network capacity analysis. https://tradeblock.com/blog/bitcoin-network-capacity-analysis-part-1-macro-block-trends

  47. van Renesse, R., Dumitriu, D., Gough, V., Thomas, C.: Efficient reconciliation and flow control for anti-entropy protocols. In: LADIS (2008)

    Google Scholar 

  48. Wilson, L.: Average electricity prices around the world. http://shrinkthatfootprint.com/average-electricity-prices-kwh

  49. Wood, G.: Ethereum: a secure decentralized transaction ledger (2014). http://gavwood.com/paper.pdf

  50. Wuille, P.: Block size following technological growth (BIP 103). https://github.com/bitcoin/bips/blob/master/bip-0103.mediawiki. Accessed Nov 2015

  51. Xie, C., Su, C., Littley, C., Alvisi, L., Kapritsos, M., Wang, Y.: High-performance ACID via modular concurrency control. In: SOSP (2015)

    Google Scholar 

Download references

Acknowledgements

This work is supported in part by NSF grants CNS-1314857, CNS-1453634, CNS-1518765, CNS-1514261, CNS-1518899, a Packard Fellowship, a Sloan Fellowship, two Google Faculty Research Awards, and a VMWare Research Award.

Author information

Authors and Affiliations

Authors

Corresponding author

Correspondence to Christian Decker .

Editor information

Editors and Affiliations

Appendices

Appendix

A BFT Experiments (Consortium Consensus)

Table 3. Consortium blockchain scalability. Results of running PBFT over geographically distributed EC2 nodes for some representative (nk) parameterizations. As for any BFT protocol, the throughput drops as the number n of nodes increases. Conversely, in this small experiment, enlarging the batch size k may be seen to increase throughput at the cost of a small increase in latency.

Here we report on our experiments on BFT performance. Table 3 illustrates the attractiveness of BFT as a basis for the consensus layer in a cryptocurrency (given acceptance of its strong trust assumptions). Even with dozens of nodes, PBFT greatly outperforms Bitcoin in both transaction latency and throughput. Scaling to hundreds of nodes, however, would greatly degrade the performance of the system.

Experiments were conducted using t2.medium Amazon EC2 instances. The results are displayed in Table 3. The 4 node experiment represents a best-case setting; all nodes were located in the US East N. Virginia region. In all other experiments the nodes, plus a client furnishing transaction inputs but not participating in the consensus protocol, were evenly distributed across 8 geographical regions: Northern Virginia, Oregon, Northern California, Ireland, Frankfurt, Tokyo, Sydney, Sao Paulo. As instance costs vary by region, we conservatively assume each node incurs the highest observed fee of $0.10 per hour. We experimented with several batch sizes in order to locate the point at which each configuration becomes bandwidth bound. Here, a transaction message is 190 bytes in length and is modeled after a Bitcoin transaction, including a pay-to-public-key-hash scheme and a digital signature.

We observed that configurations with a larger number of nodes became bandwidth bound at smaller batch sizes. This is due to the primary node broadcasting each batch to every other node participating in the protocol. Increasing the batch size beyond this bound for a given configuration increases latency while leaving throughput relatively unchanged. For smaller batch sizes the bottleneck was local processing, primarily signature verification for the batch as a whole. Once an ordering of batches has been agreed upon and committed, individual transactions may be processed and verified independently from the consensus protocol. However, we expect to see a much larger slowdown when scaling to hundreds of nodes, as the number of messages in standard BFT protocols grows quadratically in the number of nodes.

B Use of SNARKs for Outsourcing View Computation

We now explain how SNARKs may be used to support computation of views by a service provider, rather than individually by every node in the network (as happens today). In our experiment, we assume that a simple view is adopted containing all users’ account balances.

To support the secure outsourcing of view derivation, the provider (or prover, as we might call it) must store the balance for each Bitcoin address used in the transactions so far. As in Bitcoin, we assume \(2^{160}\) possible public addresses. The prover will maintain a Merkle tree of height 160, where each leaf stores the balance of the public address identified by the path to the leaf. (Unused zero-balance leaves do not have to be stored explicitly.) Computing the initial digest of the tree when all balances are zero can be done by utilizing the similarity across levels. Later, when a transaction is received, the system checks the balance of the sender address, and if it is sufficient, transfers the desired amount to the receiver’s balance. (In case of a mining reward, the initial check is not necessary.) The prover then updates the ledger digests accordingly.

Using SNARKs, the service provider will be able to prove the correct application of a set of transactions, and the correct update of digests. We evaluated a SNARK circuit that checks and applies 25 1-sender 1-receiver transactions to the ledger. Each transaction in that case specifies the desired amount of money to be transferred. This is equivalent to 1-input 2-output transactions in Bitcoin, where one of the outputs is a remainder going back to the sender’s address, but the remainder does not have to be specified explicitly in our setting. The prover then outputs the modified digest with a vector representing which transactions were valid, and possibly the modified balances. To make the circuit efficient, we used a SNARK-friendly collision resistant function based on subset sum [16], at 80-bit of security as in [34]. To experiment at higher transaction rate, multiple circuits can be run in a nearly-parallel mode, by computing and feeding the next digest quickly from one circuit to the next one without waiting for the proof to complete.

Table 4 shows the estimated cost incurred by the prover (provider) and the verifiers (relying miners or consensus nodes) to produce the proof at multiple settings. We ran the experiment for the first case using an Amazon EC2 r3.8xlarge instance [7] (using 32-cores for the proof computation, and single core for verification) and using libsnark [17] as a backend, and estimated the overall performance and cost accordingly assuming throughputs of 7 tx/sec, and 10 tx/sec. The table shows that the computation cost for applying one transaction to the ledger is about $0.0154, but at high throughput, the waiting time for proof computation is about or more than 10 min (implying a higher delay if higher security level is used).

Table 4. Verifiable outsourcing of ledger storage and maintenance using SNARKs

By adopting SNARKs, miners no longer need to store the full ledger nor the necessary views to validate transactions. In this way, decentralized storage and replication of the ledger and views can be decomposed from the consensus protocol and the view computation. Additionally, in our current experiments, we assume that the consensus nodes are validating the signatures on the transactions, and this signature validation is not performed within SNARKs (otherwise the cost of SNARKs would be more expensive).

Rights and permissions

Reprints and Permissions

Copyright information

© 2016 International Financial Cryptography Association

About this paper

Cite this paper

Croman, K. et al. (2016). On Scaling Decentralized Blockchains. In: Clark, J., Meiklejohn, S., Ryan, P., Wallach, D., Brenner, M., Rohloff, K. (eds) Financial Cryptography and Data Security. FC 2016. Lecture Notes in Computer Science(), vol 9604. Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-662-53357-4_8

Download citation

  • DOI: https://doi.org/10.1007/978-3-662-53357-4_8

  • Published:

  • Publisher Name: Springer, Berlin, Heidelberg

  • Print ISBN: 978-3-662-53356-7

  • Online ISBN: 978-3-662-53357-4

  • eBook Packages: Computer ScienceComputer Science (R0)