冷热价差的来历
自 2021 年 8 月的伦敦升级起，以太坊对状态访问实行两套价：一笔交易里第一次碰某个存储槽或账户要付昂贵的冷访问费（例如冷 SLOAD 两千多 Gas），同一笔交易里再碰它就只付便宜的热访问费（一百 Gas）。这套”冷写热读”设计的初衷是让每条交易自己内化它给节点带来的磁盘压力。关键细节是：这个热状态在每笔交易结束后就被清掉，下一笔交易哪怕访问的是同一批槽，也要重新付一次冷费。
重复缴费的浪费
现实里很多区块反复触碰同一批热点：热门借贷协议的利率槽、高频兑换对的储备槽、系统合约的配置槽。十笔交易碰同一个存储槽，今天的规则要收一次冷费加九次热费——而节点其实只需要从磁盘读它一次。EIP-7557 在 2023 年 10 月提出：把”首次加载”的成本上移一层，由整个区块支付一次，块内所有交易从第一下访问起就享受热价；同时把省下来的钱按公平规则摊回去，保证区块总收费与成本对齐，而不是白送折扣。
省下的 Gas 归谁
这是提案最微妙的一点。如果冷费直接改热价，差额等于凭空送给交易发送者，区块收入下降。EIP-7557 的”公平摊回”思路是把区块级的首次加载成本折算进各交易的计费里：你的交易受益于预热，但也按你对热点的占用分摊那份公共成本。结果是总 Gas 基本守恒，分配更贴近真实成本结构——付费从”按交易条数重复罚”变成”按实际磁盘读取分摊”。对开发者的直观感受是：同一块里挤在同一批热槽上的交易，单笔成本更低，打包它们对提议者也更有利。
为什么搁置
截至本文核验，EIP-7557 状态是 Stagnant（搁置）。反对与顾虑集中在几处：区块级状态跟踪会加长执行的关键路径，节点要在执行前或执行中维护跨交易的热集；攻击者可能操纵”谁先付款预热”的摊回规则，把成本转嫁给无辜交易；还有与后续无状态路线的兼容问题——如果未来的见证（witness）模型改了计费基础，这套修补可能白做。它没有被否决，只是排不进优先级。
一个算术直觉
假设某个热点槽冷费两千六、热费一百。今天十笔交易碰它：总计两千六百加九百，约三千五百。区块级预热后：区块付一次两千六，交易十笔各付一百——同样的三千五百左右，但每笔交易的起点更低，折扣先给了用户、成本再由摊回规则补回。省的不是钱，是重复劳动。
开发者现在能做什么
在提案落地前，同样的效果可以在应用层部分模拟：把高频读写合并进同一笔交易，让这笔交易内的多次访问只付一次冷费；或者用存储设计把热点数据集中到少数槽位，提高块内的偶然复用。这些都只是绕行手段，比机制层摊平粗糙得多。也正因存在这些替代路径，7557 的预期收益被评估为”锦上添花”而非”雪中送炭”，这多少解释了它为什么在优先级表上位置靠后。
快速问答
问：这和 EIP-2929 是什么关系？ 答：2929 定义了冷热两套价与交易内热集，7557 是把热集的边界从”一笔交易”扩到”一个区块”，属于同一计费框架的延续修改。
问：Gas 会更便宜吗？ 答：不必然。提案目标是让收费对齐成本而非降价，单笔更便宜与公共摊回会相互抵消。
风险提示
本文为协议机制科普，不构成投资建议。Gas 计费调整会影响费用结构，但无法据此推断资产价格；提案状态请以官方文档为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。