委托指示器也能被查询：EIP-7880 的 EXTCODEADDRESS 与 EOF 的读码缺口

一扇被焊死的观察窗

EIP-7702 已定稿，它允许普通外部账户在代码字段里写入一段委托指示器：0xef0100 加一个 20 字节地址，执行时跳转去跑那个地址的代码。这个前缀后来的故事——包括它被另一份提案再次认领去焊死私钥——本栏目在 同一个前缀，两种焊死私钥的活路：7702 之后 0xef0101 的两次认领 里完整梳理过。麻烦出在 EOF 这一侧：EVM 对象格式为了永久禁止代码内省，合约不但不能复制别人的字节码，连「这个账户是不是委托账户、委托给谁」都问不到。EIP-7880 在 2025 年 2 月 8 日提出，由 Danno Ferrin 撰写，就是要在这扇焊死的窗上开一个只透一个答案的缝：一条新指令，只回答「最终生效的是哪个地址」，别的一个字节都不给。截至按仓库原文核验时，该提案处于 Review 状态，依赖 7692（EOFv1 集合）、7702 与 7761。

一条指令的取值规则

新指令叫 EXTCODEADDRESS，占用 0xea。执行逻辑原文写得很克制：先按暖访问价扣 100 Gas，若目标地址不在已访问集合里再补 2500 差价（冷账户访问共 2600，沿用 2929 的暖冷体系）；随后读取目标账户的代码，如果代码开头是 7702 定义的 0xef0100 委托指示器，就把指示器里那个地址压上栈；否则原样返回被查的地址本身。三类边界值得记下：正在创建中的合约返回其地址本身；只把被查的目标地址标暖，它委托到的地址不算暖——即使那个地址已在访问集合里也不影响本指令收费；高 12 字节非零的地址直接异常终止，原文还特意加注「未来地址空间若扩大，此处规则会变，不要长期依赖」。向后兼容的理由也写在原文：EOF 校验在提案激活前一直拒绝 0xea 字节，链上不可能存在含这条指令的 EOF 合约，所以不用升版本号。

它想拦住的三类事故

动机部分给了三个具体场景。第一类是受管理的代理合约：这类合约要在被升级时确认新目标不是一个委托地址——委托随时可能被账户主人改走，代理若指向一个委托，行为就不再受升级方控制。第二类是 Gas 赞助与意图防串：赞助方给一笔交易付 Gas 时，最怕收款合约先收赞助、再把账户委托改指到别处，执行出与审批时完全不同的动作；把委托地址预先写进交易数据、执行时用这条指令比对，就能可靠地验明「还是不是当初那家」。第三类是白名单收缩：某些合约只想接受少数几个已知委托，验证时需要解析出委托的真实地址，而不只是知道「有委托存在」。三个场景的共同点是：问题不在执行对错，而在合约需要回答「我对面的账户到底以什么身份行事」。

为什么不做成读一段指示器让合约自己解析

原文的 Rationale 专门否掉了一条省事路线：让特供版 EXTCODECOPY 只返回委托指示器字节、由合约自己拆格式。被否决的理由有两层，一层是它会破坏 EOF 禁止代码内省的根本原则；更深一层是格式锁定——一旦合约开始按今天的 0xef0100 结构解析字节，未来任何升级委托格式的分叉（比如允许链式委托）都会牵连这些合约。改为只返回解析后的效果，机制可以换、指令不用变。同一份 Rationale 还引用了 EIP-7761 的账户类型内省讨论，那条思路在钱包赛道的对应物见 账户不必部署代码也能共享实现：EIP-7819 的 SETDELEGATE 设想，可以把两者当作「查类型」与「查去向」的对照来读。

对普通用户的实际含义

这条指令服务的是合约作者，但它折射的检查动作值得每个做授权的用户借鉴：账户代码被委托之后，区块链浏览器上「有没有合约代码」这个直觉判断已经不再可靠，一个 EOA 地址可以拥有合约行为，一段委托可以悄悄改向。凡涉及长期授权、自动续费或代付安排，值得定期用浏览器核对授权目标的行为是否变化——委托指示器的更新本身也是链上事件，改向历史可以回查。提案自身还在 Review，指令并未上链，EOF 本身也尚未随 EOFv1 集合激活，眼下这些只是设计与核对思路。

风险提示

本文涉及的提案状态与行为规则按 EIPs 官方仓库原文核验，均未最终生效，请以仓库当前内容为准。账户委托能力可被滥用，核对授权对象是防御手段之一，但不构成投资建议；签名前请仔细核对授权范围与目标合约。