RPC 响应里那个 baseFee 字段之争：EIP-3041 与 3044 的四胞胎提案考古

一个字段名引发的四胞胎

2020 年 10 月 13 日到 14 日，Abdelhamid Bakhta 在两天内提交了编号 3041、3044、3045、3046 的四份提案，内容一句话就能说完：EIP-1559 把基础费写进了区块头，那就应该在 eth_getBlockByHash、eth_getBlockByNumber 这两个查块主接口，以及两个按高度与哈希查 uncle 块的接口响应里，各加一个叫 baseFee 的字段，让调用方直接读到。写法完全对齐 1474 定义的 RPC 术语表，前后各加一条规则：1559 分叉块之前的区块响应不得包含该字段，分叉块及之后必须包含。提案动机里说得很实用：基础费对准确估算 Gas 价很重要。四份提案的状态至今全是 Stagnant（停滞）。

字段最后从哪冒出来的

今天你实际调用这些 RPC 时，区块结果里有没有基础费？有——但名字不叫 baseFee，叫 baseFeePerGas，而且它不是这批提案的功劳：1559 生效后，各客户端按执行层接口的字段命名把区块头里的 base_fee_per_gas 直接以 baseFeePerGas 暴露进了 RPC 结果。主流 RPC 服务商的接口文档里，eth_getBlockByNumber 的返回对象清单写的就是 baseFeePerGas 这个驼峰名，你可以在任何公共端点上用一行 curl 亲眼确认。也就是说需求被满足了，只是绕开了提案指定的字段名，让 3041 到 3046 变成了”说对了事、起错了名”的标本。查区块的方法本身见 eth_getBlockByHash 怎么按哈希查区块？，那篇按现网字段口径讲怎么取区块；估算 Gas 价时用到的 eth_gasPrice 与 baseFee 的关系见 eth_gasPrice 怎么估算当前 Gas 价？。两篇合起来看你会发现：钱包估算器的输入链条就是区块基础费乘以用量上限，再加优先费。

为什么命名权之争也是标准之争

这批提案没有投票否决记录，它们的消失方式是典型的技术性搁置：RPC 字段名最终由客户端仓库与接口规范的合并节奏决定，而不是由 EIP 文本决定。1559 的规范文本里字段写作 base_fee_per_gas，接口清单落地时按驼峰惯例成了 baseFeePerGas，此时再让生态为 baseFee 这个别名改一遍解析器，纯属自找 breaking change。于是提案族保持 Stagnant，事实标准继续演化。这个案例值得所有以为”提案编号等于功能上线”的读者抄下来：编号记录意图，字段名记录实现，两者偶尔对不上。

用户视角：基础费到底影响你什么

普通用户在钱包高级设置里看到的 Gas 费构成，基础费部分就是从这个字段逐块推出来的：每块的基础费按上一块用量在目标线上下微调，用量热则涨、冷则降。你提交的那笔交易最终烧掉的基础费，等于成交区块的 baseFeePerGas 乘实际 Gas 用量，这部分被协议直接销毁；你多付的优先费才进出块者口袋。所以查历史账单时，正确的对账路径是：取交易回执的 gasUsed，乘所在区块的基础费加有效优先费，而不是拿提交时的报价回推。报价只是估，回执才是账。

一条规则倒是以另一种方式成立了

有趣的是，提案里那条分叉规则——分叉块之前的响应不得带该字段、之后必须带——今天倒是在现网事实上成立了：向任何兼容节点查询伦敦分叉前的旧区块，返回对象里没有 baseFeePerGas；查分叉后的区块，它必然在场。这个细节对做历史数据回填的工程师有实际意义：判断某块该不该有基础费，比较的是区块高度与伦敦分叉块号，而不是猜节点版本。提案赢了逻辑、输了命名权，大致就是这个画面。

读接口类提案的两条纪律

第一，接口提案要区分”内容正确”与”会被实现”：3041 一族的需求判断完全正确，字段命名却在实现的快车道之外，正确但不兼容就不落地。第二，家族式提交往往说明作者判断分叉在即，而 1559 当时确实处在实现冲刺期，这类抢跑提案的命运几乎完全取决于客户端团队先合并谁的字段名。风险提示：本文为提案与接口历史分析，不构成投资建议，Gas 参数请以你的节点与钱包当前实现为准。