Imagine this: you’re in a busy kitchen where chefs must wait for one to finish chopping vegetables before the next can start baking potatoes. Sounds frustratingly slow and inefficient, right? That’s what synchronous execution is like in computing and blockchain: one task must be finished before the next can be started. Now, picture a well-coordinated kitchen where each chef works on different parts of multiple dishes simultaneously, preparing ingredients, cooking, and plating all at once. That’s asynchronous execution — tasks run concurrently, creating a more efficient and faster workflow.

At the crossroads of the blockchain evolution, synchronous composability has become a buzzword because it seems to offer a solution to unite the fragmented rollup layer 2s on the Ethereum network. This approach addresses the disastrous UX and DevEx where even a simple transfer between layer 2s could cost a buck and take up to 7 days. Vitalik’s involvement in these debates highlights that universal synchronicity is not necessarily a requirement for resolving these issues. We concur that effective translation execution doesn’t have to involve synchronicity, and there are real costs to building and maintaining synchronous infrastructure. We believe it’s not a binary choice between everything being synchronous or asynchronous. Both can co-exist on an ad hoc basis, with a likely shift towards the latter.

1. Asynchronous Decomposable

In the pursuit of scaled performance in blockchain technology, the parallel execution of individual smart contracts has garnered significant attention. Conventionally, each smart contract’s performance has been constrained by the capabilities of a single virtual machine (EVM), even with the advent of multi-chain or Layer-2 systems. Parallel virtual machines offer a promising solution, allowing transactions of a single smart contract to be executed concurrently, thus leveraging more CPU cores for improved performance.

Parallel Relay-Execution Distributed Architecture (PREDA) is a distributed, functional, scope-oriented, and high-level programming model designed for inherently parallelized general smart contracts on distributed multi-EVM blockchain systems. From a system perspective, PREDA makes parallel EVMs decomposable and asynchronous, enabling the full parallelizability of a contract function and maximizing the concurrency of a set of transactions. This ensures that all instances of EVMs can be mostly utilized, achieving optimal performance and scalability.

Before diving into the nitty-gritty details, let’s first clarify what several key terms refer to in this piece:

Tx1= Transaction 1

Tx2= Transaction 2

We assume that,

Execution of Tx1 needs to change state A, state B, state C

Execution of Tx2 needs to change state A, state D, state E

State-of-the-art parallelization methods for EVMs¹, like those implemented by Sei, Aptos, and Sui, attempt to execute all steps in every transaction synchronously. Imagine zooming in on a single transaction scene, in these systems a transaction is executed within one block height, regardless of the nature of scattered data dependencies (i.e., accessing different pieces of contract states). As a result, if any step of the accessed contract states are shared or updated between two transactions, they are identified as read-write or write-write conflicts and cannot be executed in parallel, hindering the overall throughput and scalability of the system. This situation worsens significantly when on-chain activity suddenly skyrockets.

PREDA takes a novel and different approach from the systems mentioned above. It adopts a smart contract execution model that implements asynchronous decomposability, where steps of a transaction are decomposed according to their data access dependencies, allowing steps to be executed asynchronously. The PREDA execution model results in greater efficiency and theoretically infinite scalability. We’ll delve further into how PREDA achieves this and demonstrate experimental results to support this claim.

2. Performance Evaluation

Historical ETH token transfer transactions are replayed to evaluate Sei (V2), Aptos, Sui and PREDA, by throughput and scalability. Note that our evaluation employs real world historical ETH token transfer transactions instead of creating a set of transfer transactions between random pairs of addresses. Random transactions will produce an experimental result excessively over the performance in real word cases since real world transactions involve addresses that are related in one way or another, which introduce a great deal of data dependencies.

Experimental Setups are as follows:

The comparison in Figure 1 underscores the necessity of adopting the PREDA programming model to achieve significant improvements in throughput. PREDA demonstrates 3.3X — 28.2X higher TPS than Aptos for real historical transfer transactions on the Ethereum network.

Since these systems are implemented in different languages (including Go, Rust, and C++) and different virtual machines, we evaluate the scalability of different systems based on the relative speedup over the baseline of using a single EVM, to exclude the impact of different system implementations.

Figure 1. The absolute throughput numbers in TPS of equivalent token transfer smart contracts executed on Sei, Aptos, Sui, and PREDA

Figure 2. Relative Speedups for Aptos, Sui, Sei and PREDA over their own baselines

3. The Programming Model

To facilitate understanding of PREDA for anyone familiar with parallel EVM, there exists two typical types of parallelization mechanisms in today’s parallel EVM blockchain systems¹.

• Optimistic Parallelization, including Aptos, Sei (V2), and Monad, ignore state dependencies between transactions, concurrently execute and validate transactions, and roll back a transaction for re-execution in case of conflict.
• Pessimistic Parallelization, including Solana (Sealevel), Sui, and Sei (V1), pre-check state dependencies for every transaction before execution, analyze their state dependencies, and concurrently execute only those transactions without conflict.

Both methods follow Shared-everything Architecture and treat a transaction as a whole in concurrency control; all steps (e.g., accessing different contract states) are not decomposable and must be executed synchronously. The PREDA model proposes @devteam_48518/crystality-the-parallel-evm-model-implementing-shared-nothing-architecture-8d82fc0a836a">Shared-nothing Architecture to break state dependencies and ensure different EVM instances will never access the same piece of contract state, avoiding write conflict completely.

At its core, PREDA introduces Programmable Contract Scopes to decompose contract state into non-overlapping, parallelizable pieces with fine granularity, and Asynchronous Functional Relay to describe the execution flow switch across different EVMs.

To further explain what these concepts mean, in PREDA, a contract function is decomposed into multiple ordered steps, each relying on a single parallelizable piece of the state without conflicts. A user-initiated transaction is first directed to an EVM that holds states of the user address in a deterministic manner, such as by using a user address-to-EVM mapping method. During transaction execution, the execution flow can switch from one EVM to another that holds the desired contract states by issuing a relay transaction. In this way, PREDA keeps data stationary while moving the execution flow around EVMs according to data dependencies.

At each EVM, user-initiated and relay transactions are ordered and executed sequentially, while transactions on different EVMs are executed concurrently because there are no data dependencies between EVMs. This mechanism avoids the conflict-related re-execution in optimistic parallelization-based methods and the need for runtime state dependency analysis and locking/unlocking overhead in pessimistic parallelization-based approaches. Hence, PREDA provides a parallel and shared-nothing architecture for the blockchain systems, differing from the sequential and shared-everything architecture in both Solidity and Move, which may incur significant concurrency control overhead.

4. The Language

We implemented the PREDA programming model as an Algo-like language, similar to C/C++ and Javascript. Following is a simplified token transfer function in both Solidity and the PREDA language.

The Solidity code in Figure (a) features a contract state (balances) representing address balances and a transfer function to transfer a specified amount of tokens from the transaction sender (msg.sender) to a receiver (payee).

In the PREDA implementation shown in Figure (b), the keyword @address defines programmable contract scopes, where contract states belonging to a contract variable (balance) are partitioned by address, and scattered and managed by EVMs. The keyword relay identifies an asynchronous functional relay.

There are three parts in the PREDA implementation. In part (1), the keyword @address defines users’ balances, providing a fine-grained, separable state description. The address scope variable balance has a unique instance for each user address. The instances of different user addresses are accessed and maintained by different EVMs non-overlapping. The transfer function is defined in the same address scope in part (2), invoked by providing the payer’s address as the target scope when initializing a transfer transaction by a user. In part (3), to proceed with the deposit to the payee after a successful withdrawal, a relay is initiated with the payee’s address as the target scope, adding funds to the payee’s balance and executed by an EVM that hosts the balance instance of the payee’s address.

The execution flow of a token transfer transaction in PREDA

The above figure shows the execution flow of a token transfer transaction in PREDA’s parallel EVM system. Bob initiates a transaction to call the transfer function, which will be directed to the EVM that holds Bob’s balance and the withdrawal is executed there. After that, a relay transaction is issued and directed to the EVM that holds Alice’s balance and the deposit is executed. Parallelization occurs in two ways:

1. Between User-initiated Transactions: Since states partitioned by address are non-overlapping, user-initiated transactions can be executed concurrently without conflict. For instance, in the token transfer contract that updates payer’s state per address, different user-initiated transactions can be parallelized across EVMs.
2. With Relay Transactions: In a scenario where Bob transfers tokens to Alice and Carol, the relay transaction for the deposit to Alice (from Bob to Alice transfer) can be executed concurrently with the user-initiated transaction for the withdrawal from Bob (in the Bob to Carol transfer) and the deposit to Carol. Only with the decomposability of the PREDA model can the inherent parallelization in a smart contract be exposed to the underlying blockchain system, allowing user-initiated and relay transactions to be processed in a pipelined manner, facilitating parallel execution.

Next and Beyond

PREDA marks a major advancement in blockchain performance and, more importantly, scalability. By implementing asynchronous decomposability, it enables efficient transaction processing without the bottlenecks of conventional synchronous parallelization models. This approach decomposes transactions into micro-transactions according to data dependencies, allowing concurrent state changes and avoiding write conflicts completely.

PREDA’s generality extends beyond using @address to partition contract states by address. It allows customized partition types with keywords like @type, where the type can be any Solidity elementary typename such as @uint. Additionally, PREDA supports unpartitioned contract states with @global, ensuring every EVM maintains consistent values for such states. This flexibility in state partitioning enhances the model’s adaptability and effectiveness across diverse smart contracts.

Our experiments demonstrate that PREDA significantly outperforms other parallelization methods, achieving higher throughput and scalability. The PREDA team’s upcoming articles will delve further into our findings, offering more comprehensive comparisons with various types of smart contracts and in-depth analyses of the PREDA programming model and language. Stay tuned for these detailed explorations.

Disclaimer:

1. This article is a repost from [Medium]. The copyright belongs to the original author, [PREDA Parallel VMs]. If you have any objections regarding this repost, please contact the Gate Learn Team. The team will address your concerns promptly in accordance with relevant procedures.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute investment advice.
3. The Gate Learn team translated the article into other languages. Copying, distributing, or plagiarizing the translated articles is prohibited unless mentioned.