The future of Ethereum statelessness and the Beam Chain timeline

Ethereum clients use a Merkle Patricia Trie to store state. Information about individual accounts stays as leaves on the trie. Pairs of leaves are hashed repeatedly until only a single root hash remains. To verify a block, a client executes transactions and calculates a new root hash. A block is valid if the computed root matches the root provided by the block proposer. Current clients must store the state for the head block and 128 historical blocks. This requirement forces high hardware costs. Merkle witnesses are too large for 12 second slots. For 1000 leaves, a Merkle witness is 3.5MB. The current Merkle tree structure requires every node to hold sibling nodes to verify a root hash, and this creates a massive data burden that prevents smaller, low power hardware from participating in block validation. Verkle trees reduce witness size by shortening the distance between leaves and the root. They remove the need for sibling nodes. Verkle trees use (key, value) pairs. Keys have 32 bytes: a 31-byte stem and a 1-byte suffix. Extension nodes represent a stem for 256 children. Inner nodes have 256 children. This architecture makes the tree flatter. A Verkle tree witness for 1000 leaves is 150kB. This is a 23x reduction in size. Polynomial witnesses drop that size to 0.128 to 1kB.

The reduction of witness size is only a stepping stone

I think the current roadmap is fundamentally flawed. A client that only performs stateless block execution can do very little. Without the state, a client cannot participate in transaction gossip because validation depends on checking nonces and account balances. A client without the state cannot validate transactions or provide account information. It cannot serve JSON-RPC endpoints like eth_call or eth_getBalance. It lacks the ability to serve GetNodeData requests or participate in the DevP2P eth network. You already know that node operators need functional APIs to support users. The first stateless clients will be greenfield projects from new teams. These teams must build entirely different architectures to handle transaction gossip and JSON-RPC. I find the focus on witness production before client utility to be an error in logic. Developers must still work on binary trie conversion and code merklization.

Redesigning consensus with Beam Chain

Justin Drake proposed Beam Chain to overhaul the consensus layer. The proposal targets 4 second slot times and 3 slot finality. It suggests lowering validator stakes from 32 ETH to 1 ETH. This plan addresses design mistakes in the Beacon Chain. The speccing process starts in 2027, with building starting in 2026 and a two year testing phase starting in 2027. Orbit SSF aims to achieve faster finality by introducing a single super committee. This requires EIP-7251 to raise the maximum staking amount to 2048 ETH. The goal of Orbit SSF is to reduce the time for Ethereum blocks to reach finality from 15 minutes to within 12 seconds. When validators with large staking amounts are almost always included, smaller solo validators might see reduced rewards. To prevent this, Orbit SSF adjusts rewards so that APR increases linearly with the staking amount. This helps ensure that larger validators are included in committees more frequently. Approximately 98% of blocks propagate within 4 seconds, so a 4 second slot time is possible if communication remains efficient. Will the community accept this trade-off for faster finality?