Exploring the Ethereum Virtual Machine (EVM)

Introduction

Note: The concepts about the Ethereum Virtual Machine (EVM) as described in this article are highly technical and complex in nature. As such, this article takes the liberty of a high degree of simplification in an attempt to aid readability.

There are various Distributed Ledger Technology (or Blockchain) protocols out there, most of which have their own unique set of features. Some protocols are dedicated to doing one thing and doing it well, such as Bitcoin and its variants being focused entirely on the creation of a decentralised digital currency. Other protocols, like Ethereum, are essentially platforms that developers may leverage to create and deploy smart contracts that operate in a decentralised manner. Apps, often referred toas dApps (decentralised apps), may then interact with these smart contracts.

These types of protocols allow developers to utilise an existing decentralised network, without developers having to build their own from scratch. In principle this increases decentralisation as even if your smart contract is intended to be used by a small community, the resiliency and benefits of decentralisation are attained by leveraging a network that is popular amongst a large cohort of other participants.

However, a double-edged sword of the decentralised world is that there are no set standards that constrain what a protocol may do. While this increases the potential and allows for protocols to have their unique selling points, it also runs the risk of developers not being able to easily shift from one protocol to another. So, does this mean developers have to rebuild their smart contracts for each and every chain out there?

EVM COMPATIBLE CHAIN

Luckily for developers familiar with the Ethereum protocol, a number of popular protocols are leveraging the Ethereum Virtual Machine (EVM) and building what are often called EVM compatible chains. What this means is that, in theory, a smart contract developed on one EVM-compatible chain can be deployed to another EVM-compatible chain. Examples of EVM-Compatible chains we work with on a daily basis at Hash Data include Ethereum, Polygon, Fantom, and Binance Smart Chain.

While these protocols differ amongst each other, most notably in the consensus algorithms they implement, the level of EVM compatibility may be something that varies from protocol-to-protocol. Even protocols such as Cardano which has some very unique characteristics in comparison to the other blockchains has a degree of support for EVM contracts in Solidity.

In chains where the level of EVM compatibility is high through, the decentralised apps can often interact with them using the same libraries and tools making cross-chain support extremely easy. For example, a Smart Contract that has been deployed on the Ethereum Mainnet, may very easily be ported over to the Polygon and Fantom networks.

‍

EVM SMART CONTRACTS

Various programming languages exist for writing smart contracts (i.e. the code that will reside and execute on the decentralised network) for the EVM, but the most popular is Solidity. This programming language is somewhat similar to other popular languages (such as JavaScript) making it somewhat of a gentler learning curve for developers trying to get to grips with smart contract programming. Other languages also exist, such as Vyper which aims to be more secure and readable (making it easier to audit) at the expense of features that arguably make Solidity the easier language to program with.

BYTE CODE

Irrespective of which language is chosen, once finished the code is converted (compiled) into EVM byte code. The byte code is a set of codes (called opcodes) that represent very small and specific operations, such as ADD to add two numbers, MUL to multiply two numbers, and SHA3 to generate the hash for a set of data. While not easily human readable (unlike Solidity or Vyper), byte code is able to be efficiently understood and processed by the EVM.

TURING COMPLETENESS

While the operations exposed by the opcodes may seem limited for the uninitiated, a defining feature of the EVM is that it is Turing Complete. In very loose terms, Turing Completeness means that the set of opcodes available are sufficient to describe (and thus execute) any possible computing problem.

While this sounds great in theory, it does create a major issue: an attacker, or perhaps a bug by a developer, may cause a smart contract to loop infinitely, meaning that the execution will never end, which will result in the blockchain’s resources becoming hogged for other legitimate uses.

In order to avoid such attacks each opcode in the EVM carries with it a weighting, more commonly known as a gas cost (ADD costs 3 gas, MUL costs 5 gas). The collective amount of code that is executed by a call is then translated into an amount to be paid. This means the more intensive the computational workload demanded from the EVM, the more fees must be paid. Therefore, the EVM is able to be Turing Complete while creating heavy economic disincentives for using this feature maliciously against it.

APPLICATION BINARY INTERFACE

As the EVM Byte Code is not easily human readable any other developers who may wish to interact with a smart contract that they did not write are unable to easily understand and identify how to interact with it. This, could be reasonably argued, somewhat defeats the purpose of deploying a smart contract on a decentralised network.

Thankfully, when the code is compiled (i.e. solidity or viper converted to EVM Byte Code), the EVM also provides the developer with an Application Binary Interface (ABI). This piece of information is a form of human-readable register for all the functions and operations that the smart contract exposes. The ABI is also optimised so that the EVM is then able to easily translate the information within the ABI to invoke the appropriate functionality in the underlying Byte Code.

EVENTS

As the functions and operations that the EVM undertakes in the process of a user invoking a smart contract can be complex, the EVM is also able to emit events that are broadcast publicly for any interested party to be able to identify that an action of interest took place.

For example, when two users transfer an amount of ERC20 tokens between them, a transfer event is emitted by the EVM upon successful transfer of funds. This allows the sender and the recipient to know that the transfer has taken place without necessarily having to look at the balance. While this is a fairly simplistic example, events can prove invaluable for dApps to know when an operation actually took place, and thus be able to show the correct information to the end user.

Further, events may be used for any reason that the smart contract developer deems fit, such as broadcasting an event when a token is minted or burned, or when the user occupying a specific role in a smart contract is changed.

Events emitted by the EVM are invaluable assets for any user looking to understand the history of a particular wallet.

THE TRADE-OFF

Allowing for smart contracts to be deployed on different networks is not without its downsides though.

Such scenarios might make it difficult for users to keep track of their portfolio, and even more of a nightmare for auditors and service providers to be able to track relevant information. This is because fundamentally each protocol is still logically separate from one another. For example, users who want to monitor their assets and activities will need to utilise different block explorers (such as https://etherscan.io/ for ETH and https://ftmscan.com/ for FTM) or otherwise leverage bespoke tooling to be able to do this (read this other article for a more in-depth view of this problem).

In fact, we at Hash Data are working on solving this problem by creating a Data Analytics tool that takes advantage of the uniformity brought about by the EVM, in order to be able to collect and process data from across chains so that the cross-chain complexity is eliminated for you.

CONCLUSION

While this article explored the high-level basics of what the EVM and EVM-compatibility bring about, it is only scratching the surface and in order to do so various concepts have been simplified. For further information on the EVM that is technically accurate, one must always make reference to the Ethereum Yellow Paper, which contains a section dedicated to the technical definitions and principle of the EVM.