收款人地址为什么要预先加热：EIP-3651 与 Warm COINBASE

每笔交易里那个不起眼的收款人

以太坊交易里有一个字段常被普通用户忽略：这笔交易的优先费最终付给谁。执行层客户端把它读进 EVM 世界时用一个名为 COINBASE 的操作码（编码 0x41）暴露它的地址。合并之前这个位置指矿工，合并之后它指提案验证者设定的费用接收地址，日常语境里常叫费用受益人。地址随区块来，每块可能不同。

EIP-2929 给状态访问定了冷热两档价：交易生命周期里第一次碰某个账户或某个存储槽算冷访问，收费高（账户冷访问收 2600 gas、热访问 100 gas，冷存储读 2100 gas）；之后都算热访问，便宜得多。规则假设了“哪些地址会被碰”：发起方账户和交易目标地址在验证阶段本来就要加载，所以开局即热。可 COINBASE 地址偏偏不在名单里——它每个区块都在变，预加载它需要多一次状态查找。

定价错配引发的路线扭曲

这个遗漏在很长一段时间无人在意，因为普通用户不会主动给矿工地址转账。改变来自一类新玩法：把 ETH 直接转给 COINBASE 地址，作为“条件支付”的实现手段——整笔交易一旦回滚，这笔转账连同其他状态一起消失，相当于自动取消。它比先调合约再付款更便宜、更原子。

问题在于：转账给一个冷账户，要按冷访问价付费。同样金额的 ETH 直转，目的地换成 COINBASE 就比转给朋友贵出明显一截。做市与打包服务很快发现这条价格洼地的反向版本——绕开 ETH 直转，改用 ERC-20 代币结算，因为代币合约的存储槽可能已经预热。协议本意让 ETH 转账处于最平价的通道，定价细节却让条件支付场景下 ETH 反而不划算。

规则本身很薄

EIP-3651 的规范只有一句话：交易执行开始时，已访问地址集合初始化时就把 COINBASE 操作码返回的地址一并加入。理由也很直白：发起方地址因为要核对余额是否够付 gas 上限，目标地址因为要开始执行，两者无论如何都要从状态里加载；COINBASE 地址作为费用结算对象，同样处在验证必经之路上，提前预热与真实成本相符。

这条规则随 2023 年 4 月 12 日的 Shapella 升级（执行层名 Shanghai）在主网激活。它不改任何资金流向，只把一次必然发生的查找提前到交易开始，抹平冷热差价。

它为什么值得单独成题

看协议演进，EIP-3651 是个微型样本：先有 EIP-2929 建立冷热框架，框架的预加载清单按“验证必经”原则圈定地址；随后应用场景长出新用法（COINBASE 直转的条件支付），暴露清单的缺口；最后一条补丁提案把缺口对齐到原则本身。没有新增字段、没有新增操作码，改动全部落在访问集合的初始化步骤。评估此类“对齐型”升级时，重点看它有没有引入新的不可预测状态——3651 的答案是没有：预加载的对象（区块收款人地址）在交易执行前就已确定。

一个直觉算术

冷账户访问与热账户访问的差价在 2600 与 100 之间：同一笔转账，目的地是冷是热，相差两千五百 gas，按 2023 年春季的 gas 价折算就是一笔可观的常设折扣被抹平。3651 之后，给费用受益人地址直转 ETH 与给朋友转账在同一费率平面上，“条件支付”路线的定价歧视就此消失。

快速问答

问：这个 COINBASE 和比特币区块第一笔交易同名，是一回事吗？ 答：不是。以太坊语境里 COINBASE 指区块的费用受益人地址；比特币的 coinbase 交易是出块奖励的那笔交易，两者只在挖矿时代语义上有过远亲关系。

问：直转 ETH 给出块者地址现在划算吗？ 答：从 gas 角度，冷访问溢价已取消；但条件支付能否成立还取决于执行结果是否回滚，实际使用前应逐场景验证，并注意接收方地址在交易执行前必须已知。

风险提示

本文只解释协议定价机制，不构成任何支付路线或交易构造建议。实际 gas 行为以链上执行与当期客户端文档为准。