一种基于联盟管理的高效分布式域名系统

2024-01-26邓锦禧郭泽宇田志宏

信息安全学报 2024年1期

邓锦禧,韩毅, 苏申, 郭泽宇, 李爽, 田志宏

一种基于联盟管理的高效分布式域名系统

邓锦禧1,韩毅1, 苏申1, 郭泽宇1, 李爽1, 田志宏1

1广州大学广州中国 510006

在域名解析系统中, 下级域名的命脉被上级域名所掌握, 这种中心化的管理为域名解析带来了巨大的风险。以比特币等加密货币为代表的区块链则具有去中心化的特性。随着namecoin的提出, 区块链开始被应用在命名系统和域名解析的领域, 之后的Blockstack和ENS都提出了去中心化命名系统的解决方案。其中, Namecoin和Blockstack采用了完全去中心化的命名管理方式, 产生了域名抢占问题。因此, 我们将目光转向了采用小群组投票决定域名增加和删除的联盟化管理方案。在联盟化管理方案中, 比如ENS的和超级账本的均存在交易空间太大的问题, 在区块链本身存储代价大的背景下, 存储效率将变得低下。因此, DNS系统和区块链的结合难度很大, 不仅需要保证在多变的域名存储信息中保证存储总量较小, 同时还需要针对域名解析实现高效的联盟化管理, 这使得至今仍未有一个令人满意的去中心化域名解析系统的解决方案。为此, 我们提出了ECMDNS——一个高效的基于联盟化管理的域名解析系统, 既考虑到DNS区域文件具有存储量大且变换频繁的特点, 又能在完全中心化和完全去中心化之间采取折衷方案, 并拥有较高的时空效率及较小的存储总量。我们通过区分链上链下的存储保证在多变的域名信息中保证存储总量较小; 通过群组决策投票的方式实现联盟化管理, 同时优化了Hyperledger Fabric提出的混合复制模型, 将空间存储效率优化到原本的1/16。并且仅需要花费1次分布式副本同步, 就可以完成一项由名成员背书对同一域名背书的事务, 并在联盟化管理的基础上实现区块链交易空间性能的高效性, 从而实现整体存储效率的高效性。

区块链; 域名解析系统; 联盟化管理

1 简介

域名解析系统本质上是一个分布式命名系统, 域名解析的目的是让IP地址更容易被寻址, 用户能通过一个容易记忆的域名找到其复杂的域名信息[1]。这种分布式命名系统的内容过多且难以管理, 因此现有的DNS采用了树形的中心化管理的方式, 上级域名对下级域名有完全的管理权力。但是这种中心化管理的方式会带来风险[2], 假如根域名的管理者删除某个国家根域名(ccTLD), 或者.com域名的管理者删除某国家相关的跨国企业域名, 那么被删除的域名体系都将土崩瓦解。

随着比特币这种基于P2P网络和密码学算法的分布式存储系统的提出, 区块链的概念被引入[3]。接着, Namecoin的提出说明了去中心化不仅可以应用在加密货币上, 也可以用于更广泛的命名系统[4]。由于DNS系统本质上也是一个以域名为主体的命名系统, 因此区块链能用于解决域名解析的中心化问题。

但是, 将DNS系统和区块链结合起来是非常困难的。Namecoin曾经尝试用它的区块链存储域名信息, 并创立了.bit这个去中心化域名。但是, 在处理区块链和域名信息的兼容性上, 它不能满足现今DNS系统的需求。它的域名是以先到先得的方式授权的[5], 并且每个名称都把其对应的全部内容存储在区块链上[6]。这种管理方式不仅面临着存储总量过大的问题, 更重要的是, 这是一种完全去中心化的管理方式, 先到先得的管理方式完全缺乏监管, 已经导致了严重的域名抢占问题。

由于域名解析系统的本质是命名系统, 我们也研究了一些较有名气的去中心化命名系统, 如Blockstack和ENS。Blockstack提出的多级验证结构在保证存储内容真实性的条件下大幅度缩小了去中心化命名系统的存储总量, 因为它只存储某个名字对应的数据哈希值或公钥代表, 而真实数据存储在下一级系统[7]。然而, Blockstack在解决域名授权时, 仍采用了完全去中心化的管理方式, 并没有改善缺乏监管的问题。

在实践中, 中心化和完全去中心化的方式均表现出了它们存在的管理风险。因此在设计我们的系统时考虑到了一种基于联盟化管理的方式。中心化管理是一种由一个独立实体管理系统的管理方式, 去中心化管理是由系统所有参与者或者所有参与的独立实体共同管理系统的管理方式。我们考虑的联盟化管理是一种由部分的、有限个的独立实体管理系统。其中, ENS在处理根域名时就用到了联盟化管理的方式, 它实现了一种基于多重签名智能合约的管理方式[8-9], 被授权的管理者可通过调用多重签名智能合约对根域名投票, 如果票数超过阈值, 则该域名可以被建立或删除。

然而ENS采用联盟化管理时在时间和空间上存在效率低下的问题。假如存在一个需要经过名成员背书的域名, 则需要这名成员分别发布调用这份多重签名智能合约的交易, 至少需要将份交易以PoW共识的方式同步到所有的分布式节点上。因此, 实现这样的投票背书, 需要花费次分布式副本同步, 以及在每个分布式节点上存储份交易。然而, DNS区域文件具有存储量大, 且变换频繁的特点(例如.com域名拥有1.47亿个域名, 并且区域文件至少每天更改一次[10-11])。所以, ENS投票决策带来的时空效率低下的问题, 在DNS系统中是无法接受的。

我们在深入研究DNS和区块链结合的难题后, 将需要解决的问题归结为两个。一是需要保证在多变的域名存储信息中保证存储总量较小。二是需要实现高效的联盟化管理方式。

为了解决以上问题, 我们提出了一种基于联盟管理的高效分布式域名系统ECMDNS(Efficient Consortium Management DNS)。本文不仅通过构建联盟化管理的DNS系统, 还通过使用MuSig多重签名管理, 优化混合复制模型的投票机制。

为了保证在多变的域名信息中保证存储总量较小, 我们借鉴了Blockstack中的多级存储结构, 实现了区分链上链下的存储。在区块链节点上只保存密钥信息和完整区域文件的寻址信息, 完整的区域文件则存储在可自定义的存储位置, 并用区块链节点上的密钥签名验证其正确性。

为了保证在在去中心化的系统中保持一定程度的可监管性, 又要保证其时空效率。我们调查了Hyperledger Fabric的混合共识模型, 它把共识分为两个阶段: 用于生成背书信息的预共识阶段, 以及用于以分布式副本形式复制背书结果到整个分布式系统的post共识阶段。为了实现在投票效率上的优化, 我们重点优化了预共识阶段。我们将MuSig多重签名算法应用于投票信息背书上, 相较于Hyperledger Fabric原本的解决方案而言, ECMDNS将空间存储效率优化到原本的1/16。在时间效率上, 我们仅需要花费1次分布式副本同步, 就可以完成一项由名成员对同一域名决策进行背书的事务。

本文系统可部署在任意级别的域名中, 可替代根域名、顶级域名等。由于现有中心化域名解析系统已经达到足够广泛的应用, 在具体实施时可通过逐步替代的手段。在完全替代现有系统前, 但又未发生中心化风险时, 本文系统与现有域名解析系统并存, 并以现有系统数据为准, 原有域名解析系统数据假定为本文系统数据的超集。本文系统的入口为任意用户可自行搭建的DNS服务器, 访问这些DNS服务器时, 服务器将查询本系统的DNS数据并返回给用户。

如果在发展过程中发生中心化风险, 本文系统的联盟成员可选择停止与原DNS服务器的数据同步。此时本文数据将与原服务器数据不同, 并可通过联盟化管理的方式抵御中心化风险。我们的最终目标是替代原DNS服务器, 并建立由联盟化管理的DNS存储体系。

本文系统与原域名解析系统的区别只在数据来源, 因此并不影响用户域名解析的效率。

本文的主要贡献如下:

(1) 分析了当前DNS系统和区块链结合的现状, 并总结了两者结合过程产生的难题。

(2) 实现了一种符合当前DNS数据存储量大、变换频繁的特点的去中心化的存储方法。

(3) 优化了Hyperledger Fabric的混合共识模型, 实现了一种基于MuSig多重签名算法的、高效的、可用于DNS系统与区块链结合的联盟化管理方式。

(4) 提供DNS区域文件的存储和解析。ECMDNS是一个能与现有DNS对接的、兼容性高的新型域名解析系统。

2 相关工作

我们深入调查了现有的基于区块链的域名解析系统、现有的共识系统、现有的背书策略以及现有的用户信息存储模型。我们从现有的基于区块链的域名解析系统中, 总结出了它们存在的存储冗余问题和监管性问题, 并从用户信息存储模型、共识系统、背书策略的角度深入调查和优化, 从而实现了ECMDNS——一个能解决DNS与区块链结合而带来的存储冗余问题和监管性问题的去中心化域名解析系统。

2.1 现有的基于区块链的域名解析系统

Namecoin

Namecoin是在2011年被提出的第一个基于区块链的命名系统, 并在其命名系统实现的基础上实现了域名解析。这是第一个达成有意义、唯一性(或称安全性)、去中心化三个条件的命名系统, 并实现了实时查询区块链的域名解析[4]。

Namecoin采用了“先预定、再注册”的完全去中心化的方式处理名称相关的交易, 以避免在交易发起时发生域名抢占行为。但是, Namecoin的注册方式在本质上依然是先来先服务的抢占注册, 而这还是导致了十分严重的域名抢占行为[5]。另外, Namecoin将域名相关的全部信息以json形式存储在区块链上[6], 而区块链上的信息会以分布式副本的形式存储到所有的全量节点上, 这会大幅度提高存储总量。

Namecoin是去中心化域名解析系统的先驱, 同时也给我们提出了一些关于如何实现一个去中心化域名解析系统应当考虑的问题。

Blockstack

Blockstack是一个利用区块链来增强去中心化性的命名系统。它实现了多级验证的机制, 可利用现有区块链的强大算力来缓解区块链初创时期算力不足的问题。与Namecoin不同, Blockstack没有把所有内容都存放在区块链上, 也没有成立自己的公链。它把数据分为多级存储, 每一级都会存储下一级的数据验证(比如公钥或哈希值), 它的最底层是以强大算力为保证的区块链[7,12-14]。

这样的多层验证机制, 既能保证用户可访问的资料的真实性, 又能大幅度缩减所需要的存储空间。但是, Blockstack的域名注册方式与Namecoin相似, 它没有改变先到先得的注册制度[15], 仍是完全去中心化的管理机制, 所以还是存在十分严重的域名抢占问题。

Ethereum Naming Service (ENS)

ENS是一套基于以太坊智能合约的命名系统, 它的目标是将人容易读懂的域名与人难以读懂或难以记忆的标识进行映射。比如, 它能实现DNS区域文件解析、以太坊地址解析和以太坊合约ABI解析等。

用户可以在ENS上设置一套与现有DNS相似的树形管理体系, 即下级域名需要在上级域名注册, 同时下级域名也会受到上级域名的管理。但是, ENS的上级域名对下级域名的管理可以使用智能合约, 从而达到一种不能人为干涉的去中心化管理。常见的管理方式有先到先得管理和多重签名智能合约管理等[16]。

其中, ENS根采用了一种联盟化的管理方式, 由多重签名智能合约投票来管理其唯一的顶级域名, 而投票者密钥则由以太坊社区可信任的若干成员掌握。这种管理方式在ENS这种唯一顶级域名的情况下显得非常有用, 因为它将去中心化的范围缩小到了可监管的小群体, 避免了先来先服务制度所带来的域名抢占问题。但是, 这种管理方式不适用于管理较多域名的情况。因为每次投票都需要发送一份交易, 使得它额外产生了更多次数的交易共识, 同时也需要巨大的存储开销。

针对现有系统的分析

Namecoin给出了一种用区块链存储真实域名信息的尝试, 而Blockstack和ENS则分别给出了一种基于区块链的命名系统的实现方式。从它们的工作中, 我们知晓了基于区块链的域名解析系统的可行性, 同时也知晓了将DNS与区块链结合的难度大, 其难度主要表现在以下几个方面:

需要实现高效的联盟化管理方式。Namecoin和Blockstack均采用了完全去中心化的方式实现命名系统的管理, 使得域名的申请在完全未经验证的情况下完成, 造成域名完全缺乏监管, 导致了严重的域名抢占行为。ENS通过多重签名智能合约实现一种联盟化管理, 从而实现在去中心化的情况下保持一定程度的可监管性。但是, 如果ENS需要完成一份带有N个投票对象的交易, 需要经过N次PoW共识和N次交易的提交, 它们分别带来了时间效率低和空间效率低的问题。

需要在多变的域名存储信息中保证存储总量较小。Namecoin采用了将区域文件全量存储在区块链上的形式, 这样做有很好的去中心化的效果, 因为用户能在任意一个Namecoin节点上访问到完整的区域文件。但是, 区块链是一个以分布式副本为基础的存储系统, 所有的区域文件数据及其变更信息都将存储在所有的区块链节点上。DNS区域文件不仅总量大, 而且变更频繁。例如.com域名拥有1.47亿个域名, 并且区域文件至少每天更改一次[10-11]。如果我们按照Namecoin所用到的存储方式来存储DNS区域文件, 那么会造成非常大的存储冗余。

以上两个问题致使DNS系统和区块链结合的难度大, 使得很长的时间都没有能得到广泛应用的解决方案。为了解决现有系统的问题, 我们深入研究了现有的区块链共识系统、现有的去中心化的用户信息存储模型和用于投票的背书策略存储方法。

2.2 区块链和共识系统

区块链安全的本质在于将经过交易主体背书的交易, 通过共识系统以分布式副本的形式复制到节点不能互相信任的分布式系统中, 再借由庞大的分布式系统中大量的交易副本形成更强大的背书[15]。

以比特币和以太坊为代表的多数区块链公链的链上交易仅拥有少数交易主体, 每份交易均代表若干主体向若干客体转账, 或者某个主体调用智能合约的过程。因此它们仅需要少量的交易主体的签名就可以完成该交易的背书[3,17-18]。

Hyperledger Fabric的背书过程比较复杂, 它提出的混合复制模型(hybrid replication)把共识分为两个阶段: 用于生成背书信息的预共识阶段, 以及用于以分布式副本形式复制背书结果到整个分布式系统的post共识阶段[19-20]。

在预共识阶段, 为了实现多种数字签名算法, Hyperledger Fabric需要把所有投票者的数字签名记录在交易中。但这样的背书方式和存储方式产生了不少存储冗余。

在post共识阶段, 根据对提交交易成员身份的限制, 将区块链区分成公链和联盟链, 其中公链不设成员限制, 联盟链只允许经过验证的成员提交交易[21]。由于可提交交易的成员数量不同, 区块链需要采用不同的共识算法实现拜占庭容错, 联盟链共识算法的执行效率也大幅度优于公链的共识算法[22-23]。

关于时间性能, 在同等情况下, 预共识的时间性能花费很明显比post共识阶段的少。因为预共识只需要与交易相关主体进行交互, 而post共识阶段需要与包括交易相关主体在内的所有节点交互。

2.3 现有的用户信息存储模型

主流的用户信息模型和交易模型分为两种, UTXO-base和account-base, 分别以比特币和以太坊为各自代表[24]。UTXO-base是以密钥为存储主体的多输入多输出的交易存储结构和用户信息模型, 并且每笔交易的输出不能多次使用。Account-base模型是一种以存储内容的关键信息为主体、完整存储内容为客体的交易存储结构和用户信息模型, 存储内容的关键信息的类型可以随应用场景变换而变换(如: 在以太坊里指一串160位二进制数[18]、IPFS里指数据哈希值[25]、域名解析存储里指域名)。

在基于区块链的域名解析系统中, Namecoin的用户信息存储模型基于UTXO-base实现, 它的域名信息记录在其交易输出中, 存储时以密钥为主体, 域名及域名信息为密钥的对应客体。由于域名解析系统也是以域名为主体、域名信息为客体的模型, 所以Namecoin和DNS的存储主体不一样。因此Namecoin的交易中每一个域名所能存储的信息种类十分有限, 比如在一个域名对应多个密钥的需求中, UTXO-base的存储模型将很难实现DNS信息的存储。

ENS和Blockstack的交易信息基于account-base模型存储。这种用户信息存储模型的最大好处是能够改变存储内容关键信息的定义, 从而变动存储主体, 可以实现某个主体对应更多种类的信息存储。如果我们用account-base存储模型, 并且把关键信息定义为域名, 存储内容为具体的域名区域文件数据, 这样和现有的DNS系统的存储模型是相一致的。因此, 在我们的系统中, 也采用了account-base的存储模型。

2.4 现有用于投票的背书策略的存储方法

投票是多个主体对同一客体背书的过程, 我们深入研究了ENS和Hyperledger Fabric用于投票的背书策略的生成和存储的过程。

ENS根采用了由多重签名智能合约投票来管理顶级域名, 具体执行方式是各管理者各自向管理顶级域名的智能合约发布交易, 每份交易都需要经过以太坊的共识算法以分布式副本的方式复制到所有节点[8]。

即使我国社会经济一直处于稳定增长的状态，但是如果环境污染问题无法得到及时有效的处理，那么势必会导致我国经济的发展也会因此而受到一定的影响。由于环境被严重的破坏，导致全球变暖、雾霾天气越来越多等，这些不仅会影响到我国城乡的规划和建设发展，而且还会影响到人们的日常生活。因此，在针对城市进行规划的时候，一定要意识到环境的重要性，在遵循环境保护的基础上，开展一系列城乡规划措施。只有这样做，才能够促使城乡规划发展与生态文明建设建立良好的协调发展关系。

Hyperledger Fabric基于混合复制模型提出了一种用于投票的背书策略的存储方法, 以实现联盟化管理。在发布某份带有投票记录的交易前, 先收集所有投票主体对该交易的签名, 最后由发布者将这些签名记录在交易中, 再将交易以分布式副本的形式复制到所有节点[20]。Hyperledger Fabric提出的存储方法解决了ENS共识次数过多的问题, 不管有多少个投票主体, 都只需要发布一份交易。

为了进一步解决背书策略带来的共识次数过多和签名数量过多的问题, 我们基于Hyperledger Fabric的混合共识模型, 研究了一套基于MuSig多重签名算法的、用于投票的背书策略的存储方法。

3 动机

前文提到了实现DNS系统与区块链结合的过程中, 存在两个基本问题:

(1) 需要在多变的域名存储信息中保证存储总量较小

为了解决存储总量问题, 我们实现了与Blockstack多级验证结构相似的区分链上链下的存储结构, 只将域名对应的密钥存储在链上, 而将完整的区域文件和与链上密钥对应的签名存储在链下。这样的存储方法能在多变的域名存储信息中保持存储总量较小, 因为当域名区域文件发生变动时, 我们并不需要在区块链上提交新的交易, 可以直接变动该区域文件及签名依然能保持完整的验证链, 即由区块链保证链上密钥的正确性, 由密钥和链下签名保证区域文件的完整性。区分链上链下的存储结构, 将域名具体规模与区块链系统区分开, 域名区域文件的大小只影响对应单个节点的域名服务器的效率, 而与区块链网络整体无关。

在设计区分链上链下的存储结构时, 我们设计了以域名为主体、域名信息为客体的基于account- base设计的用户信息存储模型。我们考虑到域名的数量是十分有限的, 因此在思考post共识阶段时, 设计了可基于现有的联盟链共识算法(如RAFT和PBFT)[12,26], 实现新消息在分布式副本中同步。

(2) 需要实现高效的联盟化管理方式

为了解决联盟化管理的效率问题, 我们参考了Hyperledger Fabric的共识系统, 将共识划分为预共识和post共识两个阶段[20]。其中, 预共识是生成联盟背书策略的阶段(也可以说是交易生成的阶段), post共识是将新消息复制到其他节点并验证的阶段。

与ENS实现投票监管的方式相比, 我们不仅仅优化了空间存储效率, 同时也优化了时间性能。在ENS的多重签名智能合约中, 完成一次带有N名投票成员的域名申请需要提交N次交易才能完成共识[9]。我们实现的多人投票背书策略可在一份交易中保存这N次投票得到的背书结果, 因此只需要提交1次交易即可完成共识。

我们基于以上措施实现了ECMDNS, 它分为命名系统和域名解析两部分内容。我们先实现一个去中心化的命名系统, 然后再在命名系统的基础上实现DNS资源记录存储, 最后由外部DNS服务器去读命名系统的域名信息, 从而实现域名解析。

命名系统基于区块链实现, 一共存在四种交易: 域名新建、域名弹劾、密钥更新、区域文件索引更新, 分别实现相应功能。其中, 域名新建和域名弹劾的交易利用混合复制模型结合MuSig多重签名的方式来实现多人背书, 密钥更新和区域文件索引更新这种仅需要单人背书的交易则利用Schnorr签名实现背书。

域名解析部分则是在已实现签名的命名系统中, 存储域名的相关公钥, 然后在完整的区域文件上附上其对应的签名用作验证。接着, 用离线备份的方式把区域文件存储在域名解析服务器, 并向用户提供域名解析。

4 命名系统

我们参考了Blockstack的多级存储方式, 实现了区分链上链下的存储。我们在区块链的链上存储了用于验证交易的链上密钥、用于验证链下DNS区域文件数字签名的链下密钥以及域名区域文件存储索引。接着将DNS区域文件、根据链下密钥产生的DNS区域文件数字签名存储在存储索引对应的地方[7]。

为了实现影响域名增删的功能, 我们采用了更合理的投票方式, 而不是Namecoin和Blockstack的先来先服务的方式[5,15]。我们的命名系统参考了account-base的用户模型[24], 将每一个account定义为域名。它是一个以域名为主体的存储系统中。我们可以赋予某些域名参与投票, 并通过投票决定增加或者删除其他域名的权力。

虽然我们与ENS一样应用了多重签名算法实现多人投票交易的背书, 但我们使用先收集用户投票、再发布投票结果, 而非ENS投票者各自发布投票的方法。具体来讲, 就是基于优化的混合共识模型, 设计了以多人投票作为预共识阶段的背书策略, 以此来减少post共识的次数并且降低信息的存储总量。

4.1 用户信息存储

4.1.1 身份验证

我们采用非对称密钥的方式来实现身份验证的功能。其中, 密钥空间使用了与比特币和以太坊相同的secp256k1椭圆曲线[18,29], 并运用schnorr signature scheme为运算法则[27], 在具体实现上引用了一个golang实现的比特币全量节点库[30]。我们采用的包括+和*等运算都是基于schnorr signature scheme的运算。

对于某个密钥来说, 其公钥能被所有节点访问, 而私钥则只能被极少数的拥有者访问。

4.1.2 存储模型

在域名解析系统中, 域名的变更是不频繁的, 但域名的密钥变更是频繁的。所以我们也采用了account-base的这种以account作为存储的主体, 而非UTXO-base这种以密钥作为存储主体的用户信息存储模型。在设计信息存储方法时, 我们参考了Blockstack的多级验证结构[15], 将域名信息区分为链上信息和链下信息两类。其中链上信息包含了域名、链上密钥、链下密钥和域名区域文件索引。链下信息包含完整的域名区域文件和域名区域文件签名。

图1描述了ECMDNS的数据存储分布。其中, ECMDNS的命名系统中存储链上数据, 完整的DNS数据存储在区块链以外。ECMDNS实现的account- base模型中, account指某个域名, 而内容指的是包含两种密钥和索引的链上数据。存储链上数据时, 将数据分为公开和私有两部分, 其中所有公钥和索引都属于公开信息, 它应能被所有存储节点访问, 而私钥属于私有信息, 只能被域名拥有者掌握的节点存储。

图1 ECMDNS数据存储分布图

Figure 1 ECMDNS data store distribution

其中链上命名系统为只存储gzhu.edu域名私钥的节点, 链下DNS数据存储系统可被任意用户访问

4.2 命名系统逻辑

Namecoin先来先服务的注册方式, 以及抢占注册后的名字能永久被拥有者掌握的命名系统逻辑, 导致产生了很大的监督漏洞, 最终引发严重的域名抢占问题[5]。所以, 我们需要提出一种既符合去中心化的特性, 又能保证一定程度的可监管性的的基于联盟化管理的命名系统逻辑。

我们的逻辑总共包含四项: 新建域名、更新域名密钥、更新域名索引以及弹劾域名。其中, 每种逻辑在一次执行时都只需要一份交易。在Namecoin的基础上, 我们增加了删除域名的操作, 而域名的新建和删除的方式我们参考了ENS的做法——需要通过一个小群体的投票[8]。这种折衷的方式既考虑了域名去中心化的特性, 又考虑了一定程度的可监管性。拥有者更改自身信息的决策, 当且仅当拥有者自己同意才可以更改。这样做是为了保障拥有者自身的权益, 同时也能提高系统运行的效率。

对于更新域名密钥和更新域名索引的两项逻辑, 我们使用了Schnorr签名验证[27], 也就是在交易上添加该域名的链上数据密钥对应的签名。当其他节点接收到该类型的新交易时, 仅需要验证该交易的Schnorr签名是否与拥有者的对应即可。该部分将在section 5.1中详细描述。

对于新增域名和弹劾域名这两项影响域名总量的功能, 我们都应用了预共识的形式。先在线下收集所有投票成员的MuSig成员签名, 并聚合成多重签名记录在交易上, 从而完成预共识。当其他节点接收到通过post共识传输的交易后, 只需要提取出所有投票者的公钥, 再验证即可。该部分将在section 5.2中详细描述。

图2是命名系统的名称逻辑自动机, ECMDNS的域名可以被群组投票创建和弹劾。域名在被创建和被弹劾的期间, 域名拥有者可以任意次更新对应域名的密钥和完整区域文件的索引。

4.3 交易内容

我们采用了account-base类型的交易, 每份交易的主体是某个域名, 其内容则是针对该域名的某种操作。系统的每份交易都包含了三项: 域名、交易项以及背书策略项。

其中, 交易项包含了四种交易的类型, 与前面提到的命名系统自动机一一对应, 也就是新增域名、弹劾域名、更新域名密钥和更新域名索引四项。

另外, 背书策略一共包含两种, 一种是需要单人签名的背书策略, 另一种则是需要群体决策的背书策略。其中, 新增域名和删除域名对应的是群体决策背书策略, 而更新域名密钥和更新域名索引则采用拥有者签名的背书策略。图3所对应的是交易背书策略和交易执行功能的对应关系。

图2 名称逻辑自动机

Figure 2 Name logical automata

域名可被群组决策创建和弹劾, 在创建和弹劾期间拥有者可以更新密钥和索引

图3 交易功能图

Figure 3 Transaction function diagram

每份交易在检验时, 验证者都需要先检验交易内容是否与背书策略一一对应, 然后再分别检验两项的正确性。

5 背书策略

ECMDNS的两种背书策略都是基于secp256k1椭圆曲线和schnorr signature scheme执行。因此, 两种签名能使用同样的公私密钥对签发, 也就是用于签发单人Schnorr签名的密钥, 依然能用于签发MuSig成员签名并用于投票。只是生成单重签名仅需要单个密钥或单个签名者, 而生成多重签名交易需要多个密钥或多个签名者, 并且需要经过通信来交换密钥信息。两种背书策略的目的都是生成可以验证背书者或若干背书者的交易。

则有:

5.1 单重签名背书策略

我们使用Schnorr签名来验证更新域名密钥和索引的交易。设域名拥有者的私钥为, 则拥有者公钥为:

并验证:

如果都成立则签名正确。

5.2 多重签名背书策略

图4 申请MuSig多重签名的三步交互过程

Figure 4 Three-step interactive process of applying for MuSig

随机数交换: 如果请求者收到所有投票者的随机数哈希, 则代表他们都初步同意该交易。接下来, 请求者将1发送至所有投票者。在接收到1后, 投票者先检查列表里是否存在自己先前生成的公开随机数哈希。如果存在, 投票者则将1存储在本地, 并将R返回给请求者。之后, 请求者将所有投票者对应的R记录在本地, 并令列表2:

如果随机数检验结果匹配, 请求者则将2发送至所有投票者。

所有投票者再各自检验1和2是否匹配, 接着各自计算聚合随机数:

最后投票者各自向请求者返回成员签名s。请求者得到所有成员签名后, 计算聚合签名:

并验证:

是否成立, 如果成立则签名正确。

5.3 投票法则

投票法则指生成多重签名算法过程中, 投票者决定是否配合请求者完成多重签名背书策略的法则。在新增域名或删除域名的投票法则中, 本应当由用户自行设计投票法则。但考虑到现有的去中心化域名解析系统中, 还没有投票法则的设计, 因此我们给出一种实际应用中, 所使用的投票法则的设计方案。

现有的基于联盟化管理投票方案中, ENS用多重签名智能合约的方式实现实时的去中心化的票数统计, 每个用户能随时调用多重签名智能合约更改自己的选票。本文所实现的联盟化管理的背书策略与Hyperledger Fabric都基于混合共识模型实现, 两者的投票都需要一次性获取所有投票者的选票。因此本文系统应在投票申请发起时, 投票者应该要在由网络时延决定的短时间内, 完成对某个域名的决策。

因此, 我们要求所有投票者均实现了能短时间做出决策的方案。假定了所有投票者都有自己的人工审核机制, 在生成多重签名背书策略前, 请求者需要将需要执行的交易发布至投票者完成人工审核。若人工审核通过, 投票者则在服务器中记录下该交易的哈希值, 并向请求者返回使用该投票者链上密钥签署的数字签名, 保证不可抵赖。在投票者接收到某个请求者发来的交易时, 查看数据库是否存在该交易的哈希值, 就能知道是否有通过线下人工审核, 并作出是否投票的判断。

该投票法则仅作为设计参考, 实际投票法则应该又投票者自定义。

5.4 交易的生成和执行

无论何种交易, 它的生成都经历过读取本地数据库、编写交易内容、根据交易类型编写背书策略并执行post共识。每个共识节点接收新交易时, 都需经过先检验背书策略、再写入数据库的过程。所有交易内容的生成所依赖的数据都来自链上的公开数据库, 而背书策略的生成会依赖非公开数据库里存放的私钥信息。

系统的交易生成流程如图5所示。在交易生成时, 我们需要先确定所需要操作的域名和交易执行的具体操作, 接着根据交易执行的操作选择需要的背书策略。如果交易要执行的操作需要用到单重签名背书策略, 则读取该域名对应链上私钥写入Schnorr签名; 如果交易要执行的操作需要用到多重签名背书策略, 则请求者需要将交易发送至所有投票者来请求多重签名, 并依据投票者信息以及多重签名生成背书策略项, 将背书策略项写入交易中。然后发起post共识, 直到所有接收者更新自身状态。

图5 交易生成流程图

Figure 5 Transaction generation flowchart

图6 交易验证流程图

Figure 6 Transaction validation flowchart

系统的交易验证流程如图6所示。当某节点在post共识过程中接收到一份新交易时, 需要先检验背书策略类型和交易的操作类型是否匹配。如果交易使用了单重签名的背书策略, 则需要读取域名拥有者公钥, 检验交易上的Schnorr签名与域名拥有者是否匹配; 如果交易使用了多重签名的背书策略, 则先检验签名成员和身份是否符合要求, 若符合则读取所有签名者公钥, 检验MuSig多重签名与这些签名者的公钥是否匹配。若匹配, 仍需要检验交易的操作是否符合命名系统逻辑, 比如域名在创建时是否已存在该域名、域名删除时该域名是否存在。如果其中一项检查不通过, 则检查会中断, 该交易就不能通过检验。

6 DNS信息存储

在执行一次DNS查询时, 用户一般是以标准的DNS请求访问某递归服务器, 然后递归服务器通过迭代查询按照树形解析的方式由根开始直到查询到目标的IP地址。ECMDNS本质上是一个扁平化的查询系统, 它不存在现有系统的树形结构, 所以它可以实现去中心化的单层域名解析。ECMDNS的命名系统以去中心化的方式存储了每个域名所对应的完整区域文件的索引以及其链下验证密钥。ECMDNS的DNS存储操作根据操作者主要分为两种: 拥有者操作和解析者操作。

拥有者操作: 拥有者的定义是某个域名拥有其链下私钥的实体, 它需要在不改变区块链链上数据的情况下更改DNS区域文件。在命名系统中存储了该域名对应的索引, 并且该索引是公开的。拥有者需要将该域名对应的完整域文件, 以及其使用域名链下私钥生成的区域文件的Schnorr签名一同存放在该索引对应的位置, 并且该区域文件需要符合DNS区域文件的格式[34]。因此, 拥有者需要使用链下私钥生成该区域文件的Schnorr签名, 并将该签名和区域文件存储在其对应索引的位置, 其签名的方法与第5.1章提到的单重签名的生成及验证方法相同。

解析者操作: 解析者是任何能通过某域名索引, 能够访问并得到其完整区域文件和签名, 并能使用其链下公钥验证签名正确性的实体。解析者面向的是广大用户, 它需要以标准的DNS请求和答复的方式与用户交互[34]。ECMDNS所采用的方式是服务器定时访问命名系统, 得到其关注的域名索引和公钥, 得到其对应的区域文件和签名, 最后使用链下公钥验证签名的正确性。如果知晓该区域文件是由拥有者发布的, 解析者则将区域文件离线复制至本地DNS服务器中, 使得外网用户可以用原有的方式访问DNS服务。

Namecoin使用的是将完整文件存储在链上的方式, 并开发了可实时根据接收到的DNS请求读取节点信息的Namecoin-DNS[35]。我们认为这样的存储方式在域名区域文件较大时, 链上存储总量太大。由于区块链链上空间存储代价太大, ECMDNS选择了区分链上链下的存储方式。

但这样的方式相比Namecoin而言不能保证区域文件的去中心化, 所以额外添加了区域文件签名用于验证拥有者。因此我们能在区块链存储总量较小的条件下完成分布式授权。同时, 我们认为DNS服务器的访问量会比区块链节点的访问量大, 如果使用实时访问的方式会增加区块链节点的负担, 因此采用了离线DNS区域文件的方式存储。

7 应用及分析

7.1 应用

我们使用了raft作为post共识部分的共识算法[12], 实现了整个完整的系统, 并部署在若干服务器中, 每台服务器都模拟一个raft共识节点。在我们实现的raft共识算法中, 每份交易都会经过由若干节点投票。若票数过半则更新当前状态, 投票原则是检验交易在当前数据库中的正确性。我们使用了go 1.14实现了每个共识节点的逻辑, 并将每个共识节点部署在一台服务器上, 服务器之间以星形拓扑连接, 单台服务器配置包括操作系统Ubuntu 18.04、单核CPU OctaCore Intel(R) Xeon(R) Silver 4116 CPU @ 2.10GHz、1G内存、50G硬盘。由于用到计算资源比较多, 因此我们把实验环境部署在鹏城实验室的靶场上。

实现raft算法时, 我们侧重考虑了两个重要方面,领导者选举和新消息投票传递。领导者选举是我们实现主节点选举的过程, 它在初始化及原主节点失效时发生。我们在所有节点中内置了时钟, 当时钟归零则判定为超时。其中, 主节点心跳包、候选者请求等都可将时钟重置为随机的3～6s, 而成功选举为候选节点可将时钟重置为10～15s, 并且每0.5s检测一次是否超时。

当需要发起新消息时, 主节点每0.5s向全部节点广播最新的交易或者广播待更新交易的投票请求。如果收到一半以上节点投票, 则更新自身状态, 并在心跳包中将最新状态扩散出去。在实验中, 为了让尽可能多的节点都按序收到最新状态, 我们强迫主节点至少完成两次广播后才可以发起新一轮的新交易投票。

7.2 交易空间性能分析

空间性能分析包括两项, 一般性分析和实例分析。在一般性分析中, 我们主要研究系统在联盟成员增加时的可扩展性; 实例分析中, 我们主要研究系统在实际运行时, 所产生的具体开销是否合理。

7.2.1 一般性分析

在一般性分析中, 我们假设域名长度为, 私钥长度为公钥和签名长度为2, 域名完整区域文件索引长度为, 单位为字节。每份交易中都包含域名、交易项、背书策略项三项, 其中交易项和背书策略项的对应关系已在4.3章提及。其中, 我们用1字节的空间表示交易类型和背书策略类型。

使用单重签名背书策略的交易共包含两种类型, 更新域名密钥、更新域名索引。

因此, 单重签名交易的大小仅与域名长度、私钥长度、域名区域文件索引长度有关。而在现有系统中, 这些项的长度都是有限的, 因此单重签名交易的空间性能可扩展性良好。

使用多重签名背书策略的交易共包含新建域名和弹劾域名两种, 由于两种交易全部的信息都记录在域名以及交易类型种, 因此它们的交易项均只占用1字节。

7.2.2 实例分析

以域名gzhu.edu.cn为例, 设其区域文件索引为“http://202.192.18.1/public”, 简单计算可知, 域名占用空间=11字节, 域名索引占用空间=26字节。假设我们使用=32字节的私钥, 其公钥和签名均为64字节。

在单重签名背书策略的交易中, 代入一般性分析的结果, 一份更新域名密钥交易总共占用208字节, 更新域名索引的交易总共占用103字节。显然, 该存储空间占用大小的交易在合理的范围内。

在多重签名背书策略的交易中, 当域名数量较多时签名所占用的空间远大于其他信息所占用空间, 因此值大小可忽略不计。本文系统调查了.com域名数量为1.47亿个[36], 因此在对比实验中设定域名上限分别为232和264两种情况进行比较, 在密钥长度相同的情况下与超级账本所实现的累加签名预共识的方法进行比较。以下分别对256位和512位两种密钥长度分别做了实验。

当设密钥长度为定值时, 从图7和图8中均显现相同的趋势, 累加签名预共识方法所生成的交易大小远远大于域名上限分别为232和264。其中, 若将签名数量为现有的国家根数量(250个), 在256为长度的密钥前提下, 原本的累加签名预共识交易大小为15.6kB, 而上限为232个域名的MuSig预共识交易仅需要1.04kB。如果考虑可扩展性, 即便将上限扩展为264个交易也仅占用2.02kB的空间, 仍远远小于累加签名预共识的15.6kB。

图7 多重签名背书策略交易对比图(256位密钥)

Figure 7 Multi-signature endorsement strategy transaction comparison diagram (256-bit key)

图8 多重签名背书策略交易对比图(256位密钥)

Figure 8 Multi-signature endorsement strategy transaction comparison diagram (256-bit key)

若采用更安全的方式, 采用512位长度的密钥, 在同样用250个签名者的情况下。累加签名预共识交易大小为31.25kB, 而域名个数上限为232时占用仅需要1.10kB, 考虑可扩展性设定上限为264也仅占用2.08kB空间。

在以上两组对比实验中能看出, 在密钥长度相同时, MuSig预共识生成的交易比超级账本提出的混合共识模型预共识生成的交易, 在空间占用上有显著优势。并且如果以现有共250个拉丁字符格式(Latin-character) ccTLD形成一份投票交易为例, 空间占用的优势将变得更加明显。

比特币从2020年6月至2020年末的平均交易大小为471字节[37], 而一份拥有250个国家根背书的交易约占用2份比特币大小的空间, 说明使用多重签名背书策略的空间占用是合理的。而更新域名密钥交易约占用0.43份比特币平均交易大小的空间, 而更新索引交易仅占用0.21份。

在MuSig预共识中, 图6 (a)和图6 (b)中均存在相同趋势: 当域名上限1增加时, 空间都变得更大。因此, 需要在密钥长度相同情况下对比可扩展性。根据公式(18)可绘制图7。

图9 预共识交易空间比值图

Figure 9 Ratio diagram of pre-consensus trading space

由图9可看出, 在256位密钥的前提下, 在历史域名总数在1<2512时, MuSig使用预共识的方案比原有混合模型方案要好; 而在512位密钥前提下, 在历史域名总数在1<21024时, MuSig使用预共识的方案比原有混合模型方案要好; 而这个域名数量在现有可见的水平下, 是不可能达到的。

综上所述, 本文系统的交易在空间性能上是合理的, 且具有良好的可扩展性。

7.3 时间性能分析

时间性能分析主要包括两项, 第一项是针对我们系统优化的预共识阶段的时间性能分析, 第二项是整个完整实现的系统的吞吐量分析。时间性能分析的目的在于检验系统的在预共识阶段付出额外时间代价, 以及整个系统的吞吐量是否在合理。

7.3.1 预共识时间性能分析

本文测量了预共识阶段在整个共识阶段的时间占用情况。实验分为两组, 第一组包含5个共识节点, 第二组包含10个共识节点。其中第一组实验中, 每个共识节点包含20个投票者密钥; 第二组实验中, 每个共识节点包含10个投票者密钥。两组实验中, 网络都总共包含100个投票者。

实验结果如图10所示, 两组对比试验有相同趋势, 只是第二组实验中传播完成时间和同步完成时间波动比较大, 特别是同步完成时间这一项。产生波动的原因有两个: 一是数据传播量会随着节点数量增多而增多, 二是同步完成的条件会随着节点数量增多而变得苛刻, 两者都会造成更大的波动。

图10 预共识时间性能分析

Figure 10 Pre-consensus time performance analysis

但即使产生了这样的波动, 依然显示出相同的趋势。两组实验的预共识完成时间都随着域名数量的增加呈线性增加的趋势, 而且即使在投票成员数量到达100的条件下, 预共识时间在同步完成时间中占比依然较小。这是由于预共识过程中, 只有第一次接收的时候需要读取当前数据库, 之后的投票阶段都能很快的完成, 运算也只是无状态的椭圆曲线运算。而post共识是有状态的, 实验中的raft算法需要等待每一项工作完成才能进入下一阶段的运算, 比如我们会强迫主节点需要广播两次当前状态才能发起下一次的投票, 这个过程是必要的也是耗时的。在我们的实验中, post共识的时间体现在同步完成时间与发送完成时间之差, 实验结果也显示它们的差异比较大。

实验说明了我们成功地改进了hyperledger fabric的混合复制模型, 基于MuSig的预共识阶段产生的额外时间代价在可接受范围内。

7.3.2 吞吐量分析

我们测量了区块链网络的吞吐量, 得到若干交易所需要的同步时间, 从而知晓ECMDNS在共识上的时间优化。ENS是通过多重签名智能合约实现了投票, 每次成员投票都需要发布一份交易完成, 也就是执行一次post共识。因此, 我们需要知道执行多次post共识所花费的时间, 与前面预共识时间对比就可以知道优化了多少。

实验结果如图11所示, 在两组测试中, 完成传播或同步的序号几乎与对应时间成线性关系, 而且相同的序号对应的传播完成时间和同步完成时间之差比较接近, 这个时间也与前面测得post-consensus时间相似。再次说明了预共识的时间性能分析中的即使同步时间波动较大, 也是合理的。

8 结论和未来工作

我们提出了ECMDNS, 一个具基于联盟化管理的、存储总量较小的、共识次数较少的域名解析系统。首先, 我们采用了区分链上链下存储结构, 解决了域名区域文件过大导致区块链链上节点存储总量过大的问题; 接着, 我们采用混合复制模型并做了优化, 在预共识阶段应用MuSig多重签名算法, 解决了投票共识次数过多的问题, 并进一步减少了链上节点存储总量。在前两者的基础上, 我们实现了基于联盟化管理的命名系统逻辑, 为ECMDNS加入了群组投票和删除的功能, 实现了在去中心化条件下的一定程度的可监管性。

图11 吞吐量分析

Figure 11 Throughput analysis

我们给出了ECMDNS的一种具体应用方法, 在可自定义的post共识阶段中采用raft算法(以及投票法则), 并分析了空间和时间性能。实验结果显示, 我们采用MuSig多重签名算法将原本混合共识模型的交易优化到原来的1/16, 并且时间成本比较小。此外, 我们减少了投票交易的共识次数, 大幅度减少了决策完成的时间。

未来, 我们将进一步优化ECMDNS。我们将继续针对去中心化DNS系统研究存储优化方案。另外, 我们也将进一步研究共识算法方面的问题。本文我们主要优化了混合共识模型中预共识过程, 在post共识过程甚至在混合共识模型本身仍有不少优化的空间。未来的ECMDNS将会进一步和现有DNS系统结合, 其实现会逐渐透明化。

致谢国家重点研发计划项目(No. 2018YFB1800701); 广东省重点研发计划项目(No. 2020B0101090003); 国家自然科学基金项目(No. 61902083, No. 62172115, No. 61976064), 广东省高校创新团队(No. 2020KCXTD007)与广州市高校创新团队(No. 202032854), 以及广州市市校基础研究计划联合资助项目(No. 202102010445)。

[1] Mockapetris P V, Dunlap K J. Development of the Domain Name System[J]., 1995, 25(1): 112-122.

[2] Zhang Y, Xia Z D, Fang B X, et al. An Autonomous Open Root Resolution Architecture for Domain Name System in the Internet[J]., 2017, 2(4): 57-69. (张宇, 夏重达, 方滨兴, 等. 一个自主开放的互联网根域名解析体系[J]., 2017, 2(4): 57-69.)

[3] Nakamoto S. Bitcoin: A peer-to-peer electronic cash system[J]., 2008: 21260.

[4] Name coin official website[EB/OL]. https://www.namecoin.org/. 2020.12/2020.12.

[5] Kalodner H A, Carlsten M, Ellenbogen P, et al. An Empirical Study of Namecoin and Lessons for Decentralized Namespace Design[A]. 14th Annual Workshop on the Economics of Information Security[C]. 2015:1-23.

[6] Namecoin. Namecoin Core integration/staging tree[DB/OL] https://github.com/namecoin/namecoin-core,2022.2/2022.3.

[7] Ali M, Shea R, Nelson J, et al. Blockstack: A new decentralized internet[J]., 2017:1-22.

[8] Who-owns-the-ens-rootnode-what-powers-does-that-grant-them. [DB/OL]https://docs.ens.domains/frequently-asked-questions, 2022.3/2022.5.

[9] Praitheeshan P, Pan L, Yu J S, et al. Security Analysis Methods on Ethereum Smart Contract Vulnerabilities: A Survey[EB/OL]. 2019: arXiv: 1908.08605. https://arxiv.org/abs/1908.08605.pdf.

[10] InterNIC,DNS root zone file [DB/OL] https://www.internic.net/ domain/root.zone, 2022.3/2022.3.

[11] Van Rijswijk-Deij R, Chung T, Choffnes D, et al. The Root Canary: Monitoring and Measuring the DNSSEC Root Key Rollover[C]., 2017: 63-64.

[12] Ongaro D, Ousterhout J. In Search of an Understandable Consensus Algorithm[C]., 2014: 305-320.

[13] Nelson J, Ali M, Shea R, et al. Extending existing blockchains with virtualchain[A] Workshop on distributed cryptocurrencies and consensus ledgers[C]. 2016.

[14] Blockstack document[DB/OL]. https://docs.blockstack.org/build- apps/references/bns. 2020.12/2020.12.

[15] Ali M, Nelson J, Shea R, et al. Blockstack: A Global Naming and Storage System Secured by Blockchains[C]., 2016: 181-194.

[16] Ethereum naming service document. https://docs.ens.domains/. 2020.12/2020.12.

[17] Lu H, Jin C J, Helu X H, et al. DeepAutoD: Research on Distributed Machine Learning Oriented Scalable Mobile Communication Security Unpacking System[J]., 2022, 9(4): 2052-2065.

[18] Wood G. Ethereum: A secure decentralised generalised transaction ledger[J]., 2014, 151(2014): 1-32.

[19] Hyperledger fabric sdk document [DB/OL]. https://hyperledger. github.io/fabric-sdk-node/release-1.4/tutorial-sign-transaction-offline.html. 2020.12/2020.12.

[20] Androulaki E, Barger A, Bortnikov V, et al. Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains[C]., 2018: 1-15.

[21] Kang J W, Xiong Z H, Niyato D, et al. Incentivizing Consensus Propagation in Proof-of-Stake Based Consortium Blockchain Networks[J]., 2019, 8(1): 157-160.

[22] Vukolić M. The Quest for Scalable Blockchain Fabric: Proof-of-Work Vs. BFT Replication[C]., 2016: 112-125.

[23] Tian Z H, Li M H, Qiu M K, et al. Block-DEF: A Secure Digital Evidence Framework Using Blockchain[J]., 2019, 491: 151-165.

[24] Zahnentferner J. Chimeric ledgers: Translating and unifying UTXO-based and account-based cryptocurrencies[J]., 2018.

[25] Benet J. Ipfs-content addressed, versioned, p2p file system[J]. arXiv preprint arXiv:1407.3561, 2014.

[26] Castro M, Liskov B. Practical byzantine fault tolerance[A] 3rd OSDI [C]. 1999: 173-186.

[27] Schnorr C P. Efficient Signature Generation by Smart Cards[J]., 1991, 4(3): 161-174.

[28] Maxwell G, Poelstra A, Seurin Y, et al. Simple Schnorr Multi-Signatures with Applications to Bitcoin[J].,, 2019, 87(9): 2139-2164.

[29] Bi W, Jia X Y, Zheng M L. A Secure Multiple Elliptic Curves Digital Signature Algorithm for Blockchain[EB/OL]. 2018: arXiv: 1808.02988. https://arxiv.org/abs/1808.02988.pdf.

[30] An alternative full node bitcoin implementation written in Go [DB/OL] https://github.com/btcsuite/btcd. 2020.12/2020.12.

[31] Johnson D, Menezes A, Vanstone S. The Elliptic Curve Digital Signature Algorithm (ECDSA)[J]., 2001, 1(1): 36-63.

[32] Mendel F, Nad T, Schläffer M. Improving Local Collisions: New Attacks on Reduced SHA-256[C]., 2013: 262-278.

[33] Liardet P Y, Smart N P. Preventing SPA/DPA in ECC Systems Using the Jacobi Form[M].. Berlin, Heidelberg: Springer Berlin Heidelberg, 2001: 391-401.

[34] Mockapetris P V. Domain names-concepts and facilities[J]., 1987: 1-55.

[35] Namecoin. Ncdns [DB/OL] https://github.com/namecoin/ncdns, 2020.1/2022.3.

[36] Iana, root zone database [DB/OL] https://www.iana.org/domains/ root/db, 2020.12/2020.12.

[37] Tradeblock, bitcoin historical data [EB/OL]https://tradeblock.com/ bitcoin/historical/6h-f-tsize_per_avg-01101, 2020.12/2020.1.

An Efficient Decentralized Domain Name System Based on Consortium Management

DENG Jinxi1, HAN Yi1, SU Shen1, GUO Zeyu1, LI Shuang1, TIAN Zhihong1

1Guangzhou University, Guangzhou 510006, China

In the domain name resolution system, the lifeblood of the subordinate domain name is controlled by the superior domain name. This centralized management brings great risks to domain name resolution. Blockchain, represented by cryptocurrencies such as Bitcoin, is decentralized. With the proposal of Namecoin, blockchain began to be applied in the field of naming system and domain name resolution, and then Blockstack and ENS proposed solutions of decentralized naming system. Among them, Namecoin and Blockstack adopted a completely decentralized naming management method, which caused the problem of domain name being squatted. Therefore, we turned our attention to consortium management that uses small group voting to decide the addition and deletion of domain names. Consortium management method such as ENS and Hyperledger Fabric, there is a problem that the transaction storage space is too large. Under the background of the high storage cost of the blockchain itself, the storage efficiency will become low. Thus, in practical application, the combination of DNS system and blockchain is very difficult. First, it is necessary to ensure a small amount of storage in the changeable domain name storage information. The second is the need to achieve efficient consortium management for domain name resolution, which makes there is still no satisfactory solution for a decentralized domain name resolution system. Therefore, we propose ECMDNS, an efficient domain name resolution system based on consortium management, which not only takes into account the characteristics of large storage and frequent transformation of DNS zone files, but also can take a compromise between complete centralization and complete decentralization, with high spatio-temporal efficiency and small storage volume. We keep the amount of storage small in the changing domain name information by differentiating the on-chain storage; in addition, the hybrid replication model proposed by Hyperledger Fabric is optimized to optimize the storage efficiency of space to 1/16 of the original. And it only takes 1 distributed copy synchronization to complete a transaction in which N members endorse the same domain name. And improve blockchain transaction space performance for consortium management, so as to optimize the efficiency of overall storage efficiency.

blockchain; domain name resolution system; consortium management

TP311

10.19363/J.cnki.cn10-1380/tn.2024.01.07

田志宏, 博士, 教授, Email: tianzhihong@gzhu.edu.cn。

本课题得到国家重点研发计划项目(No. 2018YFB1800701)资助。

2022-05-06;

2022-06-27;

2023-09-27