co-written with Krishna Nandakumar, with substantial help from Vernon Johnson, David Phelps, Carlos Diaz-Pedron, Tomer Ben-David, and Jad Esber.
Ethereum (as most know it) is simply one implementation of the Ethereum blockchain. The Ethereum Virtual Machine, on the other hand, is open-source blockchain-based software that allows developers to create decentralized applications. It is the global virtual computer that records the state of every smart contract the network stores and agrees on. Solidity is its programming language.
EVM was the first software to offer smart contract capabilities to developers and has grown into a thriving ecosystem with valuable developer network effects that extend beyond the Ethereum blockchain alone. In fact, some of the notable blockchains that use EVM have their own token economies and consensus mechanisms, completely separate from the ETH token and ETH mining. The innovations, infrastructure, and user growth on other EVM chains are leveraged by the Ethereum blockchain seamlessly and vice versa.
The network effect is a phenomenon whereby an increase in users or participants improves the value of a good or service, sometimes exponentially. The Internet, for example, is more valuable to you with everyone on it than just a handful of people/organizations. Social networks are another common example.
Open-source software and ecosystems benefit from similar network effects: the more developers build on or integrate with it, the more valuable it is for everyone. But that’s not all that OSS may benefit from. If most of the infrastructure and applications atop the network are also open-source, network effects are multiplied.
This is why EVM network effects are so strong: every user onboarded permissionlessly and every line of code written openly, regardless of which network it was for, improves the value of all EVM chains. It also improves the defensibility of EVM compared to alternatives.
A protocol is EVM-compatible if its smart contracts can be executed on the Ethereum virtual machine. Practically, this means that the protocol’s contract must be written either in Solidity, or have a package that compiles its code into byte code that can be run on the EVM.
Consider zkSync, a zero-knowledge protocol that aims to reduce transaction costs and speed. The protocol supports solidity smart contracts with no changes required in most cases. On the other hand, StarkNet - another zk roll-up - has a native language called Cairo. It is currently not EVM-compatible, but teams are working to build compilers so that it can be executed on the EVM, and a transpiler for the other direction (EVM -> StarkNet) has already been built. Other examples of EVM compatible/native blockchains and layer 2s include Ethereum Classic, Polygon, BSC, Optimism, Arbitrum, Gnosis Chain, Avalanche, and Celo. You can see them all and hundreds more on Chain List.
EVM is JavaScript with billions of dollars in spending capital. It has a first-mover advantage, and all the money and resources spent on furthering EVM with new solutions are available to use and expand upon without permission. Therefore, it becomes highly advantageous to build on EVM rather than to build an ecosystem from scratch, even as another L1 or side-chain.
It’s worth noting that some consider JavaScript to be an infamously bad programming language – but it was the first. Attempts to replace it (Dart) all failed, and only improvements that targeted it as a transpiler (Typescript) have succeeded. The network effects were so strong that any break in composability made an attempt to replace it unviable, regardless of the quality of the language. The same may be true for EVM.
For builders and operators, composability means they can leverage one or more of the following:
Beyond building on Ethereum itself, traditional businesses have caught on to the advantages of building on EVM. JP Morgan, for example, built their enterprise blockchain on their own Ethereum fork named Quorum. TikTok launched its NFTs on ImmutableX, a layer 2 roll-up (on Ethereum) for NFTs. 100 Thieves released their first NFT airdrop on Polygon, an Ethereum side-chain running EVM.
Other blockchains are also attempting to interoperate with Ethereum, building EVM implementations on their own chain. Some examples include Solana (Neon), NEAR (Aurora), and Cosmos (Evmos).
Some L2s are signaling that they might break equivalence with EVM at some point soon to try some features that either only makes sense on L2 or would take a long time to get Ethereum Layer 1 to integrate. In a sense, we might enter a world where L2 EVM implementations slightly diverge and become testing grounds for new EVM features. This might break 1-1 code deployability at some point down the line.
That being said, as long as the state between the layers remains composable, it should be insignificant, typically keeping execution properties to a minimum when bridging data between chains. And as long as an adapter can be written on the other end and the state format makes sense between the two chains, minor execution differences might not be a blocker. It could resemble how JavaScript developed, where ES6 existed before some browsers supported it.
What does this all mean for competing chains and ecosystems? They’ll need massive budgets and must find ways to serve the EVM audience. The ecosystem model can work for non-Eth projects if they move quickly and efficiently. Solana, one of the worthy challengers, is still missing some of this software despite spending massive amounts of capital to catch up.
Additionally, there’s a ton that EVM can't do and there will be applications that are only possible outside EVM long-term and will drive value to other VMs too. It’s worth noting that some unique projects have begun choosing different solutions than EVM, Stepn, for example, is on Solana. This may be evidence that EVM isn't winner takes all and there will be plenty of applications outside. It’s worth mentioning that the same was true for JS, but every year the number of applications that are impossible to build in the browser with JS goes down.
Cosmos, Polkadot, and other blockchains have taken a composability-first approach that is winning over competent builders and users. While years behind the EVM ecosystem, Cosmos SDK enjoys very similar network effects, but most of the composability is asynchronous meaning it happens in multiple steps with various verifications. Until now, Cosmos didn’t have identical addresses for accounts across chains, though this is meant to change soon. CosmWasm is super new, and the ecosystem is missing important mechanisms such as a robust oracle solution for DeFi. JunoSwap (the AMM on Juno), for example, launched months late with disorganization and incomplete code.
Solutions like Celestia seem to take these network effects under consideration, allowing Ethereum and other EVM chains to function as the settlement layer. This will retain EVM composability but with much more optionality and scalable security. This approach may be the topic of discussion surrounding Layer 1 blockchains in the coming years.
Developers and L1 competitors should seriously consider the massive advantages of building on EVM currently. For most cases, I expect an existing EVM chain or layer 2 will be sufficient for most needs, though they may need specific features that the EVM isn’t built for. EVM is years ahead of its competing ecosystems and this will continue to increase adoption and network effects. However, ETH supporters need to reconcile the possibility that a different EVM-based chain may capture much of Ethereum’s market share in a manner that doesn’t necessarily trigger demand for ETH.
About: Nir (nir.eth) has been in the web3 space for many years with a particular passion for web3 social and DAOs. He’s the co-founder of Yup and deeply involved with large projects in the space such as Forefront.