一笔交易里最不可靠的参考系
以太坊合约里有个历史包袱：tx.origin 返回发起整笔交易的外部账户，而 msg.sender 只是直接调用者。钓鱼脚本正是利用这个差值——骗用户签一笔调用，脚本合约再代替用户调用他的钱包合约，此时 msg.sender 是脚本、tx.origin 却是用户本人。早年代付与元交易时代的合约常用「tx.origin 必须等于 msg.sender」来检测自己是否被直接调用，因为那意味着合约输入就是用户亲手签的交易参数，没被中间人改包。账户抽象兴起后，这条路越来越窄：聚合器、批处理、EOA 委托都会让直接调用检测误伤正常用户。EIP-7664 在 2024 年 3 月 27 日由 protolambda 提出，想彻底换掉这个参考系。按仓库原文，它已撤回，撤回理由原文只有一句话：小众场景，用 EIP-7702 实现更好。
把访问列表从省钱开关变成承诺书
访问列表是 EIP-2930 加入的交易字段，允许发交易的人提前声明「这交易会碰哪些账户和存储键」，碰之前预热，冷访问费就不用付，机制细节见 区块怎么汇总访问列表：EIP-2930 访问列表与区块级的 EIP-3584。问题是它历来只影响 Gas 数字，执行中的合约完全看不见它。EIP-7664 的改动只有一条指令：ACCESS_KEY（0x4B），从栈上弹出一个下标 index，返回交易访问列表里为当前执行地址声明的第 index 个存储键；地址不在列表或下标越界就返回全零的 bytes32。固定收费 3 Gas，访问列表本身的固有费用不变。提案把这称作「合约输入的静态声明」：合约可以在执行前逐位核对关键参数有没有被原样写进交易结构——这件事对区块构建器和验证节点同样可见，不依赖任何 EVM 内省。作者还类比了瞬态存储 TLOAD 的全局只读语义，并强调访问列表键一旦定下，整笔交易执行期间绝不会变。
0x4B 这个位置的三方竞争
槽位故事是这篇提案最容易看错的地方。0x4B 并不是无主之地：EIP-3322 早把该位置命名给 STOREGAS（把 Gas 存进账户余额的设想，见 Gas 能存进合约账户里吗：EIP-3322 的三个操作码和退款上限之墙），EIP-7843 又把它给了 SLOTNUM（让合约读出当前时段编号，见 合约怎么知道现在是第几个时段：EIP-7843 的 SLOTNUM 操作码）。三份提案都没激活，谁也不压谁，但任何一份先落地都会逼后来者换门牌。这正是本栏目反复讲的「操作码占号排队」现象：编号只是登记意图，不是承诺资源。看到资料里出现 0x4B，先确认语境属于哪条提案，和 0xea 上 EOF 与历史提案的纠葛是同一个套路。
「7702 实现更好」到底好在哪
撤回理由需要翻译。访问列表声明是发交易时一次性写死、随交易签名冻结的，而 7702 的授权列表同样是签名过的结构：用户签一个 [chain_id, address, nonce] 元组，把「授权哪个地址以我的名义执行」写进交易本身，验证方在协议层就能核对该承诺，不需要发明一条新指令去偷读交易结构。换句话说，7664 想要的「静态声明输入」属性，7702 用更通用、已有安全评审的授权签名就覆盖了，剩下的差异只剩「合约可自查」这一项小众需求。这解释了撤回的干脆：不是设计有缺陷，而是被更一般的机制吸收了——和当年 1193 吸收 2786 事件定义是同一种结局。
用户侧能带走的核对习惯
这个机制史给普通用户的启示落在签名环节：凡是把「授权」做成可签名结构的方案——无论是 2930 的访问列表还是 7702 的授权元组——其共同点是承诺内容写在交易骨架里、肉眼可在浏览器复现，而不藏在某段合约回调里。下次遇到「授权后自动执行」类产品，值得先弄清它依赖的是交易结构内声明还是链下转发：前者每笔承诺都可静态审计，后者永远依赖转发方的诚实。EIP-7664 本身已撤回，指令从未存在过，现网不存在 ACCESS_KEY 这个操作。
风险提示
本文涉及的提案状态与规则按 EIPs 官方仓库原文核验，请以仓库当前内容为准。了解交易结构有助于识别授权类风险，但不构成投资建议；签名不可逆，请逐字段核对后再确认。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。