区块 Gas 上限由谁决定？提议者投票、客户端默认值与百分之一千零二十四的弹性

区块容量不是升级才能动的参数

以太坊每个区块最多能消耗多少 Gas，写在区块头的 gasLimit 字段里。很多读者以为这个数要等硬分叉才能改，其实不然：合并之后，每一轮的提议者都可以为自己出的是那个块声明一个新上限，规则只有一条——相对上一个区块的变动不能超过约百分之一千零二十四的比例。这就是 EIP-1559 一并引入的弹性规则：上限像一根只能小步挪动的柱子，每块最多挪一点，靠无数个区块接力爬升或回落。

理解这条规则，才能看懂”gas limit 投票”这个说法。节点运营者在自己客户端里配置一个期望值，提议者出块时把自己的期望值写进区块头；全网按规则接受缓慢漂移，谁也不能一步到位。EIP-8261 的动机部分对现状的描述很直白：当前区块 gas 上限由每个提议者设定，受验证者客户端偏好、客户端默认配置与 builder 竞价驱动，再由 EIP-1559 的弹性规则逐块移动 realized 上限。

谁在推这根柱子

实际操作层面有三层力量。第一层是客户端默认值：每个新版本发布时，客户端团队会更新建议的默认 gas limit，用户升级节点时上限就跟着换一档。EIP-8261 批评的正是这一点——默认值跟着软件发布走，而不是跟着网络协调的纪元走，“运维者何时升级节点”这种随机事件能移动全网参数。第二层是大运营者的手动覆盖：交易所、质押池、机构节点会在配置里写自己的偏好值。第三层是 builder：在 MEV-Boost 与 PBS 流程里，builder 会声明一个贴近提议者偏好的 gas_limit 参与竞价，EIP-8261 把这列为现状机制的一部分。

这套设计的代价是”没有协议级安全网”：一次协调好的客户端默认值变更或一阵配置风潮，可以在几天里把上限推动数百万 Gas。这也是 2025 年出现 EIP-7938（指数式扩容时间表）和 EIP-7935（把默认上限调整绑进 Pectra 升级时点）这类提案的背景：前者设想让客户端默认值按固定指数曲线自动上投票（注意它至今是草案状态，官网标注为 Stagnant 的 Informational 文档，从未按原样激活）；后者则示范了”把一个协调好的默认值绑在已知纪元生效”是可行的。2026 年出现的 EIP-8261 进一步建议把上限改成硬分叉排程固定的参数，同样还是草案。截至这些文档各自发布时点，主流路径仍是”默认值加弹性规则”，进展以官方仓库为准。

用户会看到什么

上限上调不等于你付的钱变少，但通常改变拥挤程度：同样的需求摊到更宽的块里，基础费的波动会更平缓；上限下调或停滞时，需求高峰更容易顶满目标值，EIP-1559 的调节公式就会推高基础费。判断当下状态有现成字段：任意区块浏览器或 eth_getBlockByNumber 都能读到当前 gasLimit 与本块 gasUsed，两者之比就是”装满度”；eth_feeHistory 则能看一段窗口里装满度与基础费的联动。如果连续很多块都贴近目标值的一半上下，说明上限当前不是瓶颈；如果长期顶到上限，基础费的单边上涨就有了机制解释。

还有一个容易漏看的机制细节：目标值等于上限的一半。也就是说，网络真正在调节的都是”相对目标”的偏差——装满度高于目标基础费上涨，低于目标下降，上限本身只划定单块天花板与目标线的距离。而上限自身的每块变动空间约为其一千零二十四分之一，上限越大，每块允许移动的绝对量也越大。这解释了为什么弹性规则既能防止单人瞬间拔高容量，也让追赶式扩容在早期显得偏慢。

常见误区

第一个误区是把”gas limit”与”每笔交易的手续费上限”混为一谈：前者是区块容量参数，后者是 EIP-1559 交易里的 maxFeePerGas，两码事。第二个误区是把某个时点的数值当永久事实：上限随提议者漂移，也随升级与配置变动，引用时要看查询时间。第三个误区是认为提案通过等于生效：EIP 的状态从草案到激活隔着实现、测试网、激励网与主网四道门，本文提到的几个提案在各自文档发布时点都未在主网按提案原文激活。本文只做机制说明，不构成任何投资建议。