{"id":17378,"date":"2026-02-18T03:37:48","date_gmt":"2026-02-18T03:37:48","guid":{"rendered":"https:\/\/cryptoted.net\/index.php\/2026\/02\/18\/the-future-of-ethereums-state\/"},"modified":"2026-02-18T03:37:48","modified_gmt":"2026-02-18T03:37:48","slug":"the-future-of-ethereums-state","status":"publish","type":"post","link":"https:\/\/cryptoted.net\/index.php\/2026\/02\/18\/the-future-of-ethereums-state\/","title":{"rendered":"The Future of Ethereum\u2019s State"},"content":{"rendered":"<p> <br \/>\n<\/p>\n<div id=\"\">\n<p class=\"chakra-text css-gi02ar\"><em class=\"chakra-text css-0\">Disclaimer: The following blog is a proposal from the Stateless Consensus team. Content may not imply consensus views, and the EF is a broad organization that includes a healthy diversity of opinion across Protocol and beyond that together strengthen Ethereum. Special thanks to Ladislaus von Daniels and Marius van der Wijden for reviewing this article.<\/em><\/p>\n<p class=\"chakra-text css-gi02ar\">Ethereum has grown from a small experimental network into a critical piece of global infrastructure. Every day it settles billions of dollars in value, coordinates thousands of applications, and anchors an entire ecosystem of L2s.<\/p>\n<p class=\"chakra-text css-gi02ar\">All of this ultimately relies on a single underlying component: <strong>state<\/strong>.<\/p>\n<h2 class=\"chakra-heading group css-1kpzc4q\" id=\"what-is-state-and-why-it-matters\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"what is state and why it matters permalink\" href=\"#what-is-state-and-why-it-matters\"><svg viewbox=\"0 0 24 24\" focusable=\"false\" class=\"chakra-icon css-173jpr1\"><g fill=\"currentColor\"><path d=\"M10.458,18.374,7.721,21.11a2.853,2.853,0,0,1-3.942,0l-.892-.891a2.787,2.787,0,0,1,0-3.941l5.8-5.8a2.789,2.789,0,0,1,3.942,0l.893.892A1,1,0,0,0,14.94,9.952l-.893-.892a4.791,4.791,0,0,0-6.771,0l-5.8,5.8a4.787,4.787,0,0,0,0,6.77l.892.891a4.785,4.785,0,0,0,6.771,0l2.736-2.735a1,1,0,1,0-1.414-1.415Z\"\/><path d=\"M22.526,2.363l-.892-.892a4.8,4.8,0,0,0-6.77,0l-2.905,2.9a1,1,0,0,0,1.414,1.414l2.9-2.9a2.79,2.79,0,0,1,3.941,0l.893.893a2.786,2.786,0,0,1,0,3.942l-5.8,5.8a2.769,2.769,0,0,1-1.971.817h0a2.766,2.766,0,0,1-1.969-.816,1,1,0,1,0-1.415,1.412,4.751,4.751,0,0,0,3.384,1.4h0a4.752,4.752,0,0,0,3.385-1.4l5.8-5.8a4.786,4.786,0,0,0,0-6.771Z\"\/><\/g><\/svg><\/a>What is \u201cstate\u201d and why it matters<\/h2>\n<p class=\"chakra-text css-gi02ar\">A user\u2019s balance is not stored in their wallets: It lives in Ethereum\u2019s state. The state can roughly be thought of as \u201ceverything Ethereum knows right now\u201d:<\/p>\n<ul role=\"list\" class=\"css-1ars4k6\">\n<li class=\"css-0\">Accounts<\/li>\n<li class=\"css-0\">Contract storage (all the data contracts have written)<\/li>\n<li class=\"css-0\">Bytecode (the logic that runs when you use a smart contract)<\/li>\n<\/ul>\n<p class=\"chakra-text css-gi02ar\">State underpins almost everything:<\/p>\n<ul role=\"list\" class=\"css-1ars4k6\">\n<li class=\"css-0\">Wallets use it to show balances and past actions.<\/li>\n<li class=\"css-0\">Dapps query it to know which positions, orders or messages exist.<\/li>\n<li class=\"css-0\">Infrastructure (explorers, bridges, indexers, etc.) reads it constantly to provide services on top.<\/li>\n<\/ul>\n<p class=\"chakra-text css-gi02ar\">If the state becomes too large, too centralized, or too difficult to serve, all of these layers become more fragile, more expensive, and harder to decentralize.<\/p>\n<h2 class=\"chakra-heading group css-1kpzc4q\" id=\"scaling-l1-comes-with-consequences\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"scaling l1 comes with consequences permalink\" href=\"#scaling-l1-comes-with-consequences\"><svg viewbox=\"0 0 24 24\" focusable=\"false\" class=\"chakra-icon css-173jpr1\"><g fill=\"currentColor\"><path d=\"M10.458,18.374,7.721,21.11a2.853,2.853,0,0,1-3.942,0l-.892-.891a2.787,2.787,0,0,1,0-3.941l5.8-5.8a2.789,2.789,0,0,1,3.942,0l.893.892A1,1,0,0,0,14.94,9.952l-.893-.892a4.791,4.791,0,0,0-6.771,0l-5.8,5.8a4.787,4.787,0,0,0,0,6.77l.892.891a4.785,4.785,0,0,0,6.771,0l2.736-2.735a1,1,0,1,0-1.414-1.415Z\"\/><path d=\"M22.526,2.363l-.892-.892a4.8,4.8,0,0,0-6.77,0l-2.905,2.9a1,1,0,0,0,1.414,1.414l2.9-2.9a2.79,2.79,0,0,1,3.941,0l.893.893a2.786,2.786,0,0,1,0,3.942l-5.8,5.8a2.769,2.769,0,0,1-1.971.817h0a2.766,2.766,0,0,1-1.969-.816,1,1,0,1,0-1.415,1.412,4.751,4.751,0,0,0,3.384,1.4h0a4.752,4.752,0,0,0,3.385-1.4l5.8-5.8a4.786,4.786,0,0,0,0-6.771Z\"\/><\/g><\/svg><\/a>Scaling L1 comes with consequences<\/h2>\n<p class=\"chakra-text css-gi02ar\">Ethereum has been on a multi-year journey to scale: L2s, EIP-4844, gas limit increases, gas repricings, and enshrined Proposer-Builder Separation (<a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-7732\">ePBS<\/a>). Each step lets the network handle more activity, but they introduce more challenges.<\/p>\n<h3 class=\"chakra-heading group css-xuzltg\" id=\"challenge-1--state-keeps-growing\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"challenge 1  state keeps growing permalink\" href=\"#challenge-1--state-keeps-growing\"><svg viewbox=\"0 0 24 24\" focusable=\"false\" class=\"chakra-icon css-173jpr1\"><g fill=\"currentColor\"><path d=\"M10.458,18.374,7.721,21.11a2.853,2.853,0,0,1-3.942,0l-.892-.891a2.787,2.787,0,0,1,0-3.941l5.8-5.8a2.789,2.789,0,0,1,3.942,0l.893.892A1,1,0,0,0,14.94,9.952l-.893-.892a4.791,4.791,0,0,0-6.771,0l-5.8,5.8a4.787,4.787,0,0,0,0,6.77l.892.891a4.785,4.785,0,0,0,6.771,0l2.736-2.735a1,1,0,1,0-1.414-1.415Z\"\/><path d=\"M22.526,2.363l-.892-.892a4.8,4.8,0,0,0-6.77,0l-2.905,2.9a1,1,0,0,0,1.414,1.414l2.9-2.9a2.79,2.79,0,0,1,3.941,0l.893.893a2.786,2.786,0,0,1,0,3.942l-5.8,5.8a2.769,2.769,0,0,1-1.971.817h0a2.766,2.766,0,0,1-1.969-.816,1,1,0,1,0-1.415,1.412,4.751,4.751,0,0,0,3.384,1.4h0a4.752,4.752,0,0,0,3.385-1.4l5.8-5.8a4.786,4.786,0,0,0,0-6.771Z\"\/><\/g><\/svg><\/a>Challenge #1 \u2013 State keeps growing<\/h3>\n<p class=\"chakra-text css-gi02ar\">Ethereum\u2019s state size only goes one way: up. Every new account, storage and bytecode write adds data the network has to keep forever.<\/p>\n<p class=\"chakra-text css-gi02ar\">This has concrete costs:<\/p>\n<ul role=\"list\" class=\"css-1ars4k6\">\n<li class=\"css-0\">Validators and full nodes must store more data. This introduces additional work in the database that is less efficient as the state grows larger.<\/li>\n<li class=\"css-0\">RPC providers need to keep the full state available so any account or storage can be queried at any time.<\/li>\n<li class=\"css-0\">Syncing becomes slower and more fragile as the state grows.<\/li>\n<\/ul>\n<p class=\"chakra-text css-gi02ar\"><img decoding=\"async\" alt=\"\" src=\"https:\/\/notes.ethereum.org\/_uploads\/ryfZiAAfZg.png\" class=\"chakra-image css-hw6q2r\"\/><br \/>\nFigure 1. New state added per week in the past year (<a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-8037\">EIP-8037<\/a>)<\/p>\n<p class=\"chakra-text css-gi02ar\">Gas limit increases amplify state growth, since they allow more writes per block. Other chains already experience this problem. With growing state sizes, running a full node is unrealistic for average users, which pushes state into the hands of a few large providers.<\/p>\n<p class=\"chakra-text css-gi02ar\">On Ethereum, most blocks are already produced by sophisticated builders. One concern is how many independent parties can still build blocks end-to-end when it matters. If only a tiny set of actors can hold and serve the full state, censorship resistance and credible neutrality suffer, because fewer parties can build blocks that include censored transactions.<\/p>\n<p class=\"chakra-text css-gi02ar\">As a partial silver lining, mechanisms like <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-7805\">FOCIL<\/a> and <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/ethresear.ch\/t\/a-pragmatic-path-towards-validity-only-partial-statelessness-vops\/22236\">VOPS<\/a> aim to preserve censorship resistance even in a world with specialized builders. But their effectiveness still depends on a healthy ecosystem of nodes that can access, hold, and serve the state without prohibitive cost. Keeping state growth under control is therefore a prerequisite, not an optional optimization.<\/p>\n<p class=\"chakra-text css-gi02ar\">To determine when this would become a problem, we are actively measuring and stress-testing:<\/p>\n<ul role=\"list\" class=\"css-1ars4k6\">\n<li class=\"css-0\">When state growth becomes a scaling bottleneck.<\/li>\n<li class=\"css-0\">When state size makes it hard for nodes to follow the head of the chain.<\/li>\n<li class=\"css-0\">When client implementations start failing under extreme state size.<\/li>\n<\/ul>\n<p class=\"chakra-text css-gi02ar\">Find more details at <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"http:\/\/bloatnet.info\">bloatnet.info<\/a>.<\/p>\n<h3 class=\"chakra-heading group css-xuzltg\" id=\"challenge-2--in-a-stateless-world-who-holds-and-serves-the-state\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"challenge 2  in a stateless world who holds and serves the state permalink\" href=\"#challenge-2--in-a-stateless-world-who-holds-and-serves-the-state\"><svg viewbox=\"0 0 24 24\" focusable=\"false\" class=\"chakra-icon css-173jpr1\"><g fill=\"currentColor\"><path d=\"M10.458,18.374,7.721,21.11a2.853,2.853,0,0,1-3.942,0l-.892-.891a2.787,2.787,0,0,1,0-3.941l5.8-5.8a2.789,2.789,0,0,1,3.942,0l.893.892A1,1,0,0,0,14.94,9.952l-.893-.892a4.791,4.791,0,0,0-6.771,0l-5.8,5.8a4.787,4.787,0,0,0,0,6.77l.892.891a4.785,4.785,0,0,0,6.771,0l2.736-2.735a1,1,0,1,0-1.414-1.415Z\"\/><path d=\"M22.526,2.363l-.892-.892a4.8,4.8,0,0,0-6.77,0l-2.905,2.9a1,1,0,0,0,1.414,1.414l2.9-2.9a2.79,2.79,0,0,1,3.941,0l.893.893a2.786,2.786,0,0,1,0,3.942l-5.8,5.8a2.769,2.769,0,0,1-1.971.817h0a2.766,2.766,0,0,1-1.969-.816,1,1,0,1,0-1.415,1.412,4.751,4.751,0,0,0,3.384,1.4h0a4.752,4.752,0,0,0,3.385-1.4l5.8-5.8a4.786,4.786,0,0,0,0-6.771Z\"\/><\/g><\/svg><\/a>Challenge #2 \u2013 In a stateless world, who holds and serves the state?<\/h3>\n<p class=\"chakra-text css-gi02ar\">Even if Ethereum stayed at today\u2019s gas limit forever, we would eventually run into state growth issues. At the same time, the community clearly wants more throughput.<\/p>\n<p class=\"chakra-text css-gi02ar\">Statelessness removes a big constraint: validators no longer need to hold the full state to validate blocks, they can just verify proofs. This is a major scalability win that lets us meet the community\u2019s demand for higher throughput, and it also makes explicit something that used to be implicit: state storage can become a separate, more specialized role instead of being tied to every validator.<\/p>\n<p class=\"chakra-text css-gi02ar\">At that point, most state is likely to be stored only by:<\/p>\n<ul role=\"list\" class=\"css-1ars4k6\">\n<li class=\"css-0\">Block builders<\/li>\n<li class=\"css-0\">RPC providers<\/li>\n<li class=\"css-0\">Other specialist operators like MEV searchers and block explorers<\/li>\n<\/ul>\n<p class=\"chakra-text css-gi02ar\">In other words, the state becomes much more <strong>centralized<\/strong>.<\/p>\n<p class=\"chakra-text css-gi02ar\">That has several consequences:<\/p>\n<ul role=\"list\" class=\"css-1ars4k6\">\n<li class=\"css-0\"><strong>Syncing gets harder<\/strong>: centralized providers could start gatekeeping access to the state, making it harder to spin up new providers.<\/li>\n<li class=\"css-0\"><strong>Censorship resistance weakens<\/strong>: censorship resistance mechanisms like FOCIL might be neutered due to the unavailability of censored state.<\/li>\n<li class=\"css-0\"><strong>Resilience and capture risk:<\/strong> if only a few actors store and serve the full state, outages or external pressure on them can quickly cut off access to large parts of the ecosystem.<\/li>\n<\/ul>\n<p class=\"chakra-text css-gi02ar\">Even if many entities store state, there\u2019s no good way to prove they actually serve it, and there are few incentives to do so. Snap sync is widely served by default, but RPC is not. Without making state serving cheaper and generally more attractive, the network\u2019s ability to access its own state ends up in the hands of few providers.<\/p>\n<p class=\"chakra-text css-gi02ar\">This also affects L2s. Users\u2019 ability to force-include their transactions relies on having reliable access to the rollup contract state on L1. If L1 state access becomes fragile or highly centralized, those safety valves become much harder to use in practice.<\/p>\n<h2 class=\"chakra-heading group css-1kpzc4q\" id=\"three-broad-directions-we-see\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"three broad directions we see permalink\" href=\"#three-broad-directions-we-see\"><svg viewbox=\"0 0 24 24\" focusable=\"false\" class=\"chakra-icon css-173jpr1\"><g fill=\"currentColor\"><path d=\"M10.458,18.374,7.721,21.11a2.853,2.853,0,0,1-3.942,0l-.892-.891a2.787,2.787,0,0,1,0-3.941l5.8-5.8a2.789,2.789,0,0,1,3.942,0l.893.892A1,1,0,0,0,14.94,9.952l-.893-.892a4.791,4.791,0,0,0-6.771,0l-5.8,5.8a4.787,4.787,0,0,0,0,6.77l.892.891a4.785,4.785,0,0,0,6.771,0l2.736-2.735a1,1,0,1,0-1.414-1.415Z\"\/><path d=\"M22.526,2.363l-.892-.892a4.8,4.8,0,0,0-6.77,0l-2.905,2.9a1,1,0,0,0,1.414,1.414l2.9-2.9a2.79,2.79,0,0,1,3.941,0l.893.893a2.786,2.786,0,0,1,0,3.942l-5.8,5.8a2.769,2.769,0,0,1-1.971.817h0a2.766,2.766,0,0,1-1.969-.816,1,1,0,1,0-1.415,1.412,4.751,4.751,0,0,0,3.384,1.4h0a4.752,4.752,0,0,0,3.385-1.4l5.8-5.8a4.786,4.786,0,0,0,0-6.771Z\"\/><\/g><\/svg><\/a>Three broad directions we see<\/h2>\n<h3 class=\"chakra-heading group css-xuzltg\" id=\"state-expiry\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"state expiry permalink\" href=\"#state-expiry\"><svg viewbox=\"0 0 24 24\" focusable=\"false\" class=\"chakra-icon css-173jpr1\"><g fill=\"currentColor\"><path d=\"M10.458,18.374,7.721,21.11a2.853,2.853,0,0,1-3.942,0l-.892-.891a2.787,2.787,0,0,1,0-3.941l5.8-5.8a2.789,2.789,0,0,1,3.942,0l.893.892A1,1,0,0,0,14.94,9.952l-.893-.892a4.791,4.791,0,0,0-6.771,0l-5.8,5.8a4.787,4.787,0,0,0,0,6.77l.892.891a4.785,4.785,0,0,0,6.771,0l2.736-2.735a1,1,0,1,0-1.414-1.415Z\"\/><path d=\"M22.526,2.363l-.892-.892a4.8,4.8,0,0,0-6.77,0l-2.905,2.9a1,1,0,0,0,1.414,1.414l2.9-2.9a2.79,2.79,0,0,1,3.941,0l.893.893a2.786,2.786,0,0,1,0,3.942l-5.8,5.8a2.769,2.769,0,0,1-1.971.817h0a2.766,2.766,0,0,1-1.969-.816,1,1,0,1,0-1.415,1.412,4.751,4.751,0,0,0,3.384,1.4h0a4.752,4.752,0,0,0,3.385-1.4l5.8-5.8a4.786,4.786,0,0,0,0-6.771Z\"\/><\/g><\/svg><\/a>State Expiry<\/h3>\n<p class=\"chakra-text css-gi02ar\">Not every piece of state is equally important forever. In our <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/ethereum-magicians.org\/t\/not-all-state-is-equal\/25508\">recent analysis<\/a>, we have shown that roughly 80% of the state has not been touched for more than 1 year. However, nodes still bear the cost of holding the state forever.<\/p>\n<p class=\"chakra-text css-gi02ar\">State expiry is the general idea of temporarily removing inactive state from the \u201cactive set\u201d, and requiring some form of proof to bring it back when needed. At a high level, we can think of two broad categories:<\/p>\n<p class=\"chakra-text css-gi02ar\"><strong>1. Mark, Expire, Revive<\/strong><br \/>Instead of treating all of the state as permanently active, the protocol can mark rarely used state as inactive so it no longer lives in the active set every node maintains, while still allowing it to be revived later with a proof that it previously existed. In effect, frequently used contracts and balances stay hot and cheap to access, while long-forgotten state doesn\u2019t burden every node but can still be brought back if someone needs it again.<\/p>\n<p class=\"chakra-text css-gi02ar\"><strong>2. Multi-era Expiry<\/strong><br \/>In a multi-era design, we don\u2019t expire individual entries, but periodically roll the state into eras (for example, one era = one year). The current era is small and fully active, older eras are frozen from the point of view of live execution, and new state is written into the current era. The old state can be reinstated only if it comes with proofs that it existed in a previous era.<\/p>\n<p class=\"chakra-text css-gi02ar\">Mark\u2013expire\u2013revive tends to be more fine-grained and makes reviving more straightforward, but marking requires additional metadata to be stored. Multi-era expiry is conceptually simpler and pairs more naturally with archiving, but the revival proofs tend to be more complex and larger.<\/p>\n<p class=\"chakra-text css-gi02ar\">Ultimately, both categories aim at the same goal\u2014keeping active state small by temporarily removing inactive parts while still providing ways to revive them\u2014but they make different trade-offs in complexity, UX, and how much work is pushed onto clients and infrastructure.<\/p>\n<p class=\"chakra-text css-gi02ar\">Additional readings:<\/p>\n<h3 class=\"chakra-heading group css-xuzltg\" id=\"state-archive\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"state archive permalink\" href=\"#state-archive\"><svg viewbox=\"0 0 24 24\" focusable=\"false\" class=\"chakra-icon css-173jpr1\"><g fill=\"currentColor\"><path d=\"M10.458,18.374,7.721,21.11a2.853,2.853,0,0,1-3.942,0l-.892-.891a2.787,2.787,0,0,1,0-3.941l5.8-5.8a2.789,2.789,0,0,1,3.942,0l.893.892A1,1,0,0,0,14.94,9.952l-.893-.892a4.791,4.791,0,0,0-6.771,0l-5.8,5.8a4.787,4.787,0,0,0,0,6.77l.892.891a4.785,4.785,0,0,0,6.771,0l2.736-2.735a1,1,0,1,0-1.414-1.415Z\"\/><path d=\"M22.526,2.363l-.892-.892a4.8,4.8,0,0,0-6.77,0l-2.905,2.9a1,1,0,0,0,1.414,1.414l2.9-2.9a2.79,2.79,0,0,1,3.941,0l.893.893a2.786,2.786,0,0,1,0,3.942l-5.8,5.8a2.769,2.769,0,0,1-1.971.817h0a2.766,2.766,0,0,1-1.969-.816,1,1,0,1,0-1.415,1.412,4.751,4.751,0,0,0,3.384,1.4h0a4.752,4.752,0,0,0,3.385-1.4l5.8-5.8a4.786,4.786,0,0,0,0-6.771Z\"\/><\/g><\/svg><\/a>State Archive<\/h3>\n<p class=\"chakra-text css-gi02ar\">State archive is an approach that separates hot and cold parts of the state.<\/p>\n<ul role=\"list\" class=\"css-1ars4k6\">\n<li class=\"css-0\">Hot state is what the network needs to access frequently.<\/li>\n<li class=\"css-0\">Cold state is everything that still matters for history and verifiability, but is rarely touched.<\/li>\n<\/ul>\n<p class=\"chakra-text css-gi02ar\">In a state archive design, nodes explicitly store recent, frequently used state from older data separately. Even if the total state keeps growing, the part that needs fast access (the hot set) can remain bounded. In practice, this means that the execution performance of a node\u2014especially the I\/O cost of accessing state\u2014can stay roughly stable over time, instead of degrading as the chain ages.<\/p>\n<h3 class=\"chakra-heading group css-xuzltg\" id=\"making-it-easier-to-hold-and-serve-state\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"making it easier to hold and serve state permalink\" href=\"#making-it-easier-to-hold-and-serve-state\"><svg viewbox=\"0 0 24 24\" focusable=\"false\" class=\"chakra-icon css-173jpr1\"><g fill=\"currentColor\"><path d=\"M10.458,18.374,7.721,21.11a2.853,2.853,0,0,1-3.942,0l-.892-.891a2.787,2.787,0,0,1,0-3.941l5.8-5.8a2.789,2.789,0,0,1,3.942,0l.893.892A1,1,0,0,0,14.94,9.952l-.893-.892a4.791,4.791,0,0,0-6.771,0l-5.8,5.8a4.787,4.787,0,0,0,0,6.77l.892.891a4.785,4.785,0,0,0,6.771,0l2.736-2.735a1,1,0,1,0-1.414-1.415Z\"\/><path d=\"M22.526,2.363l-.892-.892a4.8,4.8,0,0,0-6.77,0l-2.905,2.9a1,1,0,0,0,1.414,1.414l2.9-2.9a2.79,2.79,0,0,1,3.941,0l.893.893a2.786,2.786,0,0,1,0,3.942l-5.8,5.8a2.769,2.769,0,0,1-1.971.817h0a2.766,2.766,0,0,1-1.969-.816,1,1,0,1,0-1.415,1.412,4.751,4.751,0,0,0,3.384,1.4h0a4.752,4.752,0,0,0,3.385-1.4l5.8-5.8a4.786,4.786,0,0,0,0-6.771Z\"\/><\/g><\/svg><\/a>Making it easier to hold and serve state<\/h3>\n<p class=\"chakra-text css-gi02ar\">An obvious question is: can we do enough while holding less data? In other words, can we design nodes and wallets that are still useful participants without storing the full state forever?<\/p>\n<p class=\"chakra-text css-gi02ar\">One promising direction is partial statelessness:<\/p>\n<ul role=\"list\" class=\"css-1ars4k6\">\n<li class=\"css-0\">Nodes only hold and serve a subset of the state (for example, the parts relevant to a set of users or applications).<\/li>\n<li class=\"css-0\">Wallets and light clients take a more active role in storing and caching the pieces of state they care about, instead of relying entirely on a few big RPC providers. If we can safely decentralize storage across wallets and \u201cniche\u201d nodes, the burden on any single operator goes down, and the set of state holders becomes more diverse.<\/li>\n<\/ul>\n<p class=\"chakra-text css-gi02ar\">Another direction is to lower the barrier to running useful infrastructure:<\/p>\n<ul role=\"list\" class=\"css-1ars4k6\">\n<li class=\"css-0\">Make it easier to spin up nodes that can serve RPC for a partial state.<\/li>\n<li class=\"css-0\">Design protocols and tools so wallets and apps can discover and combine multiple partial sources instead of depending on a single full RPC endpoint.<\/li>\n<\/ul>\n<p class=\"chakra-text css-gi02ar\">We explore these ideas in more detail in:<\/p>\n<h2 class=\"chakra-heading group css-1kpzc4q\" id=\"whats-next\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"whats next permalink\" href=\"#whats-next\"><svg viewbox=\"0 0 24 24\" focusable=\"false\" class=\"chakra-icon css-173jpr1\"><g fill=\"currentColor\"><path d=\"M10.458,18.374,7.721,21.11a2.853,2.853,0,0,1-3.942,0l-.892-.891a2.787,2.787,0,0,1,0-3.941l5.8-5.8a2.789,2.789,0,0,1,3.942,0l.893.892A1,1,0,0,0,14.94,9.952l-.893-.892a4.791,4.791,0,0,0-6.771,0l-5.8,5.8a4.787,4.787,0,0,0,0,6.77l.892.891a4.785,4.785,0,0,0,6.771,0l2.736-2.735a1,1,0,1,0-1.414-1.415Z\"\/><path d=\"M22.526,2.363l-.892-.892a4.8,4.8,0,0,0-6.77,0l-2.905,2.9a1,1,0,0,0,1.414,1.414l2.9-2.9a2.79,2.79,0,0,1,3.941,0l.893.893a2.786,2.786,0,0,1,0,3.942l-5.8,5.8a2.769,2.769,0,0,1-1.971.817h0a2.766,2.766,0,0,1-1.969-.816,1,1,0,1,0-1.415,1.412,4.751,4.751,0,0,0,3.384,1.4h0a4.752,4.752,0,0,0,3.385-1.4l5.8-5.8a4.786,4.786,0,0,0,0-6.771Z\"\/><\/g><\/svg><\/a>What\u2019s Next?<\/h2>\n<p class=\"chakra-text css-gi02ar\">Ethereum\u2019s state is quietly at the center of some of the biggest questions for the protocol\u2019s future:<\/p>\n<ul role=\"list\" class=\"css-1ars4k6\">\n<li class=\"css-0\">How large can the state grow before it becomes a barrier to participation?<\/li>\n<li class=\"css-0\">Who will store it, once validators can safely validate blocks without it?<\/li>\n<li class=\"css-0\">Who will serve it to users, and under what incentives?<\/li>\n<\/ul>\n<p class=\"chakra-text css-gi02ar\">Some of these questions are still open, but the direction is clear: <strong>reduce state as a performance bottleneck<\/strong>, <strong>lower the cost of holding it<\/strong>, and <strong>make it easier to serve<\/strong>.<\/p>\n<p class=\"chakra-text css-gi02ar\">Our priorities today are to focus on low-risk, high-reward work that helps:<\/p>\n<p class=\"chakra-text css-gi02ar\"><strong>Archive solutions<\/strong><br \/>We are experimenting with out-of-protocol solutions to keep the active state bounded while relying on archives for older data. It should give us real-world data on performance, UX and operational complexity. If proven successful, we can push it into an in-protocol change if it\u2019s necessary.<\/p>\n<p class=\"chakra-text css-gi02ar\"><strong>Partial stateless nodes and RPC enhancements<\/strong><br \/>Most users and apps interact with Ethereum through centralized RPC providers. We are working on improvements that:<\/p>\n<ul role=\"list\" class=\"css-1ars4k6\">\n<li class=\"css-0\">Make it easier and cheaper to run nodes, even if they don\u2019t hold every piece of state.<\/li>\n<li class=\"css-0\">Allow multiple nodes to cooperate to serve the full state surface.<\/li>\n<li class=\"css-0\">Increase diversity among RPC providers, so no single actor becomes a bottleneck.<\/li>\n<\/ul>\n<p class=\"chakra-text css-gi02ar\">These projects are deliberately chosen because they are immediately useful and forward-compatible: they make Ethereum healthier today while also preparing the ground for more ambitious protocol changes later.<\/p>\n<p class=\"chakra-text css-gi02ar\">As we iterate, we\u2019ll keep sharing our progress and our open questions. But we can\u2019t solve this in isolation. If you are a client developer, run a node, operate infrastructure, build on L2s, or simply care about Ethereum\u2019s long-term health, we invite you to get involved: share feedback on our proposals, join the discussion on forums and calls, and help test new approaches in practice.<\/p>\n<\/div>\n<p><br \/>\n<br \/><a href=\"https:\/\/blog.ethereum.org\/en\/2025\/12\/16\/future-of-state\">Source link <\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Disclaimer: The following blog is a proposal from the Stateless Consensus team. Content may not imply consensus views, and the EF is a broad organization that includes a healthy diversity of opinion across Protocol and beyond that together strengthen Ethereum. Special thanks to Ladislaus von Daniels and Marius van der Wijden for reviewing this article. [&hellip;]<\/p>\n","protected":false},"author":6,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"tdm_status":"","tdm_grid_status":"","footnotes":""},"categories":[24],"tags":[],"kronos_expire_date":[],"class_list":["post-17378","post","type-post","status-publish","format-standard","hentry","category-ethereum"],"_links":{"self":[{"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/posts\/17378","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/comments?post=17378"}],"version-history":[{"count":0,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/posts\/17378\/revisions"}],"wp:attachment":[{"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/media?parent=17378"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/categories?post=17378"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/tags?post=17378"},{"taxonomy":"kronos_expire_date","embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/kronos_expire_date?post=17378"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}