Introduction

Every blockchain faces a question: how do you take a user’s intent and turn it into a permanent fact everyone agrees on? Ethereum’s answer isn’t simple, but it’s coherent—an architecture built on state trees, transaction pipelines, and consensus machinery working in concert. It’s a system that has to reconcile competing demands: permissionless access, cryptographic trust, and execution speed that doesn’t collapse under its own weight.

That balance defines the design. The way Ethereum tracks who owns what. The way it shepherds transactions from creation to finality. The virtual machine executing code. The consensus layer coordinating validators. Each piece connects to the next, creating an architecture that has, over ten years, proven both resilient and adaptable.

State, Accounts, and the Merkle-Patricia Backbone

Ethereum uses an account model. Simple enough. Every account—whether controlled by a person with a private key or a smart contract running code—stores four fields: balance, nonce, code, and storage. Those fields live in a global state trie, a database accessible to every node, updated with every block.

This differs from Bitcoin’s UTXO model, where value moves through discrete outputs rather than balances. The account model makes certain things easier. A DeFi swap can update multiple balances in one transaction. A lending protocol can adjust collateral ratios across accounts atomically. You don’t need to assemble coins; you read balances, execute logic, write new balances. It’s more composable.

There’s a cost. Nodes must maintain the full state to validate new transactions, creating storage burdens that shape validator hardware requirements. As of 2025, full nodes demand 4–8 TB of NVMe storage and 64 GB of RAM. Archive nodes storing all historical state push past 12–20 TB depending on client. That’s a barrier to participation, though not an insurmountable one.

The state isn’t just a flat database. It’s a Merkle Patricia Trie (MPT), a tree structure where every account is a leaf, branches connect through cryptographic hashes, and the entire structure resolves to a single 32-byte state root stored in the block header. Change one storage slot in one contract, and the hash path from that slot to the root changes deterministically. The new root becomes the header’s commitment—a cryptographic fingerprint of the entire world state.

This design enables light clients. You don’t need to download terabytes of state to verify a balance. Present a Merkle proof—a path of hashes from the account to the root—and you can confirm the data matches the block header. That’s powerful for mobile wallets, browsers, or anyone who can’t run a full node. It’s also what makes stateless Ethereum feasible: validators wouldn’t store state at all, just receive witnesses proving reads and writes are valid.

Stateless Ethereum remains a research direction, not a shipped feature. But progress is visible. EIP-4444, deployed in July 2025 across Geth, Besu, and Nethermind, lets nodes prune historical block bodies while retaining headers. That freed 300–500 GB per node immediately. Verkle trees, tested on Fusaka Devnet-3 as of mid-2025, promise smaller proofs and lighter storage requirements, enabling validators to run on commodity hardware without sacrificing verification strength. The roadmap is clear: reduce storage demands while preserving cryptographic guarantees.

Still, today’s reality is that maintaining state integrity means maintaining state size. The MPT hashing scheme works, but it’s not free—every branch consumes disk, every update requires recomputing hashes. The tension between global accessibility and practical node operation is ongoing.

From Mempool to Finality: The Execution Pipeline

Transactions don’t appear in blocks by magic. They start when a user signs an instruction—send ETH, call a contract, deploy new code—and broadcasts it to the peer-to-peer network. That transaction enters the mempool, a pool of pending transactions held by individual nodes, waiting for inclusion.

Under EIP-1559, users specify a max fee cap and a priority tip. The protocol calculates a base fee algorithmically, targeting 50% full blocks. If the previous block exceeded that target, the base fee rises by up to 12.5%. If it fell short, the fee drops. Users pay base fee plus their tip; the base fee gets burned, removing ETH from circulation. The tip goes to the block proposer as an incentive to include the transaction quickly.

This structure smooths fee volatility compared to the old pure-auction model, where gas prices spiked unpredictably during congestion. It doesn’t eliminate competition—users still bid via tips—but it makes the baseline more predictable. And because the base fee adjusts block-by-block, the system self-regulates toward equilibrium.

Mempools aren’t global. Each node maintains its own pool of transactions it’s seen, ordered by effective priority (tip divided by gas usage). Latency matters. Geography matters. A high-value transaction broadcast from New York might reach a builder in Virginia milliseconds before reaching one in Frankfurt, giving the faster builder first shot at including it. This isn’t a flaw; it’s a consequence of running a permissionless network across the physical internet.

Ethereum separates block *building* from block *proposing* through a framework called MEV-Boost. Specialized entities called builders scan mempools for profitable transaction orderings—arbitrage between decentralized exchanges, liquidations in lending protocols, sandwich attacks around user trades. They assemble blocks optimized for Maximal Extractable Value (MEV), then bid those blocks to proposers via relays. The proposer, randomly selected each 12-second slot, picks the highest bid, signs the block, and broadcasts it to the network.

This separation captures MEV for validators, who would otherwise lose out to searchers running sophisticated bots. It also centralizes power. As of 2025, the top five builders construct roughly 90% of blocks, creating concentration risks and enabling potential collusion to suppress bids or censor transactions. The market for block construction is competitive but not broadly distributed.

Once a block is proposed, validators attest. Ethereum organizes validators into committees; each slot, one validator proposes while others vote on whether the proposed block is valid and should become the head of the chain. Those votes—called attestations—are cryptographically signed, aggregated, and included in subsequent blocks. The system requires two-thirds agreement to advance.

Finality doesn’t happen instantly. Ethereum’s Gasper consensus combines LMD GHOST (a fork-choice rule that follows the chain with the heaviest recent attestations) with Casper FFG (a finality gadget requiring two successive justified checkpoints). Under normal conditions, finality takes about two epochs—roughly 64 to 95 slots, or 12 to 15 minutes. Until then, a deep reorganization is economically costly but technically possible.

Single-slot finality remains on the research roadmap. If implemented, finality would drop to 12 seconds, matching slot time. But that requires protocol changes to maintain safety with faster votes, which means more research, more testing, more coordination. For now, 12–15 minutes is the guarantee.

It’s worth noting what finality means. Once a block is finalized, reversing it would require destroying roughly one-third of all staked ETH—over $10 billion as of late 2025. That makes reversion economically infeasible for any rational actor. The chain might fork before finality, but after? It’s locked.

Execution Engine and VM Details

Smart contracts don’t run as JavaScript or Python. They compile to bytecode, sequences of single-byte instructions called opcodes, executed by the Ethereum Virtual Machine (EVM). The EVM is stack-based: instructions pop values from a stack, perform operations, push results back. It’s deterministic, meaning the same bytecode with the same inputs produces the same outputs on every node, every time.

Gas metering prevents infinite loops. Every opcode costs gas—simple arithmetic might cost 3 gas, reading from storage costs 2,100 gas, writing to storage can cost 20,000 gas or more depending on the previous value. A transaction specifies a gas limit. If execution exceeds that limit, the EVM halts, reverts all state changes, but keeps the fee. This ensures malicious or buggy contracts can’t lock up the network.

The asymmetry in gas costs shapes development. Storage operations dominate expenses, so developers minimize writes, prefer calldata for passing data, and optimize contract logic aggressively. Understanding gas pricing isn’t optional—it’s fundamental to building efficient, usable applications.

The EVM includes precompiled contracts for common cryptographic operations: signature recovery (`ecrecover`), hash functions, modular exponentiation, pairing checks for zk-SNARKs. These precompiles run natively in client code rather than EVM bytecode, offering performance and cost advantages for operations that would otherwise be prohibitively expensive.

Post-Merge, Ethereum split into two parallel software stacks: the execution layer (handling transactions, state, and the EVM) and the consensus layer (handling validators, attestations, and finality). The two communicate via the Engine API, a request-response protocol where the consensus client asks the execution client to build a payload or execute a block, passing along randomness, proposer assignments, and transaction lists.

This separation enables client diversity. You can run Geth for execution and Prysm for consensus. Or Nethermind and Lighthouse. Or any combination. Different teams, different codebases, different languages—Go, Rust, Java, .NET. If a bug appears in one execution client, validators running different clients continue operating normally, containing the failure rather than halting the chain.

The 2021 Geth bug that briefly split the network illustrated why this matters. A consensus flaw in a majority client could cascade across validators, delaying finality or worse. Client diversity is a defense mechanism, turning monoculture risk into distributed resilience. As of 2025, Prysm and Lighthouse each run on roughly 30–35% of validators, with Teku, Nimbus, and others covering the remainder. That’s healthier than the pre-Merge state, when Geth commanded over 85% of nodes, but still a work in progress.

Consensus Mechanics and Client Diversity

Proof-of-Stake replaced mining in September 2022. Validators lock 32 ETH as collateral, receiving duties to propose blocks or attest to others’ proposals. The Beacon Chain coordinates this, assigning one proposer per 12-second slot via weighted randomness (RANDAO) and distributing attestation responsibilities across committees.

Validators earn rewards for timely, correct participation: proposing valid blocks, attesting to the canonical chain, helping finalize checkpoints. They face penalties for going offline (inactivity leaks) or misbehavior (slashing). Slashing punishes equivocation—proposing two blocks in the same slot, attesting to conflicting blocks, or double-voting—with immediate balance reduction, ongoing penalties during exit, and correlation penalties if many validators misbehave simultaneously. Worst-case slashing can destroy a validator’s entire stake.

This economic security model replaces energy expenditure with capital lockup. Attacking the chain means risking billions in staked ETH. Honest behavior is profitable; deviation is costly. That’s the equilibrium Gasper aims to maintain.

LMD GHOST (Latest Message-Driven Greedy Heaviest Observed SubTree) is the fork-choice rule. It picks the chain with the most recent attestation weight, adapting quickly to new blocks. Casper FFG overlays finality, upgrading blocks to justified status when two-thirds of validators vote, then finalizing blocks once two successive justified checkpoints exist. Together, LMD GHOST handles short-term responsiveness, Casper FFG handles long-term security.

The interplay isn’t trivial. Research has identified edge cases—voting delay attacks, finality delay attacks, commitment attacks—where adversaries holding one-third or more of stake can disrupt finality or penalize honest validators. These remain theoretical; no mainnet exploits have occurred. But they underscore that consensus security isn’t just about honest majority assumptions. It’s about timing, network latency, and the economic costs of manipulation.

Client diversity extends beyond execution. Consensus clients—Prysm, Lighthouse, Teku, Nimbus, Lodestar—each implement the Beacon Chain spec independently, written in different languages by different teams. This redundancy reduces the risk that a single bug halts consensus or creates chain splits. It also distributes influence: no single team controls the majority of validators, making coordinated capture harder.

The Ethereum Foundation and staking providers actively encourage diversity. Coinbase committed publicly to running validators across multiple clients. Community dashboards track client distribution in real time, flagging concentration risks. Progress is measurable—Prysm’s dominance fell from over 66% in early 2022 to roughly 30–35% by 2025. But vigilance remains necessary. A critical bug in a 30% client is still a major incident.

Ethereum has shipped 16 successful upgrades since mainnet launch, each requiring coordination across execution clients, consensus clients, node operators, and validators. The architecture’s modularity—splitting execution from consensus, supporting multiple implementations, relying on open standards—has proven capable of evolving without fracturing. That’s not guaranteed to continue, but ten years of evidence suggests the design holds.