7 min read - Posted 13 Feb 19

Ethereum 101 - Part 7 - The EVM

Quick Overview

The EVM is the part of Ethereum that handles smart contract deployment and execution. Simple value transfer transactions from one EOA to another don’t need to involve it, practically speaking, but everything else will involve a state update computed by the EVM. At a high level, the EVM running on the Ethereum blockchain can be thought of as a global decentralized computer containing millions of executable objects, each with its own permanent data store.

Citation: "Mastering Ethereum, Section 13 - The Ethereum Virtual Machine" authors Andreas Antonopoulos and Gavin Wood Ph.D.

The EVM's been mentioned throughout this documentation, but we haven't gone into much detail. The EVM is the Ethereum Virtual Machine, it is the Turing complete virtual machine that handles all of the transaction processing on the Ethereum network. It is a complete 256 bit virtual machine that serves to execute arbitrary EVM bytecode.

EVM bytecode

Bytecode is the machine code that the high-level smart contract languages are compiled into. It looks like this:


This is not human readable code. If you had some free time, it could be reverse engineered, but that's not always a value-adding task. Further, you shouldn't be interacting with contracts on the blockchain unless you also have their high-level source code and application binary interface (ABI).

Deployment vs runtime bytecode

The above is the deployment bytecode of the HelloWorld.sol Solidity smart contract we deployed earlier in the Smart Contract section. Deployment bytecode is the runtime bytecode wrapped in auxiliary code to foster successful deployment of the contract. After successful contract deployment, the runtime bytecode resides alone at its new contract address.

EVM Assembly

The solidity compiler can print out the EVM assembly of our HelloWorld.sol contract in human readable format: ``` / "HelloWorld.sol":109:871 contract HelloWorld // defining the contract... / mstore(0x40, 0x80) / "HelloWorld.sol":231:395 constructor() // constructor function, optional, executed once upon deployment and cannot be called again... / callvalue / "--CODEGEN--":8:17 / dup1 / "--CODEGEN--":5:7 / iszero tag_1 jumpi / "--CODEGEN--":30:31 / 0x00 / "--CODEGEN--":27:28 / dup1 / "--CODEGEN--":20:32 / revert / "--CODEGEN--":5:7 / tag_1: / "HelloWorld.sol":231:395 constructor() // constructor function, optional, executed once upon deployment and cannot be called again... / pop / "HelloWorld.sol":362:388 greeting = "Hello, World." / 0x40 dup1 mload swap1 dup2 add 0x40 mstore dup1 0x0d dup2 mstore 0x20 add 0x48656c6c6f2c20576f726c642e00000000000000000000000000000000000000 dup2 mstore pop / "HelloWorld.sol":362:370 greeting / 0x00 / "HelloWorld.sol":362:388 greeting = "Hello, World." / swap1 dup1 mload swap1 0x20 add swap1 tag_4 swap3 swap2 swap1 tag_5 jump // in tag_4: pop / "HelloWorld.sol":109:871 contract HelloWorld // defining the contract... / jump(tag_6) tag_5: dup3 dup1 sload 0x01 dup2 0x01 and iszero 0x0100 mul sub and 0x02 swap1 div swap1 0x00 mstore keccak256(0x00, 0x20) swap1 0x1f add 0x20 swap1 div dup2 add swap3 dup3 0x1f lt tag_8 jumpi dup1 mload not(0xff) and dup4 dup1 add or dup6 sstore jump(tag_7)

[ ---- cut ---- ]

  jump    // out

auxdata: 0xa165627a7a723058205a6ad79adf0bb2db43f8594df4cf90d9ddac2dcc7fdec3406884535056226e4c0029


``` This EVM assembly has been truncated. It's actually quite long. This is a little easier to interpret than the raw bytecode.

Quick primer on the EVM instruction set

The instruction set consists of many operations called opcodes. Each opcode is a computational step with an explicit gas cost. Some examples:

0x01ADDAddition operation3Simple computational steps
0x02MULMultiplication operation5N/A
0x31BALANCERetrieve balance of given account400See higher costs
0x54SLOADLoad word from storage200N/A
0x55SSTORESave word to storage20000High cost to store a 256-bit word
0xf4DELEGATECALLPerform a message call to another account in the context of the calling accountVariesNeed to be cautious when using this opcode

Some opcodes cost 0 gas. For example, opcodes that halt execution are gas-less opcodes. For example, the 0x00 STOP opcode halting execution costs 0 gas. Opcodes that terminate a transaction generally use no gas. Some other exceptions that will force the EVM to terminate a transaction are invalid opcodes, invalid jump destinations (the EVM is able to jump to arbitrary positions only if lands on a valid jump-destination), and stack underflows.

Notes on EVM performance

On mainnet, the EVM generally executes bytecode slower than one would expect of other virtual machines. The salient reason for this is that each operation must be executed by every full node in the network in order to achieve a trust-less environment. This is by design. The EVM was designed to achieve decentralized consensus across the whole network, and as a result, computation speeds are slower and costs are higher than those of a centralized network. The upside is that Ethereum network experiences near immutability, significantly improved fault tolerance, and zero downtime.

Additionally, the EVM's gas metering mechanism ensures that miners receive compensation for including the transaction in a block. This also prevents programs from looping eternally. Eventually the transaction will exceed its gas limit, the transaction will immediately halt and rollback all sandboxed state changes. The only state changes resulting from the transaction is the sender's nonce incremented by one and the gas costs up until transaction failure are paid to the miner for their computational effort.

Learning more

The EVM is a subject that should be discussed at length. We won't go into any more detail, as the purpose of this section is to simply introduce users to the internal mechanisms of the EVM. If this topic is interesting to you, then we recommend the Ethereum Virtual Machine (EVM) Awesome List as a good starting point: - https://github.com/ethereum/wiki/wiki/Ethereum-Virtual-Machine-(EVM)-Awesome-List

Created with Sketch.Content is"CC-BY-SA 4.0" licensed
Article On-chain
Article Author

Wil Barnes

Software Engineer




Related Articles
A Deep Dive into the Ethereum Virtual Machine (EVM) - part 1: Introduction

This is the first article of a 4-part series on the EVM; 1. Part 1: Introduction to the EVM 2. Part 2: Memory and Storage on the EVM 3. Part 3: Execution Model of the EVM 4. Part 4: Relationship of the EVM with High-level contract-oriented languages evm-architecture In computing, a virtual machine is an emulation of a computer system which may be implemented as a specialized hardware, software or a combination of both. (source: wikipedia) Virtual machines may be generally categorized into two ty

Mayowa Tudonu

26 Jun 19

A Deep Dive into the Ethereum Virtual Machine (EVM) - part 2: Memory and Storage

This is the second article of a 4-part series on the EVM; 1. Part 1: Introduction to the EVM 2. Part 2: Memory and Storage on the EVM 3. Part 3: Execution Model of the EVM 4. Part 4: Relationship of the EVM with High-level contract-oriented languages evm-storage The Ethereum Virtual Machine has three locations where it can store data; stack, memory, storage. Each of these storage locations play a major role in the execution model of the EVM and also helps to maintain the state of the blockchain.

Mayowa Tudonu

26 Jun 19