Understanding The Ethereum Virtual Machine

Once you write your first few solidity contracts, you may wonder how are contract actually executed? Sure, when you compile your solidity code it may look like a traditional compilation similar to a C program. But understanding the intricacies of how your smart contract is compiled and executed will definitely make you a better developer and help you debug your code faster. In this post we’ll try seek answers to the following questions:

• How a solidity program is compiled?
• What is the Ethereum Virtual Machine (EVM)?
• How the EVM interprets and executes your code?

Prerequisites

• This is advance discusion. You need to have some experience with blockchain development and have a basic understanding of what a smart contract is. If you do not have this knowledge yet. Please feel free to watch checkout courses like 6-Figure Blockchain Developer or Web Development For Blockchain.
• Please install solidity compiler. Refer this link for details

A simple smart contract

//hello.sol
pragma solidity >=0.7.0 <0.9.0;

contract HelloWolrd{ 
   uint256 a;
   constructor() {
      a = 1;
   }
}

Lets compile the program using the following command:

$ solc --bin --asm hello.sol

You should see a similar output on your terminal:

======= hello.sol:HelloWolrd =======
EVM assembly:
    /* "hello.sol":33:109  contract HelloWolrd{ ... */
  mstore(0x40, 0x80)
    /* "hello.sol":73:107  constructor() {... */
  callvalue
  dup1
  iszero
  tag_1
  jumpi
  0x00
  dup1
  revert
tag_1:
  pop
    /* "hello.sol":99:100  1 */
  0x01
    /* "hello.sol":95:96  a */
  0x00
    /* "hello.sol":95:100  a = 1 */
  dup2
  swap1
  sstore
  pop
    /* "hello.sol":33:109  contract HelloWolrd{ ... */
  dataSize(sub_0)
  dup1
  dataOffset(sub_0)
  0x00
  codecopy
  0x00
  return
stop

sub_0: assembly {
        /* "hello.sol":33:109  contract HelloWolrd{ ... */
      mstore(0x40, 0x80)
      0x00
      dup1
      revert

    auxdata: 0xa26469706673582212205fe60a80f73e86d9f3ad4b2fce33b99a5903282fbd1e3b5c7df084ce790bd8d964736f6c634300080a0033
}

Binary:
6080604052348015600f57600080fd5b506001600081905550603f8060256000396000f3fe6080604052600080fdfea26469706673582212205fe60a80f73e86d9f3ad4b2fce33b99a5903282fbd1e3b5c7df084ce790bd8d964736f6c634300080a0033

I admit that output is very difficult to understand. Let first focus on the output under the heading

Binary:
6080604052348015600f57600080fd5b506001600081905550603f8060256000396000f3fe6080604052600080fdfea26469706673582212205fe60a80f73e86d9f3ad4b2fce33b99a5903282fbd1e3b5c7df084ce790bd8d964736f6c634300080a0033

This is the compiled bytecode of our contract. The bytecode is a set of instruction that describes what we have written in solidity. Bytecode is deployed to the ethereum network which the EVM then executes.

The Ethereum Virtual Machine

The part of the protocol that actually handles processing the transactions is Ethereum’s own virtual machine, known as the Ethereum Virtual Machine (EVM).

The EVM is a Turing complete virtual machine, as defined earlier. The only limitation the EVM has that a typical Turing complete machine does not is that the EVM is intrinsically bound by gas. Thus, the total amount of computation that can be done is intrinsically limited by the amount of gas provided.

Moreover, the EVM has a stack-based architecture. A stack machine is a computer that uses a last-in, first-out stack to hold temporary values.

The size of each stack item in the EVM is 256-bit, and the stack has a maximum size of 1024.

The EVM has memory, where items are stored as word-addressed byte arrays. Memory is volatile, meaning it is not permanent.

The EVM also has storage. Unlike memory, storage is non-volatile and is maintained as part of the system state. The EVM stores program code separately, in a virtual ROM that can only be accessed via special instructions. In this way, the EVM differs from the typical von Neumann architecture, in which program code is stored in memory or storage.

If you scan the raw bytecode by bytes (two characters at a time), the EVM identifies specific opcodes that it associates to particular actions. For example: The first 4 characters of the bytecode 6080 translates to (in hexadecimal):

0x60 0x80

The disassembled code is still very low-level and difficult to read, but as you will see, we can start making sense out of it. Each instruction is made up of an opcode and an optional arguments.

Opcodes

Opcodes are low level stack operators that tells the EVM what to do in an instruction. You can think of opcodes as basic arithmetic operations used in algebra. Before we get started on our ambitious endeavour of completely deconstructing the bytecode, you’re going to need a basic tool set for understanding individual opcodes such as PUSH, ADD, SWAP, DUP, etc. An opcode, in the end, can only push or consume items from the EVM’s stack, memory, or storage belonging to the contract. That’s it.

The following table contains the EVM’s opcode instruction set:

Instructions

Each line in the disassembled code above is an instruction for the EVM to execute. Each instruction contains an opcode. For example 0x60 0x80 translates to:

 PUSH1 0x80
  |     |     
  |     Hex value for push.
  Opcode.

Destructing our contract

The compiled code has a lot of boilerplate, the code we have written essentially is compiled under “tag_1”:

tag_1:
  pop
    /* "hello.sol":98:99  1 */
  0x01
    /* "hello.sol":94:95  a */
  0x00
    /* "hello.sol":94:99  a = 1 */
  dup2
  swap1
  sstore
  pop
    /* "hello.sol":33:107  contract HelloWolrd{ ... */
  dataSize(sub_0)
  dup1
  dataOffset(sub_0)
  0x00
  codecopy
  0x00
  return
stop

This assignment is represented by the bytecode “6001600081905550”. Let’s break it up into one instruction per line:

60 01
60 00
81
90
55
50

The EVM is basically a loop that execute each instruction from top to bottom. Let’s annotate the assembly code (indented under the label tag_1) with the corresponding bytecode to better see how they are associated:

tag_1:
  // 60 01
  0x1
  // 60 00
  0x0
  // 81
  dup2
  // 90
  swap1
  // 55
  sstore
  // 50
  pop

Note that 0x1 in the assembly code is actually a shorthand for push(0x1). This instruction pushes the number 1 onto the stack.

EVM: A Stack Machine

The EVM is a stack machine. Instructions might use values on the stack as arguments, and push values onto the stack as results. Let’s consider the operation add. Assume that there are two values on the stack:

[1 2]

When the EVM sees add, it adds the top 2 items together, and pushes the answer back onto the stack, resulting in:

[3]

And notate the contract storage with {}:

// Nothing in storage.
store: {}
// The value 0x1 is stored at the position 0x0.
store: { 0x0 => 0x1 }

Let’s now look at some real bytecode. We’ll simulate the bytecode sequence “6001600081905550” as EVM would, and print out the machine state after each instruction:

// 60 01: pushes 1 onto stack
0x1
  stack: [0x1]
// 60 00: pushes 0 onto stack
0x0
  stack: [0x0 0x1]
// 81: duplicate the second item on the stack
dup2
  stack: [0x1 0x0 0x1]
// 90: swap the top two items
swap1
  stack: [0x0 0x1 0x1]
// 55: store the value 0x1 at position 0x0
// This instruction consumes the top 2 items
sstore
  stack: [0x1]
  store: { 0x0 => 0x1 }
// 50: pop (throw away the top item)
pop
  stack: []
  store: { 0x0 => 0x1 }

The end. The stack is empty, and there’s one item in storage. Evm has now executed our contract successfully.

Conclusion

It’s definitely a good investment to learn how a high-level language like Solidity runs on the Ethereum Virtual Machine (EVM). Knowing the EVM well would help you make awesome tools for yourself and others, also to debug your code better. For further reading checkout the following articles:

• Wood, G. (2014). Ethereum: A secure decentralised generalised transaction ledger
• Ethereum Foundation. (2016). Solidity Documentation
• Santander, A., & Arias, L. (2018). Deconstructing a Solidity Contract
• Howard. (2017). Diving Into The Ethereum Virtual Machine