状态过期是什么？不活跃账户怎么休眠又怎么唤醒

结论先说

状态过期（State Expiry）处理的是以太坊一个越来越沉的包袱：只要一个账户被写过一次，全世界每个全节点就永远替它记账。思路是让”很久没被碰过的状态”从活跃数据库里降温挪走——不是删除，而是搬到冷层，节点平时不必携带，需要时凭出生证明（见证加复活元数据）把它唤醒（背景见状态膨胀（state bloat）是什么？为什么节点越来越重）。它和常被混谈的历史过期是两回事：历史过期丢弃的是旧区块流水（EIP-4444 路线，见EIP-4444 历史过期是什么？节点为什么可以不存全部历史），状态过期处理的是仍会影响执行的账户数据。以太坊官方路线图中讲无状态与状态过期的页面（页面自注更新于 2026 年 6 月 30 日）把状态过期标注为研究阶段、尚未准备好上船——它是路线图里最诱人也最远的项目之一；该页面之外，本文不对状态过期在那之后的进展做任何推断。

包袱有多重

以太坊状态就是所有账户余额、合约代码与存储槽的最新快照，每个全节点必须完整保存，因为任何一笔交易都可能触碰任何地址。账户只增不减：钱包批量空投、协议部署废弃合约、游戏链上存档，写一次就永久增加所有节点的负担。这个负担的后果不是存储数字难看，而是节点门槛抬升、中心化验证压力增大——愿意跑全节点的人越少，链的可核验性越薄（节点分工见全节点、归档节点和轻客户端有何区别？）。状态过期的哲学转变在于：把”节点永远记得一切”改成”节点只记得最近活跃的，冷掉的可以被任何持有见证的人唤醒”。

状态过期是什么？不活跃账户怎么休眠又怎么唤醒机制示意

两种过期模型

研究讨论聚焦两条路线。按租金过期：给账户挂一份持续计费，租金付到零就休眠——问题是”向谁收、怎么收”在以太坊账户模型里极难设计，EOA 不能被迫付款。按时间过期：一段时间（例如约一年）无任何读写即休眠——不向用户收钱，代价是需要一套复活机制。两条路线共享的关键结构是分时代的状态树：每开一个纪元种一棵新的活跃树，只有当前树可写，旧树封存不可变；节点只需携带当前树与最近一棵旧树，更早的状态整体沉入冷层。休眠状态被再次访问时必须”复活”，而复活可能引发地址冲突——一个休眠多年的旧地址与新生成的同名地址相撞怎么办，这正是复活冲突最小化研究的核心题。一个著名的配套议题是把地址从 20 字节加长到 32 字节，给时代编号留位——官方路线图文档仅把地址空间扩展列为配套研究议题，未记载任何已进入升级流程的对应 EIP。

唤醒一个沉睡账户

用户视角想象这笔操作：你要动用十年前注册的域名合约，合约对应的状态早已休眠。交易不再只带 calldata，还要附一份”复活包”：账户在封存树里的路径证明、所属时代编号、以及证明该状态确实是那个时代合法终值的元数据。执行层验证复活包、把状态搬回当前树、再正常执行。麻烦在中间态：如果复活与执行塞进同一笔交易，成本陡增；拆成两步，则引入”复活已提交但还没法用”的时间窗。谁替你保管这些复活包？答案不会是每个用户自己——这催生了一个新角色：状态托管服务商，与归档节点一起构成冷层生态（归档职能见数据归档是什么？节点为什么还要存历史数据）。

和历史过期、无状态怎么分

三个词一张表说清：历史过期=旧区块数据可以不存（对应 EIP-4444 路线，官方文档记载其讨论活跃但尚未准备好上线）；状态过期=冷账户状态降温（研究阶段）；无状态=验证不再需要本地状态库、靠区块附带见证（弱无状态在高级研究阶段，官方文档口径是离主网还有几年）。三者的分工不是替代而是接力，官方文档明确提醒：如果状态过期先行落地，历史过期未必还需要——路线图项目之间存在这种互相吃掉需求的开放局面（升级排期方法见公链升级怎么排期？从 devnet、测试网到预定激活）。