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?

It's a difficult question in itself, but it gets worse : in a world with centralized builders and FOCIL, what happens when a builder drops part of the state, and then a FOCIL transaction triggers an access to that dropped state ?

We want Ethereum to scale, and this means that the state that isn't needed is moved outside of a client's db to ensure continued performance. Mechanically, this creates a risk that a client is missing data that it is supposed to hold as per FOCIL.

So scalability is at odds with censorship resistance : a mechanism is needed to relax FOCIL in order to reject a tx accessing expired state. But we can't allow this to be an excuse to censor transactions either.

The proposal, coming from a discussion with @soispoke, is that if the builder can demonstrate that a FOCIL tx touches the state that is "old enough", and if no witness was passed with the tx, then it's ok to reject that tx. It's up to the wallet to provide the witness.

Isn't this moving the same problem to the wallet? It isn't, because: 1. the wallet can charge a "resurrection fee" to send the transaction, so it is incentivized to keep the expired state. 2. The resurrection is no longer on the critical path of block production.

The rationale here, is that if a user hasn't touched their account for the last 6 years, they can definitely wait for a few more minutes to get their account back. If the user cannot wait, then they should spend some gas every few months to keep the account "hot".

So this removes the need for a fast resurrection. How do we prove that a piece of state is expired? By adding an epoch counter to that state. According to estimates based on @ngweihan_eth , we would add 1GB of data at worst, and would be able to delete 80% of the state!

Does this solve all the problems? No, wallets can be censored too, and data is less redundant so it can be lost. But this means FOCIL can't be leveraged to prevent state expiry. It also somewhat addresses the UX issue posed by state expiry / statelessness.

There are a lot more wallets than builders, and they make more money. So they're harder to censor. And if wallets don't want to play this role, there's room for state networks to form and provide this. This is more hypothetical, though.

Note that, while this requires two protocol changes, state expiry itself doesn't need to be in-protocol.