Ethereum technical architecture deep dive
Ethereum operates as a distributed state machine, transitioning from one state to another through transaction execution. Post-Merge in September 2022, the architecture separates into two distinct layers: an execution layer handling computation and state management, and a consensus layer coordinating validators through Proof of Stake. This dual-layer design enables Ethereum to maintain 21.6 million ETH staked (worth ~$41 billion) while processing transactions with 99.95% less energy consumption than the previous Proof of Work system.
The technical infrastructure comprises multiple sophisticated subsystems working in concert. The Ethereum Virtual Machine executes smart contracts using a 256-bit stack-based architecture optimized for cryptographic operations. State is managed through Modified Merkle Patricia Tries that enable cryptographic verification of any piece of data. The networking layer uses a DevP2P protocol suite for peer discovery and block propagation. Together, these components create a platform capable of processing ~15 transactions per second while maintaining Byzantine fault tolerance with over 900,000 validators participating globally.
The consensus layer orchestrates proof of stake validation
Ethereum's Proof of Stake consensus operates through the Beacon Chain, which manages validator coordination and block finalization. Validators stake exactly 32 ETH as collateral, which can be destroyed through slashing for protocol violations. Every 12 seconds, a validator is pseudorandomly selected via RANDAO to propose a block, while committees of 128-2,048 validators attest to block validity. The system achieves finality through Casper FFG, a two-phase commit protocol requiring supermajority (≥2/3 stake) agreement. Under normal conditions, blocks achieve finality after approximately 13 minutes (2 epochs).
The validator lifecycle begins with depositing 32 ETH to the deposit contract, followed by an activation queue processing 4-16 validators per epoch based on total active validators. Validators earn rewards for correct attestations and block proposals, with base rewards calculated as effective_balance * base_reward_factor / (base_rewards_per_epoch * sqrt(sum(active_balance))). Penalties mirror rewards for missed duties, while slashing for protocol violations results in immediate loss of 1/32 of stake plus potential correlation penalties up to 100% for mass slashing events. The LMD-GHOST fork choice rule (Latest Message Driven Greedy Heaviest-Observed Sub-Tree) determines the canonical chain by recursively selecting branches with highest accumulated attestation weight.
Communication between layers occurs through the Engine API, a JSON-RPC interface enabling the consensus layer to request block building via engine_forkchoiceUpdatedV2 and validate execution payloads through engine_newPayloadV2. This separation allows independent client development while maintaining protocol coherence.
The EVM executes computation through a stack-based virtual machine
The Ethereum Virtual Machine operates as a 256-bit word, stack-based machine with a maximum stack depth of 1,024 items. This architecture aligns with Keccak-256 hash outputs and secp256k1 elliptic curve operations, both fundamental to Ethereum's cryptography. The EVM maintains three memory types: volatile memory (cleared after transactions), persistent storage (key-value mappings stored in tries), and calldata (read-only transaction input).
Execution follows a fetch-decode-execute cycle where opcodes consume gas proportional to computational complexity. Arithmetic operations cost 3-8 gas, memory operations scale quadratically (memory_cost = memory_size_word²/512 + 3×memory_size_word), while storage operations vary dramatically: SLOAD costs 100/2,100 gas (warm/cold), and SSTORE ranges from 100 to 22,100 gas depending on state transitions. Recent upgrades added opcodes like PUSH0 (Shanghai, 2 gas for zero constant), MCOPY (Cancun, efficient memory copying), and transient storage operations TLOAD/TSTORE (100 gas each).
Gas prevents infinite loops through pre-execution validation and runtime metering. EIP-1559 introduced dynamic base fees adjusting ±12.5% per block based on utilization, with the formula: base_fee_new = base_fee_old * (1 + (gas_used - gas_target) / gas_target / 8). Transactions specify max_fee_per_gas and max_priority_fee_per_gas, with base fees burned and priority fees paid to block proposers. Block gas limits target 15 million gas with 2x elasticity allowing temporary spikes to 30 million.
State management relies on merkle patricia tries for cryptographic verification
Ethereum's state architecture uses Modified Merkle Patricia Tries (MPT) combining trie structure for efficient retrieval, Merkle hashing for integrity verification, and Patricia path compression to reduce depth. The MPT contains four node types: branch nodes (17-element arrays for 16-way branching), extension nodes (compressed shared prefixes), leaf nodes (terminal key-value pairs), and null nodes (empty subtrees). All nodes use RLP (Recursive Length Prefix) encoding for deterministic serialization.
The global state comprises four primary tries. The state trie maps account addresses (hashed to 32 bytes) to account objects containing [nonce, balance, storageRoot, codeHash]. Each contract account maintains a storage trie mapping 32-byte keys to values, referenced by the account's storageRoot. Per-block transaction and receipt tries store transaction data and execution receipts indexed by transaction position.
Storage backends typically use LevelDB (default in Geth) or RocksDB (Nethermind, Besu), implementing LSM-tree structures optimized for write-heavy workloads. Database keys are keccak256 hashes of RLP-encoded nodes, with values storing node content. Full nodes maintain ~500GB of data with 128 recent states, while archive nodes store complete history requiring 12TB+. Pruned nodes aggressively clean old data, reducing requirements to ~150GB.
The networking layer enables decentralized peer communication
Ethereum's networking uses the DevP2P protocol suite for peer-to-peer communication. The discovery protocol implements modified Kademlia DHT over UDP, calculating peer distances as keccak256(node1) XOR keccak256(node2). Nodes maintain k-buckets (k=16) organized by distance, with least-recently-seen eviction. RLPx provides encrypted TCP transport after cryptographic handshaking establishes secure channels.
Ethereum Node Records (ENR) encode node information including consensus layer data like attestation subnet participation. Initial network entry occurs through hardcoded bootnodes, followed by PING-PONG bonding and neighbor discovery. The wire protocol negotiates capabilities through Hello messages, maintaining connections via periodic Ping/Pong exchanges.
Post-Merge, the consensus layer uses libP2P with gossipsub for block propagation, while execution layer maintains DevP2P for transaction gossip. Validators must attest within 4-second windows, creating tight timing requirements. The two-tier transaction broadcast system announces hashes via NewPooledTransactionHashes before full exchange through GetPooledTransactions.
Transactions evolved from simple transfers to complex typed structures
Ethereum supports multiple transaction types through EIP-2718's typed transaction envelope format: TransactionType || TransactionPayload. Legacy transactions (Type 0) use RLP encoding of [nonce, gasPrice, gasLimit, to, value, data, v, r, s]. EIP-1559 transactions (Type 2) introduce fee market reform with base and priority fees. EIP-2930 transactions (Type 1) add access lists pre-declaring state access for gas optimization.
Transaction validation verifies ECDSA signatures using secp256k1 curve parameters (256-bit prime field, specific generator point). Signature recovery through ecrecover extracts sender addresses from transaction hashes and signatures. Nonces enforce ordering and prevent replay attacks, incrementing sequentially from zero.
The mempool maintains two pools: pending (ready transactions with correct nonces) and queued (future transactions). Prioritization sorts by gas price, with replacement allowed for same-nonce higher-fee transactions. Size limits trigger lowest-fee evictions when capacity is reached.
Smart contracts combine code execution with persistent storage
Ethereum distinguishes between Externally Owned Accounts (EOAs) controlled by private keys and Contract Accounts controlled by code. Both store four fields: nonce, balance, storageRoot, and codeHash. EOAs have empty storage and code, while contracts contain EVM bytecode and state variables.
Contract creation uses CREATE (address from creator+nonce) or CREATE2 (deterministic addresses via salt parameter). The deployment process executes initialization code, storing returned bytecode on-chain. SELFDESTRUCT removes contracts, though usage is discouraged due to breaking immutability assumptions.
Contract execution occurs through message calls: CALL executes in target context modifying target storage, DELEGATECALL preserves caller context enabling proxy patterns, and STATICCALL enforces read-only execution for view functions. Gas forwarding follows the 63/64 rule, reserving 1/64 for post-call operations.
The application binary interface standardizes contract interaction
The ABI defines encoding for function calls and event logs. Function selectors use first 4 bytes of keccak256(signature), like transfer(address,uint256) becoming 0xa9059cbb. Arguments follow ABI encoding: static types align to 32 bytes, dynamic types use offset pointers, arrays/strings are length-prefixed.
Event logs support up to 4 indexed topics (searchable) plus unlimited non-indexed data. Indexed dynamic types store keccak256 hashes instead of values. LOG operations cost 375 + 375×topics + 8×data_bytes gas.
Storage uses 256-bit slots with addresses calculated via keccak256. Simple variables pack when possible (multiple sub-32-byte values per slot). Mappings hash keys with slot numbers: keccak256(key || slot). Dynamic arrays store length in base slot, elements at keccak256(slot) + index. Storage operations distinguish cold (first access) from warm (subsequent) with 10-20x cost differences.
Account abstraction enables programmable wallets
EIP-4337 introduces account abstraction without protocol changes through UserOperations - transaction-like objects processed by bundlers. The EntryPoint contract validates and executes operations, while paymasters can sponsor gas fees. Smart contract wallets implement custom validation logic enabling multisig, social recovery, or alternative signature schemes.
UserOperations specify gas limits for validation and execution phases separately. The alternative mempool prevents DoS through simulation and reputation systems. Signature aggregation reduces costs for multiple operations from the same account.
Cryptographic foundations secure all operations
Ethereum uses Keccak-256 hashing (distinct from SHA-3) throughout: address derivation, storage keys, function selectors, and Merkle trees. The secp256k1 elliptic curve (y² = x³ + 7) provides ECDSA signatures with 256-bit private keys generating 512-bit public keys compressed to 20-byte addresses.
Address derivation takes the last 20 bytes of keccak256(public_key). Contract addresses use keccak256(rlp([creator, nonce])) or keccak256(0xff || creator || salt || keccak256(init_code)) for CREATE2. The ecrecover precompile at address 0x01 enables signature verification without storing public keys, consuming 3,000 gas.
Execution clients implement the protocol with varying optimizations
Post-Merge, execution clients handle transaction processing while consensus clients manage validation. Geth (50-80% market share, Go implementation) provides stability and extensive tooling but requires most resources. Nethermind (30% share, C#) offers fastest sync times under 24 hours with online pruning. Besu (31% share, Java) targets enterprise deployments with Bonsai tries eliminating pruning needs. Erigon (~9% share, Go) minimizes storage to 2TB for archive nodes through flat database schemas.
All clients implement the Engine API for consensus communication, but differ in storage backends, sync strategies, and performance characteristics. Client diversity strengthens network resilience against implementation bugs.
Future developments target scalability and efficiency
Active research pursues several architectural improvements. Verkle trees will replace MPTs, reducing witness sizes from ~3KB to ~200 bytes using polynomial commitments on the Bandersnatch curve. State expiry proposals like EIP-7736 would automatically expire unused state after defined periods, bounding growth to 20-50GB active state.
Single slot finality aims to reduce finalization from 13 minutes to 12 seconds through enhanced consensus mechanisms. Proposer-builder separation and data availability sampling lay groundwork for sharding and Layer 2 scaling. Path-based storage models in development reduce redundancy by 98% through direct key addressing rather than content hashing.
These optimizations address Ethereum's trilemma of security, scalability, and decentralization while maintaining backward compatibility and ecosystem stability. The modular architecture enables independent evolution of execution and consensus layers, facilitating rapid protocol development without compromising the $400+ billion of value secured by the network.