部署后自毁这条旧路
有些合约只活一笔交易：状态通道的双方结算逻辑、一次性的执行沙盒、通过 DELEGATECALL 借用的可复用模板。旧剧本是 CREATE 部署、用完 SELFDESTRUCT 拆掉。这条路近年越来越贵也越走越窄——EIP-3529 起自毁不再给 gas 退款；坎昆之后，自毁只能拆掉同一笔交易内创建的合约；而且销毁语义预计还会继续收紧。换句话说，“先占状态再还状态”的模式既拿不到补贴，长期行为也无法依赖。EIP-8360（2026年8月起草，Draft 状态）提出把这种需求扶正：一个名字叫 TCREATE 的操作码，T 代表 transient，临时。
计费结构拆开看
参数表里有几行关键数字。基础操作码费 100 gas，与常规创建同档；真正定价在状态层——每个新账户折算 120 个状态字节，按 EIP-8037 的每状态字节 1530 gas 计费。对比之下，普通 CREATE 要为代码字节、存储初始化等一揽子状态增量付费，而临时账户不进代码库、不留账户对象到交易结束，费用账单天然短。交易结束即消失的语义，让节点可以把这类账户放在交易级的工作集里处理，而不是写进要永久同步的磁盘状态——省钱和减轻节点负担是同一枚硬币的两面。
语义细节
TCREATE 的行为大体镜像 CREATE：地址派生需要处理临时账户特有的”临时随机数”语义——同一笔交易内多次调用 TCREATE 必须得到不同地址，防止自我覆盖。存储读写按瞬态存储的方式记账：SSTORE 写进交易级结构，SLOAD 在账户存续期内正常回读，交易一结束整体蒸发。账户抽象兼容性是提案强调的点：现有账户语义不动，智能账户可以在 calldata 里塞一段逻辑、临时部署再 DELEGATECALL 执行，用完即走，不留常驻代码。
快速问答
问：临时合约里存的资产去哪了？ 答：提案把余额转移的状态 gas 记账单独列出——临时账户不应成为余额黑洞，涉及转账时的处理规则在 gas 章节内有明确条款，读提案时这段不能跳。
问：和瞬态存储（EIP-1153 的 TSTORE）什么关系？ 答：两者同属”只活一笔交易”的思路，对象不同：TSTORE 是已有账户里的临时格子，TCREATE 是临时账户本身。组合使用可以拼出完整的单交易执行环境。
一条算术直觉
给”不留痕迹”标个价最有助于比较：TCREATE 走的是 120 状态字节乘以 1530 每字节的账，约等于十七万八千 gas 的固定门槛，外加 100 的操作码费；老剧本里部署一段几百字节代码再加自毁的运行费，通常显著高于这个数，还附赠状态膨胀的社会成本。当然真实比较取决于代码大小与参数最终值——参数表中 CPSB 若被 EIP-8037 系列的再校准提案调整，这道门槛会同步浮动。
为什么值得为’消失’设计指令
协议为”会消失的东西”立专项，是一个值得玩味的信号：状态治理从收费罚站升级到结构分流。节点运维角度的收益最直接——永久状态只增不减是数据库的顽疾，交易结束即蒸发的对象不进状态树、不进快照、不参与同步，等于把一类本会永久沉积的字节挡在门外。读者可以把这条思路推广到所有状态提案：先问对象的寿命被写进协议没有，再问价格——生命周期有明确终点的数据，才谈得上低成本；价格再低的永久对象仍是永久债。这也是它与瞬态存储、存储租金等提案被反复放在一起讨论的原因：三者在回答同一个问题——以太坊想让什么留在状态里。
一笔对照实验
给读者一个可自行推演的思想实验：同一逻辑分别用老剧本（部署加自毁）与新指令各写一遍，在参数当前值下比较三栏账单——部署费、运行费、留给节点的状态量。前两栏的差值随代码体积线性拉大，第三栏老剧本在重组与快照里都留下过痕迹，新指令一概不落盘。参数若被相邻提案再校准，三栏会整体缩放但结构不变。这类”结构省钱优于折扣省钱”的提案，历来是 EVM 演进里争议最小的一类：它不重新分配利益，只是承认一部分状态本不该存在。
风险提示：本文为协议提案的科普介绍，EIP-8360 截至撰写时未在主网激活，参数依赖的 EIP-8037 定价亦在演进中；本文不构成投资建议或合约开发指导。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。