Adding concurrency to smart contracts

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.

[1]  Jason Teutsch,et al.  Demystifying Incentives in the Consensus Computer , 2015, CCS.

[2]  Daniel Davis Wood,et al.  ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER , 2014 .

[3]  Bradley C. Kuszmaul,et al.  Cilk: an efficient multithreaded runtime system , 1995, PPOPP '95.

[4]  Marko Vukolic,et al.  Non-determinism in Byzantine Fault-Tolerant Replication , 2016, OPODIS.

[5]  Maurice Herlihy,et al.  Transactional boosting: a methodology for highly-concurrent transactional objects , 2008, PPoPP.

[6]  Maurice Herlihy,et al.  Coarse-grained transactions , 2010, POPL '10.

[7]  Elaine Shi,et al.  Hawk: The Blockchain Model of Cryptography and Privacy-Preserving Smart Contracts , 2016, 2016 IEEE Symposium on Security and Privacy (SP).

[8]  Prateek Saxena,et al.  Making Smart Contracts Smarter , 2016, IACR Cryptol. ePrint Arch..

[9]  Elaine Shi,et al.  Step by Step Towards Creating a Safe Smart Contract: Lessons and Insights from a Cryptocurrency Lab , 2016, Financial Cryptography Workshops.

[10]  Nick Szabo,et al.  Formalizing and Securing Relationships on Public Networks , 1997, First Monday.

[11]  Satoshi Nakamoto Bitcoin : A Peer-to-Peer Electronic Cash System , 2009 .

[12]  Rachid Guerraoui,et al.  On the correctness of transactional memory , 2008, PPoPP.

[13]  Matthew J. Parkinson,et al.  The Push/Pull model of transactions , 2015, PLDI.

[14]  Sarita V. Adve,et al.  Parallel programming must be deterministic by default , 2009 .

[15]  Marko Vukolic,et al.  Hyperledger fabric: a distributed operating system for permissioned blockchains , 2018, EuroSys.

[16]  Maurice Herlihy,et al.  Software transactional memory for dynamic-sized data structures , 2003, PODC '03.

[17]  Eddie Kohler,et al.  Type-aware transactions for faster concurrent code , 2016, EuroSys.

[18]  Kunle Olukotun,et al.  Transactional predication: high-performance concurrent sets and maps for STM , 2010, PODC '10.

[19]  Miguel Oom Temudo de Castro,et al.  Practical Byzantine fault tolerance , 1999, OSDI '99.