探索与实现去中心化域名系统
在我们日常使用的互联网中,域名系统(DNS)等命名服务使我们能够无缝导航网络。尽管如此,那些致力于实现Web3理想的解决方案,特别是那些为完全去中心化应用而设计的,还没有得到广泛的应用。
与那些受到严格管理的DNS不同,去中心化区块链网络的参与者所管理的服务旨在提供可靠的中立性、免许可的访问,以及对域名的直接所有权和控制权。
虽然DNS实际上是由一系列分层的分布式名称服务器构成的,我们仍然依赖于它来进行IP地址的转换,以及通过我们选择的第三方网关解析HTTPS内容——这个过程由负责管理互联网编号分配机构的ICANN控制,并进一步管理DNS的根区域,由一个由16个成员组成的投票机构进行治理。
在探索去中心化托管选项以及在由Lorenzo Sicilia撰写的文章中总结决策过程的关键点时,我们也热衷于寻找符合提出的接受标准的Web3命名服务——即简化CI/CD集成并能够以一种经济的方式通过代币支付任何状态变更。此外,该服务还必须与所选的存储解决方案——即Arweave的Permaweb——良好配合。
选择命名服务的过程中,我们定义了以下几个接受标准:
- EVM兼容性:提供与EVM地址的完全兼容性。
- 可读域名:为用户提供易于阅读、识别和记忆的域名。
- 去中心化:作为一个去中心化协议,最小化单点故障的风险。
- CI/CD友好:支持对域名记录的程序化更新,便于集成到DevOps流程中。
- 经济性:更新域名记录时,无需支付或只需支付象征性的交易费用。
基于这些标准,我们考虑了几个成熟的以及一些新兴的命名服务。
以太坊名称服务 (ENS)
ENS提供的 .eth 后缀是Web3中目前最被认可和采用的EVM命名服务之一——但其名称注册主要是由寻求其个人加密地址的独特标识符的用户所驱动。对于我们的目标而言,重要的是,除了允许用户设置这个主要名称外,ENS还支持将钱包地址解析为可读的ENS名称,同时每个ENS名称还允许所有者设置不同的“记录”,这些记录可以指向文本、其他以太坊地址、应用程序二进制接口(ABIs)或内容哈希。
通过将这些记录设置为内容哈希,我们可以利用易于识别的ENS名称作为可读域名,引导用户访问我们应用程序的去中心化前端。
尽管如此,我们在采用ENS时做了几个假设:
- .eth 尚未成为可能导致解析冲突的DNS顶级域名——幸运的是,目前对我们而言它还不是,并且有关此话题的详细解释可以在相应的链接中找到;
- 主流浏览器普遍未集成支持ENS名称解析的逻辑——在大多数情况下,用户需要向他们的浏览器添加扩展,以启用无缝解析和浏览体验。
由于缺乏广泛的浏览器或DNS支持,我们需要将ENS名称与专门设计的网关配对,通过HTTPS解析关联的ENS记录。提供此类特定解析的两项服务是eth.link和eth.limo。
考虑到eth.link网关由Cloudflare运营,这引入了中心化的失败点,我们更倾向于使用eth.limo——继续阅读以下内容,了解更多关于此服务及我们为扩展其功能所做的工作的激动人心的细节。
eth.limo是一个免费的、公共的、优良的ENS网关,它通过使用通配符DNS记录*.eth.limo来提供对ENS域名的HTTPS访问。
我们希望能够定期更新网站内容,这意味着我们希望保持对ENS记录中内容哈希的可变性。如上所述,每次向Arweave上传新内容时,都会生成一个独特的交易ID;因此,为了支持我们的CI/CD目标,我们计划在将新提交合并到我们的生产分支时更新ENS记录,以确保用户能够查看最新的网站内容。
然而,由于ENS公共解析器智能合约位于以太坊主网上,我们不幸地面临每次想要将新内容推送到Arweave时高昂且可变的gas费用——这并不经济,因此未能满足所有接受标准。
Layer 2 ENS
为了寻找一种更经济的解决方案,定期更改我们记录的内容哈希,同时保留.eth域名的识别度,我们寻找了在EVM Layer 2上构建的相邻解决方案。尽管有一些尝试,但目前还没有原生的ENS解决方案——然而,ENS团队最近发布的一篇文章透露,他们正在开发一个EVM网关服务,以实现以太坊服务和L2解析器之间的互操作性。我们将密切关注这方面的进展,但鉴于目前缺乏成熟度,我们决定寻求其他解决方案。
Unstoppable Domains
Unstoppable Domains提供了一站式购买Web3域名的服务:不仅仅是.eth记录,还包括.crypto和.x后缀。尽管他们的产品在网站上完全去中心化,但该公司运营着一个中心化的商业模式,并在去年因被授予“解析区块链域名”的专利而受到批评——ENS的主要开发者声称该专利“完全基于ENS的创新,并未包含任何自身的新创新”。
尽管我们认为Unstoppable Domains提供了有价值的服务,特别是因为它提供的.crypto和.x域名可以一次性付费永久拥有,但我们决定我们希望我们的Web应用尽可能去中心化,因此选择不采用这个解决方案。
Arweave 名称系统 (ArNS)
由于Arweave目前正在开发和测试他们自己的名称服务,我们研究了是否可以利用它来满足我们的接受标准。该服务相对较新,但它带来了与ENS相似的功能和优势(人类可读和去中心化设计),我们得以迅速掌握,多亏了通过Discord获得的令人难以置信的开发者关系团队的帮助。
ArNS利用Arweave的SmartWeave智能合约协议构建,并使用一个注册合约与ID记录,这些记录指向被称为Arweave Name Tokens(ANTs)的代币。ANTs是特定人类可读子域名所有权的代币化和可转让表示。ANT合约本身持有一个记录,可以设置为Arweave交易ID,而这个ID指向的内容可以通过大量的Arweave网关简单地通过预先添加的注册子域名解析,例如my_domain.ar-io.dev。
更新ANT记录既经济又可以通过程序执行,满足了我们与CI/CD工作流无缝集成的目标。更具体地说,与我们开发的Arweave打包工具相结合,我们非常接近于满足我们的接受标准,尽管没有保留.eth名称。
增强的名称服务网关功能和应用学习
与 eth.limo 和 ArNS 团队一起激励创新
为了增强名称服务网关的功能和应用,我们激励了eth.limo和ArNS团队的创新。鉴于我们已经与Arweave的技术密切合作,但希望保持.eth名称的识别度,我向ArNS和eth.limo团队提出了一个问题:eth.limo网关是否可以包含解析逻辑,允许我们设置一个指向ANT的ENS记录,并直接在ANT的记录上解析?
换句话说,ENS名称的记录可以持有Arweave内容哈希,但更改它代价高昂——我们应该能够在eth.limo网关中添加一些逻辑,以识别ENS记录是否为ANT(而不是普通内容哈希),如果是,便查找并渲染ANT记录所指向的内容哈希。
这种混合方法将让我们使用eth.limo进行ENS解析,同时使我们能够访问ANT记录,后者仍然是可变的,但定期更新更加经济。它还将提供额外的域名冗余。令人高兴的是,eth.limo团队对此表示兴趣,并开始积极开展工作,以我们的ANT作为测试对象。
eth.limo团队目前正在测试新的解决方案,并预计将在今年第一季度或第二季度初的新版本中加入解析逻辑。
arweave-bundler:使用 'set' 命令
在引言中提到并链接的那样,我们的工程总监在一篇单独的博客文章中详细介绍了Outlier Venture开源的arweave-bundler——这个工具允许开发者轻松地将web应用文件从目标目录打包并上传到Arweave,并可以通过命令行指令使用,或者作为GitHub Action集成到自动化CI/CD工作流中。
根据我们对ArNS的了解,我们为该工具编写了一个新的'set'命令和'ant-address'选项,启用自动ANT记录更新,使得在域名解析后不久,用户就可以查看到最新的web应用内容。使用CLI,有两种方式可以以编程方式更新ANT指向的记录:
显式调用“set”命令
如果您已经将内容上传到Arweave,并有一个ANT地址,您希望更新该记录所指向内容的交易或清单ID,您可以使用'set'命令,包括--ant-address选项标志并传递ANT的地址,然后使用--manifest-id选项标志后传递所需的交易ID。
npx arweave-bundler set --ant-address
使用‘upload’命令时隐式调用‘setRecord’
如果您希望在将新内容上传到Permaweb的同时更新指向您最新的web应用内容的ANT记录,您只需包含--ant-address选项标志并传递您的ANT地址。这将自动采用上传函数生成的返回的manifest-id,并通过setRecord函数提交一个Arweave SmartWeave交易。注意,用于上传新文件的私钥必须与拥有ANT的私钥匹配。
npx arweave-bundler upload build/ --ant-address
清单ID是指向清单文件的Arweave内容哈希,清单文件是一个包含打包文件中所有文件的交易ID的JSON文件。它包含一个index属性,指向web应用入口点的交易ID的别名。
免责声明:文章中的所有内容仅代表作者的观点,与本平台无关。用户不应以本文作为投资决策的参考。