Ethereum Architecture: EVM and State

Hello! Welcome to your fourth lesson.

In our last session, we explored how decentralized networks agree on a single source of truth by comparing Proof-of-Work and Proof-of-Stake consensus mechanisms. We learned how Ethereum decides who gets to add the next block to the chain. Today, we'll shift our focus to what is actually being built and updated with each new block.

This lesson addresses a core concept that separates Ethereum from earlier blockchains like Bitcoin. You will learn to describe the architecture of Ethereum, including the Ethereum Virtual Machine (EVM) and the concept of state. Understanding this is fundamental to your goal of building applications on Ethereum, as the EVM is the environment where your code will run, and the state is what your code will manipulate.

From Distributed Ledger to Distributed State Machine

In previous lessons, we've used the analogy of a "distributed ledger" to describe a blockchain. This is a good starting point, especially for a system like Bitcoin, which primarily tracks transactions of its native currency.

However, Ethereum is more powerful. It doesn't just track transactions; it runs complex applications (smart contracts). To accommodate this, it's better described as a distributed state machine.

What does this mean?

• State: Imagine a "snapshot" of the entire Ethereum network at a specific moment. This snapshot includes every account's balance, the data stored in every smart contract, and all other relevant information. This comprehensive snapshot is called the world state.
• State Machine: The network transitions from one state to the next with each new block of transactions. A transaction is essentially a command that tells the machine how to change the current state into a new one.

To formalize this concept, let's start with a foundational reading from the official Ethereum documentation.

As the article explains, every valid set of transactions (T) applied to the current valid state (S) produces a single, new valid output state (S'). The "engine" that computes this state transition is the Ethereum Virtual Machine (EVM).

The Ethereum Virtual Machine (EVM): The World Computer

The EVM is the heart of Ethereum. It's the sandboxed execution environment that lives inside each Ethereum node, responsible for running smart contract code. Think of it as a global, decentralized processor.

Why a "Virtual" Machine?

Given your background in computer science, the term "virtual machine" might bring the Java Virtual Machine (JVM) or .NET's CLR to mind. The parallel is intentional and very useful.

• Abstraction: The EVM abstracts away the underlying hardware and operating system of the node. This ensures that smart contract code runs exactly the same way on a powerful server in a data center as it does on a personal laptop, guaranteeing determinism.
• Determinism: This is the most critical property. For the network to reach consensus, every node must execute a transaction and arrive at the identical new state S'. If there were any variation, the chain would fork, and consensus would break. The EVM's strict, sandboxed environment makes this possible.

The following video provides an excellent and detailed explanation of what the EVM is and how it functions.

Inside the EVM: Architecture and Execution

Now, let's look under the hood. The EVM has a specific architecture designed for its purpose. Since you're a developer, you'll find these components analogous to those in a traditional computer architecture.

Let's break down these components:

• Virtual ROM (Read-Only Memory): When a transaction calls a smart contract, the EVM loads the contract's bytecode into this read-only memory. This code is immutable; it cannot be changed during execution.
• Memory (Volatile): This is a temporary, word-addressable byte array used by the contract for calculations and short-term data storage during a single transaction. Just like RAM in a computer, its contents are cleared once the transaction execution is complete.
• Storage (Persistent): This is the permanent data store for a smart contract. It's a key-value map where both keys and values are 256-bit words. Unlike memory, data written to storage persists across transactions and is part of the Ethereum world state. Writing to storage is one of the most computationally expensive operations, as it modifies the blockchain's state permanently.
• Stack: The EVM is a stack-based machine. It uses a stack with a maximum depth of 1024 items to hold inputs, outputs, and intermediate values for its operations.

The next segment of the video we started earlier details this architecture.

From Solidity to Opcodes

You won't write EVM code directly. You'll write in a high-level language like Solidity. The Solidity compiler then transforms your human-readable code into EVM bytecode. This bytecode is a sequence of opcodes (operational codes), which are the low-level instructions the EVM can execute.

Examples of opcodes include ADD, PUSH1, SSTORE (save to storage), SLOAD (load from storage), and BALANCE. Each opcode has a predefined gas cost, which is a fixed amount representing the computational effort required to execute it. This is how Ethereum meters resource usage and prevents infinite loops.

The World State in Detail

We started with the idea of the "state." Now let's refine that. The Ethereum world state is formally a massive data structure called a Modified Merkle Patricia Trie. You don't need to understand the intricacies of this data structure right now, but what's important is knowing what it stores: a mapping from every address to its corresponding account.

The state contains two types of accounts (which we will explore in detail in the next lesson):

1. Externally Owned Accounts (EOAs): Controlled by users with private keys (like your MetaMask wallet).
2. Contract Accounts: Controlled by the code of a smart contract.

Each account in the state has four fields:

• nonce: A transaction counter for EOAs or a contract creation counter for contracts.
• balance: The amount of Ether (in Wei) owned by the account.
• storageRoot: A hash representing the root of the contract's private storage trie. It's empty for EOAs.
• codeHash: The hash of the EVM code associated with this account. For EOAs, this is the hash of an empty string.

Every time a transaction is executed by the EVM, it can change one or more of these fields, resulting in a new world state.

Test your understanding!

Consider two common Ethereum transactions:

1. You send 0.5 ETH from your MetaMask wallet (an EOA) to a friend's wallet (another EOA).
2. You call a function on a Uniswap (a decentralized exchange) smart contract to swap one token for another.

Based on what you've learned, briefly describe the key differences in how the Ethereum state is updated in these two scenarios. Which one primarily involves simple balance changes, and which one involves complex EVM execution on bytecode?

Show answer

1. Sending ETH to a friend: This is a simple value transfer. The EVM's role is minimal. The state transition primarily involves:

   • Decrementing the balance of your EOA.
   • Incrementing the balance of your friend's EOA.
   • Incrementing the nonce of your EOA.
     No smart contract bytecode is executed.

2. Swapping tokens on Uniswap: This is a complex operation that deeply involves the EVM. The state transition involves:

   • The EVM loading the Uniswap contract's bytecode.
   • Executing the opcodes corresponding to the swap function.
   • This execution will likely read from and write to the contract's persistent storage (e.g., updating token reserve balances in the liquidity pool).
   • The balance of multiple accounts (yours, the contract's) for multiple tokens will change.
   • The nonce of your EOA will be incremented.

In short, the first scenario is a simple state change of account balances, while the second requires the EVM to run complex, arbitrary code to compute the new state.

Conclusion

In this lesson, we demystified Ethereum's core architecture. You've moved beyond the simple ledger model to understand Ethereum as a sophisticated, distributed state machine.

Key Takeaways:

• Ethereum is a transaction-based state machine. Its primary purpose is to transition from one valid world state to the next.
• The Ethereum Virtual Machine (EVM) is the decentralized computation engine that runs smart contract code to calculate these state transitions. It is designed for determinism, ensuring every node gets the same result.
• Your Solidity code is compiled into EVM bytecode (opcodes), which is what runs on the EVM. Every operation has a gas cost.
• The world state is a mapping of addresses to accounts. Each account has a nonce, balance, codeHash, and storageRoot. Changes to these fields constitute a state transition.
• The EVM has volatile memory (like RAM, for one transaction) and persistent storage (like a database, saved to the blockchain state).

Preview of the Next Lesson:
We've mentioned the two types of accounts that make up the state. In our next lesson, we will dive deeper into them, learning to differentiate between Externally Owned Accounts (EOAs) and Contract Accounts. Understanding their distinct roles and capabilities is essential for interacting with and building on Ethereum.