Deferred Objects to Enhance Smart Contract Programming with Optimistic Parallel Execution

TL;DR

The paper tackles the bottleneck of smart-contract throughput caused by read-write conflicts in parallel blockchain execution. It introduces deferred objects as a programming abstraction to defer computations on shared data, coupled with RapidLane, an extension to Block-STM that records and replays deferred operations via logs and deltas, aided by a rolling commit mechanism for fine-grained finality. The approach enables optimistic parallel execution on contended workloads, achieving significant throughput gains (up to $12\times$ in production cases) on Aptos with workloads including sponsored transactions, NFT minting, and P2P transfers. This work provides a practical path to higher blockchain throughput by enabling more parallelism without sacrificing determinism, and it ships a production-ready implementation and benchmark suite to evaluate contended workloads.

Abstract

One of the main bottlenecks of blockchains is smart contract execution. To increase throughput, modern blockchains try to execute transactions in parallel. Unfortunately, however, common blockchain use cases introduce read-write conflicts between transactions, forcing sequentiality. We propose RapidLane, an extension for parallel execution engines that allows the engine to capture computations in conflicting parts of transactions and defer their execution until a later time, sometimes optimistically predicting execution results. This technique, coupled with support for a new construct for smart contract languages, allows one to turn certain sequential workloads into parallelizable ones. We integrated RapidLane into Block-STM, a state-of-the-art parallel execution engine used by several blockchains in production, and deployed it on the Aptos blockchain. Our evaluation shows that on commonly contended workloads, such as peer-to-peer transfers with a single fee payer and NFT minting, RapidLane yields up to $12\times$ more throughput.

Figures (16)

• Figure 1: On the right, a snippet of smart contract code which is being executed. The code uses a deferred object $\mathtt{a}$ which supports checked arithmetic via the $\mathtt{add}$ and $\mathtt{sub}$ methods. Both methods return $\mathtt{true}$ if there is no overflow or underflow. On the left, a parallel execution engine which captures the updates to $\mathtt{a}$ from the contract ($-5$, $+10$, and $-11$). Instead of reading the value of $\mathtt{a}$, its value is estimated to make a prediction about the outcomes of arithmetic operations. Also, modifications to the value stored inside the deferred object are delayed, thus eliminating read-write conflicts if the object is shared across multiple transactions.
• Figure 2: On the right, an example of a smart contract in the Move programming language which implements a simple counter (lines 4--18). Functions $\mathtt{initialize}$ and $\mathtt{increment}$ are used to, respectively, create a new counter and modify it. On the left, an example of four user transactions and their execution output, from top to bottom: 1) Transaction fails to increment the counter because it does not exist in the global state. Gas is still charged, updating the user's balance in the write-set. 2) Transaction initializes a counter. 3) Transaction successfully increments the counter. 4) Transaction runs out of gas due to insufficient gas budget. The counter is not modified, but gas is still charged.
• Figure 3: Example of a smart contract written in Move that implements logic to sell tickets. Users call the $\mathtt{claim}$ function, and if tickets are still available, a $\mathtt{Ticket}$ is stored in the global state under their address. If all tickets are sold out, the call aborts. The figure shows two different implementations of this smart contract: without (lines 13--27) and with (lines 28--45) deferred objects.
• Figure 4: On the left, an example code snippet using three deferred objects $\mathtt{a1, a2, a3}$ with comments that specify the estimated outcomes of preconditions during execution. On the right, the corresponding set of logs. Object $\mathtt{a1}$ is created, and so row 0 of the log shows the initial value. Object $\mathtt{a2}$ already existed (e.g., it was created by another transaction), and so row 0 of the log is none. Because the precondition of f failed, the corresponding log entry is false. Object $\mathtt{a3}$ is derived from $\mathtt{a2}$ and is initialized with the prefix of the log of $\mathtt{a2}$.
• Figure 5: Example of revealing the deferred object $\mathtt{a3}$ in transaction 5. Revealing traverses preceding transactions for deferred objects (in red) to identify all logs needed for replay. The initial value of the deferred object is retrieved from storage.