Introducing SupraSTM: Faster Parallel Execution of EVM

Blockchains are transforming human society by enabling Byzantine fault-tolerant decentralized trust. Their potential is widely recognized as immense, but realizing this potential depends on designing efficient and effective systems. The Supra Layer 1 blockchain is built for extreme performance, offering vertically integrated services such as price feed oracles, verifiable randomness, automation, support for MultiVM (multiple smart contract platforms), blockchain interoperability solutions, and various innovations in Decentralized Finance (DeFi) applications.

To achieve this high level of integration, Supra Research rigorously examines every component and building block from both security and performance perspectives. Having led innovations in consensus and data dissemination, we now focus on making significant advancements in efficient blockchain transaction execution. This led us to explore the existing literature and state-of-the-art systems designed for optimizing transaction execution on multi-core validator machines.

In any smart contract platform, every node must arrive at the same final state. Traditional blockchains process their transactions sequentially — wherein every node executes each transaction one after another to maintain a consistent state. 

While sequential execution ensures consistency, it limits throughput, especially when many transactions don’t actually interfere with each other. In fact, our analysis of Ethereum workloads indicates that more than 60% of transactions can be parallelized. But what happens when they do? How to safely execute smart contract transactions in parallel when they conflict (i.e., overlapping read/write sets)? That’s the core challenge our research tackles, leading to our novel SupraSTM model that introduces a new specification-aware parallel execution strategy to optimize performance beyond what has been possible so far.

Let’s Look at an Example 

We consider two transactions, T1 and T2, that are required to execute in a specific order — T1 must come before T2 (denoted as T1 → T2). The execution scenario unfolds as follows with the two transactions accessing accounts A1 and A2 with values initiated to 0:

1. T1 Reads: T1 starts its execution by reading an account A1 and obtains the value 0.
   
2. T2 Reads and Writes: Immediately afterward, T2 begins executing. It reads another account, A2, and gets the value 0. Then, T2 writes a new value (say, 1) to account A1.
   
3. Potential Conflict Scenario: At this point, if T2 commits its changes before T1 has committed, T1 might later perform a write operation on account A2. This creates a problem: the write by T2 to A1, and T1’s later write to A2 lead to a final state that cannot be reconciled with any sequential execution that respects the intended order (T1 → T2).

• If T2 commits early:
  The system state becomes such that T2’s update to A1 is visible, and when T1 subsequently attempts to update A2, it does so based on the outdated assumption (that A2 still holds its original value 0). This ordering (with T2 committing before T1) is inconsistent with the preset order.

• If T1 aborts and restarts:
  T1, upon restarting, will read the updated value of A2 (now 1, because of T2’s earlier commit). This again results in an execution state that does not mirror any valid sequential execution of T1 before T2.

If T2 commits before T1, it might read an outdated balance for Account A2 — leading to an incorrect state. Even worse, if T1 later commits and writes its updates, the final state may not correspond to any valid sequential execution that respects the intended order (T1 → T2). The safe way to ensure that the final state remains consistent with the intended order (T1 → T2) is to enforce that T2 does not commit until T1 has committed. Note that transactions T1 and T2 are in conflict because they access a shared state and both perform reads and writes on that state.

We need to carefully manage these dependencies because if the execution order deviates from the intended sequence for conflicting transactions, it can easily lead to an inconsistent and unusable blockchain state. Some chains have applied optimistic execution strategies to manage this, but these strategies come with aborts and re-executions due to dependencies between the transactions, which creates substantial overhead. Determining the dependencies between transactions beforehand is crucial to minimizing this inefficiency. 

To identify such dependencies prior to execution, we are developing a Conflict Analyzer that helps minimize the overhead of optimistic execution. This gives us a precise pre-analysis of each transaction’s read and write sets using a confluence of techniques including static bytecode analysis and transaction input parameters (value transfer transactions). It also does not require transactions to be loaded with read and write sets, states being read and written during execution (Solana’s approach), which increases the bandwidth requirements, and thus dampens the maximum throughput possible due to bandwidth constraints.  

Our Approach: Specification Aware Parallel Execution

With this Conflict Analyzer, we introduce Specification Aware Parallel Execution, wherein the system’s threads (the ones executing the transactions) are made aware of dependencies before executing them. 

The conflict analysis helps the system detect that T2 depends on the outcome of T1, beforehand. Consequently, T2 is deferred until T1 completes, ensuring that dependent transactions are executed only when dependencies are resolved, therefore the final state remains deterministic and consistent. On the other hand, if T1 and T2 do not conflict — meaning they access entirely separate state — the Conflict Analyzer identifies the absence of dependencies. In that scenario, both transactions can be executed concurrently without waiting for one another, fully leveraging parallelism while preserving correctness. This is the power of Specification Aware Parallel Execution.

We may not have exact specifications all the time. All we need is safe specifications, which are over-approximate in the sense that when no conflict is indicated between two transactions then there is definitely no conflict for sure, but a specified conflict may be spurious.

It may not always be possible to schedule two non-conflicting transactions in parallel may be because of high conflict in the given ordered block of transactions. In that case the regular speculative strategy still comes into play, where a transaction is re-executed upon conflict. But we show in our paper that even though there are aborts and re-executions here, they come down significantly when conflict specifications are leveraged.

It allows the operators to execute transactions only after prerequisite dependencies have been resolved, reducing the number of redundant computations, while independent transactions could be executed in any order. By analyzing each transaction’s access patterns — specifically, their read and write sets — we can determine in advance which transactions are independent and which have dependencies. This pre-determination enables us to:

• Identify Conflicts Safely: Using static bytecode analysis and the inherent input parameters (like account addresses in token transfers), we extract the data dependencies before execution.
  

• Transform Linear Order into a Partial Order: With this knowledge, we can relax the strict sequential execution order. Independent transactions are grouped together for parallel processing, while those that might conflict are carefully ordered to maintain the blockchain’s integrity.
  

• Reduce Abort and Re-execution Rates: Traditional optimistic parallel execution methods, like those based on Software Transactional Memory (STM), may need to abort and re-execute transactions when conflicts are detected on the fly. By knowing these dependencies beforehand, our method minimizes costly aborts, leading to more efficient execution.

Algorithms

We developed and evaluated two distinct algorithms that embody our approach:

1. Specification Aware SupraSTM (SupraSTM):
   This algorithm constructs a Directed Acyclic Graph (DAG) where each vertex represents a transaction and edges denote conflicts. By tracking the indegree (i.e., the number of unresolved dependencies), transactions with an indegree of zero can be executed in parallel.
   
   Our experiments have shown that SupraSTM can achieve up to a 4× speedup over sequential execution and a 2.4× improvement over prior approaches. This method truly pushes the envelope in terms of parallel throughput when transaction dependencies are well characterized.
   
2. Specification Aware BlockSTM (saBlockSTM):
   This approach builds on the ideas behind optimistic execution (like the state-of-the-art Aptos BlockSTM) but smartly integrates conflict specification data via our Conflict Analyzer. In essence, saBlockSTM avoids unnecessary aborts by allowing transactions known to be independent to proceed without re-validation.
   
   This hybrid method not only boosts throughput but also lowers execution latency by reducing the overhead of aborts and re-executions.

Performance and Real-World Impact

We rigorously tested these algorithms on both the Ethereum Virtual Machine (EVM) and the MoveVM, using a mix of synthetic workloads (e.g., high-volume ERC20 transfers with tail-distributed account accesses) and real-world historical data (including blocks from critical periods like the CryptoKitties launch and the Ethereum 2.0 merge).

• EVM Experiments:
  • Over 60% of Ethereum transactions are shown to be parallelizable.
  • SupraSTM demonstrated up to a 4× speedup over sequential execution and a 2.4× improvement over existing approaches.
  • These improvements mean that during high network activity involving a lot of conflicting transactions, transaction finality will be significantly faster.
    
• MoveVM Experiments:
  • Our approach was tested on peer-to-peer value transfer workloads, showing marked improvements in throughput and reduced latency even when contention was high.
  • The success in both platforms illustrates the broad applicability of our conflict-aware execution model across different smart contract environments.

Not only does this demonstrate that our approach is broadly applicable across different smart contract systems (EVM and MoveVM), but it also lays out the extent of the impact these solutions can have on the key performance metrics which determine the quality of on-chain experience for users and developers alike. The key findings include:

• Higher Throughput: Significant increases in transactions per second (tps) were achieved, with parallel execution approaches vastly outperforming traditional sequential execution.
• Lower Latency: By minimizing conflict-induced aborts, both SupraSTM and saBlockSTM demonstrated lower execution latencies, ensuring that even during periods of heavy network activity, users experience swift execution finality.

What This Means for Supra and Our Community

At Supra, our commitment is to continuously push the boundaries of blockchain performance and scalability. This research is a cornerstone in our broader vision of a high-performance, resilient Layer 1 blockchain. With these innovations:

• Developers will be able to build more complex, data-intensive applications without worrying about the explicit requirements of read-write specifications and conflict synchronization during block execution.
• Users will benefit from faster transaction processing, even during high conflict executions.
• The Ecosystem as a whole will move closer to realizing truly scalable, secure, and efficient blockchain infrastructure.

Looking Ahead: The Future Roadmap

While these results are exciting, they are just the beginning. Our ongoing research includes:

• Expanding Multi-VM Support:
  Beyond EVM and MoveVM, we’re exploring integrations with additional virtual machines, like the SVM, to further broaden our platform’s capabilities.
• Further Optimizations:
  Continued efforts to reduce abort rates and enhance parallel execution techniques, pushing closer to the theoretical maximum performance.
• Adopting Statistical AI Techniques for Adaptive Parallel Execution Algorithms: The advantage of the conflict specification model proposed in this work is that it allows us to determine how many pairwise conflicts exist in a block of transactions. We demonstrate how we can leverage this for an adaptive implementation that can also handle high-conflict workloads. Specifically, by computing a conflict threshold for each block of transactions with minimal overhead, we deterministically fallback to sequential execution in case of high conflicts. We believe this will allow us to leverage statistical AI techniques in the future for adaptive parallel execution algorithms. 
• Enhanced Data Visualizations:
  Future posts will include detailed graphs and infographics that visually represent throughput, latency improvements, and other key metrics to make our progress even more accessible.
• Empirical study of Conflict Characteristics in Smart Contract VMs:
  We conducted a comprehensive analysis of historical data across two popular blockchain networks: Ethereum, and Solana. Our study focuses on two key aspects: transaction conflicts and the maximum theoretical parallelism within the historical blocks. By examining block-level characteristics both within individual blocks and across different historical periods, we aim to quantify the degree of transaction parallelism and assess how effectively it can be exploited. In particular, this study is the first of its kind to take advantage of historical transactional workloads to evaluate the distribution of transactional conflicts in blockchain networks. By offering a structured approach to analyze transactional conflicts, our research provides useful insights with ground truth for the development of efficient parallel execution approaches across various blockchain ecosystems. You can read about this in our white paper.

We believe that by sharing our progress and learnings, we can foster a more informed and excited community ready to leverage these advancements for real-world applications. If you love diving into the technical depths and geeking out over beautiful execution algorithms, please do explore the whitepaper to learn more. A detailed technical report including the full details of our conflict analyzer and the proofs of correctness for our STM algorithms will be available on the Arxiv Computing Repository soon.

Note: These developments are still in the final stages of research. While we ship Supra EVM today, these ideas will be slated for implementation once fully tested and built in upcoming network upgrades.