You are reading an excerpt from our free but shortened abridged report! While still packed with incredible research and data, for just $20/month you can upgrade to our FULL library of 50+ reports (including this one) and complete industry-leading analysis on the top crypto assets. 

Becoming a Premium member means enjoying all the perks of a Basic membership PLUS:

• Full-length CORE Reports: More technical, in-depth research, actionable insights, and potential market alpha for serious crypto users
• Early access to future CORE ratings: Being early is sometimes just as important as being right!
• Premium Member CORE+ Reports: Coverage on the top issues pertaining to crypto users like bridge security, layer two solutions, DeFi plays, and more
• CORE report Audio playback: Don’t want to read? No problem! Listen on the go.

What Is the Ethereum Virtual Machine (EVM)?

Understanding the concept of the Ethereum Virtual Machine (EVM) state is crucial to grasp the scalability issues that blockchain technology faces. The EVM state can be likened to a computer with attached storage such as RAM or a disk drive. Every time data is written to this storage, it is consumed permanently, altering the EVM state. The EVM serves as a distributed, permissionless computer that the entire world can access. It updates the global state (transactions, wallets, smart contracts, etc) with each block, ensuring network consensus. 

Source

In the Ethereum blockchain, blocks propagate these state changes through valid transactions. Each block contains multiple transactions that sequentially modify the EVM state. For instance, when Tom transfers 10 ERC-20 tokens to Karen, who previously had zero tokens, the EVM state is updated twice: once to decrease Tom's balance and once to increase Karen's. If Tom had no balance before, a new unit of storage is allocated from the EVM state, which is more costly than updating existing storage.

Rules within the EVM include:

• Every operation incurs a cost in order to prevent abuse/spam
• Every operation must be deterministic, as all nodes must agree on the state after transaction execution
• Transactions must be isolated with no access to I/O or external state.

Any entity participating in the Ethereum network must run the EVM to compute state transitions.  If all nodes run the same EVM (same rules), all nodes are aware of global state changes. 

The cost of state change in the EVM is measured in gas, with storage instructions being the most expensive. The EVM keeps state using a data structure known as a "Merkle Patricia tree." Merkle Trees are generated through multiple rounds of hashing. The initial data begins at the bottom (of the image) and is combined with the other data and hashed together to create the parent hash on the rung above. These hashes are pooled (of the same size) and hashed again until a single (root) node remains. A Merkle tree's aim is to enable Merkle proofs, which prove a piece of data exists in the underlying dataset without requiring the broadcasting of the complete dataset.

Source

Merkle trees can store all key-value pairs for all Ethereum addresses. The keys relate to both public and smart contract addresses, and their respective values describe their current state. However, this adds overhead to any state change beyond the actual payload it writes. 

EVM's Adoption and Dominance in the Crypto Space

Ethereum is a decentralized blockchain platform for building and running autonomous, Turing-complete smart contracts over a global network of permissionless nodes. The most popular implementation of the protocol (Geth) is written in Go, and the most widely-used smart contract language on the platform is Solidity. 

Solidity is designed to compile down to Ethereum Virtual Machine (EVM) bytecode, and it is currently the primary choice when coding smart contracts. Solidity has its problems, though, and other languages like Vyper and Scilla for coding more secure and auditable smart contracts are on the rise. Despite this, Solidity’s syntactic similarity to JavaScript – one of the most popular programming languages in the world – affords it the unique advantage of having a less prohibitive learning curve compared to other languages. 

Source

Having Solidity become the de facto "standard" language for writing smart contracts (image below) enables more composability for dApps on Ethereum. Because smart contracts are deployed as open-source code in Solidity on Ethereum, anyone can build on top of these smart contracts by forking the code, incorporating their Solidity code, and creating an entirely new dApp.

Solidity contracts hold 90%+ of DeFi TVL. Source

Possible Scalability Improvements to the EVM Model

There are strategies that involve changing the EVM:

1. Replacing Merkle trees with Verkle trees: The Verge is the name of one aspect of Ethereum's future roadmap that focuses on Verkle trees. It will work to enhance Ethereum's scalability and optimize storage utilizing Verkle Trees, a type of mathematical proof improving upon the currently used Merkle proofs. By decreasing the amount of data that validators must store on their computers in order to execute operations, node sizes will decrease, and more users will be able to serve as validators. This will boost network decentralization, security, and performance.
2. Optimistic parallel transaction processing: Take inspiration from the Solana or Aptos parallel sequencing models and include the optimistic assumption model made popular by Optimistic rollups like Optimism and Arbitrum
3. Sharding, which involves multiple rollups with intercommunication

These strategies offer potential solutions to the scalability issues faced by the EVM and blockchain technology as a whole. However, they also present their own challenges and trade-offs, and their implementation would require careful consideration and planning.

Advancements in Virtual Machines

The development of virtual machines (VMs) has progressed significantly, with efforts focusing on two main paths: devising more efficient VMs or enhancing the EVM.

1. Innovating Beyond the EVM

   • The first school of thought contends that the EVM, being somewhat antiquated, is not worth modifying. Instead, entirely new VMs are being developed to tap into the full capabilities of smart contract platforms. This includes designing VMs specific to particular programming languages, like Cairo for Starknet or Move for Sui and Aptos. These specialized VMs offer optimized performance but necessitate the cultivation of a dedicated developer community.
   • Another strategy is the adoption of general-purpose VMs like WebAssembly (WASM) or RISC-V, which appeal to a broader range of developers due to their support for multiple languages and familiarity to those outside of blockchain development. Protocols like Polkadot, Solana, and Near leverage WASM for its performance and security features. Projects such as Fluent's zkWASM, Eclipse’s migration of the Solana VM to Ethereum, and Cosmos's Nitro SVM exemplify this trend.

2. Modifying the EVM

   • The alternative approach seeks to enhance the EVM without compromising its compatibility. Efforts here aim to parallelize the EVM's execution process. Early attempts involved integrating a Directed Acyclic Graph (DAG) into the EVM, as seen with Fantom. Recently, this method has seen a decline in favor.
   • A notable evolution in parallelization was introduced by Aptos with its block-Structured Transactional Memory (block-STM), which processes transactions in parallel by default and then sequentially handles any conflicts that arise.
   • Projects like Avalanche have upgraded their engines to incorporate parallel execution, and it remains to be seen how Ethereum might adapt similar innovations. Meanwhile, new initiatives like Monad are exploring the development of a parallelized EVM from the ground up, attracting interest in primary markets.

Solana Virtual Machine (SVM)

While Solana may be an Ethereum competitor, it’s not an Ethereum clone, along with the likes of Binance Chain (BNB), Avalanche’s C-Chain, Fantom, and others (all to varying degrees). Solana isn’t Ethereum Virtual Machine (EVM)-compatible, meaning existing Ethereum dApps and infrastructure can’t be easily ported over to Solana. Rather than the EVM, Solana operates within the LLVM, a standard compiler that separates human readable code (Rust) from assembly, which is low-level code that can take advantage of hardware optimizations. 

In Solana, smart contracts are called “programs,” and the programming languages are Rust C and C++. Rust is generally considered a more difficult programming language to learn than Solidity. Solana Labs chose it hoping that it would primarily only attract “professional programmers” and reduce the number of copy-and-paste projects seen in Ethereum, BSC, and others. 

Solana's Virtual Machine (SVM) is a technology known for its high throughput. Unlike the Ethereum Virtual Machine (EVM), which processes transactions in a single-threaded, sequential manner, SVM enables parallel transaction execution. This aspect significantly enhances efficiency and allows Eclipse to deliver a performance level that outstrips many alternative rollup solutions.

Solana offers a remarkably straightforward vision of a highly optimized, shared-state machine capable of handling a broad range of valuable use cases. Eclipse Mainnet posits that this vision can exist cohesively alongside a rollup-centric roadmap. The misconception that Solana's architecture is incompatible with rollups largely stems from the current nature of rollups themselves. Today's rollups predominantly utilize the single-threaded Ethereum Virtual Machine (EVM), often unchanged, to benefit from its early network effects.

The notion of dedicating a rollup's block space for a specific app is often seen as a solution to preventing fee hikes caused by high-activity events, such as NFT mints. However, this approach introduces unnecessary complexities, fragmented liquidity, and compromised UX. Solana’s parallelized Virtual Machine (SVM) with localized fee markets for state hotspots offers a more efficient solution.

Solana's SeaLevel

In addition to Gulf Stream, SeaLevel is a parallel smart contract-processing runtime solution. The implementation of SeaLevel creates a runtime that effectively processes tens of thousands of contracts in parallel. Parallel processing means the task is divided into smaller computable tasks, using as many avenues as each validator has available. This concept allows for non-overlapping transactions and multiple smart contracts to run simultaneously without impacting each other's performance.

The process of pipelining allows the Solana network to validate large blocks of transactions at high speeds. Pipelining is a common process within computing in which “multiple instructions are overlapped during execution.” Different stages are created and connected together to form a pipeline, which then carries instructions from one end to another, increasing the overall throughput. 

Solana uses this technique to maximize its processing efficiency. For Solana, the pipeline is referred to as the Transaction Process Unit (TPU), which greatly speeds up the network by preemptively fetching packets, verifying their signatures, and crediting tokens before the blocks are ever even sent to the corresponding validators.

Neon, a project building on Solana with the hopes of bringing the EVM to Solana, raised $40M and aims to launch a mainnet in 2023. Neon is a software environment on Solana that enables developers to build apps using EVM and languages such as Solidity and Vyper. According to Neon, its implementation of the EVM will be able to process 4,500 TPS and could be a significant catalyst for growth, just as other EVM Layer-1s acquired developers, users, and considerable market share during 2021.

Neon is able to be EVM-compatible because of the use of an intermediary "proxy." Once a user has signed a transaction, it is forwarded to the proxy, a Solana account that operates the EVM-transcriber and is responsible for executing the Neon transactions. Prior to introducing the transaction on the Solana blockchain, the proxy will request the current blockchain state from Solana. Once received, the proxy generates the new transaction according to Solana's requirements based on the received data and delivers it, together with the packed data, to Solana for data processing. These include account information, program information, coin balances, and account mapping options. Finally, the transactions are transmitted back to Neon for signature verification in accordance with Ethereum protocol rules. Once verified, the transactions are processed in parallel on Solana.

 Source

Additionally, projects Eclipse and Nitro are deploying the SVM to Celestia and Cosmos, respectively. These initiatives aim to combine the advantages of the SVM's speed and the modularity of chains such as Celestia and Cosmos to have the best of both worlds. Solana projects will be able to release their code on Eclipse or Nitro with the same ease as Ethereum projects that launched on Avalanche or Polygon.

MoveVM

With the blockchain economy facing a large number of security breaches from smart contract loopholes, persistent security concerns have led developers to search for more appealing designs and programming languages. For this reason, Aptos has chosen to use the Move programming language. Move is also used by other projects, including:

• Sui Network
• Pontem
• Parachain

Move is a new smart contract programming language that emphasizes safety and flexibility for developers. Move integrates formal verification within its development process, providing an advantage to projects such as Aptos, as it helps to ensure security of the code being used within the earliest stages of product development. A core function of the language, Move Prover, serves as the verification tool and provides developers with the assurance that their code is correct.

Move is memory-safe, expressive, and based on the widely used Rust programming language. This helps to make it a more attractive option for developers as there's crossover knowledge from Rust to Move. This is less applicable to other languages, such as Solidity. This can, theoretically, help Aptos to attract more development talent to its ecosystem. 

The use of resources in Move inspired by linear logic helps in improving security by preventing certain issues. The concept of custom resource types in Move ensures that a resource can only be moved and never cloned or deleted, making it more secure. The Move modules, similar to smart contracts, control the procedures for creating, updating, and deleting declared resources. The enforcement of data abstraction in Move modules leads to cleaner code structures, making it easier to navigate and reducing the risk of human error. The Move Prover, with its flexible programming architecture, can formally validate the characteristics of Move modules, making it an important tool in ensuring the code’s security and reliability.

Fuel Virtual Machine

Fuel distinguishes itself from other rollups by utilizing its very own virtual machine (VM), called FuelVM, rather than the Ethereum Virtual Machine (EVM). A typical VM can interact with smart contracts and generally describes the rules for modifying blocks on a network.

The FuelVM supports a variety of program types, including smart contracts, scripts, libraries, and predicates, which offer unique advantages over traditional EVM interactions. By allowing multiple contracts to be called within a single transaction using a script, FuelVM efficiently manages UTXO spending conditions with predicates. These predicates determine transaction validity by evaluating to either True or False, enabling cost and fee prediction without arbitrary gas variable ordering.

UTXO and predicate usage minimize state growth and introduce account abstraction (AA), addressing state bloat issues that can impact blockchain performance and lead to centralization. As scripts and predicates don't store data like smart contracts, they don't contribute to state growth, enabling sustainable growth and user activity for Fuel. Native multisigs in FuelVM allow for more efficient group transactions without storing state on-chain.

Account abstraction via predicates enables programmable transaction validation, with Fuel implementing stateless account abstraction to prevent state bloat. This feature allows developers to create custom verification schemes at the application level, offering use cases such as social recovery, transaction fee subsidization, and wallet compatibility with various signature schemes. While Ethereum is working towards incorporating AA, Fuel's ability to program based on outputs sets it apart, enhancing flexibility and efficiency.

Additionally, nearly all dapps in Ethereum are written in Solidity, while the FuelVM uses its own programming language called Sway. Sway is a domain-specific language that is based on the well-known Rust programming language and is utilized on Fuel to write smart contracts. 

Metis Virtual Machine (MVM)

Metis has integrated an EVM-equivalent optimistic rollup design into its rollup solution called the Metis Virtual Machine (MVM). The MVM is designed to be nearly identical to the EVM but with critical improvements, like separating the computing and storage functions. These design choices make any existing dApp on Ethereum easily built on Metis but with the added benefits of gas fee reductions and shorter wait times for withdrawals compared to other ORs.

As the MVM is almost identical to the EVM, the slight differences are simply a set of contracts that enable the OR design and fraud proof process. The MVM_Verifier contract is one such contract and its primary function is to manage the fraud-proof verification process. In cases where fraud-proof is validated, the contract is designed to remove specific state batches from the State Commitment Chain, particularly those added after the detection of an irregular state root.

However, despite the EVM’s prevalence, it presents an ever-evolving challenge for rollups. Its continual upgrades, typified by structural alterations and the introduction of new op-codes, mean that it's not the most viable platform for systems like ZKFP. The dynamic nature of EVM often runs counter to the need for stability in fraud-proof systems.

This is yet another reason for generalized execution environments, such as WASM and MIPS. Firstly, they epitomize consistency and simplicity, devoid of the constant changes often seen in EVM. Secondly, their inherent flexibility makes them a favorable ground for the implementation of zero-knowledge proof systems. A distinct edge of these programs, written in low-level languages, is their universality. Unlike solutions tied to a specific blockchain or programming language, these systems can seamlessly transition across different blockchains, necessitating only minimal modifications.