Impromptu technical AMA on history expiry

Currently, one of the biggest bottlenecks in scaling the Ethereum L1 is hard disk storage. Even at current gas limits, the chain is only a few years away from being too large for many people's hard drives (including my own) to store. Statelessness through Verkle trees, and potentially state expiry, allow validators and nodes to run either without storing any state or at least storing an amount of state that stays constant instead of growing over time.

History expiry is the idea of doing the same with blockchain history: instead of all full nodes having to download and serve the full chain from genesis, and needing to have ever-increasing technical complexity to deal with both old and new versions, the core Ethereum protocol would only be responsible for holding and serving the most recent ~1 year of historical blocks, transactions and receipts/logs. This can reduce code complexity and reduce storage requirements for nodes, paving the way for more decentralization.

Older blocks, transactions and receipts/logs would still be accessible through dedicated sub-protocols (eg. the Portal Network) or externally developed protocols (eg. TheGraph), in addition to a much smaller but still sufficient number of volunteer nodes and block explorers. Note that many dapps are already moving their historical data queries to TheGraph and similar protocols for efficiency.

There are two realistically implementable history expiry proposals (which are not mutually exclusive; we can do both):

• One-time expiry of pre-merge history: a few months to a year after the merge, Ethereum nodes stop downloading or serving the pre-merge PoW chain
• Regular rolling expiry (EIP 4444): see the EIP 4444 documentation, and Matt's Twitter thread explaining the importance of doing something like it.

The EIP 4444 authors and myself are happy to answer any questions on history expiry, what the benefits are, and how existing users and applications that depend on older history can adapt.