以太坊每个区块能消耗多少 Gas，是由验证者通过客户端参数投票、按每块最多千分之一点零九七的节奏缓慢调整的，没有任何协议条文给它设过顶。EIP-3756 想做一件相反的事：从某个分叉块起，凡 gas_limit 高于三千万的区块一律视为无效。这个数字并不是随便挑的——提案起草的 2021 年 8 月，主网 Gas 上限正好在三千万附近运行，等于把当时的现状凝固成上限。
上限不是越大越好
直觉上 Gas 上限越高，能塞进区块的交易越多，网络越”强”。但每个全节点都要为一块Gas重新执行和验证全部计算，上限抬高意味着状态增长更快、历史数据膨胀更猛，这些成本由所有诚实节点平摊。EIP-3756 把后果分成两类：良性情况下，高上限让状态与历史的增长速度超过社区可持续维护的水平；恶意情况下，某些拒绝服务攻击的破坏力会被上限直接放大——攻击者能用一个区块的预算制造远超平时的负载，让慢机器掉队、让同步流量暴涨。上限越高，这种单块重锤越有得打。
谁在决定现在的上限
提案的动因里有一句很关键的话：Gas 上限目前掌握在出块者手里，他们可以把数字拉到任意值，这就绕开了 EIP 流程与核心开发者会议对协议的集体决策。换句话说，抬高上限在技术上只是一次参数投票，在后果上却等价于一场没有经过评审的隐性升级。给上限设协议级天花板，等于把”扩张”这种不可逆的选择框进制度里，把”收缩”这种可逆的选择留给现场应急。
为什么只封上不封下
作者明确不主张固定上限：如果网络不稳定或正在被攻击，验证者需要立刻把 Gas 上限降下来止血。因此设计的形状是单向阀——向下永远自由，向上最多顶到三千万。这个不对称背后是一个普遍的工程判断：让能力可缩比让扩张有度更难事后补救，所以规则只锁死难以收回的那一半。
现状与边界
提案状态停留在 Stagnant（停滞），以 EIP 官网当前标签为准。它后来提供的参照价值大于落地价值：此后每一轮 Gas 上限上调的讨论里，“要不要一道协议上限”都被拿出来反复权衡。同类思路后来还演进出排期表版本，把上限何时升高写进配置的日历，思路同源：都是用规则约束参数，而不是每次临时投票。
快速问答
问：Gas 上限和交易里填的 gas limit 是一个东西吗？ 答：不是。区块的 gas limit 是全链参数，决定一个区块装多少计算；单笔交易里填的是这一笔愿意消耗的上限，两者相差好几个数量级。 问：顶到天花板的链会不会永远卡死在三千万？ 答：按提案文本，天花板只封上涨；若未来社区决定更高，需要再走一次修改协议的流程，这本身正是设计目的——抬高门槛，不是禁止抬升。 问：验证者不投票配合怎么办？ 答：现行机制下投票本来就允许离散，参数向多数靠拢；天花板生效后再高的票也无法让区块合法，规则从引导变成硬校验。
一笔直觉账
现行规则允许每个区块把上限朝目标方向挪约千分之一，从三千万抬到三千三百万，即便验证者全部顶格投票也要积累数千个区块、折合好几天，遑论现实里投票方向并不一致。也就是说”缓慢”本身就是现行机制的护栏；EIP-3756 担心的不是慢爬升，而是慢爬升的天花板不存在——客户端默认值一届一届悄悄上调，多年之后回看，安全性已经被一连串没人专门投票的参数决定悄悄改写了。
一条判断线
看任何”性能参数”的争论，先问它动的是可逆的一半还是不可逆的一半。调低随时能调、调高要重开共识，这类不对称决定了规则该往哪边焊死。
风险提示：本文仅为协议机制科普，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。