以太坊状态的未来

免责声明：以下博客是来自无状态共识团队的提案。内容可能不代表共识观点，以太坊基金会是一个广泛的组织，在协议内外包含健康的观点多样性，共同加强以太坊。特别感谢 Ladislaus von Daniels 和 Marius van der Wijden 对本文的审阅。

以太坊已经从一个小型实验网络发展成为全球基础设施的关键组成部分。每天，它结算数十亿美元的价值，协调数千个应用程序，并锚定整个 L2 生态系统。

所有这些最终都依赖于一个单一的底层组件：状态。

什么是“状态”以及为什么它很重要

用户的余额不会存储在他们的钱包中：它存在于以太坊的状态中。状态可以粗略地认为是“以太坊现在知道的一切”：

• 账户
• 合约存储（所有合约已写入的数据）
• 字节码（在使用智能合约时运行的逻辑）

状态几乎支撑着一切：

• 钱包使用它来显示余额和过去的动作。
• Dapps 查询它以了解存在哪些位置、订单或消息。
• 基础设施（浏览器、桥、索引器等）不断读取它以提供顶层服务。

如果状态变得太大、太中心化或太难服务，所有这些层都会变得更加脆弱、更加昂贵且更难去中心化。

扩展 L1 会带来后果

以太坊一直在进行多年的扩展之旅：L2、EIP-4844、gas 限制增加，gas 重新定价和已确定的提案者-构建者分离 (PBS)。每一步都让网络处理更多的活动，但它们也引入了更多的挑战。

挑战 #1 – 状态持续增长

以太坊的状态大小只会单向增长：向上。每个新的账户、存储和字节码写入都会增加网络必须永久保存的数据。

这有实际的成本：

• 验证者和完整节点必须存储更多的数据。这在数据库中引入了额外的工作，随着状态的增长，效率会降低。
• RPC 提供商需要保持完整的状态可用，以便可以随时查询任何账户或存储。
• 随着状态的增长，同步变得更慢且更脆弱。

图 1. 过去一年每周新增状态 ()

Gas 限制的增加会放大状态的增长，因为它们允许每个区块进行更多的写入。其他链已经遇到了这个问题。随着状态大小的增长，运行完整节点对于普通用户来说是不现实的，这会将状态推向少数大型提供商手中。

在以太坊上，大多数区块已经由复杂的构建者生产。一个担忧是，当重要时，有多少独立的参与者仍然可以端到端地构建区块。如果只有一小部分参与者可以持有和服务完整的状态，那么审查阻力和可信中立性就会受到影响，因为更少的参与者可以构建包含被审查交易的区块。

作为部分有利的一面，诸如 PBS 和 FOCIL 之类的机制旨在即使在具有专业构建者的世界中也能保持审查阻力。但是，它们的有效性仍然取决于可以访问、持有和服务状态而没有过高成本的节点的健康生态系统。因此，控制状态增长是先决条件，而不是可选的优化。

为了确定这何时会成为问题，我们正在积极测量和压力测试：

• 状态增长何时成为扩展瓶颈。
• 状态大小何时使节点难以追踪链的头部。
• 客户端实现在极端状态大小下何时开始失败。

在 https://ethereum-magicians.org/t/state-growth-scalability-threats/13853 中查找更多详细信息。

挑战 #2 – 在一个无状态的世界中，谁持有和服务状态？

即使以太坊永远保持今天的 gas 限制，我们最终也会遇到状态增长问题。与此同时，社区显然希望有更高的吞吐量。

无状态性消除了一个很大的限制：验证者不再需要持有完整的状态来验证区块，他们只需验证证明即可。这是一个主要的扩展胜利，使我们能够满足社区对更高吞吐量的需求，并且它还明确了过去隐含的内容：状态存储可以成为一个单独的、更专业的角色，而不是与每个验证者绑定。

届时，大多数状态可能仅由以下人员存储：

• 区块构建者
• RPC 提供商
• 其他专业运营商，如 MEV 搜索者和区块浏览器

换句话说，状态变得更加中心化。

这有几个后果：

• 同步变得更加困难：中心化提供商可能会开始限制对状态的访问，从而使启动新的提供商变得更加困难。
• 审查阻力减弱：由于无法获得被审查的状态，诸如 FOCIL 之类的审查阻力机制可能会失效。
• 弹性和捕获风险：如果只有少数参与者存储和服务完整的状态，那么中断或外部压力可能会迅速切断对生态系统的大部分访问。

即使许多实体存储状态，也没有好的方法来证明他们实际上正在服务它，并且几乎没有动力这样做。快照同步默认情况下得到广泛服务，但 RPC 则不然。如果不降低状态服务的成本并使其更具吸引力，网络访问自身状态的能力最终将掌握在少数提供商手中。

这也会影响 L2。用户强制包含其交易的能力取决于可靠地访问 L1 上的 rollup 合约状态。如果 L1 状态访问变得脆弱或高度中心化，那么这些安全阀在实践中将变得更加难以使用。

我们看到的三个广泛方向

状态过期

并非每个状态都永远同等重要。在我们的分析中，我们已经表明，大约 80% 的状态在一年多内未被触及。但是，节点仍然承担着永久持有状态的成本。

状态过期是指临时从“活动集”中删除非活动状态，并且在需要时需要某种形式的证明才能将其恢复的一般概念。在高层次上，我们可以考虑两个广泛的类别：

1. 标记、过期、恢复

协议可以不将所有状态视为永久活动状态，而是将很少使用的状态标记为非活动状态，因此它不再存在于每个节点维护的活动集中，同时仍然允许以后通过证明它以前存在来恢复它。实际上，经常使用的合约和余额保持活跃且易于访问，而长期被遗忘的状态不会给每个节点带来负担，但如果有人再次需要它，仍然可以恢复。

2. 多时代过期

在多时代设计中，我们不使单个条目过期，而是定期将状态滚动到时代中（例如，一个时代 = 一年）。当前时代很小且完全活跃，旧时代从实时执行的角度来看是冻结的，新状态被写入当前时代。只有当旧状态附带证明它存在于先前时代中的证明时，才能恢复旧状态。

标记-过期-恢复往往更细粒度，并使恢复更加直接，但标记需要存储其他元数据。多时代过期在概念上更简单，并且更自然地与存档配对，但恢复证明往往更复杂且更大。

最终，这两个类别都旨在实现相同的目标——通过暂时删除不活动的部分来保持活动状态较小，同时仍然提供恢复它们的方法——但它们在复杂性、用户体验以及有多少工作被推送到客户端和基础设施方面做出了不同的权衡。

补充阅读：

• https://ethereum-magicians.org/t/a-path-to-state-expiry/4407
• https://ethereum-magicians.org/t/multi-era-state-expiry/15800

状态存档

状态存档是一种分离状态的热部分和冷部分的方法。

• 热状态是网络需要频繁访问的内容。
• 冷状态是对于历史和可验证性仍然重要，但很少触及的所有内容。

在状态存档设计中，节点显式地将最近的、频繁使用的状态与旧数据分开存储。即使总状态持续增长，需要快速访问的部分（热集）也可以保持有界。实际上，这意味着节点的执行性能——尤其是访问状态的 I/O 成本——可以随着时间的推移保持大致稳定，而不是随着链的老化而降低。

使持有和服务状态更容易

一个显而易见的问题是：我们可以在持有更少数据的情况下做足够的事情吗？换句话说，我们能否设计出仍然是有用的参与者而无需永久存储完整状态的节点和钱包？

一个有希望的方向是部分无状态：

• 节点仅持有和服务状态的子集（例如，与一组用户或应用程序相关的部分）。
• 钱包和轻客户端在存储和缓存他们关心的状态片段方面发挥更积极的作用，而不是完全依赖于少数大型 RPC 提供商。如果我们可以安全地将存储分散到钱包和“利基”节点中，那么任何单个运营商的负担都会减少，并且状态持有者的集合会变得更加多样化。

另一个方向是降低运行有用基础设施的门槛：

• 使启动可以为部分状态提供 RPC 服务的节点变得更容易。
• 设计协议和工具，以便钱包和应用程序可以发现和组合多个部分来源，而不是依赖于单个完整 RPC 端点。

我们在以下内容中更详细地探讨了这些想法：

• https://hackmd.io/@gballet/partial_node_architecture

接下来是什么？

以太坊的状态静静地处于协议未来一些最大问题的中心：

• 在成为参与障碍之前，状态可以增长到多大？
• 一旦验证者可以在没有它的情况下安全地验证区块，谁将存储它？
• 谁将以什么激励措施向用户提供它？

其中一些问题仍然是开放的，但方向很明确：减少状态作为性能瓶颈，降低持有状态的成本，并使其更容易服务。

我们今天的优先事项是专注于低风险、高回报的工作，以帮助：

存档解决方案

我们正在尝试链下解决方案，以在依赖于旧数据的存档的同时保持活动状态有界。它应该为我们提供有关性能、用户体验和运营复杂性的真实世界数据。如果证明成功，我们可以在必要时将其推送到链上更改中。

部分无状态节点和 RPC 增强

大多数用户和应用程序通过中心化的 RPC 提供商与以太坊交互。我们正在努力改进以下方面：

• 使运行节点更容易和更便宜，即使它们不持有每个状态片段。
• 允许多个节点合作以提供完整的状态表面。
• 增加 RPC 提供商之间的多样性，因此没有单个参与者成为瓶颈。

这些项目是经过深思熟虑的选择，因为它们立即有用且向前兼容：它们使今天的以太坊更加健康，同时也为以后更雄心勃勃的协议更改做好准备。

当我们迭代时，我们将继续分享我们的进展和我们的开放性问题。但是我们无法孤立地解决这个问题。如果你是客户端开发人员、运行节点、运营基础设施、在 L2 上构建，或者只是关心以太坊的长期健康，我们邀请你参与其中：分享对我们提案的反馈，加入论坛和电话会议的讨论，并帮助在实践中测试新方法。

• 原文链接： blog.ethereum.org/2025/1...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～