Overview
当前用户账户/钱包的ID系统比较分散,有一些钱包提供方为用户提供完全自定义的ID实现,也有通过ENS直接或者间接实现的。
- 钱包完全自定义的实现:
- 直接使用 ENS:
- 优点:兼容性高
- 缺点:成本太高,以至于对于更广泛的用户来说是不可接受的
以下分享一种高兼容性的基于ENS的渐进式去中心化ID系统的设计
具体来说为用户提供的域名大概是这个样子( 假如 swl.eth 为我们自己的ENS ):
- bob.swl.eth
- bob.soul.eth 能够返回的解析为不同链上的不同钱包地址(参考 ENSIP-9),这批地址是用户默认的收款地址,每个链上只能指定一个地址。
- xxx.bob.swl.eth
- bob 有权利任意指定在 bob 这个二级域名下的三级域名,例如 bob 可以通过三级域名设置他的其他钱包配置。
最终版本大概执行流程:
- 无成本解析设置
- 在我们的 ENS swl.eth 中自己设置 resolve, 这个 resolve 支持 *.swl.eth 的通配符解析。所有请求到 *.swl.eth 都会
revert StorageHandledByL2(L2ChainId,L2Contract)
(参见 EIP-5559)。这时我们的 ENS 会重定向到某个我们选定的低成本 L2 上面,当用户在这个 L2的 L2Contract 中解析域名时,这个 L2Contract 会返回 revert StorageHandledByOffChainDatabase(info)
, 这时会把用户的域名解析重定向到我们的服务器中。在这个流程中 用户增加域名解析是没有任何链上成本的。
- 安全的链上解析设置
- 如果用户希望更安全且独立控制的域名地址,用户当然可以直接选用 ENS,但同时用户又不想直接租赁ENS域名,也不想在 L1 中支付相关的 gas fee ,则我们可以在我们的 L2 解析器中把指定域名的权限在链上设置为用户在当前链的某个钱包地址,这样以后用户的ENS更新我们就不再负责,以后所有的更新都由用户在 L2 上支付 gas fee 自己设置。
Phases 1
- 可行评估:可以立即实施
- 中心化程度:完全中心化
- 兼容性:高
- 任何兼容 eip-3668 & ensip-10 的客户端都可以解析相关域名。经过初步调研,使用较新版本 ethers.js web3.js 等开发库的软件可以完全兼容。
- 但请注意,当前方案无法实现‘反向解析’,也就是仅仅可以把 bob.swl.eth 解析成 0xb0b,但是无法通过 0xb0b 来得到 bob.swl.eth
- 用户使用成本:零成本。
- 说明:我们的用户可以 0 成本拥有基于我们 ENS(swl.eth) 下面的二级以及三级域名。