Unlike the 'black box' systems of Web2, verifiability means that anyone can independently verify how the system operates. Ethereum furthers this by ensuring that anyone (even on low-end devices) can verify state, execution, and consensus. To make Ethereum truly verifiable, three things must be proven: - State: Can users confirm the current data on the blockchain? - Execution: Can users confirm that the state transition function (STF) is valid? - Consensus: Can users confirm that the correct chain has been chosen? The state of Ethereum is a snapshot of all account balances, smart contract storage, and code at any given time. How can this state be proven valid without downloading the entire blockchain? This involves Merkle Trees and their successor, Verkle Trees. Merkle trees create a 'proof path' from data to the Merkle root, allowing users to verify a single data point without requiring the complete dataset. However, as the state of Ethereum grows, Merkle proofs become large and inefficient. Verkle Trees reduce proof sizes using 'elliptic curve vector commitments'. Instead of hashing each data branch, Verkle Trees use cryptographic techniques to generate a smaller single proof, effectively reducing the proof size from 330 MB to about 2 KB. The execution layer of Ethereum runs the state transition function (STF), which takes the previous state and a new block to compute the next state. To verify execution, users must re-run the transaction — a costly process requiring significant storage and computational power. Ethereum uses 'validity proofs' attached to blocks, eliminating the need to re-run each block. Through validity proofs, proposers demonstrate the correctness of STF execution to light clients. Users only verify three simple hash values: the old state root, the new state root, and the block hash. Ethereum's hybrid probabilistic and deterministic consensus allows for low-latency block production (slots), with finality for each epoch (32 slots). How can this process be verified without running a full validator? The sync committee uses 512 randomly selected validators to sign the head of the chain for 27 hours. Light clients can verify this signature without downloading the chain to ensure its correctness. This approach is simple and efficient, but there are also some risks (such as the inability to penalize bad actors).
