Accelerating the Modular Paradigm: Parallelized AltVMs Parallelized execution layers are the natural and necessary evolution of the monolithic to modular paradigm. When we have resolved the scalability bottlenecks of Web3, we will reflect on the rise of parallelized alternative ious bridge to adoption-qualifying performance. The Ethereum modular landscape is saturated with 100s of layer 2 solutions competing on iterations of the same EVM design space. Highly performant AltVMs are immediately differentiated - as new developer design spaces are introduced they will attract a swell of users and developers gravitating towards broader possibilities. Building a city, rather than a skyscraper. This article will explore VMs that focus on parallelization as a core design element to scale the modular landscape. We will look at the designs behind
@fuel_network,
@solana,
@Aptos_Network&
@SuiNetworkto better understand the parallel execution elements that can contribute to scaling the Ethereum modular stack. Expanding the bounds of design space A design space can be broadly thought of as the development environment enabled and informed by its underlying infrastructure. For example, the EVM design space is defined by its smart contract capabilities and execution limitations. AltVMs make fundamental changes to execution layer architecture, necessarily altering and expanding the design space for developers. The robustness of design spaces can be gauged by the complexity of design available to developers at reasonable cost, the two parameters being: 🅰️ cost of resources; and 🅱️ technically achievable sophistication A good design space will endeavor to optimize one of two, for example increasing sophistication without bloating cost. But a great design space will attempt to push boundaries in both directions - increasing capacity to handle complexity while reducing the cost of resources required for higher thresholds of sophistication. Design Space: Parallel Execution Environments The premise of parallel execution is that the ability to batch and simultaneously process non conflicting transactions will create efficiencies beyond a linear execution environment. The variable factors of parallelized AltVMs create design spaces that fall along the spectrum of good to great. These environments can vary based on: 🔹Transaction grouping; e.g. intentional vs optimistic 🔹Model architecture; e.g. account, UTXO etc. 🔹Execution logic; e.g. object based, strict access list etc. A combination of the above allows for different degrees of performance optimization and customizability. - *tinyurl.com/Source-Starkwa… Transactional Grouping; Intentional vs Optimistic Design The transaction grouping parameter can be largely broken down into two forms; intentional and optimistic. Here the two methods distinguish between the stage at which the transaction is qualified or disqualified for parallel execution: An intentional design will have pre-defined parameters by which it qualifies transactions. By building identifiers into the transaction data it allows distinct transactions to be executed simultaneously across cores/threads. Alternatively, optimistic design can only qualify the success of parallel execution post-validation, errors are re-executed until resolved. Intentional Design: As the transaction is submitted to the network, it is immediately qualified or disqualified for parallel execution. On the other hand, optimistic design assumes that the majority of transactions are simple, non-dependent transactions that can be parallelized. The VM architecture relies on the block producers and validators to propagate the batching of parallel transactions with the view to re-execute until all conflicting transactions are resolved. Optimistic design: Two applications building within an optimistic design space will necessarily be subject to the same level of performance optimization - the flow is assumed and identical. Whereas, two applications building within an intentional design space are able to build in operational flows and transactional identifiers that achieve varying degrees of parallel execution. Here a developer operates on a spectrum rather than an assumption. To be clear, there are some parallel execution environments that do not operate strictly within intentional or optimistic design, Sui being one example. Sui’s qualified transactions (owned objects) are not executed in parallel but rather bypass consensus entirely. Meanwhile its shared objects pass through normal, linear consensus. Here parallelization is occurring through an abstraction away of its stateless transactions from the necessarily stateful ones. Intentional designs: PE1 to PE2 The effectiveness of parallel execution can be broken down into two levels of optimization; PE1 (parallel execution type 1) and PE2 (parallel execution type 2). The most fundamental and base form of qualifying transactions for parallel execution is to distinguish between independent and dependent transactions. PE1 refers to the parallel execution of independent transactions, while PE2 refers to the further parallelization of dependent transactions. While PE1 is the foundation methodology, PE2 is an enhancement that further pushes the boundaries of cost efficiency and design sophistication. An independent transaction is where one individual address interacts with one other individual address - resulting in a single, non-conflicting state mutation. These are the simplest to parallelize given their independent execution environments. This is distinguished from dependent transactions where the interactions involve multiple addresses or contracts. The dependent transactions are interlinked, with the execution of one potentially influencing the outcome of another due to shared state variables. These more complex transactions require sequential processing to preserve the blockchain's consistent state. The method of qualifying transactions for simple parallelization (PE1) may vary across protocols, but if we were to oversimplify it - it is a single yes/no question: “Is the transaction required to call on a contract/address that will conflict with or depend on other transactions?” If “no”, it is a simple transaction. If “yes”, there will be a mandatory component of sequential execution. PE2, unlike PE1, extends parallel execution to dependent transactions as well - a further deliberation of the question above. PE2 attempts to streamline dependent transactions, calling on a specific contract or address to be grouped - and then executed in sequence. To achieve PE2
@solanaappends instructions to transaction data, this allows further grouping to take place within complex account interactions where dependent transactions can be grouped and executed in parallel to other dependent groups. Similarly
@fuel_networkutilizes a strict access list, where defining the contract IDs in the transactions allows parallelization of non conflicting transaction groups. ➖ As PE1 and PE2 scale performance, the optimal outcome is that we minimize fees to negligible amounts while scaling up the number of potential interactions within a set window of time. At the peak of its execution capacity, parallelized AltVMs will surpass the performance ceiling created by the legacy issues of linear processing - achieving the highest grade of scalability within the modular paradigm. AltVMs like Solana, Fuel, Sui and Aptos exemplify this evolution, each with unique approaches to transaction grouping, model architecture, and parallel execution logic. Whilst the SolanaVM and MoveVM are not yet part of the Ethereum modular stack, VMs optimized for parallelization will be the prevailing design space in the move towards adoption. As a result we will see the presence of more AltVM layer 2s like FuelVM, intentionally designed for a highly performant modular paradigm.