How Ethereum Works
From accounts and the EVM to gas, state tries, and consensus, the architecture of a world computer visualized
01The Big Idea
Bitcoin proved you can build distributed consensus, a shared ledger that thousands of nodes agree on without trusting each other. Ethereum generalizes that: instead of just tracking coin balances, it maintains a shared world state that includes accounts, balances, code, and storage, and lets transactions trigger arbitrary computation via smart contracts.
Bitcoin
State = set of UTXOs (unspent outputs)
Transactions consume and create UTXOs
Limited scripting (not Turing complete)
The ledger tracks coins
Ethereum
State = mapping of accounts to balance, nonce, code, storage
Transactions trigger code execution
Turing complete (EVM + gas metering)
The ledger is a computer
Both Bitcoin and Ethereum follow the same abstract model: APPLY(State, Transaction) → State′
02Accounts (Not UTXOs)
Ethereum replaces Bitcoin's UTXO model with accounts. Every address in the state is an account object with persistent fields. There are two types:
Externally Owned Account (EOA)
Controlled by a private key (a human or bot). Can initiate transactions. Has a nonce (tx count) and balance.
Contract Account
Controlled by code (EVM bytecode). Cannot initiate transactions on its own, only responds to calls. Has nonce, balance, code, and storage.
03Anatomy of a Transaction
Every state change starts with a transaction signed by an EOA. Unlike Bitcoin (which has inputs and outputs), an Ethereum transaction is a single message with explicit fields:
to recipient address (or empty for contract creation)
value ETH to transfer (in wei)
data input data (function selector + arguments for contract calls)
gasLimit max gas units this tx can consume
gasPrice price per gas unit (or maxFeePerGas post EIP-1559)
v, r, s ECDSA signature components
value: 1 ETH (1e18 wei)
data: empty (0x)
gasLimit: 21,000 (fixed cost for simple transfers)
Result: sender.balance -= 1 ETH + fees, recipient.balance += 1 ETH
04The State Transition Function
This is the heart of Ethereum. When a transaction is applied, the protocol follows a precise sequence: validating, metering gas, executing code, and committing state changes.
2. Deduct upfront gas cost from sender: balance -= gasLimit × gasPrice
3. Set gas counter = gasLimit, subtract intrinsic gas (21,000 base + data costs)
4. Transfer value from sender to recipient
5. Execute code (if recipient is a contract):
EVM runs bytecode, consuming gas per opcode
Contract may CALL other contracts (internal messages)
If gas runs out, all changes revert (but gas is NOT refunded)
6. Refund unused gas to sender: balance += remaining_gas × gasPrice
7. Pay fees to block proposer (validator)
05The EVM: Ethereum Virtual Machine
The EVM is a deterministic stack machine. Given the same starting state and input, every node in the network computes the exact same result. It executes low-level bytecode opcodes, each with a defined gas cost.
Memory byte-addressable, volatile (cleared after execution)
Storage 256-bit to 256-bit mapping, persistent (on chain forever)
Calldata read-only input data from the transaction
Program Counter points to current opcode in bytecode
MLOAD, MSTORE 3 gas + memory expansion cost
SLOAD 2,100 gas (cold storage read)
SSTORE 5,000 to 20,000 gas (storage write is expensive)
CALL 2,600+ gas (calling another contract)
CREATE 32,000 gas (deploying a contract)
Storage writes dominate costs because they change the permanent world state that every node stores.
06Gas: The Anti-DoS Mechanism
Ethereum allows Turing complete programs, which means contracts could theoretically loop forever. Gas is the engineering solution: every computation step costs gas, and every transaction has a hard limit. If gas runs out, execution halts and reverts, but the fee is still consumed (you used real resources).
Prices resources fairly storage is expensive because it is permanent
Aligns incentives users pay validators for compute time
Post EIP-1559: base fee is burned, priority tip goes to validator
Total fee = gas_used × (base_fee + priority_tip)
If the base_fee is 20 gwei and you use 65,000 gas:
Fee ≈ 65,000 × 20 gwei = 1,300,000 gwei ≈ 0.0013 ETH
07Transactions vs Messages (The Call Tree)
A single signed transaction from an EOA can trigger a cascade of internal message calls. When Contract A calls Contract B which calls Contract C, every node must reproduce that exact call tree deterministically.
08State Commitments: Merkle Patricia Tries
Bitcoin commits to transactions with a Merkle tree. Ethereum commits to three things in every block header, each via a Merkle Patricia Trie, a key-value trie with cryptographic hashing:
transactionsRoot commits to every transaction in the block
receiptsRoot commits to execution results (logs, gas used, status)
Each root is 32 bytes. Together they let a light client verify:
that a transaction was included (like Bitcoin SPV)
that an account has a certain balance at a certain block
that a contract's storage contains a specific value
09Consensus: From PoW to Proof of Stake
The original whitepaper described Proof of Work (like Bitcoin). In September 2022, “The Merge” switched Ethereum to Proof of Stake. Validators lock up 32 ETH as collateral and take turns proposing and attesting to blocks.
Pre-Merge (PoW)
Miners compete to find a nonce where the hash is below a target. Energy intensive. Rewards: block subsidy + fees. Security is proportional to hashrate.
Post-Merge (PoS)
Validators stake 32 ETH. Randomly selected to propose blocks. Others attest. Misbehavior leads to slashing (lose ETH). Security is proportional to staked capital.
2. Proposer assembles transactions from the mempool into a block
3. Proposer executes all transactions and computes new stateRoot
4. Block broadcast to the network
5. Other validators independently verify and attest to the block
6. After 2 epochs (~12.8 min), the block is finalized (irreversible)
10Full Lifecycle of an Ethereum Transaction
Putting it all together, from signing to finality:
② Transaction broadcast to network and enters the mempool
③ Validator selected as proposer picks transactions (by priority fee)
④ Proposer executes each tx via APPLY(S, TX) → S′ using the EVM
⑤ New stateRoot, txRoot, receiptsRoot computed and placed in block header
⑥ Block broadcast and other validators verify and attest
⑦ After 2 epochs the block is finalized (economically irreversible)
⑧ World state is updated: balances changed, storage written, events emitted