Understanding How Ethereum Nodes Store Data and Execute Smart Contracts

If you’ve ever heard terms like EVM, OPCODES, stack, and heap, and thought, “Wait, what?” — you’re not alone. Ethereum’s inner workings can sound like a foreign language, especially if you’re not steeped in computer science. But fear not, we’re here to break it down for you!

In this journey, we’re diving into the Ethereum Virtual Machine’s (EVM) execution engine. We’ll unravel how data is stored, played with, and carried out during transactions. But before we embark, let’s quickly revisit what we’ve learned so far.

Ethereum, at its core, functions like a state machine powered by transactions. Starting from a state called s1, transactions tinker with data to transform it into another state, s2. These transactions are bundled together into blocks, each block nudging the world state from s1 to s2, guided by every transaction’s moves.

Now, the big question: What is this world state? 🌍

It’s a fascinating mapping between addresses and account states. Think of Ethereum as a big book, where each address (like a user account or a smart contract) has its own unique chapter.

Alright, let’s get into the nitty-gritty of account states. An account state holds critical stuff like the account’s nonce (kind of like a transaction counter) and its balance in ETH.

Now, brace yourself for the two main transaction types in Ethereum — the creators of new contracts and the senders of messages.

Enter the star of the show, the Ethereum Virtual Machine (EVM). Just as Java has the JVM and Python has its runtime, smart contracts find their home in the EVM. It’s like a virtual playground for executing these smart contracts.

Imagine EVM like a building with two storage rooms: the stack and the memory (which you can think of as a heap). The stack is like a stack of plates, handling data with PUSH and POP operations. Each stack plate holds 256 bits of data (that’s 32 bytes) and you can stack up to 1024 plates high.

All EVM operations take place on this stack. You can manipulate the top 16 plates, but the other 1008 are storage space for operational data, like OPCODES, instructions for the EVM.

Here’s a cool nugget: If you use Solidity (a programming language for Ethereum), you can’t declare more than 16 local variables in a function. Why? Because only the top 16 stack plates are easily accessible for operations in the EVM.

Now, let’s dive into account storage. This is a persistent storage area where 256-bit keys match up with 256-bit values. Think of it as a map, connecting data keys to their values. Initially, everything here starts at zero.

The EVM operates like a conductor in an orchestra, directed by the Program Counter (PC). The PC points to the instruction that’s about to be played. It starts at zero, moving to the next instruction as the melody unfolds.

The instructions in the EVM manipulate data on the stack and memory. Think of memory as your RAM and account storage as your hard disk. The stack (the maestro) can read and write to RAM and the hard disk. Changes to the hard disk data stick around after the performance, unlike RAM, which gets cleared.

Here’s the twist: The EVM keeps track of the gas available. Every operation costs gas, and the EVM chugs along as long as there’s enough gas. If it runs out, the show stops. It’s like refueling a car to keep it going. Complex performances demand more gas, so you pay a premium to keep the spectacle running smoothly.

Gas matters during execution. When a sender initiates a transaction, they provide gas. The EVM plays its part, and if any gas remains, it’s handed back. But if the performance eats up all the gas, the curtains close abruptly. No refunds here — the EVM had to put in the work.

So, the next time Ethereum’s inner workings are brought up, you won’t feel like you’re in a foreign land. The EVM orchestrates the show, moving data, dancing to instructions, and performing transactions — all with a touch of gas to keep the lights on. 🎭⛽