Skip to main content
SpringerLink
Log in

Adding concurrency to smart contracts

  • Published:
Distributed Computing Aims and scope Submit manuscript

Abstract

Modern cryptocurrency systems, such as the Ethereum project, permit complex financial transactions through scripts called smart contracts. These smart contracts are executed many, many times, always without real concurrency. First, all smart contracts are serially executed by miners before appending them to the blockchain. Later, those contracts are serially re-executed by validators to verify that the smart contracts were executed correctly by miners. Serial execution limits system throughput and fails to exploit today’s concurrent multicore and cluster architectures. Nevertheless, serial execution appears to be required: contracts share state, and contract programming languages have a serial semantics. This paper presents a novel way to permit miners and validators to execute smart contracts in parallel, based on techniques adapted from software transactional memory. Miners execute smart contracts speculatively in parallel, allowing non-conflicting contracts to proceed concurrently, and “discovering” a serializable concurrent schedule for a block’s transactions, This schedule is captured and encoded as a deterministic fork-join program used by validators to re-execute the miner’s parallel schedule deterministically but concurrently. We have proved that the validator’s execution is equivalent to miner’s execution. Smart contract benchmarks run on a JVM with ScalaSTM show that a speedup of 1.39\(\times \) can be obtained for miners and 1.59\(\times \) for validators with just three concurrent threads.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Log in via an institution

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6
Fig. 7
Fig. 8

Similar content being viewed by others

Notes

  1. Following blockchain terminology, a transaction is a payment or set of payments, not an atomic unit of synchronization as in databases or transactional memory.

  2. This description omits many important issues, such as incentives, forking, and fork resolution.

  3. http://solidity.readthedocs.io/en/develop/solidity-by-example.html.

  4. For ease of exposition, abstract locks are mutually exclusive, although it is not hard to accommodate shared and exclusive modes.

  5. The Push/Pull model is more general, allowing code outside of a transaction.

  6. For brevity, we rely on the reader’s intuition of commutativity rather than reiterating the formalization here.

  7. https://theethereum.wiki/w/index.php/ERC20_Token_Standard.

  8. A transaction costs 21,000 gas plus the gas for the computation [24]. The gas limit on block 3,110,235 (latest as of writing) was 4,005,875, a maximum close to 200.

  9. https://github.com/maran/notareth.

  10. https://github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/token/StandardToken.sol.

References

  1. Androulaki, E., Barger, A., Bortnikov, V., Cachin, C., Christidis, K., De Caro, A., Enyeart, D., Ferris, C., Laventman, G., Manevich, Y., et al.: Hyperledger fabric: a distributed operating system for permissioned blockchains. In: Proceedings of the Thirteenth EuroSys Conference, ACM, p. 30 (2018)

  2. Blumofe, R.D., Joerg, C.F., Kuszmaul, B.C., Leiserson, C.E., Randall, K.H., Zhou, Y.: Cilk: an efficient multithreaded runtime system. In: Proceedings of the Fifth ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming, PPOPP ’95, ACM, New York, NY, USA, pp. 207–216 (1995). https://doi.org/10.1145/209936.209958

  3. Bocchino Jr., R.L., Adve, V.S., Adve, S.V., Snir, M.: Parallel programming must be deterministic by default. In: Proceedings of the First USENIX Conference on Hot Topics in Parallelism, HotPar’09, USENIX Association, Berkeley, CA, USA, pp. 4–4 (2009). URL http://dl.acm.org/citation.cfm?id=1855591.1855595

  4. Bronson, N.G., Casper, J., Chafi, H., Olukotun, K.: Transactional predication: high-performance concurrent sets and maps for stm. In: Proceedings of the 29th ACM SIGACT-SIGOPS Symposium on Principles of Distributed Computing, PODC ’10, ACM, New York, NY, USA, pp. 6–15 (2010). https://doi.org/10.1145/1835698.1835703

  5. Cachin, C., Schubert, S., Vukolic, M.: Non-determinism in byzantine fault-tolerant replication. In: Fatourou, P., Jiménez, F., Pedone, F. (eds.) 20th International Conference on Principles of Distributed Systems (OPODIS 2016), Leibniz International Proceedings in Informatics (LIPIcs), vol. 70, Schloss Dagstuhl–Leibniz-Zentrum fuer Informatik, Dagstuhl, Germany, pp. 24:1–24:16 (2017). https://doi.org/10.4230/LIPIcs.OPODIS.2016.24. http://drops.dagstuhl.de/opus/volltexte/2017/7093

  6. Castro, M., Liskov, B.: Practical byzantine fault tolerance. In: Proceedings of the Third Symposium on Operating Systems Design and Implementation, OSDI ’99, USENIX Association, Berkeley, CA, USA, pp. 173–186 (1999). URL http://dl.acm.org/citation.cfm?id=296806.296824

  7. DAO: Thedao smart contract. Retrieved 8 February (2017)

  8. Delmolino, K., Arnett, M., Kosba, A., Miller, A., Shi, E.: Step by Step Towards Creating a Safe Smart Contract: Lessons and Insights from a Cryptocurrency Lab, Springer, Berlin, pp. 79–94 (2016). https://doi.org/10.1007/978-3-662-53357-4_6

  9. Ethereum: https://github.com/ethereum/

  10. Ethereum design Rationale: http://github.com/ethereum/wiki/wiki/Design-Rationale#gas-and-fees

  11. Herlihy, M., Koskinen, E.: Transactional boosting: a methodology for highly-concurrent transactional objects. In: Proceedings of the 13th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming, PPoPP ’08, ACM, New York, NY, USA, pp. 207–216 (2008). https://doi.org/10.1145/1345206.1345237

  12. Herlihy, M., Luchangco, V., Moir, M., Scherer III, W.N.: Software transactional memory for dynamic-sized data structures. In: Proceedings of the Twenty-second Annual Symposium on Principles of Distributed Computing, PODC ’03, ACM, New York, NY, USA, pp. 92–101 (2003). https://doi.org/10.1145/872035.872048

  13. Herman, N., Inala, J.P., Huang, Y., Tsai, L., Kohler, E., Liskov, B., Shrira, L.: Type-aware transactions for faster concurrent code. In: Proceedings of the Eleventh European Conference on Computer Systems, EuroSys ’16, ACM, New York, NY, USA, pp. 31:1–31:16 (2016). https://doi.org/10.1145/2901318.2901348

  14. Hyperledger white paper. http://www.the-blockchain.com/docs/Hyperledger

  15. Kosba, A.E., Miller, A., Shi, E., Wen, Z., Papamanthou, C.: Hawk: the blockchain model of cryptography and privacy-preserving smart contracts. In: IEEE Symposium on Security and Privacy (2015)

  16. Koskinen, E., Parkinson, M.J.: The push/pull model of transactions. In: Proceedings of the 36th ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI’15), Portland, OR, USA. ACM (2015)

  17. Luu, L., Chu, D., Olickel, H., Saxena, P., Hobor, A.: Making smart contracts smarter. In: Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, Vienna, Austria, October 24–28, pp. 254–269 (2016)

  18. Luu, L., Teutsch, J., Kulkarni, R., Saxena, P.: Demystifying incentives in the consensus computer. In: Proceedings of the 22Nd ACM SIGSAC Conference on Computer and Communications Security, CCS ’15, ACM, New York, NY, USA, pp. 706–719 (2015). https://doi.org/10.1145/2810103.2813659

  19. Nakamoto, S.: Bitcoin: A peer-to-peer electronic cash system (2009). URL http://www.bitcoin.org/bitcoin.pdf

  20. Scala STM Expert Group.: Scalastm. web. Retrieved from http://nbronson.github.com/scala-stm/, 20 November (2011)

  21. Solidity documentation: http://solidity.readthedocs.io/en/latest/index.html

  22. Solidity documentation: Solidity by example: http://solidity.readthedocs.io/en/develop/solidity-by-example.html

  23. Szabo, N.: Formalizing and securing relationships on public networks. First Monday 2(9) (1997). http://firstmonday.org/ojs/index.php/fm/article/view/548

  24. Wood, G.: Ethereum: a secure decentralised generalised transaction ledger. http://gavwood.com/Paper.pdf

  25. Why do smart contract languages need to be deterministic? https://ethereum.stackexchange.com/questions/3557/why-do-smart-contract-languages-need-to-be-deterministic

Download references

Author information

Authors and Affiliations

  1. Brown University, Providence, RI, USA

    Thomas Dickerson & Maurice Herlihy

  2. Stevens Institute, Hoboken, NJ, USA

    Paul Gazzillo

  3. University of Central Florida, Orlando, FL, USA

    Eric Koskinen

Authors
  1. Thomas Dickerson
    View author publications

    You can also search for this author in PubMed Google Scholar

  2. Paul Gazzillo
    View author publications

    You can also search for this author in PubMed Google Scholar

  3. Maurice Herlihy
    View author publications

    You can also search for this author in PubMed Google Scholar

  4. Eric Koskinen
    View author publications

    You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Eric Koskinen.

Additional information

Publisher's Note

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Supported in part by National Science Foundation CCF Awards #1421126, #003991, and #1618542.

Rights and permissions

Reprints and permissions

About this article

Check for updates. Verify currency and authenticity via CrossMark

Cite this article

Dickerson, T., Gazzillo, P., Herlihy, M. et al. Adding concurrency to smart contracts. Distrib. Comput. 33, 209–225 (2020). https://doi.org/10.1007/s00446-019-00357-z

Download citation

  • Received:

  • Accepted:

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s00446-019-00357-z

Keywords

Search

Navigation