EVM Execution Environment: Memory, Storage, and Stack

Hello! Welcome to your first lesson on Ethereum and Solidity development.

Given your extensive background in front-end development and your engineering education, this course aims to provide a structured and deep understanding of the Ethereum ecosystem, either as a refresher or to fill in any gaps. We'll move at a technical pace, focusing on the principles that are crucial for building robust and efficient decentralized applications.

This first lesson kicks off our journey by going straight to the heart of Ethereum: the Ethereum Virtual Machine (EVM). Our goal is to understand its execution environment, specifically the roles of its primary data locations: memory, storage, and the stack. A clear mental model of the EVM is the single most important foundation for writing effective and gas-optimized Solidity code.

Let's begin.

1. What is the Ethereum Virtual Machine (EVM)?

At its core, the EVM is the computation engine of the Ethereum network. You can think of it as a global, decentralized computer that every full node on the network runs. Its primary job is to process transactions and update the state of the Ethereum blockchain.

Unlike the V8 engine running JavaScript in a browser or on a server, the EVM has two critical properties essential for a blockchain:

1. Determinism: For any given input (a transaction and the current state), the EVM must produce the exact same output (a new state) on every node in the network. This is crucial for achieving consensus.
2. Isolation (Sandboxing): The EVM is completely sandboxed. It has no access to the host computer's file system, network, or other processes. It can only access data that is already on the blockchain.

To get a high-level overview of the EVM's role, please watch the following two short clips from the video "Ethereum Explained: The EVM".

2. The EVM's Core Architecture

The EVM is a stack-based machine. If you've worked with low-level systems, you might be familiar with register-based machines (like most modern CPUs) and stack-based machines. In a stack machine, all computations are performed by taking operands from the top of a stack and pushing results back onto it.

During a transaction's execution, the EVM uses several distinct data areas. Understanding the difference between them is vital because they have vastly different characteristics in terms of persistence (how long the data lasts) and cost (how much gas it takes to use them).

The main data locations are:

• Stack
• Memory
• Storage
• Calldata (where function arguments from external calls are stored)
• Code (the contract's own bytecode)

This diagram provides a great visual model of the architecture.

Now, let's dive into the three most important data locations you'll manage as a Solidity developer: the stack, memory, and storage.

3. Deep Dive: Stack, Memory, and Storage

The following video provides an excellent, detailed explanation of the EVM's data areas. We'll watch it in segments.

3.1. The Stack

The stack is a Last-In, First-Out (LIFO) data structure. It's where the EVM holds temporary values to perform computations.

• Persistence: Volatile. Data exists only for the duration of the function call.
• Size: Each item is a 256-bit (32-byte) word. The stack has a maximum depth of 1024 items.
• Usage: Used to hold local variables, function arguments, and values for EVM opcodes (the low-level instructions).
• Cost: Operations on the stack are very cheap in terms of gas.

3.2. Memory

Memory is a temporary, byte-addressable space used to store data during a transaction's execution. Think of it as RAM for your smart contract.

• Persistence: Volatile. It is cleared at the end of each external function call.
• Size: Can be expanded as needed, but the cost increases quadratically with its size.
• Usage: Used for storing complex data types like structs, arrays, and strings that are being manipulated within a function. It's also used to pass arguments to other contracts.
• Cost: Cheaper than storage, but more expensive than the stack.

3.3. Storage

Storage is the persistent memory of a smart contract. It's a key-value store where both keys and values are 256-bit words. This is where the state of your contract lives permanently on the blockchain.

• Persistence: Permanent. Data written to storage remains on the blockchain indefinitely.
• Size: Essentially unlimited, but constrained by the immense gas cost.
• Usage: Used for all contract state variables that need to persist between transactions (e.g., token balances, ownership data).
• Cost: Extremely expensive, especially for writing or changing data. Reading is cheaper but still significant. This cost reflects the fact that every node on the network must store this data forever.

To solidify these concepts, please read the following sections from the article "Introduction to the Ethereum Virtual Machine (EVM)". It provides a concise written summary and a helpful code example.

4. How Solidity Uses These Components

When you write a Solidity contract, the compiler translates your high-level code into low-level EVM bytecode, which is a sequence of instructions called opcodes. Each opcode performs a specific task, like ADD, PUSH1 (push 1 byte onto the stack), MSTORE (write to memory), or SSTORE (write to storage).

The EVM executes these opcodes one by one, using the stack, memory, and storage as we've discussed. For example, to store a value 42 in a state variable, the compiler might generate opcodes that:

1. PUSH1 42 (push the value 42 onto the stack).
2. PUSH1 00 (push the storage slot 0 onto the stack).
3. SSTORE (pop the slot and value from the stack and write the value to that storage slot).

This is a simplified example, but it illustrates how the high-level logic you write is ultimately executed by manipulating these core data areas.

To see how Solidity compiles down to opcodes and their associated gas costs, watch this final clip.

Conclusion

Excellent work on completing your first lesson! We've covered the fundamental operating environment of all smart contracts on Ethereum.

Key Takeaways:

• The EVM is a deterministic, sandboxed state machine that executes smart contract code.
• The Stack is a volatile, cheap, LIFO structure for holding temporary values during computation.
• Memory is a volatile, moderately priced data area for storing complex types within a single transaction. Its cost grows with usage.
• Storage is the persistent, key-value store for a contract's state. It is extremely expensive to write to.
• Your choice of where to store data (memory, storage) has a direct and significant impact on the gas cost of your contract's functions.

In our next lesson, we will build on this foundation by exploring the transaction lifecycle. We'll trace the journey of a transaction from its creation by a user to its final inclusion in a block, which involves the EVM executing the code we've just learned about.