1/ Ethereum has been on a multi-year journey to scale: L2s, blobs, gas limit increases, gas repricings, and ePBS. Each step boosts throughput, but it also puts more pressure on state, the layer everything else depends on.

eip-8032 (and eip-2926 for that matter) come with a conversion process. It came to my attention that this process is poorly understood, even by core developers. Ahead of the next ACDE, I'm writing a quick explainer.

Imagine hiking with a backpack full of rocks you never use. That’s ~80% of Ethereum’s state. It’s just extra weight that makes every step harder. Great post from @ngweihan_eth and @CPerezz19

New entry about the Future of Ethereum's state in the Ethereum Foundation blog! Go checkout how we plan to mitigate the challenges that the scaling L1 will hopefully materialize more and more! Learn about solutions, research areas, predictions & more!🔥 https://t.co/N449UCjyaY

14/ State is becoming the hidden constraint for decentralization. But the direction is clear: reduce state as a performance bottleneck, lower the cost of holding it, and make it easier to serve.

13/ Concretely: - Archive solutions: test approaches to keep active state bounded, and learn what works (performance, UX, ops complexity) - Partial stateless nodes + RPC upgrades: lower the cost to run RPC infra, and increase diversity in who can serve state.

12/ Our near-term priorities are practical and forward-compatible: ship improvements that help today, but also set up the path to deeper protocol changes later.

11/ 3. Make partial stateless nodes viable: make it easier to hold and serve partial state with incentives, reducing reliance on mega providers. https://t.co/aHiOnSZA7H

10/ 2. State expiry: lots of state goes untouched for long periods. Keep the active set small, push inactive state out, and let it come back later with proofs when someone needs it. https://t.co/iYoCzoHZH7

9/ 1. State archiving: separate hot state (recent/frequent) from cold state (rare). Even if the total state grows forever, the part that needs fast access stays bounded, so execution performance stays stable. https://t.co/NzSWKc64jK

8/ To handle both today’s state growth and tomorrow’s stateless landscape, we see 3 broad directions:

7/ In a stateless world, full state will likely only be stored by: - block builders - large RPC providers - specialists (e.g. MEV searchers, explorers, indexers) Which makes gatekeeping state access easier and harder for new nodes to obtain the full state.

6/ This connects directly to statelessness. Stateless validation helps validators scale by solely verifying proofs without needing the full state. But it raises an important question: then who stores the state, and who serves it?

5/ Proposals like FOCIL can help with censorship resistance. But if state access is gated or unreliable, these mechanisms get weaker in practice.

4/ The bigger risk is centralization: if only a few players can hold + serve full state, fewer parties can build blocks end-to-end when it matters (like during censorship pressure).

3/ Why state growth hurts: - nodes store more data and database work gets less efficient - infrastructure gets more expensive to hold and serve state - syncing and staying near the head gets harder

2/ Scaling L1 has a cost: more throughput usually means more writes, and writes add state. Higher gas limits benefit users, but they also accelerate long-term state growth. https://t.co/1GoDtH0mSB

Keep your eyes open for more goodies in the lab!

......cooking something with @ethPandaOps in https://t.co/0pYYAfCjRu

For a few months, the stateless consensus team has been focused on a specific question: in a world where statelessness / state expiry is a reality, where does one find the state they need?