ERC-7996 supportsFeature：合约自报能力，不止接口探测那一问

智能合约自报家门的老办法是 ERC-165：问一句 supportsInterface，合约回答“我完整实现了某个接口”。但这套问题只能问接口形状的语法——问不出行为层面的能力。一个 ENS 解析器是否支持批量 multicall、一个市场合约能否处理某种特殊订单结构，这些能力没有接口 ID 可填，历史上全靠翻文档或试错调用。ERC-7996（Contract Feature Detection）为这类“无法用 ERC-165 表达的性质”补了一个平行的问题：supportsFeature。按以太坊 ercs 仓库的记录，提案状态为 Draft，创建于 2025 年 7 月 7 日。

能力名怎么变成一个四字节标识

标准的标识规则与 ERC-165 的神似但入口不同。能力名应当写成反域名格式，让名字本身唯一地描述其含义——标准给的示例是 eth.ens.resolver.extended.multicall，表示一个扩展 ENS 解析器的批量调用能力；把这个名字做 keccak256 哈希、取前四字节，就得到能力标识（示例对应 0x96b62db8）。合约侧的义务是完整实现声明了该接口的 supportsFeature(bytes4) 视图函数，对支持的能力返回真；这份接口自身的 ERC-165 标识是 0x582de3e7，于是问题变成两层：先用 ERC-165 问“你支持 ERC-7996 吗”，再用 ERC-7996 问“你支持某能力吗”。探测方的规范流程也照此两层展开，先确认合约实现了能力查询接口本身，再逐个哈希比对关心的能力名。

与 ERC-165 的分工线，以及一个信任前提

标准把 ERC-165 的老警告原样搬了过来：声明支持某个特性，不等于真的实现了它。四字节标识只是名字的回声，与代码行为没有任何数学绑定，探测返回真之后，模拟执行与集成测试仍是不可省略的下一步。标识推导的细节还藏着一个治理问题：反域名前缀的名号归域名持有者所有，谁控制某段前缀，谁就握有对应能力词的命名权；两个互不兼容的实现理论上可以给同一个名字领走同一个四字节标识。工具方在把标识写进配置文件前先确认命名权归属，比对出来的 true 或 false 才有意义。

从工程生态看，它补的是一个渐显的空白：接口标准化了函数形状，却管不住约定行为，市场合约、解析器、扩展钱包越来越多地靠文档句子描述自己的能力，每加一句就要为它发明一次探测协议。把能力名统一成反域名哈希之后，钱包与聚合器第一次可以用同一种问句扫全网，能力清单也因此可以被索引、被比较。趋势上值得留意的是能力目录页的出现——一旦某个前缀形成事实命名权，围绕它的 true 与 false 就会构成一层新的元数据市场，命名权与目录权本身也会成为争夺对象。

两个探测机制的边界值得画清楚。ERC-165 的接口 ID 由接口内全部函数选择器异或而来，问的是“这套函数签名是否按规范齐备”，答案是可机械验证的；ERC-7996 的标识只是名字哈希，与实现内容没有数学关系，合约回答 true 之后，那个能力究竟是否存在、语义是否如名字所述，取决于实现者的诚实与规范的约束力。这决定了它的正确用法：把 true 当作文档承诺的链上镜像、集成测试的第一个信号，而不是免检证明——涉及资产的调用前，仍要用最小化交易或模拟执行验证行为。名字的反域名约定同样有讲究：谁来拥有某个域名前缀，谁就事实上定义了对应能力的命名空间，跨项目复用能力名时要先确认命名权归属，避免两个互不兼容的实现共用一个哈希各说各话。给 NFT 基础设施的一层意义在于：钱包与市场面对五花八门的扩展行为时，多了一个不用为每种行为发明一个接口的通用问句。标准仍是草案，规则以仓库当前文本为准。本文为机制说明，不构成任何投资建议。