1 - EVM

What is the Ethereum Virtual Machine ?

The Ethereum Virtual Machine (EVM) is the heart of the Ethereum protocol. It is the computation engine that handles Smart Contract deployment and execution. More precisely, it is a quasi–Turing-complete state machine; “quasi” because all execution processes are limited to a finite number of computational steps by the amount of gas available for any given Smart Contract execution. As such, the halting problem is “solved” (all program executions will halt) and the situation where execution might (accidentally or maliciously) run forever, thus bringing the Ethereum platform to halt in its entirety, is avoided.

For each new transactions, the EVM computes a valid state transition of the Ethereum global state, named the world state, as a result of Smart Contract code execution. Ethereum is then a transaction-based state machine. It can be thought of as a global decentralized computer containing millions of executable objects, each with its own permanent data store.

The EVM has a stack-based architecture, storing all in-memory values on a stack. It has several addressable data components:

  • An immutable program code ROM, loaded with the bytecode of the smart contract to be executed
  • A volatile memory, with every location explicitly initialized to zero
  • A permanent storage that is part of the Ethereum state, also zero-initialized

The EVM runs low-level bytecode. Smart contracts are typically written in a high-level language, such as Solidity, and they must be compiled to bytecode. Once compiled, they are deployed on the Ethereum platform using a special contract creation transaction, which is identified as such by being sent to the special contract creation address, namely 0x0. Each contract is identified by an Ethereum address, which is derived from the contract creation transaction as a function of the originating account and nonce.

The Ethereum network exists solely for the purpose of keeping the single, continuous, uninterrupted, and immutable operation of the state machine that is the Ethereum blockchain. It is the environment in which all Ethereum accounts and smart contracts and data live. At any given block, Ethereum has one and only one globally accepted ‘state’. The Ethereum Virtual Machine (EVM) is what defines the rules for computing a new valid state from block to block.

Instead of a distributed ledger, Ethereum can be described as a distributed state machine 📚. A state machine is essentially any machine that can change from one state to another in response to certain inputs.

For Ethereum, the state is a bit complex. It is described using a large data structure which contains all the state of the blockchain. The specific rules of how state can change from block to block is defined by the EVM. We recommand reading this presentation to learn more about it Ethereum EVM: Illustrated 📖

To dig into details, you can also watch this video from Ethereum Engineering Group: Understanding EVM 🎬 [01:30:40]

How does gas works on Ethereum ?

Gas is the fuel of Ethereum. Gas is not ether—it’s a separate virtual currency with its own exchange rate against ether. Ethereum uses gas to control the amount of resources that a transaction can use, since it will be processed on thousands of computers around the world. The open-ended (Turing-complete) computation model requires some form of metering in order to avoid denial-of-service attacks or inadvertently resource-devouring transactions.

Gas is separate from ether in order to protect the system from the volatility that might arise along with rapid changes in the value of ether, and also as a way to manage the important and sensitive ratios between the costs of the various resources that gas pays for (namely, computation, memory, and storage).

Gas, described in more detail in [gas], is an incredibly important consideration in smart contract programming. Gas is a resource constraining the maximum amount of computation that Ethereum will allow a transaction to consume. If the gas limit is exceeded during computation, the following series of events occurs:

An “out of gas” exception is thrown.

The state of the contract prior to execution is restored (reverted).

All ether used to pay for the gas is taken as a transaction fee; it is not refunded.

Because gas is paid by the user who initiates the transaction, users are discouraged from calling functions that have a high gas cost. It is thus in the programmer’s best interest to minimize the gas cost of a contract’s functions. To this end, there are certain practices that are recommended when constructing smart contracts, so as to minimize the gas cost of a function call.

Conclusion

In this lesson, we provided a brief overview of the EVM. In the next lesson, we will see how it use it by deploying a Smart Contract.