查看原文
科技

【机遇与挑战】Chia去中心化域名服务

河马/HemaDAO HemaDAO 2023-08-27
编者按:互联网的一个显著问题是域名服务(DNS),即代表网站的名称,它们都是由ICANN这样的中心化公司监管,而域名注册商则托管在中心化服务器上。
用户购买的域名并没有完全归属权,因为注册商充当了托管者的角色,只为用户提供访问该域名的权限,并可以随时将其删除。
这正是区块链发挥作用的地方,它具有彻底改革互联网的可能:Web3域名,也称为NFT、crypto或区块链域名。它们是去中心化的——它们从试图审查、暂停或劫持你的网站域名的机构、公司和个人手中脱离出来。
典型应用案例就是以太坊域名服务ENS,它是当今最大的区块链命名标准服务,拥有超过217万个注册名称,并集成在500多个DApp上,在整体注册增长方面,「.eth」在过去 3 年每年增长 228%,同时,ENS 代币激励迄今为止为 0——这是产品 / 市场契合度的一个积极信号。
今天,Chia公司员工Fizpawiz提出了在Chia区块链上提供去中心化域名服务的完整设想,本文偏技术,但是对于有志于开发Chia区块链去中心化域名服务的开发者来说,是一个很不错的指导性文章。】


Chia 区块链上的去中心化域名方案
作者:Fizpawiz   2023年8月26日
首先,虽然我在Chia Network Inc工作,但在这个 Medium 帐户上提出的想法和意见完全是我个人观点,并不代表Chia公司的想法和意见。
在本文中,我将提出一项提案,以完全去中心化的方式将人类可读的名称与Chia区块链上的单例(singleton)关联起来。由于我不再是一名开发人员,所以无法自己有效地实现这些想法。尽管如此,我还是很了解 Chia 技术,我希望这篇文章为人们实现一个公平、高效、完全去中心化的域名注册机构提供一个起点。
  • 首先,目标是什么?这样的注册表能实现什么目的?
  • 任何人都应该能够为自己拥有的东西注册一个域名
  • 任何人都不能为自己不拥有的东西注册域名
  • 任何个人或团体不得阻止他人注册域名,也不得强行使用已经注册的域名
  • 注册域名肯定需要一些费用
  • 任何个人或封闭的团体都不应获利
  • 注册表不应依赖于任何特定个人或团体的持续维护或支持
  • 当不再需要某个域名时,应该有一些激励措施来释放该v
  • 一定要有办法可以转移域名
  • 必须有一种有效的方法来读取域名注册表的当前状态并检测更改
  • 必须有一种有效的方法来证明链上和链下域名的所有权
  • 理想情况下,应该有一种方法来嵌套域名注册表来创建域名空间
  • 理想情况下,应该有一种方法来创建许可的域名空间
  • 理想情况下,应该有一种方法来支持完全去中心化的 TailDatabase
考虑到这些目标,解决方案会是什么样子?首先,它需要是一个完全链上、无需许可的协议,因为任何中心化解决方案都将使服务提供商能够选择要满足哪些请求,从而受到审查。其次,需要有开源工具可与该协议交互,以便钱包可以集成必要的功能。
这是我希望实现的用户体验:
  • 用户决定为单例创建一个域名。例如,将域名与存储在 DataLayer 表中的应用程序(“chapp”)相关联。或者将域名与 DID 相关联。

  • 用户编写将域名添加到区块链的请求,其中包括所请求的域名、为保护该域名而持有的 XCH 存款以及为记录该域名的人提供的 XCH 提示。要创建域名,他们需要证明将被命名的单例的所有权。

  • 此后的某个时刻,有人会看到有几个未完成的请求,并将使用链上请求来更新链上注册表,并接受为此提供的提示。

  • 钱包将能够检测注册表单例的更新,查看注册表的更新方式,并将相同的更新应用于注册表的内部副本。

  • 稍后,当用户决定完成该域名时,他们将向链写入另一个请求以删除该域名并收回押金。他们将再次提供拥有单例的证明。他们将再次提供一个提示,即不久之后的某个时刻,有人将执行请求并接受提示。

我真的认为这对用户来说可以这么简单。
拟议实施概述:
通过图表描述一切都更容易理解。我希望这适用于像这样的文本密集图表:

接下来的技术描述部分更详细地讨论了我设想的上述所有内容如何工作。之后,我们进入一些更有趣的话题,例如:
  • 域名空间,例如“fizpawiz.chia”
  • 许可的域名空间,域名空间管理员可以在其中分配域名
  • 最后,一种完全去中心化的 TailDatabase 方法(!!!)
在本文末尾,我还列出了一些悬而未决的问题,其中大多数都提出了解决方案,但我希望获得有关这些问题的反馈。

技术说明:

接下来是(我希望是!)对拟议协议的清晰描述,可以对其进行审查以准确了解其工作原理。希望读者能够评估所提出的解决方案的可行性和安全性,如果看起来不错,请将其用作实施的模板。至少可以说,用英语清楚地描述代码是一项挑战,而且我确信我犯了一些小错误,但我认为基本技术是合理的。
技术描述确实有点详细。如果您现在没有时间了解详细信息,请跳到后面的一些部分,了解如何读取和使用域名注册表、如何创建嵌套域名空间以及如何应用相同的通用方法到TailDatabase。
首先,我认为非常清楚我使用的术语是有用的:
  • 存款金额:当前预留域名所需的金额。匹配当前因发现区块而奖励的 1/8 代币数量(减半时会减少)
  • 小费金额:支付给实际构建更新域名表的支出的人员的金额。
  • 域名:是一个名称,必须是原子级,可能需要其他限制(参见下面的“开放问题”)。
  • 目标单例:用域名引用的单例。请注意,这些不必是 DID,而可以是任何单例:DataLayer、NFT 等。
  • Launcher id:每个单例都由用于创建第一代单例的代币 ID 来标识。在单例的世代中,启动器 ID 永远不会改变。
  • 域名记录:域名、目标单例启动器id、充值金额
  • 域名表:域名记录表
  • 域名表默克尔根:当域名表表示为默克尔树时,这是存储在链上的该树的根
  • 操作:“插入”、“删除”或“旋转”
  • 请求硬币:由参与者提交操作请求而创建的币,其中包括域名、要执行的操作和小费金额等。
  • 同级转移:当提交两个请求硬币以实现转移时,一个删除域名,另一个使用不同的单例启动器 ID 再次插入它,然后每个请求硬币将另一个请求硬币视为其同级转移(Tansfer sibling)。
  • 押金退款接收地址:删除域名时押金退款应发送至的地址。
  • 临时硬币:在这种情况下,这是一种临时硬币,需要目标单例的声明才能花费,这是创建有效请求硬币的唯一方法。
  • 操作记录:操作记录将包括域名记录、要执行的操作、传输兄弟代币 ID 以及柯里化到请求代币中的其余参数的哈希值。如果“插入”,则还包括先前和后续记录的表记录(按域名排序)以及每个记录的默克尔路径。如果“删除”,则还包括要删除的表记录的merkle路径。如果“旋转”,则包括两个连续记录的表记录和默克尔路径,其中路径的长度至少相差两倍。
  • 域名注册表单例:托管域名表的单例
  • 执行人:实际构造并提交域名单例花费以更新域名表的参与者。可以是任何人。
  • 执行人接收地址:支付小费的执行人的接收地址。
硬币:

临时硬币。请求更新域名注册表涉及两种代币:临时硬币和请求硬币。短暂的硬币有一个固定的谜题,域名为单例启动器 ID,这使得它很容易在链上找到。当花费临时币时,解决方案需要目标单例启动器 ID、目标单例 mod 参数、请求的域名、操作(仅限“插入”、“删除”或“旋转”)、转账同级、存款退款接收地址、小费金额 ,当前区块高度和它自己的代币ID。如果操作是“插入”,硬币将验证请求的域名是否有效。如果“插入”,将确认给定区块高度的存款金额是正确的,并且将使用assert_height_absolute来确认给定区块高度不是将来的。它将创建一个条件,以断言来自临时代币的代币 ID、域名单例启动器 ID、请求的域名、操作、转账同级、存款退款接收地址和小费金额的目标单例的谜题公告。这可确保请求者拥有目标单例,并且请求参数不会被恶意农民更改。它将创建一个请求币作为唯一的孩子。临时硬币和请求硬币的硬币金额必须是存款金额(如果“插入”操作)和小费金额的总和。临时币将发出一个assert_ephemeral条件,以确保它在链上记录时始终有一个子代。

请求硬币。请求币将具有域名单例启动器 ID、目标单例启动器 ID、请求域名、操作、转移兄弟、存款退款接收地址、小费金额、当前块高度和祖父母币 ID。它将有两种支出模式:中止 并执行。

中止模式:当请求者选择中止时,请求币将和解决方案中的目标单例mod参数一起使用。它将断言该代币的 ID 的谜题公告,并使用柯里化的启动器 ID 从单例中“中止”,并创建一个带有存款和小费金额的子代币,作为单例可以领取的“支付给单例”代币。

执行模式:当执行者花费请求币执行请求时,该币将接受解决方案中的域名表merkle root。它将发出一个条件,断言其母代币具有短暂的代币谜题,并且其自身的金额是给定小费金额和当前存款金额的总和。它将断言来自该硬币的硬币 ID 的域名单例的谜题公告。它将创建一个带有消息“exec”的谜题公告。如果传输同级不为零,则请求币将断言该币 ID 的并发支出。如果操作是“删除”,则将按照要退款的存款金额创建一个子代币,并将其分配给给定的存款退款接收地址。如果操作是“插入”,则不会创建子硬币。

域名单例。每个域名注册表都是一个单例,并且具有域名表的柯里化根哈希、标准交易 mod 哈希和请求币 mod 哈希。每次支出时,它都会接受执行者公钥、小费总额和解决方案中的操作记录列表。花费币至少需要10条动作记录,所有动作记录必须按域名和动作排序,并且必须是唯一的。它将使用给定的公钥发出整个解决方案的 agg_sig_me 。硬币的价值是所有包含的记录的总存款金额。每代单例的价值都会根据处理的操作中的存款金额进行更新。总小费金额将以代币的形式输出到执行者接收地址,使用给定的公钥和标准交易 mod 哈希值进行计算。

对于每个“插入”记录:拼图将确认给定的先前和后续域名在给定域名之前和之后排序并且与给定域名不匹配。它将确认先前和后续域名记录的哈希值与相应 Merkle 路径的开头匹配,并确认先前和后续 Merkle 路径都正确到达当前 Merkle 根。它将识别merkle路径中最低的公共节点,并根据需要插入一个节点,然后重新计算merkle根。它将创建一个关于请求币的 coinid 的谜题公告。它将断言来自消息“exec”的请求币的谜题公告。

对于每个“删除”记录:拼图将确认给定的默克尔路径存在于默克尔树中,并且要删除的记录不具有零存款金额。它将促使peer删除该节点并重新计算merkle根。它将向 p2_singleton 发送一个 create_coin 作为存款金额,以便该单例的所有者可以收到返回的存款。最后,它将创建请求币的币 id 的谜题公告,并断言消息“exec”的请求币的谜题公告。

对于每个“旋转”记录:拼图将确认给定的域名记录与关联的默克尔路径中的叶子匹配。它还将确认 Merkle 路径正确并且 Merkle 根与当前 Merkle 根匹配。它将找到两条路径中最低的公共节点——这将是枢轴节点。它将确认第一个叶子是枢轴节点左分支的最右子节点,第二个叶子是枢轴节点右分支的最左子节点。它还将确认默克尔路径长度至少相差两倍。它将根据哪条路径较长来确定是否进行左旋转或右旋转,然后从枢轴节点的适当子节点计算新的默克尔根。

嵌套命名空间备用支出模式:为了支持级联域名注册表,域名单例应该具有备用支出模式,该模式在解决方案中接受临时代币的代币 ID、域名单例启动器 ID、请求的域名、转移同级、存款退款接收地址和 小费金额(但不是操作)并发出必要的谜题公告,以方便创建请求硬币以将当前域名注册表添加为另一个注册表中的域名单例。为了避免 DOS 攻击,这种支出模式应该断言临时币的并发支出。请注意,应该无法创建必要的公告来请求从父域名注册表中删除单例。

域名证明替代支出模式:为了支持证明域名与链上的特定单例相关联,另一种替代支出模式应该允许任何人通过包含域名记录和该域名的当前默克尔路径的解决方案来使用域名单例 记录。硬币将验证域名记录哈希值是否为 Merkle 路径中的起始值、Merkle 路径是否有效以及 Merkle 路径以当前根结束。如果是这样,它将创建一个域名和关联的单例启动器 ID 的拼图公告。请注意,Chia 区块链即将推出的单例支出聚合功能将防止其成为域名注册表单例上的 DOS 向量。

部署
要部署域名注册表,请构建一个起始默克尔树,其中两个节点是最小和最大可能的域名值、nil 目标单例启动器 ID 和零存款。使用这个默克尔根启动域名单例。
要部署嵌套域名空间,首先将嵌套域名空间部署为普通域名空间,然后使用备用支出模式创建适当的请求币,将其添加到更高级别的域名空间。
更新域名单例
任何人都可以成为执行者并更新域名单例。他们将从所要求的努力中获得提示。他们需要支付区块链费用才能从赚取的小费中获取包含在链上的更新。
执行者将通过拼图哈希来监控链上的请求币。当至少有 10 个未完成的请求时,他们可以创建域名为单例的支出。要求最少数量的请求并要求它们是唯一的,将阻止那些试图为每个操作请求使用域名单例的人。
支出包将包括所有相关的请求硬币。这些硬币不会创造产出硬币,但花费它们会释放它们的价值。然后,该值可以通过域名 singleton 捕获,用于插入时的存款,或作为小费的一部分支付给执行者。
在操作记录中构造 Merkle 路径时,请记住每个操作都会更新 Merkle 根,因此每个后续操作中的 Merkle 路径应根据前一个操作的根输出构造。
执行者应该在每次更新中包含适当的轮换,以保持树尽可能接近平衡。希望通过在开源执行器驱动程序中包含该行为,大多数执行器将有助于维持树处于平衡状态。
读取单例域名
通过钱包、链下:通过读取每一代单例提供的解决方案,可以读取当前的一组域名记录。任何有权访问完整节点的人都可以“跟随”单例以获得这一系列解决方案。
上链:域名注册表单例的第二种备用支出模式允许它创建有效域名及其关联的单例启动器 ID 的公告。很容易想象一个“付费命名”谜题,其中包含一个域名注册表启动器 ID 和域名(以及几个必要的 mod 哈希值)。要使用“付费域名”硬币,需要提供一个包含当前域名注册表根哈希和单例启动器 ID 的解决方案。只有当它可以断言域名注册表单例的声明该域名与给定的单例启动器 ID 相关联时,硬币才会成功花费。如果是这样,它将发出一个带有“向单例付款”谜题的 create_coin,该谜题只能通过来自该域名单例的公告来花费。这仅在需要转移域名的情况下才真正有用。
简明域名证明
如果您想要做的只是确认给定域名当前有效并引用特定的目标单例启动器 ID,则证明者可以提供域名记录和该域名的当前默克尔路径。验证者可以检查默克尔路径是否以给定域名记录的哈希开头,然后确认路径中的终端哈希与链上当前的根哈希匹配。
证明者还可以提供当前域名单例父代币 ID 和数量,从而提供简洁的域名证明。验证者可以根据给定的证明轻松计算域名单例的代币 ID,并轻松询问任何完整节点该代币是否存在且未花费以验证证明。
一项有用的服务是为表中每个域名提供所有这些简明域名证明的最新表格。这样,任何知道当前链上根哈希的人都可以使用该表快速检查任何域名。
可以通过覆盖所有提供的默克尔路径并确认没有间隙来审核上表的完整性,从而防止遗漏审查。
另一个有用的服务是域名查找服务,您可以使用域名进行查询,它会提供上述证明。
级联域名/域名空间:
域名空间。由于域名单例将域名与其他单例关联起来,因此我们可以轻松构造域名空间。例如,顶级域名注册表单例可以具有域名单例“chia”。与域名“chia”关联的单例也可以是域名注册表单例。在该较低级别的域名注册表中,我可以使用域名“fizpawiz”。这样,我可以使用域名“fizpawiz.chia”来指示代表“fizpawiz”并且是“chia”一部分的单例。
基于意图的域名空间。某些域名空间可用于描述所引用单例的意图。例如,顶级域名“did”可能表示下一个较低级别域名注册表中的所有条目都是 DID。与 DataLayer 表的“.dl”、NFT 的“.nft”等相同。类似地,顶级域名可能更具语义性,而不是描述性。因此“.site”可能是存储在 DataLayer 表中的基于 html 的站点。此外,“.chapp”可能是类似存储在 DataLayer 表中的应用程序。或者“.python”可能是通过 DataLayer 提供的 python 库。
您能否想象打开浏览器并输入“chia://cadt.chapp”,然后直接进入本地托管的气候行动数据信托版本,该版本的源文件已确认与 CADT 理事会提供的文件完全匹配?或者参考“chia://leftpad.js:5”以准确使用“js”域名空间中的第五代“leftpad”库Datalayer单例,由于区块链和镜像,该单例将始终可用且不可变。也许这并不是您想要的,但您其实可以模拟现有的 DNS 域名结构:“chia://www.chia.net”,这将涉及两个域名空间“net”和“chia”,并在其处有一个 DataLayer 单例。“www”域名。
关注点:循环图。域名单例可以为其自身添加一个域名,这会引入一个循环,可能导致图表的某些读者进入无限循环。域名注册机构的客户需要小心避免这种情况。
关注点:“.” 的特性。如果允许域名带有“.” 字符,那么域名可能会产生歧义。“fizpawiz.chia”可以是一个域名,也可以是级联域名。我们可能需要在域名中禁止“.” 。

需要许可的域名注册表

组织机构的域名可以创建去中心化域名注册表的一个版本,该版本不是去中心化的,而是以某种方式由特定实体拥有。这些经过许可的域名注册机构不需要临时或请求硬币,也不需要最低数量的操作记录或存款。他们将允许顶级域名的所有者选择谁在较低级别的域名注册机构中接收域名。因此,例如,“fizpawiz.chia”只能由“chia”顶级域名的所有者分配。使用这个域名的用户会知道“fizpawiz”是“chia”的成员。
“@”字符:从较高级别的域名空间转换到较低级别的需要许可的域名空间时,可以使用“@”字符。因此,您会得到“fizpawiz@chia”,其中“chia”是顶级域名空间中的域名,“fizpawiz”是需要许可的域名空间中的域名。这还需要禁止域名中出现“@”。

TailDatabase:

上述域名注册机制不适用于 TailDatabase,因为被命名的事物不是所有者可以用来请求域名的单例。
该模型中的全局 TailDatabase 将需要在铸币厂进行更新,这可以通过检测“eve”硬币来检测。没有办法直接检测“eve”币。因此,为了检测造币厂事件,我们将在造币厂中使用“eve”临时硬币。这枚硬币的唯一子代是 CAT 的pre-eve硬币。TAIL 哈希值和内部谜题也被传入,因此前一个eve硬币可以确认子硬币将是 CAT。由于pre-eve硬币不是 CAT,因此这是一次铸币活动。
pre-eve币还将需要一笔不可退还的“押金”,其计算方式与域名押金相同,以防止恶意污染CAT TailDatabase。这可以通过将该金额发送到砖块地址来完成。我认为这将需要比域名更多的金额,例如当前 7/8 的 coinbase 奖励金额。
pre-eve硬币将创建一个关于正在铸造的 TAIL 的谜题公告,以及通过解决方案传递的 CAT 域名、代码、描述、图像 NFT 启动器 ID 和尾部显示。请注意,当支出在内存池中时,恶意农民可能会更改解决方案,因此使用TailDatabase更新铸造 CAT 的驱动程序代码应确认交易后TailDatabase更新中记录了正确的元数据。
实际TailDatabase的功能与上述域名注册表类似,其中 CAT pre-eve 硬币充当请求硬币。由于铸币者是TailDatabase更新者,因此不需要提示和每次花费的最小更新次数。
“域名”将是硬币的代码,例如“XCH”,并且上述插入过程将确保它们是唯一的。临时的pre-eve硬币需要强制域名完全由可打印字符组成(没有空格或其他不可打印字符)。
请注意,我不提出任何机制来确保尾部本身是唯一的。据我所知,这需要每次插入时都需要维护一个完整的第二个 Merkle 尾树,这感觉开销太大,但没有什么好处。
要使用此机制,我们需要创建一个新的 CAT 铸造工具,该工具将在铸造时更新TailDatabase
我们需要用现有 TailDatabase 的当前内容“播种”尾部数据库单例根哈希。
如域名所述的尾部查找服务将是一项有价值的服务。还有一个反向查找来获取为特定尾部记录的所有域名。

开放性问题:

  • 名注册表是否应该要求域名由特定字符集中的字符组成?如果是这样,是否会排除某些人群?

  • 我认为我们应该禁止使用某些字符,例如“.”、“@”、“:”、“/”和“!”。可能还有其他一些,比如引号和各种大括号。也许域名注册表应该只允许字母数字?我们如何有效地检查链上的字母数字与符号?特别是在扩展字符集以更加包容全球语言方面?

  • 案例问题可能是个问题。许多人会认为“fizpawiz”和“Fizpawiz”指的是同一个人。有没有一种方法可以有效地检查域名是否全部小写?或者上层,都无所谓。我们只需要确保没有意外或恶意创建的域名仅在大小写上与其他域名不同。对此的一个担忧:如果我没记错的话,一些本地使用非拉丁字母的语言的罗马化将大写和小写字母视为代表母语中的不同字符。因此,忽略大小写奇怪地限制了在这些罗马字母中正确表达域名的能力。我不知道如何解决这个问题。

  • 名注册表是否应该尝试阻止同一目标单例以多个域名出现?我不这么认为。我认为这个问题不值得解决,因为它需要第二个默克尔树来确保目标单例启动器 ID 的唯一性。

  • 我认为没有任何方法可以防止抢注拼写错误。允许的字符集越大,情况就会变得更糟。这是一个真正令人担忧的问题,但允许任何人审查域名注册是一个滑坡。我想建议,作为一个潜在的解决方案,任何显示域名的用户界面都以单例启动器 ID 的LifeHash为前缀。

  • 出于同样的原因,我认为没有任何方法可以监管冒犯性的域名。防止审查包括忍受你不喜欢的事情。

  • 我认为没有任何方法可以防止域名抢注。一旦有人拥有了这个域名(例如“Microsoft”,由一些不隶属于微软的人拥有),就没有办法把它从他们手中夺走。那挺好的。有时它会非常令人不安。

  • 是否应该有一个过期机制?我会立即说不,因为我们不想在没有通知的情况下拿走人们的东西,而且我们没有办法通知他们。瞭望塔可以提供帮助,但这提供了一个攻击媒介,瞭望塔操作员可以恶意忽略通知来劫持域名。但是,不过期的域名会使顶级域名空间容易受到许多长期被遗忘且永远无法恢复的域名的污染。实际上,这可能还不错。

  • 想法:如果我们创建具有非常高存款要求的顶级域名空间,并立即引入一组具有较高存款要求的较低级别域名空间(例如“did”、“chapp”、“site”、“nft”等),会怎么样?降低存款要求以鼓励人们使用这些域名空间而不是顶级域名空间?

  • 有一种攻击,恶意农民可以从执行者那里窃取小费金额。我不知道解决方法,但只有当恶意农民实际种植名为 singleton update 的区块时,才会发生这种情况。也许这不是问题:小费不太可能很高,因此此类恶意软件流行的动力很小。

  • 最后一个悬而未决的问题:今天讨论的内容,是否应该是一个CHIP(Chia改进提案)?


    作者推特




您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存