现行规则先讲清楚
以太坊的区块 Gas 上限不是协议写死的常量，而是一种”投票结果”：每个出块的提议者可以在自己区块里报一个目标上限，规则限制每次最多比上一块移动极小的比例，整个网络的实际上限因此是所有提议者缓慢趋同的产物。这套机制的好处是去中心化——没有任何单一团队能拍板扩容；坏处也明显：缺乏协调，容易停在原地，或者涨得过于谨慎，谁也不想第一个把上限推高去承担风险。
EIP-7938 的提案内容
EIP-7938 由 Dankrad Feist 于 2025 年 4 月提出，思路是给”投票”这件事装一条默认时间表：客户端在不被用户手动覆盖的情况下，按指数曲线默认投更高的 Gas 上限，节奏大约每两年十倍，四年累计约一百倍后停止，届时再议下一版方案。换算到以太坊的时间单位，十倍大约对应十六万四千多个纪元。它不改变协议规则本身——Gas 上限的形成机制照旧，只是让默认行为从”保持现状”变成”沿曲线爬坡”，把协调成本从反复的社会博弈转成一份事先写好的公开计划。
为什么设计成指数而不是线性
提案的理由是跟上硬件与协议效率的预期进步速度：节点硬件、状态管理和客户端优化在过去多年里持续变快，线性时间表要么前期就太激进、要么后期浪费空间。指数曲线把不确定性摊开——每一段的增长幅度可预期，节点操作员能提前规划硬件，依赖容量定价的 Layer2 和协议也能更准地估成本。四年封顶则是止损阀：如果四年内现实没有按预期兑现，社区必须重新坐下来决定，而不是让一条过时代码继续自动跑下去。
它的状态与争议
截至本文核验时，EIP-7938 的状态是 Stagnant（搁置），类型被标为信息类，从未进入任何主网升级清单。围绕它的主要疑问包括：把扩容节奏交给默认参数是否削弱了”逐段同意”的安全性；万一某个阶段硬件普及不均，会不会反而放大节点压力；以及”不投票”能否被真正理解为同意。这些问题都还没有答案，也因此这篇提案更像一份扩容路线的辩论素材，而不是一份待执行计划。
怎么看待这类提案
读扩容提案时，先分清三层：协议规则层（Gas 上限怎么算出来的）、客户端默认层（软件默认投什么票）、社会共识层（社区是否接受这个节奏）。EIP-7938 只动第二层。看到”Gas 上限翻倍”之类的标题时，先确认它动的是哪一层、状态是定稿还是设想，再谈影响。
一个观察实验的视角
即使不采纳这份提案，它也像一个设计好的对照实验：把”协调失灵”这个长期归因于人性的问题，替换成一条机器规则，看看系统会发生什么。反对者担心的是把纠错权从人手里拿走，支持者担心的恰恰相反——历史一再证明，没有默认值的公共池会缓慢干涸。无论你站哪边，这条时间表都提供了一个罕见的机会：给扩容节奏一个可以被证伪的公开假设，两年一段，行就继续，不行就停在讨论桌前。
快速问答
问：提案如果实现，我需要换硬件吗？ 答：提案的设想是增长与硬件普及同步，且你始终可以手动关闭默认上调；但它未进入主网，这类推演只是机制讨论。
问：它和区块大小、Blob 数量是一回事吗？ 答：不是。Gas 上限衡量执行计算容量，Blob 衡量数据容量，区块字节上限又是另一条线，三者由不同参数与提案管辖。
风险提示
本文为协议机制科普，不构成投资建议。Gas 容量与费用生态的讨论不预示任何资产价格走势；提案状态随时变化，请以官方文档为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。