没登记子域名也能被解析：ERC-2544 通配符解析的逐步回退与新增入口

如果一家平台想给每个用户发一个自己域名下的名字，最贵的不是名字本身，而是每个用户都要在登记表上单独写一条记录。ERC-2544 要解决的就是这笔账：让没登记过的子域名也能被解析出来。它的文件头记录创建于 2020 年 2 月 28 日，仓库记录状态为 Stagnant，并声明依赖 ERC-137。

先看清楚原本为什么会“查不下去”

ERC-137 的求解是两步：客户端对完整名字跑 namehash 得到节点，去登记表问解析器；拿到解析器后，再用同一个节点问具体记录。规范里写明，如果登记表上这个节点没有设解析器，流程就此终止。通配解析改变的正是这一点。

新增的做法是把最左边一段剥掉，对剩下的部分重算节点、再问登记表；找到带解析器的节点后，把原始的完整名字交给那个解析器去取记录。这个过程一层层往上剥，直到找到有解析器的节点。

客户端必须照做的两段流程

规范写得非常具体，第一段是找解析器：先把当前名字设为目标名字，读 ens.resolver(namehash(currentname))；结果不是零地址就停下并返回；如果名字已经剥成空串就返回空；否则剥掉最左一段回到第二步。原文特别注明，一个 parent 函数负责剥掉第一段，而顶级域再往上定义为空串。若这一段流程返回空，名字解析必须以失败终止。

第二段是取值：先按要查的记录类型把调用数据编码好，例如查地址记录就是 addr(namehash(name)) 的编码；再问解析器 supportsInterface，如果支持这份提案定义的接口，就调用 resolve(dnsencode(name), calldata)，否则退回去直接调对应的解析函数。最后按该函数的返回类型解码结果。有个细节被单独拎出来强调：不论走哪条路，传给函数的都是最初的完整名字，而不是第一段里用来找解析器的那个中间片段。

为什么需要一个新的 resolve 入口

新增的 ExtendedResolver 只声明一个函数：resolve(bytes calldata name, bytes calldata data)，外部只读调用，返回一段字节，并且要么返回合法的返回数据、要么直接失败。这里的 name 是 DNS 线编码下的明文名字，不是哈希。

动机在正文的取舍说明里讲得很清楚：只有哈希可用时，解析器拿不到明文段，很多玩法做不了。作者举的例子是某个带编号的子域名可以直接解析成某个集合里对应编号的持有者——只有哈希的话，这种对应关系根本无从计算。要求不高的解析器可以继续直接实现各个解析函数，完全不做这个支持。线格式编码被选用来打包名字，理由是能快速高效地哈希和增删单段，而点分字符串得逐字符找分隔符。

兼容性与风险，规范都写明了

兼容做法是老客户端读不到通配记录、会拒绝交互；新客户端继续按原有方式解析既有记录。已经在跑的解析器即使只是直接实现解析函数，也不会因为这份提案坏掉。需要留意的是，规范在这里用了 MUST 一类措辞，也就是说不做这套回退流程的客户端遇到通配名字时，本来就应该解析失败而不是给出一个猜测结果。

安全考量部分点了两处。其一，即便按规矩在没有解析器时拒绝解析，配置不当的客户端仍可能引用错误的解析器，或者在找不到解析器时没有拒绝空地址交互。其二，可以任意生成子域名的解析器会显著提高因为手滑而把钱打错对象的概率，规范建议这类场景额外提供上下文相关校验，或者支持资金可追回。换句话说，把子域名变成“看起来存在”的东西，等于把一个原本会报错的地方变成会给出结果的地方，这时输错字符的代价就变了。

对读这套机制的人，几个实际判断可以带走：平台发给你的子域名是否真的写在登记表上、还是靠父域解析器现场推算；这个推算规则是否稳定，父域解析器换成别的实现后你的地址会不会变；以及一旦有人替你改了父域解析器，全部推算出的子域名是否跟着一起变。第一个问题的答案决定这份名单值不值得长期保存。本文为机制说明，不构成任何投资建议。