EVM compatibility and the future of blockchains
Exploring why and how more protocols are adopting the EVM stack
Back from snowy and sunny Denver. It was great to see a number of readers there. For this month’s deep dive, Denis looks at the EVM ecosystem and how it might evolve outside of the Ethereum network. Also check out DXdao’s bounties for the ongoing Codeless Hackathon.
- Chris
When thinking in DeFi years, Ethereum has already reached legacy status. It survived its first wave of “Ethereum killers”, followed by a surge in popularity of low cost chains (Polygon, BSC, Fantom) running the Ethereum Virtual Machine (EVM). And now, after launching with limited success, these same Ethereum killers are integrating the EVM and racing to enter the multichain world. Specifically, Polkadot has added Moonbeam, Near – Aurora, and soon (announced but not yet launched), Evmos will be on Cosmos and Neon on Solana.
When these chains were first launched (without EVM compatibility), they claimed to have superior designs, with features such as popular programming-language support and speed. As these chains begin to support EVM, it now seems they’re less bullish about the advantages of their own technology, and instead realize the need to support Ethereum’s. By doing so, these chains are backtracking on their original vision to build an alternative tech stack to Ethereum’s. Here, we’ll take a look at the different architectures and how emerging standards around EVM across blockchains will create more composability. Plus, we see the resulting chain-specific ecosystems becoming a hot-bed for product experimentation.
The construction phase
Think of EVM as a computer that calculates the results of operational outputs of smart contracts, given certain inputs. A copy of EVM runs on each node – it’s imperative to remember that it’s not located in one single place. EVM is also referred to as “a runtime” or “an environment”.
In addition to this runtime, there are some important instruments built around EVM, which are highlighted in red below.
EVM takes in programs written in Solidity language, and to make the language more powerful, a number of “libraries” were created. Developer tools such as Truffle or Hardhat make the writing and testing of smart contracts much easier. Also, because we’re talking about networked environments, outside wallets connect to the EVM via API libraries such as Web3.js.
And among those tools more familiar to the average user, there’s the powerful blockchain explorer Etherscan. It knows how to look into thousands of transactions and present them in a human-readable way. Plus, there’s the MetaMask wallet, which connects users to EVM by broadcasting their commands over a network.
It took thousands of hours for hundreds of highly-skilled developers to build these tools and infrastructure. The difference in time taken between creating a dApp with mature tools and unpolished ones can be 100:1 in some cases. That’s why the build-out of tools and infrastructure by proprietary stack blockchains is moving extremely slowly by industry standards (or decades in DeFi years).
In addition to the superior technology, the EVM ecosystem boasts a large market of blockchain developers and open-sourced projects. These projects can be quickly copied and don’t require time-consuming code rewriting.
A comparison of models
Proprietary stack chains have used varying methods in the integration of EVM.
Solana and Near use a single chain, so the EVM in these cases will run alongside the main “smart contract computer” of the blockchain. This can also be seen in Near’s Aurora EVM design.
To quote one of Aurora developers:
“We rewrote all of the EVM logic and compiled it as WASM bytecode, so it’s executing within the WASM piece of Near runtime. Now it’s a near-native contract, there’s nothing special about EVM-contract. Just adding EVM into Near core would introduce a lot of complexity”.
So it’s important to note that Aurora is not a chain, but an EVM environment on Near (even though it has its own block explorer). That’s why the Near-Aurora bridge is not a bridge between chains as such, but a bridge between runtimes. This technological design influences the business strategy: Aurora does not have validators and its token does not secure the network. Different models must therefore be used when valuing Aurora or Neon, which use similar designs, compared to Evmos or Moonbeam, which have their own native fee token.
Interestingly, EVM + Near’s Proof-of-Stake consensus and sharding for data availability makes the overall architecture similar to the vision of ETH 2.0. Neon’s strength is based on Solana’s speed: Neon EVM claims to handle 4,500 transactions per second and support confirmation times of less than one second. In general, this experimentation in combining EVM with different types of architecture drives innovation in the industry. Ethereum is now too big to change with agility, so the emergence of an EVM market creates an opportunity to move fast and break things without the costs and risks of Ethereum mainnet.
Polkadot and Cosmos, which support Moonbeam and Evmos respectively, are blockchains with multi-chain design. They didn’t choose to add EVM side-by-side with the main computer, but instead devote a single subchain for it. This means if there’s demand for scalability, more instances of EVM can be launched as new sub-chains on Cosmos/Polkadot (and on new shards on Near), paving the way for scalability. Solana’s model, on the other hand, seems to lack this scalability.
There are other smaller differences in design among the EVM integrations. Aurora uses ETH for transaction fees, which has (likely indirectly) helped them to secure support from the Ethereum ecosystem. Evmos will reward developers based on the activity of their dApp by sharing some of the fees between developers and network operators via the built-in shared fee revenue model.
The ups, the downs, and blockchain’s EVM future
The use of EVM has various pros and cons from the perspective of the underlying chains. The main ones for them to consider are as follows.
Pros:
These EVMs will also connect the underlying blockchain’s tokens to the broader EVM ecosystem. For example, Polkadot’s token DOT is bridged to Moonriver via the official bridge and from there will travel further via widely-available EVM bridges like Synapse, Allbridge, etc. Check out the image below which highlights mining with DOT on an EVM-based Moonriver. In general, it’s easier to build an EVM-EVM bridge than an EVM-different-consensus bridge.
The EVM environment can become the onramp point for assets from EVM chains to these underlying chains. Users will choose whichever bridge is the most convenient and safest for them. The image below illustrates an example of Cosmos Hub and Evmos interacting with EVM chains.
The EVM environment could become the demo version of the underlying blockchain for new users. By using familiar tools, they would learn about the new ecosystem, its technology, native projects and assets. Imagine Toyota gathering interest in its electric cars after buyers had first become accustomed to Prius.
Cons:
The model further strengthens Ethereum, and more demand for Ethereum tools means more resources spent improving them at the expense of underlying chains’ proprietary stack.
The early Ethereum killers initially differentiated themselves by popular programming language support and unique designs like app-specificity of chains. This new direction takes them away from this original philosophy. Will a lack of differentiation commoditize the blockchains for both users and developers?
The addition of EVM also poses a threat of product cannibalization. If the same app is available both via EVM and base blockchain implementation, the latter has to offer tangible advantages for users to forgo the familiar experience.
To summarize, probably the biggest advantage for underlying chains in adding EVM compatibility is a new onramp channel for users and assets. There’s a downside however; if all chains offer an identical user experience, the brand premium they can capture becomes smaller.
The EVM standard
The emergence of an EVM market creates an opportunity for protocol architects to push for innovations such as sharding (something that Ethereum has been slow to deliver) or app-specific chains.
It’s likely that a widely-accepted standard will bring more composability, which will strengthen the network effect in DeFi. The rapid growth of separate blockchains in 2021 was fast enough, but greater connectivity thanks to common EVM-backed standards might ignite even faster growth over the next couple of years.
Good for the industry or not, the fact that almost all large players are integrating EVM is a signal that the stack is today’s must-have, and that it’s very hard to compete without EVM compatibility.
Odds and Ends
Matter labs launches first zkEVM testnet Link
Laura Shin: Austrian programmer hacked the DAO in 2016 Link
An update on stablecoins in DC Link
dYdX users paid $0.04 per transaction on L2 rollup Link
ETH Denver 2022 videos Link
US court orders Terra, Do Kwon to comply with SEC subpoenas Link
Thoughts and Prognostications
DeFi liquidity management via Optimal Control: Ohm as a case study [Tarun Chitra/Kshitij Kulkarni/Guillermo Angeris/Alex Evans/Victor Xu]
MEV research during Wormhole incident [Misaka]
An argument for DeFi 3.0 [knower]
Optimistic rolllups vs zkRollups [Norswap/Optimism]
Proof-of-Stake and the Cantillion Effect [Data Always]
DeFi: Where we are today, and where do we go from here [Sean Lippel/Fintech Collective]
Six long-term crypto predictions [0xfbifemboy]
That’s it! Feedback appreciated. Just hit reply. Written in Brooklyn, Shanghai and Madrid, where the DoD team has finally figured out Google docs editing!
Dose of DeFi is typically written by Chris Powers, but this week it was the work of Denis Suslov, with help from Financial Content Lab as always. I spend most of my time contributing to DXdao and benefit financially from it and its products’ success. All content is for informational purposes and is not intended as investment advice.
 | A guest post by
|