以太坊每个区块的 Gas 上限不是协议常量，而是每个出块者自己投出来的偏好值：验证者客户端里有一项 gas limit preference，出块时申报，全网实际值靠规则允许的每块微调慢慢爬。客户端发版会携带一个建议默认值，历史上每次大扩容都以某次发版为标志。这套机制的裂缝在于——生效时间跟着运营者的升级日程走，而不是跟着网络共识的时间点走。EIP-8261 提议把时间轴从日历挪回链上：让配置文件带一张按 epoch 生效的排期表。
排期表解决的是协调问题
提案把问题摆得很具体：假设客户端社区决定把默认上限从六千万大幅上调，希望未来某个 epoch 起全网统一过渡。用旧办法，两种做法都别扭。发版早于激活点，凡是勤快的运营者升级后立刻开始投新值，上限在协调时间点之前就开始上移——网络还没确认这个值安全，它已经在爬了。发版晚于激活点，则要求所有人精确在窗口后立刻升级，做不到的人拖住自己的出块，实际上限爬坡参差不齐。一次性命令行覆盖参数则是把协调成本外包给每个运营者的笔记软件。
排期表的形态很朴素：共识层 config.yaml 里加一个可选字段，每条目写明从哪个 epoch 起生效、值是多少。这个值同时扮演两个角色——运营者未做个性化配置时客户端采用的默认值，以及官方建议的上限。客户端在配置值超过当期排期值时应当警告，但仍尊重运营者的选择，因为建议不是规则。排期表在 Gloas 升级前被完全忽略，行为与现状一致。
它明确没做的事
第一，没有改任何共识规则：EIP-1559 留下的正负一千零二十四分之一的弹性规则仍是上限有效性的唯一约束，高于或低于排期值的区块依旧合法，排期表不能强制谁。第二，只活在共识层：Gloas 之后验证者的上限偏好经注册信息与构建者管道流转，执行层配置不再参与，这决定了字段的家。第三，不承诺扩容幅度，它只是让将来任何幅度都能平滑排期的管道。
提案 2026 年 5 月 11 日创建，按官方页标注当前为 Review 状态。历史上 Gas 上限之争从来不只是参数之争——更高上限意味着节点硬件门槛、验证延迟与重组风险的再平衡，社区为此消耗过大量共识成本。排期表把情绪从每次发版的临时博弈里抽出来，换成一份公开、可预审的时间表：谁提前动了，看日志一目了然。这类无聊的确定性，恰恰是大扩容最稀缺的公共品。
一场争论为什么总卡住
Gas上限在名义上属于参数治理而非硬分叉级别，但历史经验是每次抬升都像一次小型硬分叉：邮件列表长谈、客户端私下协调、反对方节点默默压着不投。排期表的吸引力在把决定与节奏拆开——要不要更大区块是长期的研究判断，何时爬到什么值是日历问题；过去两次都挤在发版窗口里同时吵。Gas上限同时牵动三个群体：用户想要拥挤时的费用缓和，节点运营想要同步与验证负载可控，出块者想要单块拍卖容量。任何一方在另一方未准备好时抢跑，都会把参数之争变成协作事故，这正是发版驱动模式的结构性缺陷，也是排期表这种无聊文档存在的意义。
快速问答
问：现在Gas上限多少、谁说了算？ 答：实际值由各出块者的偏好经弹性规则聚合，当前以链上数据为准；客户端默认值只是参考起点。
问：普通验证者需要改配置吗？ 答：不需要就不改，排期表生效后客户端自动按表出默认值；想跑更高或更低值仍可以，只是会被提示。
问：这等于协议自动扩容了吗？ 答：不是，规则依旧人治，变的只是节奏的透明度与协调方式。
风险提示：本文不构成投资建议；网络性能参数调整存在不确定性，请以客户端官方发布为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。