Ethereum Virtual Machine (EVM) Internals: Bytecode, Gas Economics & State Trie Mechanics

Contract Storage Slot Layout & Dynamic Mapping Hashing Arithmetic

Because storage is a flat $2^{256}$-element key-value array, the Solidity compiler assigns state variables to storage slots deterministically according to their order of declaration:

• Value Types: Primitive types (such as uint256, address, bool) smaller than 32 bytes are packed into a single 32-byte storage slot when consecutive, reading from right to left (low-order to high-order bytes), optimizing expensive SSTORE writes.
• Fixed-Size Arrays: Fixed-size arrays of length $N$ allocate $N$ contiguous storage slots starting at the variable's base slot $p$.
• Dynamic Arrays: For a dynamic array declared at slot $p$, slot $p$ stores only the integer length of the array. The actual array elements are stored contiguously starting at the slot computed by hashing the parent slot index:

$${\text{Slot}}_{\text{elem}}(i)=\text{Keccak256}(p)+i$$

• Mappings: A mapping declared at slot $p$ stores no length (mappings do not store their keys on-chain). For a key $k$, the value is stored at the 256-bit slot derived from the concatenated hash:

$${\text{Slot}}_{\text{val}}(k,p)=\text{Keccak256}(k\parallel p)$$

For nested mappings mapping(k1 => mapping(k2 => v)), the slot is computed recursively:

$$\text{Slot}=\text{Keccak256}(k2\parallel \text{Keccak256}(k1\parallel p))$$

This cryptographic pseudo-random distribution guarantees that dynamic arrays and mapping keys will never collide across the vast $2^{256}$ addressable storage universe.

Gas Economics, Berlin Warm/Cold Access & EIP-1559 Mechanism

Gas serves as the fundamental resource metering currency of the EVM, solving the Turing halting problem by guaranteeing that infinite computational loops cannot freeze the network. Every transaction specifies a gas limit; if the execution exhausts the allocated gas before completion, the EVM reverts all state changes while still collecting the consumed gas fee to compensate miners/validators for computational expenditure.

EIP-2929 (introduced in the Berlin hard fork) revolutionized EVM storage pricing by introducing the concept of Warm vs. Cold access to deter state-access DoS attacks:

• COLD_SLOAD_COST: 2,100 gas for the first time a storage slot is read in a transaction.
• WARM_SLOAD_COST: 100 gas for subsequent reads of the same storage slot within the same transaction context.
• COLD_ACCOUNT_ACCESS_COST: 2,600 gas for the first time an external contract address is called or checked.

In London (EIP-1559), Ethereum overhauled the transaction fee market by replacing the legacy first-price auction with a dual-parameter dynamic pricing mechanism:

$$\text{FeePerGas}=\text{BaseFee}+\min (\text{PriorityFee},\text{MaxFeePerGas}-\text{BaseFee})$$

The BaseFee is adjusted deterministically on a block-by-block basis according to target block gas elasticity (target: 15M gas, hard cap: 30M gas). If a block exceeds the 15M target, the base fee increases by up to $12.5\mathrm{\%}$ for the next block:

$${\text{BaseFee}}_{n+1}={\text{BaseFee}}_n\times (1+\frac{1}{8}\frac{{\text{GasUsed}}_n-\text{GasTarget}}{\text{GasTarget}})$$

Crucially, $100\mathrm{\%}$ of the BaseFee is permanently burned (destroyed from the total ETH supply), while only the optional PriorityFee (tip) is awarded to block proposers. This burn mechanism directly links EVM transactional throughput to deflationary monetary pressure on the underlying asset.

The Global State Trie: Modified Merkle Patricia Trie Architecture

The global state of Ethereum is committed to a cryptographically authenticated data structure known as the Modified Merkle Patricia Trie (MPT). The MPT combines the deterministic key-path indexing of a Radix Trie (prefix tree) with the cryptographic integrity verification of a Merkle Tree.

Every Ethereum block header contains three 32-byte Merkle roots:

1. stateRoot: The root hash of the global State Trie mapping all 20-byte account addresses to account state tuples:

$$\text{AccountState}=(\text{nonce},\text{balance},\text{storageRoot},\text{codeHash})$$

1. transactionsRoot: The Merkle root of all transactions included in the block.
2. receiptsRoot: The Merkle root of all execution receipts, containing event logs and post-transaction status codes.

To optimize path depth and prevent explosive trie growth, the MPT uses four specialized node types:

• Null Node: An empty trie node.
• Leaf Node: A 2-item node [encoded_path, value] representing a terminal key-value pair.
• Extension Node: A 2-item node [encoded_path, child_hash] that collapses common intermediate prefix paths into a single hop, drastically reducing trie depth.
• Branch Node: A 17-item node [v0, v1, ..., v15, value] with 16 hex nibble children plus a value slot.

Using these cryptographic roots, any light client can verify an account balance or storage slot with a compact Merkle proof ($O(\log N)$ branch traversal hashes) without downloading the multi-hundred-gigabyte raw state database.

Message Calls, DELEGATECALL & Context Preservation Dynamics

The EVM executes contract inter-communication through a suite of specialized call opcodes:

• CALL: Instantiates a new execution sub-context with its own stack and memory, executing target code in the storage and msg.sender context of the target contract.
• STATICCALL: Introduced in EIP-214, behaves like CALL but strictly reverts if the called code attempts any state-mutating operation (SSTORE, LOG, CREATE, SELFDESTRUCT), guaranteeing read-only safety.
• DELEGATECALL: Introduced in EIP-7, executes the target contract's bytecode within the caller's storage, balance, and msg.sender context.

DELEGATECALL is the fundamental building block of all modern proxy architectures, upgradability patterns, and modular diamond standards (EIP-2535). However, because the target implementation executes directly against the proxy's storage slots, any discrepancy between the implementation and proxy storage variable layouts causes catastrophic storage collision bugs that can permanently compromise contract ownership.

Frequently asked questions

What is the EVM "Stack Too Deep" error and how is it resolved?

The EVM only allows direct stack manipulation on the top 16 elements. Exceeding this limit causes compiler errors. It is resolved by scoping variables in sub-blocks, using structs, or storing intermediate values in memory.

Why does EIP-1559 burn the base fee instead of giving it to validators?

Burning the base fee removes economic incentives for validators to collude or artificially simulate fake transactions to keep gas prices high, creating an efficient and predictable fee market.

How does DELEGATECALL preserve msg.sender and storage?

DELEGATECALL loads code from an external contract but executes it in the current contract's environment, preserving msg.sender, msg.value, and directly reading/writing the calling contract's storage slots.

Sources

• Ethereum Yellow Paper: A Formal Specification of Ethereum — Ethereum Foundation
• Ethereum Virtual Machine (EVM) developer documentation — ethereum.org
• EIP-1153: Transient storage opcodes — Ethereum Improvement Proposals

No contributor to this article holds a professional cryptography or security credential. Every technical claim above is sourced to primary protocol documentation rather than to personal authority — follow the sources and verify anything you intend to act on.

Not financial advice. Crypto assets are volatile and can lose value. This article describes how protocols work, not what you should buy.