killroy

He’s not kidding. Took me HALF AN HOUR to vibe code Notion with Perplexity Computer. Software is legit a zero.

I think there’s a misunderstanding here regarding statelessness. Regardless, this is a good opportunity to clarify some common misconceptions. Statelessness is not complex. Statelessness simply emerges. With real-time proving, validators will verify blocks without needing the full state. This is the "built-in" L1 statelessness. However, statelessness introduces other problems. In a world where full nodes turn into stateless nodes, who holds the state? If no one holds the state, how does state sync work? And if state cannot be synced, how can transactions be published permissionlessly? To mitigate this consequence of “built-in” L1 statelessness, we need to enable and encourage users to run partial stateless nodes. With partial stateless nodes, users take control of their own state and avoid being susceptible to censorship risks—while also improving privacy. We’ll start with out-of-protocol solutions, but if there’s sufficient demand, we can move in-protocol with proper incentives to hold and serve state. Another concept often discussed under the banner of statelessness (though I don’t like to call it that, because it isn’t) is state expiry. The goal is to remove inactive state while providing a way to revive it. It’s effective, but the trade-offs are protocol complexity and user experience. This is not a new idea. There have been plenty of proposals, but none strike the ideal balance we want in terms of impact, complexity, and UX. A continuation of state expiry is state archiving (a.k.a. hot and cold storage). Similar to state expiry, the goal is to remove inactive state. Here, however, inactive state is moved to a secondary, compressed storage layer. This allows us to decouple state access costs from state growth. While nodes would still need to hold more state over time, this becomes far less problematic because access costs are more stable. This can be done out of protocol initially, as much of the work is engineering-focused. We can later shift in-protocol with proper repricing, such that cold storage access is significantly more expensive. Another area we’re exploring is state separation. Not all state has the same access patterns—some is ephemeral, while some is not. Understanding how applications use state allows us to optimize for common patterns at the protocol level. One such feature is temporary storage (see EIP-8125). If you’ve read this far, you’re probably interested in state-related topics. If so, come join the discussion! We have a bi-weekly stateless implementers call at 3 PM UTC. Check out the "state-tree-migration" channel in the ETH R&D Discord for more details.