合约自己不提供的功能去哪找：ERC-1844 的 ENS 接口发现

一个代币合约往往自己不做批量交换、不做抵押借贷，但围绕它有做这些事的关联合约。应用想拼出完整功能图谱时，ERC-165 的接口探测在这里帮不上忙——它问的是“你支持吗”，答案只覆盖目标合约自身。ERC-1844 提供另一条路线：把功能实现者的地址登记到名字所绑定的解析器上。文件头记录创建于 2019 年 3 月 15 日，仓库记录状态为 Stagnant，声明依赖 ERC-137 与 ERC-165。

一个函数定义的档案

规范的正文短到只有一个函数签名。在某个 ENS 节点上调用 interfaceImplementer(node, interfaceID)，传入名字哈希和四字节的接口标识，返回一个地址：官方对该“名字或地址所关联的某接口功能”给出的实现合约位置。它是对 ENS 解析器配置体系的扩展，语义上是一类新的记录——过去解析器存的是地址、内容哈希、文本键值，这里存的是“接口到实现”的映射。

原文举的例子值得复述：一个代币合约不提供原子交换功能，但社区为它写了一个专门的交换合约。代币项目把交换合约的地址写进自己 ENS 名字的解析器档案，任何应用查一次解析器就能找到它，不必去论坛翻公告。实现方可以是目标合约自己，也可以是任意第三方合约，规范不做区分。

与 ERC-165 的分工

两者的问题域刚好错开。ERC-165 是对着合约地址自报家门：你实现的代码里有没有这些函数选择器。ERC-1844 是问名字背后的档案：这件事由哪个合约代劳。前者回答能力，后者回答位置；一个地址可能 ERC-165 探测全部返回不支持，却依然能通过 ERC-1844 的档案把所有周边功能交代清楚。标准文本自己也承认这一点，明说这是对 ERC-165 的补充而非替代。

查询链条上的责任

把这套机制用顺需要三步。第一步，项目方先要有 ENS 名字并把解析器配置好，档案的权威性完全建立在这次配置上。第二步，调用方查询时要处理空地址的情况——档案没登记某接口时返回零地址，应用得决定是退回 ERC-165 探测还是放弃该功能。第三步，拿到返回的地址之后，规范留了一个明显的补课动作：这个地址是否真的实现了申报的接口，仍要用 ERC-165 探一遍。ERC-1844 只保证“档案这么说”，不保证“实现方没撒谎”，也不保证档案更新后旧地址仍然安全——被登记的合约可以自己升级或作恶，这层风险不在这个标准的射程内。

停滞状态意味着什么

一次真实查询的动线

把视角换成一个钱包应用，这条链路才显出全貌。用户打开某个协议页面，前端拿着页面声明的 ENS 名字向解析器要 interfaceImplementer，名字节点先要在注册表里存在、解析器要指向一份配置了该记录族的合约——任何一环断掉，查询都会安静地返回空。原文明确这种发现机制对 ERC-165 的依赖方向：拿到实现地址后，验证责任仍交回 ERC-165 探测，也就是说 ERC-1844 的定位自始至终是路标而不是质检员。对普通用户，这一切发生在几秒钟之内，能感知到的只有一件事——功能列表是从链上档案读出来的，不是写死在某个前端仓库里的。这既是它的价值，也是它的风险面：档案由名字持有者维护，钓鱼项目可以注册一个视觉上逼近的名字，配一份指向仿冒合约的档案，把 ERC-165 探测全部做足来伪装合规。识别这类仿冒没有捷径，仍然要回到名字本身的注册历史与所有权记录上。

仓库记录里这份提案停留在 Stagnant，没有形成大规模公开部署，也说明“名字为中心的功能寻址”最终没有成为主流模式：现实里应用更多靠官方文档和聚合器的静态清单完成同样的事。但它的结构对理解今天仍有用——当你在链上工具里看到某个 ENS 名字被解析出一串功能地址，那种“档案登记”思路和 ERC-1844 是同构的。核对这类映射时，正确的怀疑顺序是：名字所有权归谁、解析器由谁配置、返回地址的合约代码是否与申报接口一致，三问缺一,查到的地址就只是一个地址而已。本文为机制说明，不构成任何投资建议。