EXTCODETYPE指令：EIP-7761让合约分得清三类账户

以太坊的状态模型里，每个地址背后可能是两种完全不同的东西：由私钥控制的外部拥有账户，或者部署了代码的合约账户。合约代码里也有过血统区分：传统写法写的遗留合约，和EVM对象格式（EOF）打包后的新格式合约。EIP-7761（2024年9月1日创建，提案文本状态为Stagnant）想给EOF合约一条专用指令EXTCODETYPE，让程序在运行时直接问出目标地址是哪一类，不再靠嗅探代码前缀去猜。

没有判型指令时合约怎么猜

EOF设计推进过程中出现了一个真实需求：新合约要处理与旧世界交互的逻辑。判断目标是不是合约，传统办法是EXTCODESIZE或EXTCODEHASH——代码为空就是外部账户。但这套判法越来越不够用。EIP-7702让外部账户可以写入一个委托指针，指向另一段合约代码执行，这类地址有代码行为、却仍不是真正的合约部署。另外EOF合约以特定字节序列开头（EIP-3540规定以0xef开头，EOFv1具体前缀是0xef0001），7702的委托指针前缀则是0xef0100。要在合约里区分这些情况，开发者只能自己取前缀、比字节，每一步都是容易写错的边界：取几个字节、不足长度怎么办、指针指向的又是一段EOF代码还是遗留代码。EIP-7761把这些判断收进一条指令。

判型规则本身

提案定义EXTCODETYPE操作码为0xe9，返回三个值之一：TYPE_NONE为0，表示目标没有任何代码——要么是普通外部账户，要么账户不存在或正在创建中；TYPE_LEGACY_CONTRACT为1，表示目标有代码但不以EOF前缀开头，包括遗留合约与经由委托指向的遗留代码；TYPE_EOF_CONTRACT为2，表示目标代码以EOFv1前缀0xef0001开头。处理委托指针有专门一条规则：如果目标地址上写的是EIP-7702式委托指针，指令要顺着指针把委托的代码取回来再判型，并按委托规则计费。提案特别注明两个细节：如果委托更新本身Gas不足，整个消息帧直接失败；如果指针指向的合约还在创建中，代码为空，返回0，这个行为与EXTCODESIZE等既有指令对齐。

计费与使用边界

收费结构复用EIP-2929：基础先扣热访问价一百Gas，目标不在已访问集合再补冷访问差价两千五百Gas，也就是和EXTCODESIZE一类指令同档。它只在EOF合约里合法——在EOF之前的世界里，包含这个字节的代码被视为无效，所以它是一个只会出现在新代码里的新能力，对存量合约零影响。对开发者而言意义有三层：安全判断可以更直接（比如只允许与EOF格式合约交互，规避遗留代码的未定义行为）；类型检查的Gas成本从一串取前缀操作压缩为一次标准访问；协议评审也省心——一个明确的指令总好过每个协议各自发明前缀嗅探。

快速问答

问：这条指令现在能用吗？ 答：不能。EIP-7761提案文本状态为Stagnant，且它依赖的EOF本身也未进入主网，主网的EVM遇到0xe9字节只会当作普通无效或未定义空间处理。

问：7702委托进来的代码算哪一类？ 答：看委托指向的实体本身。委托到EOF合约按EOF判、返回2；委托到遗留合约按1；这不是7761新增的模糊地带，而是顺着委托取回代码后按同一规则判型。

问：对合约安全审计有什么意义？ 答：判型逻辑集中后，审计师不必再逐处检查前缀比较代码的字节数边界，误判概率降低。

一条边界线

EIP-7761本身只是EOF大厦里的小房间，但它的存在方式值得记住：新协议功能先服务新格式代码，避免破坏任何存量合约，是以太坊渐进式改版的常用安全垫。看这类判型类指令时，只需检查两条边界——空代码怎么算、间接指针怎么算——两条都钉死了，语义基本就稳了。

风险提示：本文仅解释协议提案机制，不构成任何投资建议。EIP状态以官方仓库为准，提案不等于主网激活。