Source-linked AI summary
Adding Concurrency to Smart Contracts
Thomas Dickerson, Paul Gazzillo, Maurice Herlihy, Eric Koskinen
TL;DR
Serial smart-contract execution limits throughput even though contracts share state and have sequential semantics, while nondeterministic speculative execution cannot be replayed reliably by validators. The paper adapts STM techniques so miners discover serializable concurrent schedules and validators replay them deterministically through fork-join programs. A prototype reports overall speedups of 1.33x for miners and 1.69x for validators with three threads.
Problem
Serial execution limits smart-contract throughput, while shared state and Turing-complete code make safe parallelization and deterministic re-execution difficult.
Method
Miners execute contract invocations speculatively in parallel, record a serializable schedule, and validators replay it as a deterministic concurrent fork-join program.
Results
1.33x miner and 1.69x validator overall speedups were achieved with three concurrent threads on representative smart contracts.
Takeaways & Limitations
Multi-core architectures can increase smart-contract processing throughput for both miners and validators within the proposed execution model.
Takeaways & Limitations
Speculative mining risks synchronization conflicts that can trigger rollback and re-execution, delaying block construction and adding uncompensated work.
Abstract
from arXiv · showhide
Modern cryptocurrency systems, such as Ethereum, 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. Smart contract benchmarks run on a JVM with ScalaSTM show that a speedup of of 1.33x can be obtained for miners and 1.69x for validators with just three concurrent threads.
1 Introduction
Smart contracts currently execute serially despite shared-state conflicts and unknown access patterns limiting safe parallelism. The paper proposes speculative miner execution and deterministic validator replay using the discovered serializable schedule.
- Execution model: Smart contracts execute serially during mining and validation, limiting throughput and multicore utilization.Miners execute transactions before proposing blocks; validators repeatedly re-execute them to check state transitions.
- Concurrency barrier: Shared state can make parallel execution inconsistent, while Turing-complete contract code prevents statically determining conflicts.Safe parallelism therefore requires runtime conflict handling rather than advance conflict analysis.
- Proposed approach: STM-style speculative execution lets non-conflicting contract invocations proceed concurrently while runtime conflicts are delayed or rolled back.The resulting execution dynamically discovers a serializable concurrent schedule equivalent to some serial order.
- Validation challenge: Validators cannot safely mimic nondeterministic speculative execution because they may derive a different serialization and final state.Deterministic re-execution is required for validation.
- Evaluation: 1.33x miner and 1.69x validator speedups were obtained with three concurrent threads in a JVM/ScalaSTM prototype.The evaluation used smart-contract examples drawn from Solidity documentation.
2 Blockchains and Smart Contracts
Ethereum-style blockchains store executable smart-contract transactions alongside their resulting state. Contracts manage persistent state through functions, and miners and validators execute those functions to produce or verify state transitions.
- Blockchain state: Ethereum blocks contain smart-contract code and the final state produced by executing transactions.This state captures the cumulative effect of transactions in prior blocks.
- Contract state: Solidity state variables include scalars, structures, arrays, and mappings stored persistently in the contract.A mapping can associate Ethereum addresses with structured voter data.
- Sequential semantics: Sequential execution prevents a race condition such as double voting in the Ballot contract.A repeated vote can trigger an abort that discards transient state and tentative storage changes.
3 Speculative Smart Contracts
The speculative execution design runs smart contracts concurrently while using runtime synchronization to preserve serializable behavior. It combines abstract locks and inverse logs, with rollback for conflicts and fine-grained concurrency for commuting operations.
- Conflict detection: Turing-complete contracts require runtime conflict detection because shared storage accesses cannot be determined statically.The system instruments contract data structures to detect synchronization conflicts.
- Speculative execution: Speculative actions let miners schedule multiple contracts concurrently and resolve conflicts by delaying, aborting, or restarting executions.Successful actions commit; unsuccessful actions abort.
- Runtime mechanisms: Abstract locks serialize non-commuting storage operations, while inverse logs record how to undo speculative effects.Locks are acquired before operations, and inverse operations are replayed in reverse order after aborts.
- Granularity: Fine-grained concurrency is supported because abstract locks distinguish semantic commutativity more precisely than memory-region locks.Coarse-grained locks could treat commuting operations as false conflicts.
- Nested calls: Nested contract calls create nested speculative actions that may commit or abort independently of their parents.Committed nested locks and inverse logs are transferred to the parent; aborted effects are undone.
- Trade-offs: Moderate data conflicts can still allow small degrees of speculative concurrency to pay off.Mining gains are possible, but conflicts can cause rollback, re-execution, and delays that are not compensated by client fees.
4 Concurrent Validation
Validators can deterministically replay a miner’s speculative concurrent schedule by using recorded lock dependencies to construct a fork-join program. This removes speculative synchronization mechanisms during validation while preserving the schedule’s conflict ordering.
- Miner schedule capture: Lock-profile counters reveal which transactions can run concurrently and which must follow earlier commits.Transactions without shared abstract locks can run concurrently; differing counter values impose ordering constraints.
- Miner schedule capture: Miners record lock profiles and a happens-before graph while speculatively executing transactions in parallel.The miner logs locking operations, derives the graph, and produces a serial ordering for the block.
- Deterministic validator construction: The resulting validator program uses only forks and joins, so conflicting actions never execute concurrently and dynamic conflict handling is unnecessary.Validators do not need abstract locks, conflict detection, or rollback, and may use available parallelism different from the miner’s.
- Deterministic validator construction: Validators reconstruct the schedule as fork-join tasks from the miner’s serial ordering and happens-before graph.Each task joins its immediate prerequisites before executing its transaction.
- Validation and incentives: Validators compare thread-local lock traces with the miner’s profiles and reject the block when the traces differ.The scheme also raises an incentive question: miners might publish a correct but slower sequential schedule unless parallel schedules are rewarded.
5 Correctness
The concurrency scheme is designed to preserve serializable smart-contract behavior despite concurrent execution. Validators check the published schedule by replaying it and comparing its resulting state and race behavior with the block’s record.
- Serializability: Concurrent contract execution must remain equivalent to some sequential execution to avoid inconsistent persistent storage states.Because miners can choose transaction order in a block, any equivalent sequential history suffices.
- Serializability: Transactional boosting provides serializability because noncommuting storage operations acquire the same lock and conflicting executions are delayed or aborted.The argument also relies on finite operation sequences ensured by Ethereum’s gas restriction.
- Validator checking: Validators need not reproduce the miner’s exact schedule, provided both are equivalent to a common sequential history.They replay the published schedule and detect a different final state or a data race.
6 Implementation
The prototype runs smart-contract concurrency experiments on the JVM using ScalaSTM, translating Solidity examples into Scala and instrumenting execution to recover locking schedules.
- Prototype platform: Because the EVM is not multithreaded, the prototype executes speculative actions on the Java Virtual Machine with ScalaSTM.ScalaSTM supplies the software transactional memory used for speculative execution.
- Contract translation: Solidity contract examples are translated into Scala, with functions wrapped in ScalaSTM atomic sections and mappings implemented as boosted hashtables.Solidity structs become immutable case classes, and methods receive a msg field to emulate contract behavior.
- Execution and instrumentation: Java’s ExecutorService runs transaction callables in parallel while instrumentation logs atomic sections and boosted operations to encode happens-before graphs.Solidity throw is emulated with a caught Java runtime exception, and ScalaSTM supplies native deadlock detection and resolution.
7 Experimental Evaluation
The evaluation varies block size and data conflict across conservative smart-contract benchmarks, measuring parallel miners and validators against serial mining. Speedups increase with larger blocks but decline as conflicts rise, with validators generally benefiting more.
- Benchmarks: The benchmarks vary transaction count and data conflict across Ballot, SimpleAuction, EtherDoc, and Mixed workloads.Blocks contain 10–400 transactions at 15% conflict, or 200 transactions with conflict ranging from 0% to 100%.
- Block size: For low transaction counts, parallel execution provides no speedup or can slow down, while blocks exceeding about 50 transactions approach 2x speedup.The observed slowdown is attributed to data conflict and multithreading overhead; EtherDoc remains below 1.5x.
- Data conflict: As data conflict rises in 200-transaction blocks, miner speedup falls from 2x toward serial performance, while validator speedup declines from about 2x to about 1.5x.Higher conflict causes more transactions to access shared data; the validator retains more benefit from the miner’s schedule.
- Benchmark differences: Ballot’s mining speedup stays near 1.5x under increased conflict, whereas SimpleAuction and EtherDoc lose more parallelism because contending transactions share data.The Mixed benchmark still achieves substantial mining speedup despite EtherDoc’s reduced parallelism at high conflict.
- Aggregate results: 1.33x is the average speedup for parallel mining and 1.69x for validation across all benchmarks.Experiments used three concurrent threads on a four-core machine, with serial execution as the speedup baseline.
- Discussion: Speculative concurrent execution speeds up mining when threads are occupied and data conflict is not too high.The experiments used only three concurrent threads because of hardware limitations.
8 Related Work
The related work situates smart contracts within earlier blockchain and contract-language systems, surveys smart-contract security and privacy research, and connects the approach to concurrency techniques for software transactional memory and deterministic replay.
- Smart-contract platforms: Bitcoin uses a deliberately limited scripting language, whereas Ethereum uses a Turing-complete virtual machine with client charges to prevent nontermination.Solidity is identified as the most popular language for programming Ethereum contracts.
- Smart-contract research: Prior smart-contract research addresses Ethereum vulnerabilities, miner incentives, programming errors, and privacy protection through systems such as Hawk.These works cover security, rational-miner behavior, common errors, and participant privacy.
- Concurrency techniques: The concurrency mechanisms adapt transactional boosting and relate to transactional predication and other type-specific techniques for improving STM concurrency.Transactional boosting transforms thread-safe linearizable objects into highly concurrent transactional objects.
- Deterministic replay: Deterministic reproduction of prior concurrent executions has also been studied in earlier work surveyed by Bocchino et al.The paper places its deterministic replay scheme within this broader line of research.
9 Conclusion
The paper shows that miners and validators can execute smart contracts concurrently using speculative scheduling and deterministic fork-join validation. A prototype achieved speedups for both roles with three threads, while full deployment requires changes to current systems.
- Miners execute contracts speculatively and in parallel, producing lower latency when block contracts lack data conflicts.
- Validators convert the miner’s serializable schedule into a deterministic parallel fork-join program for block validation.
- 1.33x miner speedup and 1.69x validator speedup were achieved with only three threads on representative smart contracts.
- The overall proposal is incompatible with current smart contract systems because blocks must include scheduling metadata and miners must be incentivized to publish schedules.
A Example Contract: Ballot
The Ballot contract stores proposals and voter records, supports voting and delegation, and computes the winning proposal. Access checks, rollback behavior, and gas limits constrain its execution.
- State and initialization: The contract defines proposal and voter data, including names, vote counts, voting status, delegation targets, proposal indices, and voter weight.
- State and initialization: Ballot initializes proposals from supplied names and gives voters the right to vote, with the latter operation restricted to the chairperson.
- Execution constraints: Incorrect calls can throw and revert state and Ether-balance changes, while delegation loops may exceed block gas and leave a contract stuck.
- Contract operations: The contract supports casting a vote, delegating a vote, and computing and returning the winning proposal’s name.
B Mean and Standard Deviation of Benchmark Running Times
The benchmark materials distinguish measurements by transaction count at a fixed conflict rate and by conflict percentage for a fixed transaction count.
- One benchmark dimension is number of transactions with 15% conflict.
- The supplied benchmark labels do not state the corresponding running-time values or comparisons.
- Another benchmark dimension is conflict percentage for 200 transactions.