What is EVM (Ethereum Virtual Machine)?

Introduction

EVM is an abstraction layer between the code and the host that serves as a guarantee to maintain the smooth operation of Ethereum. What is EVM after all? What are the principles and typical use cases of EVM? Let’s dive deeper into it.

As the most popular blockchain at present, Ethereum provides users with a variety of decentralized applications. It is the most frequently mentioned term when people refer to DeFi, NFTs, etc. And EVM, as a core part of Ethereum, also attracts people’s huge attention. Then what is the relationship between EVM and Ethereum?

What is EVM?

EVM stands for Ethereum virtual machine. As defined by Ethereum, EVM is the runtime environment in which all Ethereum accounts and smart contracts live on the Ethereum chain.

EVM exists as one single entity maintained by all connected computers running an Ethereum client. It is what defines the rules for computing a new valid state from block to block.

How does EVM work?

Principles behind EVM

Instead of a distributed ledger like Bitcoin, Ethereum is a distributed state machine. The change from block to block represents an update of the state of all the accounts and balances on Ethereum. The update is calculated based on the code of the contract by the EVM.

Figure: https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf

EVM is a stack-based virtual machine and performs all its operations directly in the stack. When the smart contract is compiled into bytecode, the EVM will perform operations based on the bytecode, including fetching variables from memory and adding to the stack, calculating the variables in the stack, and storing variables to memory, etc.

There are two main types of data storage in EVM: memory and storage. The variables in storage will be stored on Ethereum permanently after the contract is executed, while the variables in memory exist temporarily while the code is being executed on EVM.

Take calling a contract as an example. We wrote a contract with Solidity, compiled metadata through a compiler, and published it on Ethereum. When we need to update the contract state, we need to call the contract. However, neither OS nor Windows can directly run smart contracts. EVM is needed to provide a running environment for smart contracts. The specific steps are as follows: First, the EVM finds the contract code stored on Ethereum through the contract address; then, an execution environment is generated; finally, the contract content is converted into bytecode and put into the EVM for operation. The result obtained from the operation will be stored as the latest state in the next block, hence completing the state update process.

Figure: https://cnodejs.org/topic/5aeecba802591040485bab2a

EVM Implementations
Currently, all Ethereum clients include an EVM implementation. Ethereum has launched the source code of several programming languages, including Python, C++, js, Go, etc., to implement EVM functionalities. It helps users to understand the principle of EVM in a more convenient way.

Py-EVM - Python: https://github.com/ethereum/py-evm
evmone - C++: https://github.com/ethereum/evmone
Ethereumjs - vm - JavaScript: https://github.com/ethereumjs/ ethereumjs-monorepo
eEVM - C++: https://github.com/microsoft/eevm
Hyperledger Burrow - Go: https://github.com/hyperledger/burrow

Core Elements of EVM

Smart contract

Smart contracts are code that runs exclusively on the EVM. They cannot be changed once deployed. Ethereum defines, modifies, and stores state through smart contracts to achieve various decentralized applications. EVM acts as an environment where smart contracts can run, which is similar to the relationship between a highway and a car.

Gas fee

Significant computing power is required to execute smart contracts on EVM, which consumes a certain amount of gas. For better understanding, think of vehicles that need to pay tolls on toll roads.
Gas fees help incentivize miners from all over the world to participate and provide computing power, as a way to make Ethereum more decentralized. It also prevents users from submitting random operation requests that may lead to Ethereum Mainnet congestion or protects Ethereum from crashing by preventing malicious attacks.

Solidity and Opcode

Ethereum smart contracts are written in Solidity and are compiled into bytecode before being executed on the EVM. Bytecode contains opcodes, or operation codes. EVM has 144 opcodes, each with specific functionality, which makes EVM Turing-complete. It can solve any type of computation problem. Solidity and Opcodes make it possible for us to write complex smart contracts and implement a wide variety of functions on EVM, thus providing users with a variety of dApps.

Features of EVM

Deterministic

For the same piece of code, the output is the same after being executed on different EVMs, as it has nothing to do with the execution environment and the number of executions. The certainty of EVM ensures the reliability of the code and avoids unexpected consequences. This feature helps protect the interests of users especially when they are making large transactions on Ethereum.

Isolated

EVM is like an isolated sandbox where the code runs. The running process will neither harm the software/hardware of the computer nor affect the underlying protocol of Ethereum. The isolation of EVM prevents hackers from attacking the machine that runs an EVM, and also protects the underlying protocol of Ethereum from being tampered with. It serves as a guarantee that secures Ethereum.

Terminable

The process of EVM executing code can be interrupted. If the user runs the wrong code, such as an infinite loop, the gas mechanism can be deployed to terminate the execution process in order to prevent such code from occupying computing power indefinitely. Before executing the code on the EVM, the upper limit of gas should be set in advance. When the gas is exhausted, the code will stop running, and the state will be rolled back without any update on the chain.

EVM Compatibility

As users increase, Ethereum Mainnet encounters many problems, such as congested networks and high gas fees. Limited to the design of Ethereum, these problems cannot be solved radically.

In recent years, there are many new public chains that have lower gas fees and faster networks and Layer 2 chains that are designed to scale Ethereum. These chains are all smart contract chains, which are said to have better underlying designs and may be used to build a variety of dApps.

These chains undertake the surplus demands of the Ethereum ecosystem and challenge the dominant status of Ethereum. Is it necessary for Ethereum counterparts to be compatible with EVM? Regarding this divergence, these chains are divided into two categories: EVM-compatible chains and non-EVM chains.

Public chains compatible with EVM

Recently, Layer 1 public chains have been popping up one after another. Though rebuilding an on-chain ecosystem that runs in parallel with Ethereum could overcome the existing shortcomings of Ethereum, it requires significant human resources to build a complete ecosystem and develop a dApp from scratch. The lack of qualified programmers hinders new public chain ecosystems from growing. For a public chain with an undeveloped ecosystem, it would be difficult to attract a user from Ethereum within a short period of time.

Given this, some public chains are designed to be compatible with EVM. DApps that are originally running on Ethereum can be completely transitioned to EVM-compatible public chains with only minor modifications to the source code. It can not only maximize the use of development resources but provides users with a better experience in the process of migrating from Ethereum to a new chain.

However, EVM compatibility has inevitably come with certain problems. Confined to the rules of EVM, many EVM-compatible chains encounter a problem regarding how to achieve innovation without homogenization. However, non-EVM chains can break these rules and develop a new set of rules from scratch, thereby achieving innovation fundamentally.

At present, more than 70% of mainstream public chains are compatible with EVM, such as BSC, Avalanche, Fantom, Tron, Celo, etc. It would not be difficult for developers to develop dApps or to deploy Ethereum apps on these chains for higher performance and lower gas fees, hence improving user experience.

Some other public chains are non-EVM but have developed their own virtual machines, such as Sol, Terra, etc. Although not compatible with EVM, these chains have attracted a group of loyal users and institutions with their innovative design and excellent on-chain performance. For example, the two blockchain games, Step N and Let me speak, which have been popular all over the world recently, are based on the Sol chain and have attracted enthusiastic fans from across the globe to participate.

Notably, EVM-compatible chains can co-exist with non-EVM chains. Some non-EVM chains also begin to be compatible with EVM. The process of achieving this would be arduous as it requires extensive efforts to modify the code. An example of this is Sol who launched Neon, which allows developers to build dApps on EVM.

Figure: EVM compatibility of public chains

Layer 2 chains compatible with EVM

As a scaling solution of Ethereum, Layer 2 is complementary to Ethereum instead of its competitor. Layer 2 chains are all EVM-compatible, with a higher level of compatibility than that of Layer 1. For Layer 2 to be compatible with EVM, we have two solutions: EVM compatibility and EVM equivalence.

The early Layer 2 chains are EVM compatible, which is similar to the EVM compatibility of the Layer 1 chains. Smart contracts on the Ethereum Layer 1 can be deployed on Layer 2 by making some modifications. For example, Unipig, launched by Optimism, is completely a reconstruction of the Uniswap code. It is considered Uniswap on Layer 2.

There are some limitations to EVM compatibility. When developing smart contracts on an EVM-compatible chain, some EVM-based development tools and frameworks may not be available. In addition, for the smart contracts originally arranged in Layer 1, developers still need to make some adjustments so that the smart contracts can run smoothly on the EVM-compatible blockchain.

EVM equivalence aims to give developers the exact same experience when developing smart contracts on Layer 2 as on Ethereum Layer 1. This has greatly benefited Layer2 developers, further improved development efficiency, and saved the costs of development and code maintenance on the basis of EVM compatibility.

At present, mainstream Layer 2 solutions, such as Artbitrum, Optimism, and Metis, have achieved EVM equivalence. EVM equivalence can better transfer the features of Ethereum to Layer 2, with a view to minimizing the development and migration cost caused by the scaling. EVM equivalence is expected to become the mainstream standard of Layer 2 in the future, and many Layer 2 solutions will have a fierce race around EVM equivalence.

Conclusion

EVM is the core that keeps Ethereum running. With the establishment of Ethereum’s dominance, major public chains and Layer 2 chains have followed or are compatible with the underlying design concept of EVM. Therefore, EVM has definitely had a profound impact on the entire blockchain. The EVM itself does come with many problems, making it difficult for the new chains to be compatible with the EVM. Despite that, developers have been working hard to make improvements, which has greatly facilitated the emergence of many other public chains.