以太坊的世界状态是一本巨大的账：每个账户有条目，每个存储槽有值。但账本本身从不记录一个朴素的问题——这一行最后一次被改动是什么时候。EIP-8188 在 2026 年 3 月提出一个直白的补法：给账户和存储槽的编码各加一个字段，记录最后一次写入发生在哪个区块。提案明确不动任何 Gas 价格，也不要求客户端立即据此做决策——它只是把原材料放进共识层。
为什么读不算写入
字段叫 last_written_block，只在写时更新：SSTORE 改一个槽、转账改余额，都会顺手把它刷新成当前区块号；而 SLOAD、BALANCE 这类读取一个字都不动。这个不对称是刻意的。如果把读也记进来，字段就退化成了”最近访问时间”：一个被脚本每月巡检一次的死账户会永远显得活跃，年龄信息反而失真。只记写，字段回答的才是真问题——这段状态上次真正改变世界是什么时候。它也天然免维护：不需要后台扫描进程，共识规则本身就在持续喂它数据，这是”翻区块历史”或”客户端各自统计”两条替代路线都做不到的跨客户端一致性。
为什么不回头翻历史
另一种思路是用的时候再查：翻区块历史，找这段状态最后一次被改的高度。这条路技术上走得通但代价不对——每次读状态可能多一段历史回溯，而历史正是各条链都想瘦身存放的东西（以太坊这边，EIP-4444 描述的历史过期路线就主张节点可以不保留全部远古区块）。把写入区块号直接塞进状态条目，等于给每一行自带更新页码，查询从”翻档案”变成”看页脚”。代价是每段状态多存一个数字：对动辄上亿条目的状态库，这是实打实的体积，提案也因此专门讨论了元数据对状态大小的影响。
与状态经济学咬合
提案文本用”按写入年龄给状态分层”（state tiering by write age）概括意图。状态年龄最被期待的去处是费用与清理政策：给新状态收更高的创建成本（EIP-8037 的路线，也是 8188 在提案头注里引用的前置）解决”增量”，年龄数据解决”存量”：沉睡上百万个区块的槽值若长期白占节点磁盘，政策设计者第一次有了共识层背书的筛选依据——哪些值得迁移、哪些可进过期流程、哪些该收占用费。也可以反着用：冷账户判定、空投快照的”你还在不在”核对、审计里”这个字段多久没人碰过”的举证。草案本身一条计费规则都不动。
一条判断线
把 8188 放进近几年的状态主题里看：EIP-8037 想给「写入新状态」收高价，管的是增量；历史过期与状态过期路线管的是数据能不能少存；本提案管的是存量状态「活了多久」的计量。三条路线各拿一把尺，8188 是唯一一把不带政策的尺——它只把每段状态的出生戳换成更新戳。判断它对谁最实在，也有一条简单线：越是依赖「全节点磁盘会无限胖」焦虑的政策，越需要先有年龄数据才谈得上执行；越是只想优化单笔交易开销的人，越可以忽略它的存在，因为它不动 Gas。对普通用户，这条线翻译成一句话：激活与否都不改变你链上资产的状态，改变的只是全网未来清理档案时手里有没有账。
快速问答
问：这会让每笔交易变贵吗？ 答：写入时多编码一个数字，单笔开销是字节量级；主要成本在状态体积而不是 Gas，提案明言无 Gas 变更。
问：读频繁但从不写的状态会被判成死的吗？ 答：按字段语义是的——定义就是”没人改它”。是否因此处置它是上层政策的判断，不是协议的决定。
问：节点要为此多做什么吗？ 答：若激活，客户端在写路径顺手维护字段；从创世重放建库的软件可以完整重建各条目年龄。
风险提示：本文介绍尚未激活的协议草案，不构成任何投资建议；编码与参数细节请以当期提案文本为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。