Understanding EVM, virtual machines and EVM chains

EVM is a sandbox inside which all Ethereum smart contracts run. Many blockchains, such as Avalanche and Polygon, support EVM, making it easy to migrate Ethereum dApps. Non-EVM compatible ecosystems like NEAR, Solana and Cosmos, are also getting EVM implementations like Aurora and Evmos. But can they compete with safer and more efficient solutions like Move VM or WASM?

What is a virtual machine – and what does it do?

A virtual machine (VM) is a program that emulates a computer. Often you’ll read abstract definitions of a virtual machine as a ‘system’, ‘a mechanism’, or ‘a software platform’, but it’s basically a program that you install and run.

What a VM does is emulate a machine – another computer. It has its own memory, storage space, and even a CPU. You can run different programs on it, create files, and so on – only this ‘machine’ doesn’t exist physically.

Because of all the talk about Ethereum Virtual Machine, many people think that it’s a technology specific to blockchain – but it’s not. In fact, if you’re a Mac user, chances are you’re more familiar with VMs than you think. Ever tried Parallels, VMWare, or another software to run Windows programs on your Mac? These are actually virtual machines!

You can even run several copies of a VM on one computer and create a virtual network of such ‘fake computers’. It requires a lot of resources, though, so this is better done on professional-grade servers.

A virtual machine as a sandbox

A sandbox is a virtual environment where you can test new code, apps etc. without risking breaking the rest of the system, even if what you are testing doesn’t work.

Imagine you install a new program on your laptop, start it – and it somehow messes up everything else, so that other programs stop running properly, the computer freezes, and you have to reinstall the operating system. But if you use a sandbox, the ‘bad’ program won’t damage anything outside of the sandbox.

You can also look at it the other way round: whatever is running in the sandbox is protected against various negative events that can impact the rest of the system, such as viruses and DDoS attacks. This is very important for blockchain virtual machines, as we’ll see.

Another advantage is that you can deploy and test the same code on very different devices and operating systems. This makes collaboration between developers easier.

A piece of technical lingo: since a VM creates an additional layer between the physical server and the software, it can also be called an abstraction layer. And because VMs are used to run programs, they are often termed ‘runtime environments’. Many other names are used: processing machine, container, and so on.

To summarize: a VM creates an isolated environment that functions like a separate computer/server.   The main uses of a virtual machine are:

• to run software created for another or older OS on a machine that normally wouldn’t support that software;
• to test new code;
• to run sensitive apps that should be protected from external threats that can impact the rest of the system.

EVM: the first blockchain virtual machine

The EVM, or Ethereum Virtual Machine, was the first virtual machine developed for the blockchain industry. It’s an abstraction layer separating a physical machine (a node) from the smart contract code. Every Ethereum node runs an instance of the EVM – and together they form a sort of a web, or a global decentralized computer of sorts. Vitalik Buterin even calls Ethereum a ‘world computer’.

The EVM plays several important roles that go far beyond simple sandboxing. Things can get very technical, so we’ll try to give a very basic explanation.

Protection through separation

First of all, the EVM separates dApps from the machine (node); if the machine is hit by a DDoS attack or a virus, the app and the blockchain will be safe. Second, it keeps dApps separate from each other: if one malfunctions or turns out to be malicious, the others will still function properly.

Execution: bytecode to opcodes

In other words, the EVM converts complex human-readable instructions in a language like Solidity into byte-sized commands that the machine can read and execute.

Ethereum smart contracts are written in languages like Solidity, Vyper, and FE (an interesting and easy new language, released in January 2021). These are high-level programming languages, meaning that qualified humans (i.e. programmers) can read them – but a machine can’t. It needs a translation into a low-level, machine-readable language.

That’s where the EVM comes in: it compiles (converts) Solidity, Vyper etc. into a simpler language called EVM bytecode, which is then executed by the virtual machine.This concept isn’t unique to Ethereum: for example, Java Virtual Machine has its own bytecode.

Bytecode consists of many short, human-readable instructions, or opcodes. Ethereum has 140 opcodes, including ‘STOP’, ‘ADD’, ‘NUMBER’, ‘GASPRICE’, etc. Every opcode requires exactly 1 byte of space to record (thus ‘bytecode’).

Preventing DDoS through fees

For every opcode that the EVM executes, a price has to be paid: the gas fee. Different opcodes require different amounts of computational effort, so the amount of gas also varies. For example, multiplication needs just 5 gas, while fetching the balance of an Ethereum account will cost a whopping 700 gas.

Why charge for gas, anyway? The reason is security: if operations were free, a malicious agent could swamp the network with dummy transactions, causing it to freeze (similar to a DDoS attack). Non-zero gas fees make such attacks very expensive.

EVM as a state machine

At any given moment, a blockchain finds itself in a certain state. This comprises all the balances on all the accounts, plus a lot of other data. Every time a new block is added, the state changes.

Remember that transactions processing happens in the EVM. To every input (a transaction request/call to a contract), it produces an output that causes a state transition. Thus the definition of the EVM as a state machine: it determines how the state of the blockchain changes.

Turing-complete or not?

You’ll often read that EVM is secure because it’s Turing-complete. What does it mean – and is it really that important?

A system (such as a programming language) is said to be Turing-complete if it can compute (solve) any task that you feed into it, as long as this task can be represented as code – and given unlimited time and memory. Basically it can take a Turing-complete machine a thousand years and a gazillion terabytes of memory, but it will produce an output for your computational problem.

EVM is said to be Turing-complete, since Solidity is a Turing-complete language (i.e. you can use it to express any instructions). However,  it’s not Turing-complete in practice. That’s because gas fees keep piling up with every added opcode, so you could come up with a computation so complex that the fee would be too high for anyone to pay.

Is this a problem? Not really, as it turns out. As pointed out by Emily Pillmore, a senior developer at Kadena, blockchain doesn’t have any use cases that would require Turing-completeness. Quite the contrary: being Turing-complete even creates new vulnerabilities, such as re-entrancy attacks.

EVM isn’t perfect: the 6 main issues

EVM was a groundbreaking innovation for the blockchain industry, because it made dApps as we know them possible. At the same time, some experts note its design flaws.

1) Bytecode is not human-readable. This makes it hard for developers and independent observers to analyze and verify smart contract code.

2) It’s difficult to debug. This is a direct consequence of the previous point: you have to decompile the bytecode into a human-readable form to understand what went wrong with a dApp.

3) It’s slow and charges a lot of gas. Note that EVM’s speed means the number of opcodes processed per second, so it’s not the same as the capacity of the Ethereum blockchain to process transactions – which is also slow at 15 transactions  per second.

4) It’s not safe enough. EVM is supposed to protect the blockchain and dApps from the impact of ‘bad’ code. Yet, we constantly see new smart contract exploits. Particularly dangerous are re-entrancy attacks, when a hacker repeatedly calls the withdraw function to drain the contract of funds.

5) Contracts are non-upgradable. Once you find what went wrong, you can’t fix it, because Ethereum smart contracts can’t be changed after they are deployed. You have to start from scratch, deploying a new contract, migrating users etc.

6) EVM doesn’t support native stanar libraries. A library is a set of standard contracts distributed together with a VM. Instead of writing all the code from scratch, developers can use ready items from a library and save a lot of time. With smart contracts, using libraries also saves gas – and therefore money. But since EVM doesn’t include any standard libraries by default (unlike Move VM, for example), writing and deploying smart contracts becomes very expensive.

Why is EVM still king?

In spite of all these issues, Ethereum remains the biggest dApp hub: its DeFi TVL is almost 9 times higher than that of its closest competitor, Binance Smart Chain.

More than that, most of the top 10 chains (BSC, Avalanche, Fantom and others) support EVM and promote this fact as an advantage. Why does EVM dominate the blockchain space if it’s expensive, slow, and unsafe? And what is the trade-off for a project that decides to use an alternative virtual machine?

To put it simply, Ethereum holds the first mover advantage. Being first to a new market allows a company or project to build a large user base and a strong brand, even if the product itself is far from perfect.To lure some of the user away from the first-mover company, a competitor needs to offer a product that is both better in some ways but also familiar enough to make the transition easy for the user.

For the competitors of EVM, this task is particularly hard because of Ethereum’s strong network effect, with its thousands of developers who already know Solidity, libraries of audited code samples and smart contracts, and high liquidity.

Here’s where supporting the EVM comes in very handy:

• existing Ethereum dApps can be migrated/expanded to the new chain without having to rewrite the code;
• developers don’t need to learn a new programming language;
• developers can use the familiar Ethereum tools, such as MetaMask, Truffle, Waffle, etc.
• users can connect to dApps on the new chain using their existing MetaMask account.

Alternative smart contract platforms that adopted the EVM, such as Avalanche and Fantom, have achieved success by offering:

a) better user experience for regular users compared to Ethereum: these chains are much faster and cheaper.

b) familiar (but smoother) experience for developers.  You want to have many development teams building on your chain, so that your rapidly growing ecosystem can attract regular users and their liquidity.

Ultimately alternative blockchains compete for liquidity. If a chain is EVM-compatible, it will quickly get its own versions or forks of popular DeFi projects, and users will follow. For example, Daniele Sesta’s Wonderland ($TIME) is a fork of the Ethereum-based Olympus DAO – only it’s far cheaper to use, being based on Avalanche.

The trade-off is that the chain will have to deal with all of the EVM’s issues, such as frequent exploits and non-upgradability of smart contracts.

Alternatives to EVM: Move VM, WASM, eWASM, and BPF

The alternative to using EVM is to introduce a different virtual machine. This approach has its advantages:

1) Technical improvements: you can create a system that’s free from EVM’s problems – something that is safer, easier to debug etc.

2) Higher opcode processing speed and lower gas costs;

3) Support for different programming languages;

4) Marketing possibilities – a new EVM is very news-worthy material.

There’s also a flip side, of course: existing EVM-based dApps won’t be able to migrate to your  network easily, so you’ll have a harder time building an ecosystem. You’ll need a lot of resources, and you’ll have to provide additional perks (apart from the virtual machine) to attract developers and end users.

As a result, there are few quality alternatives to EVM in the market. We’ll look at four: Move VM,

WASM (WebAssembly), eWASM, and BPF.

Move VM

Move VM and Move programming language were developed as part of the Diem project, which was backed by Meta (formerly Facebook). The resulting system is far safer and more flexible and scalable than EVM. Here are a few of the security features (you’ll find more info on our Move VM page).

• Controlled access and safety. Developers can set ownership rights and privileges for each digital asset (token). This way, even if someone manages to hack a smart contract, they won’t be able to drain it, because they won’t have the ownership rights.

• Preventing errors. With Move and Move VM, many of the common smart contract bugs simply won’t be possible. Very importantly,the risk of reentrancy and double spend attacks is really low with Move VM.

• Bytecode verification. A special verifier tool checks new code before it’s deployed, helping to eliminate errors.

The original idea was to integrate the Diem blockchain and a new Diem-based stablecoin (initially called Libra) with apps like Facebook and Instagram. However, Meta encountered a lot of resistance from the regulators and eventually sold all Diem assets to Silvergate blockchain bank.

At the same time, a group of developers who used to work for the Diem Association announced a new public chain, Aptos. The project will build on Move and Move VM. Meta isn’t an investor, but Aptos has already raised $200 million from funds like Three Arrows Capital and BlockTower.

Aptos is definitely a project to keep on your radar. Here at Pontem Network, we’re building an infrastructure for the new ecosystem: you can already try the Liquiswap DEX and the browser bode editor Move Code Playground.  

Pontem allows developers to test their dApps in a live environment, gain traction, and access liquidity on Kusama and Polkadot before Aptos goes live. Also, it’s quite possible that new Layer-1 blockchains using Move VM will arise to compete with Aptos, and that, in turn, will boost the Pontem Network ecosystem. Read more here.

WASM (Polkadot and Kusama)

WASM is a type of code that was created by the World Wide Web Consortium, or W3C. It includes developers who have worked for Apple, Google, and Microsoft. It’s fast, flexible, gas-efficient, and easy to debug. The WASM code is human-readable, and it supports a wide variety of languages, including C, C++, C#, Haxe, Typescript, and Rust.

WASM wasn’t designed specifically for blockchain: it’s used by many web apps and extensions in Chrome, Firefox, and Microsoft Edge. It makes it easier for non-blockchain developers to enter the decentralized industry via WASM rather than learn Solidity and EVM.

The blockchains that support WASM include Polkadot, Kusama, and EOSIO. By the way, our own Pontem Network was the first to connect Move VM to the WASM runtime, linking these two next-generation virtual machines.

eWASM (Ethereum 2.0)

As you probably know, Ethereum is slowly transitioning to Eth 2.0 (also called Serenity) – a Proof-of-Stake network that should reach a capacity of up to 100,000 transactions per second. Along the way, it will ditch EVM in favor of Ethereum WebAssembly, or eWASM.

With eWASM, developers should be able to write Ethereum smart contracts in languages other than Solidity. Debugging will become easier, and the whole system should run smoother and faster with lower gas costs. The creators will also supply a transcompiler – a tool to transform EVM code to be usable with eEWASM.

Don’t hold your breath, though. So far the Eth2.0 project has struggled with delays at every step, and even though the full transition is supposed to happen in 2022, it’s unlikely that node operators and dApp developers will all move to eWASM soon.

BPF (Solana)

BPF stands for Berkeley Packet Filter, and it’s a language that can be executed in a virtual machine.  The actual VM is called EbpfVM, and it’s a modification of the original BPF VM that was introduced by Linux. The languages used to write smart contracts for Solana are C, C++, and Rust.

The team doesn’t provide a clear explanation for why they chose BPF. However, in an interesting blog post about coding for a Solana hackathon, developer Brian Anderson theorizes that it’s because the BPF instruction set is easy to map for the x86 computer architecture.

The new trend: EVM implementations in multichain ecosystems

Multichain networks like Cosmos, Polkadot, and Kusama, use very different tech stacks compared to Ethereum. But sooner or later, they all get their EVM implementations on separate chains. The process goes like this:

• A new blockchain ecosystem emerges - more scalable and cheaper to use than Ethereum, but without out-of-the-box EVM support (unlike Avalanche or Fantom, which support EVM natively).
• The new ecosystem does, however, support multiple independent blockchains/parachains/subchains;
• Soon, someone comes up with a parachain or subchain that supports EVM but leverages the high speed & low costs of the ecosystem.
• Ethereum-based dApps that want to expand to the new ecosystem flock to the EVM subchain, which becomes an EVM/Ethereum hub.
• Such a hub can even support multiple VMs – for example, EVM and WASM.

Let’s look at several such EVM implementations and see what they offer to their ecosystems.

Aurora (NEAR)

NEAR is a very interesting up-and-coming blockchain that uses sharding technology to achieve a throughput of 100,000 tps. NEAR is primarily known for two things: very quirky NFT collections (seriously, check them out, they are awesome) and the EVM chain, Aurora.

NEAR is ranked 14^th on DeFiLlama’s list of the biggest chains with a TVL of $525 million, while Aurora is 15th with $502. The fact that it managed to accumulate almost the same amount of liquidity as the mother chain shows that the demand for Ethereum-compatible dApps on NEAR is very high.

Initially NEAR was (and still is) connected to the Ethereum network through the Rainbow Bridge. Then a few of Rainbow’s devs went their own way and created Aurora. It offers the following advantages:

• The base token is ETH – you don’t need NEAR or AURORA
• You don’t even need a NEAR wallet – Aurora supports MetaMask and WalletConnect (here is a tutorial for adding Aurora to MetaMask);
• You can, however, transfer tokens to NEAR if you want to (via the Rainbow Bridge);
• Gas fees are 1,000 times lower than in Ethereum (around $0.1);
• Transactions become final in about 2 seconds;
• You can bridge any ERC20 tokens to Aurora and back. NFT transfers from Ethereum should become possible soon, too. -
• Like any chain on NEAR, Aurora can be sharded if it requires scaling in the future.

Note that whenever you send tokens from Ethereum to Aurora, you’ll need to pay the standard gas fee (around $7 at the time of writing). The near-zero fees apply only to the transactions within the Aurora network.

An important distinction: Aurora is the name of the chain, not of the virtual machine. The EVM implementation used here is SputnikVM, developed by Parity Tech. The supported languages are Solidity and Vyper.

The biggest apps on Aurora

Major Ethereum DeFi dApps like SushiSwap or Aave have yet to expand to Aurora. For now, the top 10 mostly consists of Aurora-native dApps (Trisolaris, Aurigami, Bastion, etc.), the only exception being the Synapse bridge.

Neon EVM (Solana)

Solana is the second-biggest non-EVM compatible blockchain ecosystem after Tron: it has a TVL of $4 billion and handles around 2,400 transactions a minute, or almost 3.5 million per day. 90% of these are validator votes, so the actual number of ‘useful’ transactions on Solana could be around 350,000 a day - far fewer than Ethereum’s 1.25 million, but still a lot for an ecosystem that hosts only native dApps. That’s right: most of the apps you’ll find on Solana don’t work on any other chains:

Hopefully we’ll soon see Ethereum-native DeFi projects on Solana, though – thanks to Neon Labs. Their EVM implementation isn’t live yet, but the testnet and the devnet have been released. In November 2021, the project raised $40 million from such high-profile backers as Solana Capital and Three Arrows Capital.

Note that Neon is a dApp, not a chain: as you may know, Solana doesn’t support independent blockchains or shards. The dApp will feature its own DEX, called Neonswap – the first Uniswap fork on Solana.

It will be easy to update the Neon EVM whenever the original Ethereum Virtual Machine is upgraded. At first, users will need NEON tokens to pay for gas, though in the future the platform should allow  users to cover the gas costs in ETH and ERC20, as well.

It will be very interesting to see what happens when (or if) monsters like Uniswap or Compound land on Solana. Will the native AMMs and lending protocols, such as Serum, Raydium, and Solend stand their ground? Hopefully in 2022 we’ll find out.

Moonbeam (Polkadot) and Moonriver on Kusama

In the Kusama/Polkadot (‘Dotsama’) ecosystem, projects often come in pairs. First one conducts a crowdloan on the faster-moving and experimental Kusama platform to hopefully win a parachain slot; next comes a crowdloan on Polkadot. Such pairs of sister projects usually have the same features – the difference is that the one running on Kusama acts as a testing ground for all new functionality.

Moonriver won the second parachain auction on Kusama in June 2021, while Moonbeam was the winner in the second auction on Polkadot in November 2021.

Moonbeam and Moonriver provide developers with a fully Ethereum-compatible environment and support for tools like Metamask, Truffle, Waffle, Remix, etc. In addition, there is an ongoing effort to integrate with other Dotsama parachains and tools, such as the DeFi hub Acala and its Acala dollar.

Moonriver is by far the biggest parachain on Kusama by TVL ($178 million in late May 2022).

For now, SushiSwap is the one major Ethereum-native DeFi dApp to have joined Moonriver, if you don’t count the bridge apps (Synapse, Connext, and cBridge). The rest of the dApps in the top-5 are Moonriver-native: Moonwell, Zenlink, Solarbeam, and Houses of Rome.

Moonbeam on Polkadot so far has only $72m in TVL, with only one non-bridge EVM-native dApp in the top 5: DeFi protocol Beefy Finance.

Evmos (Cosmos)

The Cosmos ecosystem features many independent ‘worlds’ – blockchains that are even more loosely integrated with each other than in the case of NEAR. The biggest chain is Terra ($LUNA) with its UST stablecoin and an incredible $17+ billion TVL, followed by Osmosis ($OSMO), popular for its DEX and yield farming pools.

Evmos will be an independent chain just like these, but with the goal to serve as an EVM hub for the whole ecosystem. Ethereum-native projects will be deployed as new chains, all linked to Evmos.

Very importantly, Evmos’ own ERC-20 token module is compatible with other Cosmos chains, such as Terra and Osmosis, etc. The hub will also be linked to them thanks to IBC, or Inter-Blockchain Communication Protocol. So in theory, it should be possible to deploy an Ethereum-native dApp on Evmos, and then make its tokens available for trading and farming on Osmosis, for example.

Evmos launched in March 2022, but there were so many bugs that the devs had to deploy an urgent upgrade. Eventually the mainnet relaunched on April 27. Aave should be one of the first Ethereum dApps to be deployed on Evmos: this could give a big boost to decentralized lending across the Cosmos ecosystem.

There is a lot of excitement around EVM chains, and they can indeed bring much-needed liquidity over from Ethereum to alternative platforms like Near and Cosmos. However, even the most streamlined version of EVM can’t compete with WASM and especially Move VM in terms of security and scalability.

The battle of virtual machines could become one of the most interesting blockchain events of 2022 and 2023 – and we at Pontem Network will bring you all the news. Join us on Twitter and Telegram and don’t miss the next update!