ENSv2分层注册表架构解析：相比ENSv1的核心优势与升级指南

ENSv2 是对 ENS 协议的全面重新构想。它用分层架构取代了 ENSv1 的单一扁平注册表，其中每个名称都可以定义自己的注册表和解析器，从而解锁了以前不可能实现的模式。从即时子树管理和细粒度角色到解析器别名和无缝向后兼容性，ENSv2 保留了 ENS 成功的一切，同时扩展了以太坊 L1 上名称的功能。

七年前，ENS 以一个简单而强大的愿景推出：用人类可读的名称取代复杂的区块链地址。从那时起，ENS 已成为区块链的命名基础设施，拥有超过 150 万个注册名称，并与整个生态系统进行了集成——从钱包到社交应用再到企业平台。ENSv2 是对 ENS 协议的全面重新构想，它保留了 ENS 成功的一切，同时解锁了以前不可能实现的功能。

ENSv2 专门部署在以太坊 L1 上，用分层架构取代了 ENSv1 的单一扁平注册表，其中每个 ENS 名称都有自己的注册表。这种架构转变带来了强大的新模式：即时子树管理、跨多个名称的共享注册表、细粒度权限控制以及即时过期处理。结合改进的跨链互操作性以及两个全新设计的应用程序（ENS App 面向消费者，ENS Explorer 面向高级用户），ENSv2 赋予用户对其命名空间前所未有的控制权。让我们深入了解其工作原理。

从扁平到分层注册表

ENSv1 使用一个单一的扁平注册表合约，它在简洁性上很优雅，但在灵活性上受到限制。每个名称都必须遵循相同的所有权模型，由该单一合约强制执行。

在 ENSv2 中，注册表是分层的：每个名称都可以有一个解析器和一个子注册表。

ENSv2 引入了分层注册表。每个名称都可以提供自己的注册表实现来管理子名称，从而使名称所有者能够直接控制所有权和转移规则。名称还可以定义自己的解析器，而不是依赖共享基础设施。这共同形成了一个以单个根注册表为根的定向图结构。如果这听起来很复杂，请耐心听我们解释：以下是一些关于这在实践中意味着什么的上下文示例。

示例 1：即时子树管理

在 ENSv1 中，如果你想删除或替换 dao.eth 下的所有子名称，你必须单独修改每个子名称。在 ENSv2 中，你可以通过更新 dao.eth 的注册表，在一次操作中替换整个子树。

想象一个 DAO，它发行了 member1.dao.eth、member2.dao.eth 等。在每个治理期结束时，他们可以部署一个新的注册表并一次性重置所有成员名称，而不是单独撤销数百个子名称。

示例 2：共享注册表架构

使用 ENSv2，多个名称可以指向同一个注册表合约。这创建了强大的新模式：

Registry 0x123 contains:
- manager
- moderator
- member

If both dao.eth and community.eth point to Registry 0x123:
- manager.dao.eth exists
- manager.community.eth exists
- moderator.dao.eth exists
- moderator.community.eth exists

Adding a new role to Registry 0x123 automatically creates it for both organizations.

这不仅限于同一级别的名称。你可以让 dao.eth 和 team.project.eth 都指向同一个注册表，同时创建 manager.dao.eth 和 manager.team.project.eth。

这种模式非常适合希望在多个命名空间中保持一致角色结构，或者创建可在不同项目之间共享的标准化模板的组织。

示例 3：即时过期

ENSv1 的扁平结构意味着过期的名称会继续存在于注册表中，直到有人再次注册它们。更糟糕的是，任何子名称仍然活跃，创建了可能混淆用户的“僵尸记录”。

在 ENSv2 中，当名称过期时，它会立即从注册表中消失。该名称停止解析，并且整个子树变得不可访问。当有人再次注册该名称时，他们将从一个全新的状态开始。

角色：Name Wrapper Fuses 的演进

ENSv1 引入了 Name Wrapper，通过“fuses”实现了锁定名称和权限控制。它起作用了，但增加了显著的复杂性和开销。

ENSv2 用更灵活的角色系统取代了 fuses。你现在可以在三个级别设置细粒度权限：

1. Resolver 级别：权限适用于解析器中的所有记录，无论它们属于哪个名称。
2. 名称/节点级别：权限范围限定为特定名称下的所有记录。
3. 记录级别：特定记录类型甚至单个记录的权限。

考虑这些示例：

示例 4：多管理员设置

Company.eth configuration:
- Alice: Can update all records
- Bob: Can only update address records (for payment routing)
- Carol: Can only update the avatar record (for branding)

示例 5：委托内容管理

Museum.eth resolver permissions:
- Curator role: Can update 'description' and 'contentHash' records
- Finance role: Can only update cryptocurrency address records
- Public: Can read all records but modify none

这在使用自定义文本记录时变得特别强大，你可以在其中创建具有精确范围访问控制的应用程序特定数据字段。

示例 6：具有自定义文本记录的游戏公会

Guild.eth uses custom records for game state:
- Custom record: "guild.rank" (values: Initiate, Member, Elite, Leader)
- Custom record: "guild.treasury_allowance" (spending limit in USDC)
- Custom record: "guild.quest_completions" (integer count)

Permission structure:
- Guild Master: Can update all custom records for any member
- Treasurer: Can only update "guild.treasury_allowance"
- Quest Manager: Can only update "guild.quest_completions"
- Members: Can read all records but modify none

When member1.guild.eth completes a quest:
- Quest Manager updates their "guild.quest_completions" from 5 to 6
- Once they hit 10 completions, Guild Master updates "guild.rank" from Member to Elite
- Treasurer then adjusts "guild.treasury_allowance" from 100 to 500 USDC

这种模式使应用程序能够将结构化数据存储在 ENS 名称上，同时保持细粒度的访问控制——非常适合 DAO、游戏公会、凭证系统或任何需要将可验证元数据附加到身份的应用程序。

通用解析器 (The Universal Resolver)

ENSv2 中的解析工作方式不同。客户端不再自己实现整个解析过程，而是调用 Universal Resolver 合约，该合约在内部处理所有事情，从直接的链上解析到协调 CCIP-Read 查找，其中链下数据由客户端获取并在链上完成解析。

这种架构提供了平滑的升级路径。我们为 ENSv1 部署了 Universal Resolver，并迁移了客户端库以将其用作规范入口点。对于 ENSv2，解析器实现在幕后演进，同时保留该接口。基于这些库构建的应用程序无需进行任何更改，因为过渡是在链上透明处理的。新的分层查找过程的复杂性完全对客户端实现隐藏。

别名和共享记录

ENSv2 最强大但最微妙的功能之一是解析器的别名系统。

你可以配置多个名称使用相同的解析器，并在该解析器中定义别名以创建别名关系。当你更新记录一次时，所有别名名称都会反映更改：

示例 7：个人品牌一致性

Your resolver at 0x<YourAddress> contains:
- name: "Alice B"
- description: "Product Designer"
- avatar: ipfs://...
- url: "alice.design"

You configure these names to use the same resolver and enable aliasing:
- alice.eth
- alicedesign.eth
- alice.box

Now all three names show identical records. Update your avatar once, and it changes everywhere.

示例 8：多品牌管理

Your company owns:
- brand.eth
- brand-official.eth
- brandname.eth

All aliased by the same resolver with consistent company information.
A new product launch? Update the description once, and all brand names reflect it.

升级：保留过去，解锁未来

ENSv2 发布时，所有现有的 ENS 名称都已预先升级到特殊状态。遗留名称将：

• 继续像在 ENSv1 中一样解析
• 反映对 ENSv1 记录所做的任何更改
• 为最终用户无缝工作

当你准备升级时，过程很简单：

1. 调用升级合约
2. 指定你想要的解析器和注册表设置
3. 合约转移所有权并更新你的配置

对于在 ENSv1 中被封装和锁定的名称，ENSv2 通过要求使用特殊的 wrapper-aware 注册表合约来保留这些保证，该合约强制执行相同的限制。

通过回退解析实现向后兼容性

每个遗留名称都分配有一个 ENSv1 Fallback Resolver。当被查询时，该解析器：

1. 在 ENSv1 注册表中查找名称
2. 返回当前的 ENSv1 数据
3. 支持所有子名称的通配符解析

这意味着即使在 ENSv2 启动后对 ENSv1 所做的更改也将继续出现在 ENSv2 解析中——至少在你升级并设置自己的 ENSv2 解析器之前。

这对开发者意味着什么

如果你已将 ENS 集成到你的应用程序中，你需要了解以下内容：

1. Universal Resolver 就绪性：如果你使用的是最新的以太坊客户端库，你可能已经 ENSv2 就绪，无需进行更改。自定义 ENS 集成应确保它们通过 Universal Resolver 解析名称，以保持与 ENSv2 兼容。请参阅 ENSv2 readiness guide 以获取最新的兼容性矩阵和集成指南。
2. 注册表感知：对于高级集成，你现在可以查询单个注册表，以了解不同命名空间的具体治理和权限结构。
3. 子名称管理：如果你发行子名称（例如 Coinbase 的 cb.id 或 Uniswap 的 uni.eth），ENSv2 的注册表系统为你提供了更强大的工具来管理你的命名空间。
4. 自定义注册表：高级用户可以部署带有应用程序特定逻辑的自定义注册表合约——租赁系统、订阅模型、算法分配等等。

展望未来

ENSv2 代表了对 ENS 协议的根本性升级，这只有在构建和维护 web3 身份基础设施七年经验后才可能实现。

通过留在以太坊 L1 上，我们正在加倍强调我们的核心价值观：去中心化、安全性和中立性。通过围绕分层注册表重构协议，我们正在解锁以前根本不可能实现的功能。

通过在 ENS App 和 ENS Explorer 中构建特定用途的应用程序，我们确保无论你是认领你的第一个 web3 身份还是构建下一个主要的 ENS 集成，你都拥有所需的工具。

ENSv2 的升级将在未来几个月内进行。随着发布日期的临近，我们将分享详细的时间表、工具和文档。在此期间，你的名称将继续像往常一样工作——当你准备升级时，你将能够访问使 ENS 比以往任何时候都更强大的功能。

---

想了解更多？请查看我们的文档并在 ENS DAO 论坛中加入讨论。

对这类底层协议升级和技术架构演变感兴趣？欢迎到 云栈社区 的后端与架构板块，与更多开发者一起探讨分布式系统与设计模式。