以太坊基金会：以太坊状态演进路径与未来挑战

  作者：Wei Han Ng，Carlos Pérez，无状态共识研究团队

  以太坊已从一个实验性的小型网络成长为全球基础设施的关键组成部分。它协调成千上万的应用程序，并支撑着整个二层网络（L2）生态。

  这一切最终都依赖于一个核心底层组件：状态（state）。

1、什么是“状态”及其重要性

  状态可以粗略理解为“以太坊当前所知的一切”：账户、合约存储（合约写入的所有数据）、字节码（使用智能合约时运行的逻辑）。

  状态几乎是所有功能的基础：

  钱包依赖它来显示余额和过往操作记录；

  去中心化应用（Dapps）通过查询它来了解现有的持仓、订单或消息；

  基础设施（区块浏览器、跨链桥、索引器等）持续读取状态，以在其之上提供服务。

  如果状态变得过于庞大、过于中心化，或难以提供服务，所有上述层级都会变得更加脆弱、成本更高，且更难以去中心化。

2、L1扩展会带来相应后果

  以太坊多年来持续致力于网络扩展：通过二层网络、EIP-4844、提高Gas上限、Gas费重定价，以及内置的提议者-构建者分离机制。每一步都提升了网络处理能力，但也带来了新的挑战。

  挑战一：状态持续膨胀

  以太坊的状态规模只增不减。每个新增账户、存储操作和字节码写入都会永久增加网络必须保存的数据。

  这产生了具体成本：

  验证者和全节点必须存储更多数据。随着状态规模扩大，数据库需要处理额外工作负荷，效率随之降低。

  RPC服务提供商需保持完整状态可访问，确保任意账户或存储数据可随时查询。

  状态增长导致节点同步速度变慢、稳定性下降。

  提高Gas上限会加剧状态膨胀，因为每个区块可容纳更多写入操作。其他公链已出现此问题。随着状态规模扩大，普通用户难以运行全节点，导致状态数据集中于少数大型服务商手中。

  在以太坊，多数区块已由专业构建者生产。核心关切在于关键时刻仍有多少独立主体能完成端到端的区块构建。如果只有极少数参与者能存储并提供完整状态，抗审查能力和可信中立性将受损——因为能构建包含被审查交易的区块的主体将更少。

  部分积极因素是，FOCIL和VOPS等机制旨在保障专业化构建者生态下的抗审查性。但其有效性仍依赖于健康的节点生态，这些节点需能以可承受成本访问、存储和提供状态数据。因此控制状态增长是必要前提，而非可选优化。

  为确定问题临界点，我们正积极进行压力测试：

  状态增长何时成为扩展瓶颈；

  状态规模何时使节点难以跟随链头；

  客户端实现何时在极端状态规模下失效。

  挑战二：在无状态架构中，谁负责存储并提供状态？

  即使以太坊永久维持当前的Gas上限，我们最终仍会遭遇状态膨胀问题。与此同时，社区显然期待更高的吞吐量。

  无状态方案消除了一个重大限制：验证者无需持有完整状态即可验证区块，仅需验证证明。这是重要的可扩展性突破，既能满足社区对更高吞吐量的需求，也揭示了一个曾经隐含的事实——状态存储可演变为独立且更专业化的职能，而非与每个验证者绑定。

  届时，大部分状态可能仅由以下主体存储：

  区块构建者；

  RPC服务提供商；

  其他专业运营商（如MEV搜索者和区块浏览器）。

  换言之，状态将变得更加中心化。

  这会引发多重后果：

  同步难度增加：中心化服务商可能开始限制对状态的访问，导致新服务商难以启动；

  抗审查性削弱：若被审查的状态数据无法获取，FOCIL等抗审查机制可能失效；

  系统韧性风险：若仅少数主体存储并提供完整状态，其服务中断或遭受外部压力将迅速切断生态大部分组件的访问。

  即使许多实体存储状态，也缺乏有效方式验证其实际提供服务，且现有激励不足。快照同步默认被广泛支持，但RPC服务则不然。若不降低状态服务成本并提升其普遍吸引力，网络访问自身状态的能力将受制于少数服务商。

  这一问题同样波及第二层网络。用户强制打包交易的能力依赖于对L1上Rollup合约状态的可靠访问。若L1状态访问变得脆弱或高度中心化，这些安全阀机制在实际应用中将难以运作。

3、我们看到的三大方向

  （1）状态有效期

  并非所有状态数据都具有同等的永久重要性。我们近期的分析表明，约80%的状态数据超过一年未被访问。然而，节点仍需永久承担存储这些状态的成本。

  状态有效期机制的核心思想，是将非活跃状态从"活跃集合"中暂时移除，待需要时再通过某种形式的证明恢复。概括而言，可将其分为两大类：

  第一类：标记、失效、复活

  协议不再将所有状态视为永久活跃，而是将极少使用的状态标记为非活跃状态，使其不再存留于每个节点维护的活跃集合中，同时允许通过历史存在证明在未来将其恢复。其实际效果是：常用合约和余额保持活跃状态且访问成本低廉，而被长期遗忘的状态则无需每个节点持续承载，当有人再次需要时仍可被召回。

  第二类：多周期失效机制

  在多周期设计中，我们不对单个条目设置失效，而是周期性地将状态按周期划分（例如，一个周期=一年）。当前周期规模较小且完全活跃，旧周期从实时执行的角度看已被冻结，而新状态会写入当前周期。旧状态仅能通过证明其在先前周期中存在的方式恢复。

  标记-失效-复活机制通常更精细，复活流程更直接，但标记过程需存储额外元数据。多周期失效在概念上更简单，更自然地与归档机制结合，但复活证明往往更复杂、体量更大。

  归根结底，这两类方案目标一致——通过暂时移除非活跃部分保持活跃状态精简，同时提供复活途径——但它们在复杂性、用户体验以及对客户端和基础设施的工作分配上做出了不同取舍。

  （2）状态归档

  状态归档将状态区分为冷、热状态。

  热状态是网络需要频繁访问的部分；

  冷状态是对历史记录和可验证性仍然重要但极少被触动的部分。

  在状态归档设计中，节点会明确将近期频繁使用的热状态与历史数据分开存储。即使整体状态持续增长，需要快速访问的部分（热数据集）仍可保持有限规模。实际上这意味着节点的执行性能——特别是访问状态的I/O成本——可随时间保持基本稳定，而不会随链龄增长而下降。

  （3）降低状态存储与服务的门槛

  一个明显的问题是：我们能否在持有更少数据的情况下实现目标？换言之，能否设计无需永久存储完整状态、仍能作为有效参与者的节点和钱包？

  一个前景广阔的方向是部分无状态方案：

  节点仅存储并提供部分状态（例如与特定用户或应用相关的数据）；

  钱包和轻客户端在存储与缓存所需状态片段方面承担更主动的角色，而非完全依赖少数大型RPC服务商。若能安全地将存储分散至钱包和"利基"节点，单个运营者的负担将减轻，状态持有者群体也将更趋多元。

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

  简化部署仅服务部分状态的RPC节点的流程；

  设计协议与工具，使钱包和应用能发现并整合多个局部数据源，而非依赖单一完整RPC端点。

4、未来方向

  以太坊的状态正悄然成为该协议未来若干核心问题的关键：

  状态规模增长到何种程度会成为参与壁垒？

  当验证者无需状态即可安全验证区块时，谁来存储状态？

  谁将向用户提供状态服务？其激励何在？

  部分问题尚无定论，但方向已明确：降低状态对性能的制约、减少存储成本、提升服务可及性。

  我们当前的重点是推进低风险、高回报的工作：

  归档方案

  我们正尝试协议外解决方案，在依赖归档方案存储历史数据的同时控制活跃状态规模。这将提供关于性能、用户体验和运维复杂性的真实数据。若验证有效，必要时可将其推进为协议内升级。

  部分无状态节点与RPC增强

  大多数用户和应用通过中心化的RPC服务商与以太坊交互。我们正在推进以下改进：

  降低运行节点的难度与成本，即使节点不存储全部状态；

  允许多个节点协同提供完整状态服务；

  增加RPC服务商的多样性，避免单点瓶颈。

  这些项目经过审慎选择，因其兼具即时实用性与前瞻兼容性：它们既能提升以太坊当前的健康度，也为未来更深入的协议升级奠定基础。