Supra L1’s Parallel Execution Strategy: Exploiting Parallelism for Extreme Performance

In the fast-evolving world of Web3, scalability has always been a major challenge. Most blockchains today are still stuck in a single-threaded execution model, where transactions are processed one at a time. This creates bottlenecks and limits how much real-world activity can be handled on-chain. Supra is built to change that.

At Supra, we recognize that to truly scale Web3, we need to take advantage of parallel execution — running multiple transactions at the same time — without sacrificing security or consistency. Parallelizing blockchain execution sounds straightforward, but the reality is complex. If transactions aren’t carefully ordered and managed, the outcome could be completely different from what users expect. Getting it right means balancing speed, order, and correctness, while minimizing overhead. We’ve solved this with a three-tier parallel execution design that unlocks unparalleled scale and efficiency for Web3.

Why is Parallel Execution Difficult?

In a traditional blockchain, every transaction must be executed in sequence. This ensures the correct order and outcome, but it also severely limits throughput. As we try to scale blockchain applications — whether they’re financial transactions, decentralized exchanges, or complex smart contracts — this single-threaded model simply won’t cut it.

Here’s the issue: when two transactions interact with the same data, like an account balance, their order matters. Imagine one transaction sends tokens from Account A to Account B, and another tries to send tokens from Account B to Account C. If the second transaction happens before the first one, the balance in Account B might be wrong, causing the entire system to break. Conflicts like these must be managed carefully, or you end up with an inconsistent, unusable blockchain state.

At Supra, we’ve addressed this challenge with a three-tier strategy that makes it possible to run many transactions at once, without compromising correctness. Let’s break it down.

Supra L1: Built for Parallelization from the Ground Up

We’ve designed the Supra L1 network from the ground up to maximize parallel execution. It’s not just a parallelization algorithm at play here, but even how the network is structured plays a key role in how we process and execute transactions in an increasingly parallelized manner.

Let’s walk through how this system is structured:

Clans: The First Layer of Parallel Execution

At the broadest level, the Supra network is divided into Clans. Think of the whole network as a Tribe, which is divided into subcommittees of nodes called Clans, with each responsible for processing a subset of overall transactions. This structure allows the network to process many different transaction batches at the same time, across various Clans.

By splitting the network into multiple Clans, Supra achieves broad-level parallelization — transactions are divided among Clans, allowing many to be processed simultaneously and increasing the execution capacity of  the entire network.  Each Clan operates independently, processing its assigned transactions while maintaining the security and correctness guarantees of the entire network. This approach allows us to massively scale the number of transactions that can be processed at any given time. This is the first key to scaling: dividing the workload into separate payloads that can run in parallel.

Virtual Machines (VMs) Within Clans: Specialized Parallel Execution

Finally, each Clan is responsible for specific Virtual Machines (VMs) — these VMs are environments where smart contracts and transactions run. While this MultiVM support in itself is a unique characteristic of the Supra blockchain, it also ensures that each group of transactions is handled separately, within the Clan itself.

This is where we introduce specialized parallelization algorithms for each VM — starting with MoveVM and EVM. Supra’s system is designed to analyze transactions upfront, identifying which parts of the blockchain’s data (like account balances) each transaction will read from or write to. This helps the network avoid conflicts because it knows ahead of time which transactions can be safely executed in parallel.

Now, in most blockchains that are introducing parallel execution strategies and algorithms for deterministic parallel execution of transactions across multiple cores, they typically have to choose one of two approaches: read-write oblivious execution and read-write aware execution.

The read-write oblivious execution approach runs transactions without knowing in advance which parts of the blockchain (accounts or data) they will interact with. Conflicts (where two transactions try to change the same data) are discovered after the fact. This simplifies implementation and avoids the need for pre-analysis, making it suitable for systems with low levels of data overlap between transactions. However, it significantly restricts parallelism since the system must conservatively assume all transactions could conflict, leading to frequent aborts and retries when conflicts arise. While simple, this model struggles to fully utilize the available computational resources in high-demand scenarios.

By contrast, read-write aware models analyze transactions beforehand to know which data they will read or write. It sends this information to the validators upfront to minimize conflicts. Additionally, we also introduce novel conflict extraction techniques and succinct data structures to minimize overheads this might entail. They require transactions to share their data dependencies (which accounts they will read or write) upfront. This knowledge allows the system to identify non-conflicting transactions and execute them in parallel, greatly improving efficiency and reducing conflicts. However, this approach introduces additional computational and communication overhead to collect and share dependency information. It may also raise privacy concerns, as transaction details are shared with validators. 

Software Transactional Memory (STM) techniques are well known in the traditional space for executing programs across multiple cores in parallel. BlockSTM adapted this to the context of executing blockchain transactions. The core idea is to optimistically execute transactions in parallel on any available core on a validator node, and then validate if the execution of a transaction resulted in a conflict owing to a dependency with respect to another transaction.

At Supra, we have innovated a novel STM based scheduler-less parallelized execution algorithm that is comparable to Aptos’ BlockSTM. After studying both read-write oblivious and aware approaches, we’ve found this to be the best way forward. It can be considered a hybrid approach which creates a “Goldilocks” specification of the preset order of transaction execution. This is what will allow us to scale with parallel execution efficiently without causing too much communication overhead. We are performing extensive evaluations on this design.

How does this work? 

1. Our algorithm conducts a static analysis of the smart contract code to derive access specifications of the requested transactions.
   
2. Then, based on these specifications it builds a conflict dependency set. This essentially is able to identify which transactions are definitely not going to conflict with each other.
   
3. This lets the algorithm execute all non-conflicting transactions in their own parallels across available cores, exploiting the access specifications to maximize parallelization. 

This technique is proving to be highly optimized for efficient handling of transaction conflict workloads. Additionally, it can also take the read-write aware specification as input for when necessary, improving parallel execution by identifying transaction conflicts upfront.

Finally, we’ve optimized our parallel execution strategies and implementation individually for both the EVM and MoveVM, making sure we can maximize the parallelism and get the best performance out of both systems.

Supra Containers: Further Fine-Grained Parallel Execution

In the context of parallelization; within each Clan in the network, we will also introduce Supra Containers, which can provide fine-grained access specifications to further enhance parallel execution across the network.

Supra Containers provide the experience of Appchain to the developers and users without bootstrapping separate blockchain networks like Polkadot Paracains, Cosmos Zones, Avalanche Subnets or Layer 2s. Technically a Supra Container is a group of smart contracts related to a single dApp or a group of related dApps. Most importantly they facilitate the business models of the dApp creators and empower their community by providing gated deployment of smart contracts and setting of custom gas tokens and custom gas fee pricing. For more details, please explore the Supra Containers whitepaper.

How does this affect parallelization? Each Supra Container effectively groups a chunk of transactions within its dedicated execution space. Transactions within these Supra Containers, within the group of smart contracts deployed within them, can be executed in parallel without interacting with each other. These are also called intra-Container transactions. This adds a layer of parallelization and efficiency to the network as a whole.

Please note: The ability to exploit the containerized access specification is different for MoveVM and EVM. There may also be some cross-Container transactions which cannot be parallelized in the way intra-Container transactions can.

By separating smart contracts that often interact, Supra Containers allow transactions to execute more efficiently inside the Clan without needing constant checks to avoid conflicts. Each Supra Container has a set of well defined access specifications, meaning that most smart contract transactions here will only call functions across the same pre-determined contracts. This not only gives more control to the builders and Supra Container owners, but also ensures that cross-container calls are minimized, significantly reducing the chances of conflicting transactions.

Think of this like running multiple applications simultaneously on your phone. Most apps (transactions) run on their own, only interacting with other apps when absolutely necessary. This setup creates identifiers to manage the workload better, allowing for faster and more efficient processing.

For example, a Web3 Play-to-Earn (P2E) game could run entirely within its own Container. Most of its transactions — like in-game purchases, rewards, and actions — are handled internally. The game only interacts with other applications, such as a decentralized exchange (DEX) for trading in-game tokens and NFTs, when needed. This separation prevents unnecessary data overlap and conflict, further boosting parallel execution performance.

Minimize Conflict, Maximize Parallelism

Supra’s parallel execution model is designed to minimize conflict and maximize efficiency. By organizing transactions at multiple levels — Clans, VMs, and Containers — we ensure that transactions are grouped logically and can be executed in parallel without interfering with each other.

By identifying dependencies upfront, we can avoid unnecessary rollbacks and retries, making our system far more efficient than traditional blockchains. This allows the network to automatically separate the transactions that need special handling, making the whole process more streamlined, smooth, and conflict-free. This methodology is bound to outperform the current state-of-the-art, which often require more extensive communication between nodes and lead to performance bottlenecks.

Supra Layer 1 Can Scale Both Vertically and Horizontally

Supra’s architecture is designed to scale both vertically and horizontally, ensuring flexibility and performance as the network grows.

• Vertical Scaling: Supra can scale vertically by optimizing each Virtual Machine (VM) to handle more transactions and users. By improving throughput and introducing advanced optimizations, we can extract more power from each VM, allowing them to process more smart contracts and transactions without needing to add new infrastructure. This means each individual VM (like the Ethereum VM or Move VM) can serve an increasing number of users efficiently.
  
• Horizontal Scaling: Supra also supports horizontal scaling by adding more VMs and containers. As new VMs (such as SolanaVM or CosmWasm) are integrated into the network, each can be run on its own Clan in parallel with others, distributing the workload. Additionally, containerization allows for even finer-grained parallelization, where more containers can be added to manage specific types of transactions or smart contracts, further improving scalability across different workloads.

By combining vertical scaling (optimizing each VM) with horizontal scaling (adding more VMs and containers), Supra can handle the growing demands of Web3 applications without compromising performance or security.

Conclusion: Speed, Security, and Scalability Without Compromise

With Supra’s three-tier parallel execution model, we’ve designed a Layer 1 network that can handle the demands of Web3 at scale as adoption widens to further reaches of the internet and the world. By processing transactions in parallel across Clans, within the Clan’s VMs, and at the Container levels, we can handle massive transaction volumes while ensuring security and correctness. The separation of execution, consensus, and data dissemination makes the system even more efficient, reducing communication overhead and enabling faster finality.

This architecture is key to increasing throughput and reducing latency across the network, unlocking new possibilities for DeFi, NFTs, gaming, and all kinds of new Web3 applications that are yet to emerge, without compromising on performance. Supra is the future of scalable, efficient blockchain execution — and it’s soon ready to power the next generation of decentralized applications. Every design decision and development we’re chasing is all driven by one goal — to build the most scalable, efficient blockchain. With the highly promising designs and results so far, we’re confident that will soon power the next generation of decentralized applications.