ENS Layer2 和链下数据支持

 
 
概括

随着以太坊第 2 层解决方案的激增并开始走向成熟，ENS 能够在整个生态系统中提供解析服务，并使 ENS 用户能够利用 Layer 带来的效率，这一点非常重要2个解决方案。在Vitalik发表文章提出了一种可能的方法之后，ENS 团队以及更广泛的 ENS 和 L2 社区一直致力于开发通用的“第 2 层桥”，使 ENS 和其他应用程序的跨平台互操作性成为可能需要能够从各种链下来源检索数据（驻留在以太坊主网之外的任何数据，也称为第 1/L1 层。这包括专有数据库和第 2/L2 层解决方案，例如 Optimism、Arbitrum、Starknet、 ZKSync 等）以一种无需信任的方式并提出了标准。
EIP 3668 （最终版）允许以对客户透明的方式进行链下（包括第 2 层/L2 层）数据查找，并为合约作者提供实施任何必要的验证；在许多情况下，除了数据存储在链上所需的信任假设之外，无需任何额外的信任假设即可提供此服务。
EIP 5559 （草案）提供了一种机制，智能合约可以请求外部处理程序解决各种任务。这提供了一种机制，协议可以通过将数据的处理推迟到另一个系统/网络来减少与在主网上存储数据相关的天然气费用。这些外部处理程序充当核心 L1 合约的扩展。
ENSIP 10 （草案）是在 L1 上解析通配符（例如：*.foo.eth）的通用方法。发布子域名并将父名称的解析移至链下，允许 dapp 链下创建子域名，但可以通过 L1 进行访问。
Dapp 和钱包支持链下数据查找所需的步骤。

如果您的 dapp 或钱包使用这些库之一，则将内置 EIP 3668 和 ENSIP 10 支持，因此只需在准备好后更新库即可。EIP 5559仍处于草案的早期阶段，内容将会不断演变
​以太坊

ethers.js 5.6.2 支持 EIP3668 和 ENSIP 10。
只要您的应用程序通过etherjs ENS 方法与 ENS 交互，就不需要更改代码。
要尝试这些功能，offchainexample.eth请指向所谓的“链下解析器”，该解析器从 Google 应用引擎上托管的 JSON 配置文件中获取数据。它将向 offchainexample.eth 及其子域记录（例如 ）的任何记录回复数据2.offchainexample.eth。示例解析器未使用 L2 数据，但当 L2 解析器准备就绪时，相同的机制将起作用。
 
const { ethers } = require("ethers");
 
const url = `https://mainnet.infura.io/v3/${process.env.API_KEY}`;
 
const provider = new ethers.providers.JsonRpcProvider(url);
 
​
 
async function main() {
 
let resolver = await provider.getResolver("1.offchainexample.eth");
 
let address = await provider.resolveName("1.offchainexample.eth");
 
let email = await resolver.getText("email");
 
console.log({ resolver: resolver.address, address, email });
 
}
 
main();
预期输出如下。
 
$node index.js
 
{
 
resolver: '0xC1735677a60884ABbCF72295E88d47764BeDa282',
 
address: '0x41563129cDbbD0c5D3e1c86cf9563926b243834d',
 
email: 'nick@ens.domains'
 
}
有关更多详细信息，请参阅链下解析器客户端示例代码。
其他支持的库。

集成钱包

  •  
    ​阿尔法钱包
  •  
    ​银色
  •  
    ​Coinbase钱包
  •  
    ​信任钱包
  •  
    ​本影钱包
Dapp 和钱包在链下发布子域名所需的步骤

如果您希望使用链下数据存储来发布子域名，请按照链下解析器作为参考点。该示例使用平面文件作为数据源，但可以轻松地替换为数据库调用。
以下项目已与 Offchain 解析器集成以发布其子域名
  •  
    ​cb.id，来自Coinbase
链下解析器提供了一种简单的方法来存储链下数据，但请注意一些权衡。用户必须相信网关服务器返回正确的数据。一些链下解析器通过签名返回证明。为此，发布子域的父域的所有者必须自己托管网关，并且必须有私钥进行签名。如果网关服务器被入侵，则存在子域地址被重定向到恶意地址的风险。
为了最大限度地减少对网关的信任，我们目前正在开发L2 解析器
L2 旋转变压器

在 L2 Rollup 系统中，合约状态哈希值以及记录为 calldata 的交易调用和参数存储在链上。rollup 有一种机制可以立即或乐观地验证其链在 L1 上的状态。
ENS 集成在网关中利用了这种机制。网关从 L2 检索数据以及证明（通常通过eth_getProof）并返回给调用者。调用者将数据传递给 L1 解析器合约以验证其状态和数据（更多详细信息）。只要L1合约能够验证L2数据的状态和存储，用户就不再需要信任网关本身。如果网关服务受到损害，最糟糕的情况可能是网关停止响应数据（当发生这种情况时，解析器的所有者可以简单地启动新网关并更新 L1 合约以返回新网关地址）。父所有者甚至不必自己托管网关服务，而是可以使用第三方网关服务。
要评估 L2 Rollup 系统是否可以与 ENS 集成，请参阅以下步骤。
  • 2.
    链上的RPC是否返回？如果没有，则需要一种方法来检索存储证明以在以太坊 L1 上进行验证eth_getProof
  • 3.
    Rollup合约是否有返回提交给以太坊L1的最新L2区块信息的功能？对于 Optimistic Rollup，它需要提交的和最终确定的（挑战期后）块信息。需要在 L2 上blockhash调用eth_getProof等效函数
  • 4.
    有没有办法在 L1 合约上验证从 L2 返回的状态根是否有效？
  • 5.
    有没有办法验证是否storageProof包含在状态根中？对于乐观汇总，我们可以使用乐观团队开发的库。如果链不支持Patricia Merkle Trie，则需要自己的库Lib_SecureMerkleTrie
欲了解更多详细信息，请参阅OP Stack 解析器的原型实现。Starknet 有一个社区提案来添加支持。
常问问题

更改是否向后兼容？

是的。在没有支持这些标准的客户端或应用程序的情况下，L1 上的现有名称将继续工作。只有 L1 之外的名称不会被解析。
GraphQL 会支持 L2/链下数据吗？

一旦每个 L2 得到正式支持，我们将需要为每个 L2 桥启动一个子图，并且我们将使用模式缝合来使它们的使用对调用者透明。
对于未托管在受支持的 L2 上的名称，我们将无法获取通常仅在子图上可用的数据
你们如何支持其他 EVM 兼容链？

非 L2 链缺乏以去信任方式验证 L1 数据的方法。另一种选择是链桥运营商充当受信任的第三方并托管链下网关，或者单个 dapp 托管自己的网关并使用 ENS 名称的私钥对每个数据进行签名。
我可以发布一个针对链下环境的新顶级域名吗？

不会。请阅读“为什么 ENS 不创建更多 TLD：全球命名空间中负责任的公民”了解更多详细信息。或者，我们建议您将 DNS 名称导入为 ENS，例如 cb.id 和 argent.xyz
我可以将主名称设置为链下名称吗？

是的你可以。然而，反向注册器（它是一个以 .addr.reverse 开头的隐藏顶级域）目前驻留在 L1 上；因此你必须在 L1 上支付汽油费。我们将来可能会考虑将反向注册器移至 L2。
我可以在链下注册 .eth 名称吗？

仅当我们在找出哪个 L2 最支持 ENS 集成后，将 .eth 名称迁移到特定 L2 作为迁移的最后步骤之一时。
如何处理合约地址？

与 EOA（外部拥有账户）不同，基于合约的账户（例如多重签名）可能只能在某些链中访问。ENSIP-11允许单个名称跨多个 EVM 兼容链保存不同地址，建议将合约地址存储到 EVM 链特定地址记录字段。
我可以使用其他支持 .eth 的名称服务中的库吗？

@unstoppabledomains/resolution自 2021 年 12 月起删除了ENS 支持。其他服务往往不支持所有 ENS TLD，尤其是基于 DNS 的 TLD（.com、.net 等），因此我们建议不要依赖这些解析 ENS 名称的库。
我们的链不是 Rollup，但我们有办法在以太坊 L1 中验证我们的状态。我们还能融合吗？

如果有一个轻客户端可以验证以太坊 L1 上链的状态和数据，那就有可能了。
参考文献和之前的讨论

  •  
    ​视频： 2021 年
  •  
    ​视频： 2021 年
  •  
    ​视频： 2020 年
  •  
    ​视频： 2020 年
  •  
    ​视频： 2020 年