智能合约的存储之所以贵，是因为写进去的每一格都要全节点长期背着。可现实里大量数据只值几天：拍卖中间状态、活动期标记、短期会话凭证。开发者目前的办法要么写进永久存储再自己清理（很多人忘了清），要么忍受只活一条交易的瞬态存储。EIP-8125 试图填上中间地带：一块能跨交易存活、到点被协议自动抹掉的临时存储。
三个层级的寿命
可以把 EVM 里的可写位置想成三条寿命线。第一条是瞬态存储（EIP-1153 的 TSTORE/TLOAD，已随坎昆升级激活），寿命等于当前这条交易，交易结束即消失，费用最低。第二条是常规存储（SSTORE/SLOAD），默认永久，是节点磁盘与状态维护负担的主要来源。EIP-8125 要加的是第三条：写入后跨交易、跨区块可读，但在协议定义的日程节点被整体清空。提案给出两个操作码：TMPSTORE(key, value) 写入、TMPLOAD(key) 读取，键空间按合约地址隔离。
清零是怎么发生的
提案不靠合约调用清理函数，而是由协议按固定日程做轮换。实现方式颇为取巧：临时存储映射到两个保留系统账户的常规存储槽上，派生槽键为 keccak256(contract_address || key)。轮换就是在这两个系统账户之间切换当前生效的那一个——新周期读写另一个账户，旧账户整片作废。这种两期轮换的好处是切换瞬间不需要执行清空海量槽的重活；代价是数据实际寿命取决于写入时机与轮换时点的相对关系，设计上应按它给出的窗口来规划，而不是假设能活到自定义的时刻。
为什么不能直接用瞬态存储
这是提案在 Rationale 里必须回答的第一个问题。瞬态存储跨不了交易，凡需要多条交易之间传递状态的场景都用不上：多步流程里第一步留下凭据、后续交易读取，只能落到常规存储。而这类数据在链上毫无长期价值——提案动机部分直言，很多槽位写入后链上再也不会被访问，永久存储为纯负担付费。临时存储提供的正是有界生命周期语义加可预测清空，同时给削减状态增长提供一个积木。
计费与风险
草稿的计费常数全部标着待定：热读、冷访问附加、从零写非零、改值四类成本尚未敲定，提案只声明会落在常规存储与瞬态存储之间，并对齐 EIP-2200 与 EIP-2929 的净变化计费框架。另一个必须评估的是可预测性风险：轮换日程写进协议后，任何依赖临时存储放关键状态的应用都会在轮换点集体丢状态。把它用作权限、余额或唯一凭据的载体是危险的；用作缓存、进度标记、短期凭证才是合理姿势。提案的安全考量正是围绕丢数据后果与轮换边界展开。
当前状态
截至本文写作时，EIP-8125 处于草稿状态（Draft），创建于 2026 年 1 月 14 日，声明依赖 EIP-2200 与 EIP-2929，操作码数值与轮换周期均未定，未关联任何已激活升级。
一次典型的用法
想象一个分三轮完成的链上拍卖：第一轮出价写入临时存储供后续交易验证身份与顺序，三轮结束后的第一次轮换把这些槽整体归零，没有任何清理调用散布在业务代码里。若换用常规存储，同样的流程要么留下永久垃圾，要么给合约主逻辑掺进一段与业务无关的清扫代码。两种写法的差异不在功能，在状态账本上留下的长期负担——这正是提案想改变的比较。
快速问答
问：写了 TMPSTORE 还要自己清理吗？ 答：不需要也做不到手动清零，协议到点整体轮换，这正是设计目的之一。 问：临时存储会被算进状态根吗？ 答：它由保留系统账户的实际存储承载，随承载账户进入状态承诺；细节以当期草案为准。 问：跟 EIP-1153 的瞬态存储冲突吗？ 答：不冲突，两者寿命不同、操作码不同，可以并存使用。
风险提示：本文为技术机制说明，不构成投资建议；依赖未定参数的实验功能用于生产存在数据丢失与资金损失风险。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。