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.

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.

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.

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 tvl dominance July 2023 — Solidity contracts hold 90%+ of DeFi TVL. Source

In addition to Solidity becoming ubiquitous across the industry, there are several other key specifications that originated on Ethereum and have become widely accepted as global standards. These include:

ERC20/ERC721, Ethereum token standards
Ethereum's JSON-RPC Client API, a specification for communicating with Ethereum nodes
Ethers.js, a web library for working with Ethereum
Ethereum cryptography, such as the Keccak256 hash function and ECDSA signatures over Secp256k1

While it's possible to have an EVM-compatible chain without supporting all of these standards, conforming to them makes development and the user experience much easier. This is because with standardization comes composability, meaning devs can leverage one or more of the following:

Ethereum's Social Graph: addresses are the same across EVM chains, meaning that any new project or chain can leverage the metadata associated with a user/address to solve cold-start problems
Tooling and infrastructure: Some tools include Gnosis Safe, WalletConnect, Zerion, Metamask, and Etherscan. There are many open-source toolkits like OpenZeppelin, Hardhat, and Foundry
Interoperability: Cross-chain governance, ERC-20 token trading identical address system, etc.
8 of the top 20 blockchain ecosystems are running EVM.

EVM's Limitations Felt By Alt-L1s

The scalability of the EVM has an upper limit, determined by factors such as the speed of validator selection, how quickly the leader can execute state changes, the time it takes to propagate blocks globally, and how quickly other validators can validate the new block. Even with infinitely fast CPUs and unlimited RAM, the speed of light sets a physical limit to how quickly data can be propagated around the world. The ultimate scalability problem lies in block validation. To validate a block or a transaction, the full state of the entire blockchain must be known. This requires network bandwidth to download a new block, CPU to validate transactions, and RAM to maintain the full state.

Binance Smart Chain

Fast EVM chains are already experiencing state propagation issues, with nodes struggling to keep up. For instance, Binance Smart Chain, which runs on GoEthereum, is having blocks of size 100M gas units. The network is under strain, and it seems validators are having a hard time keeping up.

BSC enables faster transactions and cheaper fees by increasing the gas limit in each block (100M versus 15M in Ethereum) and having faster block times (5 seconds versus ~15 seconds in Ethereum). This approach has seemingly helped create cheap fees, which have led to BSC being the number one chain based on transactions/day. However, even just briefly evaluating the transactions, it becomes clear that a large portion of transactions is simple spam/spoof transactions meant to boost network usage metrics and that the network/validators are under immense strain.

Chains like BSC and Polygon can no longer run on a normal cloud server and require more specialized solutions. Over time, the blockchain state size becomes so large that only a few mega-corporations can afford to run a node due to hardware constraints. The active state size of the chain (state that smart contracts need access to) and hardware computer performance have physical limitations and can create a bottleneck if BSC continues to grow at its 2021 rate.

Because of this, Binance Chain has experienced synchronization issues, validator-sponsored front-running, and network spam attacks (highlighted below).

https://github.com/bnb-chain/bsc/issues/911,
https://github.com/bnb-chain/bsc/issues/338,
https://github.com/bnb-chain/bsc/issues/65 8,

For now, Binance just continues to increase the gas limit whenever the chain gets congested, but there could come a time when that is not an option. The chain's demands could surpass even what the most powerful servers are capable of computing, and chain performance will suffer with no real solution.

Avalanche

Avalanche’s C-Chain is its EVM-compatible (Geth client clone) network that is responsible for the majority of Avalanche's TVL and adoption, especially in the high ETH gas fee environment of 2021 and 2022. Because the C-chain utilizes the EVM design, that means it is 100% burdened by the same limitations as Ethereum. It’s able to have a higher TPS currently than Ethereum because it’s a younger chain with less state bloat and a higher gas limit.

In response to the high transaction fees in Q4 2021, Apricot Phase 5 (AP5), in addition to many upgrades, increased the target gas level by 50% to 15 million gas/10 seconds. This alleviated some of the throughput issues and helped lower gas fees as seen in the image below. However, this is a short-term solution based on current demand and network state.

Because Avalanche is only ~2 years old, it’s processed far fewer transactions (~100 million for Avalanche compared to 1.7 billion in Ethereum), and the chain history/storage is far smaller. This is great for Avalanche right now, but a true comparison would be once Avalanche has managed the same level of usage and state bloat that Ethereum has over roughly seven years. Newer chains have the advantage of starting with an empty state tree rather than 100+ GB. A larger state tree means reading and writing to the state takes longer and is more computationally expensive. Because of this, nodes take longer to retrieve data because it must look back through more history. All else equal, looking up some value deep in the Merkle tree will take longer than looking up a value that's recent. The simple fact remains: transaction fees are a direct result of demand for block space, which is a finite resource. True scalability must come from elsewhere.

Specific Limitations of the EVM

Given the limitations of the Ethereum Virtual Machine (EVM), such as finite CPU speed and RAM, the crypto economy faces significant challenges in scaling blockchain technology. Validators and full nodes must meet a certain hardware threshold to sync the blockchain. If the hardware is inadequate, the last block moves further faster than existing blocks can be consumed.

Moreover, limitations set by the EVM architecture itself pose challenges. For instance, the EVM cannot process transactions in parallel and underutilizes modern CPU and GPU power due to its serialized mode of operation. This is because any transaction can touch any part of the EVM global state, making transaction validation and state updating tasks difficult to parallelize.

Parallel execution in cryptocurrency refers to the ability to process and execute multiple transactions simultaneously rather than sequentially. In traditional cryptocurrencies, such as Bitcoin and Ethereum, transactions are executed one after the other in a linear order to ensure that one transaction’s outcome does not conflict with the next. Parallel execution is a way to increase a cryptocurrency network’s scalability and can help to reduce latency and improve network performance.

In a parallel execution setup, multiple transactions are grouped together and processed in parallel by different validators on the network. This helps the network to handle a higher TPS, allowing for increased throughput and scalability. To ensure that the transactions are processed in the correct order, the blockchain network may implement consensus algorithms and protocols to establish the transaction order and reach an agreement between all participating validators.

Possible Scalability Improvements to the EVM Model

There are strategies that involve changing the EVM:

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.
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
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.

Loading...