The Ethereum Virtual Machine, or EVM, is a distributed state machine that allows users to encumber code execution to the processing of a transaction. This allows users to define complex spending conditions and user interactions that could not have been possible in a simple payment network. The EVM is what enables and executes smart contracts on Ethereum, and is maintained by Ethereum nodes.
Each Ethereum node maintains its own copy of the EVM, and the canonical, or “correct” state of the EVM is generally determined through majority consensus among nodes. This construction retains the decentralized nature of blockchains while opening the door up to much more intricate on-chain activity than simple peer-to-peer transactions.
While the EVM is not the only mechanism that can create a programmable blockchain, it has dominated the world of smart contracts since its inception. Upon Ethereum’s release, the smart contract language Solidity was created to provide a more readable and auditable language for developers to write EVM contracts. Not using a higher level language like Solidity would force developers to manually construct contracts from bytecode, which is more error prone and harder to audit. Despite the creation of a multitude of new tooling and compilers used to interact with the EVM, Solidity remains the most widely used language to write EVM contracts.
What does it mean to be EVM compatible?
While Ethereum was the first blockchain to introduce the EVM, there are now many other blockchains that utilize Ethereum’s VM to implement smart contract support.
A blockchain’s VM is considered to be EVM-compatible if it contains the same opcodes as the EVM. If all EVM opcodes can be executed, then any language that only uses EVM opcodes can also be used to create smart contracts and interact with any other EVM-compatible blockchain.
In practice, this means that the same applications can be deployed on any EVM-compatible chain, without excessive (or oftentimes any) modification to the flow or code. Some EVM-compatible chains, like Quai Network, utilize multiple interconnected, simultaneously operating EVMs to offer lower-cost contract interactions and state modifications.
Interestingly, a blockchain must not necessarily be EVM-compatible in order to be Solidity-compatible. A VM which supports the complete EVM instruction set without modification is EVM compatible, but a VM which is not EVM-compatible may still be targetable by Solidity. A Web Assembly (WASM) based Virtual Machine, for example, can be Solidity-compatible as long as it offers a mechanism for compiling Solidity into the new VM’s bytecode. The distinction between EVM-compatibility and EVM-noncompatibility can be seen in the bytecode — raw contract bytecode can be copy-pasted between EVM compatible chains and be usable, while the same code would be unusable in a non-EVM-compatible chain.
Some alternatives to the EVM include the LLVM (used to compile to Solana bytecode) and the IELE (used by Cardano), which have cultivated budding developer communities but are still dwarfed by the popularity of the EVM.
What are the advantages of being EVM compatible?
EVM-compatible blockchains and Layer 2s maintain the largest communities of active developers and users. Due to the EVM’s existing popularity and diverse set of opcodes, the vast majority of smart contracts and decentralized applications are written for and deployed on an EVM-compatible chain.
With such a robust community of developers, the process of building for the EVM has been heavily documented and refined by a distributed and highly diverse set of individuals. A long history of successful (and unsuccessful) EVM applications have laid the foundation for a secure and well-understood developer environment.
The languages used to develop on the EVM can be complex, but make up for this complexity with their ability to fulfill nearly any imaginable demand due to the EVM’s turing-completeness. Turing-complete VMs do, however, present the risk of infinite loops, which can be avoided through thorough auditing and vetting of smart contract code.
The most valuable aspect of the EVM is its community and documentation. Thousands of resources, including the hands-on experience of Solidity developers, are available for aspiring builders to reference.
While EVM-compatibility has many advantages, there are some weaker points of the EVM, such as its complexity and its gas pricing. As the blockchain world’s first foray into smart contracts, the EVM prioritizes functionality over simplicity. While languages like Solidity are notoriously complicated, the tooling that has been built to supplement EVM-based developers in recent years has drastically improved the developer environment and experience, while keeping the EVM’s full turing-complete functionality.
The EVM also has existing issues with gas pricing, specifically surrounding state rent that bottleneck the network:
“The thing that Ethereum really suffers for is that it doesn’t have state rent. So that state size has bloated to the point where they are highly constrained by input/output operations. So it’s not necessarily an inherent problem with the EVM, it’s carrying around large amounts of state and not having a payment mechanism for it. They didn’t cost something that’s clearly an externality. The way we solve it, is — just as in sharding state allows for more efficient propagation of transactions, it also allows for smaller state size in any given context. And the other thing we’re doing is adding state rent, so we can limit the bloat of state, which will allow us to process vastly more transactions.”
-Dr K, Co-Founder of Quai Network
What are some of the most popular EVM tokens?
The most popular token utilizing the Ethereum Virtual Machine is, possibly unsurprisingly, Ethereum. As the first protocol to support smart contract capabilities in any capacity, Ethereum has enjoyed a powerful first-mover advantage, and has entrenched itself as the go-to platform for DeFi, NFTs, and more. However, the high fees that Ethereum frequently experiences during periods of high demand have driven users to look for alternative protocols that offer comparable security, decentralization, and functionality to Ethereum without the high cost of use.
There are also a plethora of projects, such as BSC, Tron, and EOS, that offer low-fee EVM-compatibility at the cost of decentralization and/or security. None of these projects, however, have been able to maintain low fees while retaining comparable decentralization, security, and functionality to Ethereum.
In contrast, Quai Network is a pre-Mainnet network of blockchains utilizing merged mining and sharding to offer the functionality of the EVM at a low cost, without making any compromises to decentralization or security. Through the use of many intertwined blockchains producing blocks asynchronously, each running an independent EVM, Quai Network scales both decentralization and smart contracts to unprecedented levels.
The EVM, as the first method of implementing smart contracts to a blockchain, has thrived over the past decade with an explosion in new development activity and tooling. However, despite this large moat, there are many improvements that can be made the EVM that have the potential to further refine incentives and improve upon the existing state of smart contracts.
Quai Network is an open-source Proof-of-Work blockchain network utilizing the capabilities of merged mining to increase throughput and security. Users of Quai Network will enjoy fast transaction times without compromising decentralization and security. Miners will have competitive mining opportunities across the many blockchains within the network.
Capable of thousands of transactions per second, the Quai Network is a Proof-of-Work solution to scalability that is soon to be ready for Mainnet release.
Opinions, ideas, and statements shared in this update are delivered with numerous assumptions, risks, and uncertainties which are subject to change over time. There are multiple risk factors, including those related to blockchain, cryptographic systems, and technologies generally, as well Quai’s business, operations and results of operations, that could cause actual results or developments anticipated not to be realized or, even if substantially realized, to fail to achieve any or all of the benefits that could be expected therefrom. We reserve the right to unilaterally, completely, or partially change plans, expectations, and intentions stated herein at any time and for any reason, in our sole and absolute discretion, and we undertake no obligation to update publicly or revise any forward-looking statement, whether as a result of new information, future developments, or otherwise.
The views, opinions, and statements made in this update are those of an individual author and not those of any institution, University, or legal entity operating within the jurisdiction of The United States or beyond. There is no association between these views, opinions, and statements and any for-profit or non-profit entity, particularly with Universities, Foundations, and other Agencies located within the United States. Any perception of such an association is purely accidental, and will be rectified immediately if brought to our attention by the reader.