History expiry

EIP-4444: Bound Historical Data in Execution Clients�

Alex Stokes�@ralexstokes

what history?

• Today’s blockchain clients keep history of the entire chain
• You may only care about the effects of recent transactions
• e.g. paying this year’s taxes
• But your node can provide the first transaction that landed on-chain
• cool…

This does not scale.

O(n) storage, bandwidth, processing costs

EIP-4444

Bound Historical Data in Execution Clients

EIP-4444: what?

• Change the guarantee that execution clients have *all* of the history

​

• Includes
• Blocks
• Headers
• Transactions
• Ommers
• Receipts from execution results

​

• Does NOT include execution state!

EIP-4444: how?

• Nodes are no longer responsible for serving historic chain data on the peer-to-peer network
• e.g. older than 1 year ago

​

• Implies your local node can prune old history
• Also implies that node will not be able to serve historic RPC queries

Aside: state expiry

• State expiry is an active research area.

​

• This EIP does NOT concern itself with the state as we likely need a more sophisticated approach than what we can get away with for chain history

​

• https://hackmd.io/@vbuterin/state_expiry_paths

How expensive is it?

• Everyone complains about high gas costs
• Reflects underlying cost of operating a node

​

• e.g. `geth db inspect`

Why do we care?

• Important in the short-run and the long-run
• Ideally don’t need fancy disk + networking to host 50 years of chain history
• Also why we can’t 10x the gas limit and call it a day

​

• Higher costs mean
• fewer nodes mean
• worse decentralization means
• easier to attack the protocol means
• worse security!

This is mainly a question of guarantees the protocol provides, �����rather than an issue requiring solving some deep technical challenge.

What should the protocol do?

• *highly secure* consensus protocol to agree on the global state
• “Cursor” over the current activity
• Output finality
• Everything else is someone else’s problem
• Settlement, execution, etc.

​

• NOT an archival service!
• The core protocol is not a full-featured cloud service
• Can talk about some kind of side-car service but not the responsibility of nodes validating the core consensus

I’m 4444-pilled, what now?

​

Who will provide this history?

• How will it be provided?

How can the history be validated?

Who should validate the history?

Who will provide the history?

• Critical to Ethereum’s values to be able to validate the full chain from the genesis block

​

• You just need a few, reliable actors
• Censorship risks to address

​

​

• Archival use case
• No writes, low volume of reads

Example providers

• Altruistic actors
• EF
• Filecoin Foundation
• Portal Network
• Internet Archive
• Individual hosting torrents / file mirrors
• Orgs that provide as a community benefit
• Etherscan
• Infura
• Public goods DAO
• Either organizing resources
• Or providing funding for one of the above

How will we get the history?

• A bit of an implementation detail
• Torrents
• Traditional FTP mirrors
• Filecoin/IPFS storage

​

• How to structure it?
• Ideally can make proofs about large chunks of history
• “Provable” file format, place commitments on-chain

​

​

How can the history be validated?

• “Shim client”
• Maintain historical client that has each fork as a rule set, along with config of blocks to forks
• Can run to verify each and every state transition if you wanted

Who should validate the history?

• ~ motivating question ~

​

• Can imagine a variety of sync modes where users of “full nodes” run multiple protocols to stitch together more and more of the history

Latest work on EIP-4444

• EIP working group, dm @ralexstokes on telegram if you want to get involved

​

• Gathering input from community members
• https://www.ogcouncil.com/ this Saturday 23.04.22 at 1300

​

• @henridf (on telegram) has been working on a prototype
• Demo later today!