Decentralized state, chain data held jointly by many
Strawmap K* (2029) · decentralized state
This builds a structure in which Ethereum's entire state (account balances, contract code, and stored values) is held and served by many participants rather than a few large operators. It is work suited to an era in which validators do not hold the state themselves.
Why it is needed
Ethereum nodes today store the current state of every account and contract in full. State keeps growing, and it grows faster if per-block throughput is raised significantly. Then only operators with large storage can run nodes, and wallets and apps end up depending on a few large RPC providers. The roadmap is moving toward letting validators verify blocks without holding state. The mandatory 1-of-1 proofs in the same column are one example. But if validators drop state, someone still has to store the full state and serve it to those who build transactions or produce blocks. If this work concentrates in a few companies, the network becomes vulnerable to censorship and outages. Decentralized state is the work of spreading this storage and serving role across many participants. It is centered on client and network implementation rather than changes to protocol rules. The Strawmap lists the K fork as the expected timing, but this is not a confirmed schedule, and the specific approach is still at the research and design stage.
How it works
- Validators drop state Validators only need to check a proof that the block is correct (a 1-of-1 proof), so they no longer need to store the full state.
- Many participants share the state The full state is not kept in one place. Many nodes each store a part of it. If one participant drops out, others still hold the same data.
- Those who need data receive pieces and proofs A wallet or block builder fetches only the account state it needs from the network, along with a proof that the data is authentic, and verifies it.