Try   HackMD

基于 Scroll 提供低成本的 ENS 二级域名

[EN] [zh-CN]

ENS 在 Layer1 中的交互成本阻碍了其广泛采用。

由于 SoulWallet 是基于合约的钱包(意味着我们无法实现一致的多链地址),确保用户拥有低成本的 ENS 对于良好的体验至关重要。

目前,我们拥有 swl.eth 域名,旨在为用户提供几乎免费的二级域名(例如 bob.swl.eth)。基本上有两种解决方案:

  1. 完全将所有二级域名存储在区块链之外,使用 EIP-3668

    • 优点 👍:用户在使用二级域名期间零 gas 费用。
    • 缺点 👎:完全集中化(从长远来看,这是不可持续的)。
  2. 迁移 ENS 二级域名到 Scroll 网络。

    • 说明:
      • 在 Scroll 中,我们将部署一个用于 swl.eth 二级域名的控制合约。用户可以在 Scroll 网络上设置他们的二级域名。
      • 当需要 ENS 解析时,我们的服务器将提供在 Scroll 网络中特定 slot 的证明。用户可以使用此证明在 Layer1 中验证域信息(例如 bob.swl.eth)。
    • 优点 👍:非中心化,且 Scroll 网络上的 gas 费用相对较低。
    • 缺点 👎:延迟(用户需要等待 Scroll 执行完成Finalize,在 Layer1 上他们的设置才会生效)。

我们更倾向于 '方案2'。

在方案2中,主要问题是用户需要等待较长的时间(尽管与 Optimistic Rollup 相比,Scroll 在 Finalize Transaction 上有优势,但近乎1小时的延迟仍然会显著影响用户体验)。

寻求帮助:

我们是否可以通过 commitBatch 存储的数据(committedBatches[_batchIndex] = _batchHash;)进行验证?

  • 信任:对于像 ENS 这样的非金融产品,为了保持用户友好的体验,我们可能会放弃一些安全性(相对于完全集中化而言更好)。此外,ENS 解析过程,例如通过我们的服务器生成证明,意味着我们的服务器和 Commit Transaction 中的数据需要共谋才可以提供虚假数据

我目前不确定在 Scroll 中是否可以通过 committedBatches 存储的 batchHash 验证最新的存储状态,例如如何通过 batchHash 最终证明出 Scroll 网络中特定 slot 中存储的数据。另外使用 commitBatch 中的数据可能存在什么其他潜在风险?


非常感谢, 有任何表述不清晰的地方请随时给我发消息。