昔日仅具实验性质的小型网络，如今已蜕变为全球数字基础设施的中流砥柱。以太坊每日结算价值高达数十亿美元，不仅协调着成千上万的应用程序运行，更构筑了繁荣的二层网络（L2）生态系统。
支撑这一庞大体系的基石，是一个常被忽视却至关重要的底层组件——状态（State）。
1、何为“状态”及其核心地位
用户的资产余额并非直接存储在钱包应用中，而是记录在以太坊的状态数据库中。简而言之，状态即代表了“以太坊当前所知晓的全部信息”，涵盖账户信息、合约存储（智能合约写入的所有数据）以及字节码（执行智能合约所需的逻辑代码）。
作为整个生态的根基，状态的作用无处不在：
钱包应用依赖它展示用户余额及历史交易记录；
去中心化应用（Dapps）通过查询状态来获取持仓情况、订单详情或消息传递；
各类基础设施服务（如区块浏览器、跨链桥接工具、索引器等）则持续读取状态，以此为基础构建上层服务。
一旦状态变得过于臃肿、过度集中或难以高效获取，上述所有层级都将面临脆弱性增加、运营成本上升以及去中心化程度下降的风险。
2、L1扩展背后的连锁反应
多年来，以太坊始终致力于提升网络吞吐量：从引入二层网络、实施EIP-4844升级、调整Gas上限与重定价策略，到内置提议者-构建者分离（PBS）机制。尽管每一步举措都增强了网络处理能力，但也随之引发了新的结构性挑战。
挑战一：状态数据的无限膨胀
以太坊的状态规模呈现出只增不减的趋势。每一个新账户的创建、存储操作的执行以及字节码的写入，都会永久性地增加网络需保存的数据总量。
这种增长带来了具体的系统性成本：
验证者与全节点需要存储海量数据。随着状态规模扩张，数据库负荷加重，处理效率逐渐降低。
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服务商的多样性，避免单点瓶颈。
这些项目经过审慎选择，因其兼具即时实用性与前瞻兼容性：它们既能提升以太坊当前的健康度，也为未来更深入的协议升级奠定基础。
以上就是以太坊（ETH）基金会：以太坊状态演进路径与未来挑战的详细内容，更多关于以太坊的挑战与演进的资料请关注其它相关文章！