以太坊把区块塞得更满的路线图上，有一块绕不开的绊脚石：运算类操作的 Gas 定价是否低估了它们的真实耗时？逻辑很直白——如果执行一批 SHA3 或模幂的实际时间远超其 Gas 预算隐含的配额，那么提高区块 Gas 上限就会把节点验证拖垮，出块开始掉队。围绕这个问题曾经有一批“给运算涨价”的提案。EIP-7904 是这个故事的反转版本：实测之后，它宣布一条都不用涨。
从涨价提案到信息文件
这份 EIP 创建于 2025 年 2 月 5 日，早期版本是正儿八经的 Standards Track，目标就是抬高一组运算操作与预编译的 Gas 价，把当时测得的性能短板拔掉，为好提高区块 Gas 上限铺路。后来事情起了变化：客户端侧因 EIP-7928（块级访问列表）解锁了一批优化——磁盘读并行、交易验证并行、无状态更新的执行旁路——在全面启用这些优化的主流客户端上重跑同一套基准与估算管线，那些原本“低于及格线”的操作全部轻松越过目标。提案于是把身份改成 Informational：不动价目表，只留方法与数据，给未来任何重新定价工作做参照。
及格线怎么定
方法论的核心是一个吞吐目标：每秒 1 亿 Gas（100 Mgas/s）。含义是，在验证者机器上，被计为 1 Gas 的操作平均应在千万分之一秒内完成；按当前价目换算成“每秒能跑多少单位该操作”，凡是实测低于这条线的，就是定价偏低、会先成为瓶颈。测试覆盖主流执行客户端的多个实现与版本组合，覆盖从加法、哈希到各类预编译。结论被原文写得干脆：所有被测运算与预编译在现行定价下均达到或高于目标吞吐，因此不需要任何涨价。这个结果本身也回答了提上限争论里的一类担忧——瓶颈至少不在运算单价上，而要去别处找（内存、状态访问、带宽等等）。
为什么值得单独科普
它示范了一种对协议讨论很有价值的姿势：把“我觉得某操作太便宜/太贵”的直觉之争，换算成可复现实验与统一口径的吞吐数。数据有保质期——客户端在演进、硬件在换代、价目表本身也可能变——所以这类信息文件的正确用法是当作方法与基线的存档，引用它之前先确认你的场景与当时的客户端版本。EIP-7904 目前是 Review 状态的 Informational 文档，不改变共识，也不改变任何 Gas 常数。
及格线之外还差什么
吞吐目标只回答“单位 Gas 是否被低估”。把区块上限抬上去还有另外几道题：状态读写带宽（磁盘随状态膨胀变慢）、区块传播时延（更大的块在 gossip 网络里更容易产生孤块）、以及验证者机房的摩尔定律红利是否还在分发。7904 的作用范围是其中一道题的实验报告，不是全部答案。另外值得注意它的方法学细节：测试要求被评估的客户端启用块级访问列表的并行管线——也就是说，结论与“优化全面铺开”这个前提绑定，把实验环境换回旧管线再引用结论，是这类文档最常被犯的引用错误。
快速问答
问：这是否意味着以太坊可以放心提块 Gas 上限？ 答：只说明运算单价不是当前短板；上限决策还要看状态、带宽、传播等其余约束的实测。
问：预编译涨没涨？ 答：按本文写作的提案状态，没有——提案明确不推荐任何价目变化。
问：100 Mgas/s 的依据是什么？ 答：它是验证者维持稳定出块所需吞吐的折算目标，对应现行区块规模与出块节奏的组合。
风险提示：本文仅转述技术文档的方法与结论，不构成投资建议；Gas 与费用相关决策以实时链上数据为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。