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 7 times higher than that of its closest competitor,Tron.

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 of 2024, Ethereum has made significant progress in its transition to Ethereum 2.0 (also known as Serenity), a Proof-of-Stake (PoS) network aiming to support up to 100,000 transactions per second. This transition involves several key changes and improvements:

1. Proof of Stake (PoS): The shift from Proof of Work (PoW) to PoS is designed to enhance the network's efficiency, security, and sustainability.
2. Ethereum WebAssembly (eWASM): Ethereum is moving towards adopting eWASM, which allows developers to write smart contracts in various programming languages beyond Solidity. This transition aims to make debugging easier and improve the overall performance and efficiency of the network, potentially lowering gas costs.
3. Transition Tools: Developers will be provided with a transcompiler to convert existing EVM (Ethereum Virtual Machine) code to eWASM-compatible code, facilitating a smoother transition for existing projects.

Current Status and Challenges

• Delays and Gradual Adoption: Despite significant advancements, the Ethereum 2.0 project has faced delays at various stages. While the full transition was initially expected to be completed by 2022, the process has extended into 2024, and the ecosystem is still adapting. Node operators and dApp developers are gradually moving to the new system, but widespread adoption of eWASM may take additional time.
• Network Upgrades: Key upgrades, such as the Merge (the joining of the current Ethereum mainnet with the Beacon Chain) and the introduction of shard chains, have been implemented, enhancing scalability and security.

Looking Forward

• Scalability and Performance: The ongoing development focuses on achieving the high transaction throughput promised by Ethereum 2.0. Sharding is expected to play a crucial role in this, distributing the network load across multiple chains to enhance scalability.
• Developer Experience: With eWASM and the broader range of supported programming languages, the development ecosystem is set to become more versatile and accessible, fostering innovation and efficiency in smart contract development.

Read more about the Ethereum upgrade in our article.

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.

About Pontem

Pontem Network is a product studio building foundational dApps for Aptos. Other Pontem products include:

• Lumio: an Optimistic Layer 2 for Move and Ethereum
• Liquidswap: the leading Aptos DEX
• Move Playground: a browser Move code editor
• ByteBabel: the Solidity-to-Move bytecode translator