ERC-2390：Geo-ENS 想让同一个域名在地球两端给出不同答案

内容分发网络早就懂得“离你近的服务器回你话”：同一个网址，不同地区的用户被指向就近的缓存节点。以太坊命名服务能不能也这样？ERC-2390 在 2019 年 11 月 15 日提出 Geo-ENS，一句话概括，就是把 GeoDNS 搬进 ENS。按 ercs 仓库记录，这份提案状态为 Stagnant，它挂在 ERC-137、165、1062 与 1185 的基础上，想给解析器加一层地理感知。

关键分岔：不查你的 IP，你自己报位置

原文最锋利的观察在对比段。传统 GeoDNS 靠查询来源的 IP 地址反查地理位置，而这个反查依赖 MaxMind 之类的 GeoIP 数据库——数据库过期时，返回的位置可以错得离谱。Geo-ENS 反过来：链上解析器没法看见谁在查询，于是让用户自己在查询里带上位置。这个改动带来一个连锁反应：既然位置是参数而不是推测量，任何人都能查询“站在地球任意一点会看到什么结果”，而不只是“我站在哪就看到哪”。传统 DNS 做不到跨地探查，Geo-ENS 反而天然是全局视图。

geohash：八个字符与二十米

地理编码用的是 geohash——把经纬度的二进制位交织起来、用三十二个字符编码的字符串，越长越精细。规范要求按地址记录资源时 geohash 恰好八个字符，对应约正负二十米的精度，每个地址必须独占一个。两个函数构成接口：setGeoAddr 按节点加 geohash 登记合约地址或其他资源，写入零地址即删除；geoAddr 按前缀查询，返回命中的资源数组——查精确的八字符得到一点，查短前缀则得到一片区域里的全部资源。原文明确说可以用 S2 Geometry 等更精细的编码替换，也提到圆形区域查询要拆成多次查询。

四份功能与一颗四叉树

动机部分列了 Geo-ENS 能做的事：找离用户近的智能合约服务、管理物理位置出入口的访问权、按查询方语言返回 IPFS 网页内容、给带物理位置的现实物品做代币化登记。实现层面，参考设计用稀疏四叉树做索引：树深八层对应八字符 geohash，每层三十二个分叉对应三十二进制，叶子存资源；由于地球表面约七成是水面，这棵树天然稀疏，省存储，也支持遍历算法返回地理包围盒内的资源清单。

为什么它停在 Stagnant

这份提案没有大面积落地，原因不难倒推：链上查询带位置参数，等于放弃“任何人可复现同一答案”的性质，结果依赖调用方自报的数据，预言机化和治理成本都被推高；而物理资产地理登记、就近合约路由这些场景本身在当时还没有需求。把它写进科普栏目的价值在于对照：ENS 家族对“名字解析什么”做过大量探索——地址、哈希、文本、地理，每一份停摆的解析提案都在替后来者试错。读者看到“地理限定的合约入口”这类产品宣传时，可以用规范里的老问题自查：位置由谁提供、错了谁负责、同一名字在不同解析路径下会不会给出矛盾答案。

从 geohash 到现实应用的距离

把这份提案当作一次技术选型样本读，还能收获方法论。geohash 用字符串前缀表达区域包含关系——八字符命中一点，五字符覆盖一片，这种编码让区域查询退化成前缀匹配，工程上极其便宜；但它的方形分区与真实行政边界、服务半径并不吻合，原文也因此提到圆形区域要多次查询。更重要的是查询模型本身：用户自报位置省掉了 GeoIP 数据库的错误，却把伪造位置的自由留给了调用方——合约无法强迫你诚实报出脚下这片土地。对内容读者，这意味着地理过滤类链上产品天然面临一个追问：位置由谁保证？如果答案是客户端自报或链下预言机，那么防刷、防串区的设计就得在那一层完成。一份停摆的接口，把这条评估链路完整地教给了后来人。

本文为机制说明，不构成任何投资建议。