鄧錦禧,韓 毅, 蘇 申, 郭澤宇, 李 爽, 田志宏

一種基于聯(lián)盟管理的高效分布式域名系統(tǒng)

鄧錦禧1,韓 毅1, 蘇 申1, 郭澤宇1, 李 爽1, 田志宏1

1廣州大學(xué) 廣州 中國 510006

在域名解析系統(tǒng)中, 下級域名的命脈被上級域名所掌握, 這種中心化的管理為域名解析帶來了巨大的風(fēng)險。以比特幣等加密貨幣為代表的區(qū)塊鏈則具有去中心化的特性。隨著namecoin的提出, 區(qū)塊鏈開始被應(yīng)用在命名系統(tǒng)和域名解析的領(lǐng)域, 之后的Blockstack和ENS都提出了去中心化命名系統(tǒng)的解決方案。其中, Namecoin和Blockstack采用了完全去中心化的命名管理方式, 產(chǎn)生了域名搶占問題。因此, 我們將目光轉(zhuǎn)向了采用小群組投票決定域名增加和刪除的聯(lián)盟化管理方案。在聯(lián)盟化管理方案中, 比如ENS的和超級賬本的均存在交易空間太大的問題, 在區(qū)塊鏈本身存儲代價大的背景下, 存儲效率將變得低下。因此, DNS系統(tǒng)和區(qū)塊鏈的結(jié)合難度很大, 不僅需要保證在多變的域名存儲信息中保證存儲總量較小, 同時還需要針對域名解析實現(xiàn)高效的聯(lián)盟化管理, 這使得至今仍未有一個令人滿意的去中心化域名解析系統(tǒng)的解決方案。為此, 我們提出了ECMDNS——一個高效的基于聯(lián)盟化管理的域名解析系統(tǒng), 既考慮到DNS區(qū)域文件具有存儲量大且變換頻繁的特點, 又能在完全中心化和完全去中心化之間采取折衷方案, 并擁有較高的時空效率及較小的存儲總量。我們通過區(qū)分鏈上鏈下的存儲保證在多變的域名信息中保證存儲總量較小; 通過群組決策投票的方式實現(xiàn)聯(lián)盟化管理, 同時優(yōu)化了Hyperledger Fabric提出的混合復(fù)制模型, 將空間存儲效率優(yōu)化到原本的1/16。并且僅需要花費1次分布式副本同步, 就可以完成一項由名成員背書對同一域名背書的事務(wù), 并在聯(lián)盟化管理的基礎(chǔ)上實現(xiàn)區(qū)塊鏈交易空間性能的高效性, 從而實現(xiàn)整體存儲效率的高效性。

區(qū)塊鏈; 域名解析系統(tǒng); 聯(lián)盟化管理

1 簡介

域名解析系統(tǒng)本質(zhì)上是一個分布式命名系統(tǒng), 域名解析的目的是讓IP地址更容易被尋址, 用戶能通過一個容易記憶的域名找到其復(fù)雜的域名信息[1]。這種分布式命名系統(tǒng)的內(nèi)容過多且難以管理, 因此現(xiàn)有的DNS采用了樹形的中心化管理的方式, 上級域名對下級域名有完全的管理權(quán)力。但是這種中心化管理的方式會帶來風(fēng)險[2], 假如根域名的管理者刪除某個國家根域名(ccTLD), 或者.com域名的管理者刪除某國家相關(guān)的跨國企業(yè)域名, 那么被刪除的域名體系都將土崩瓦解。

隨著比特幣這種基于P2P網(wǎng)絡(luò)和密碼學(xué)算法的分布式存儲系統(tǒng)的提出, 區(qū)塊鏈的概念被引入[3]。接著, Namecoin的提出說明了去中心化不僅可以應(yīng)用在加密貨幣上, 也可以用于更廣泛的命名系統(tǒng)[4]。由于DNS系統(tǒng)本質(zhì)上也是一個以域名為主體的命名系統(tǒng), 因此區(qū)塊鏈能用于解決域名解析的中心化問題。

但是, 將DNS系統(tǒng)和區(qū)塊鏈結(jié)合起來是非常困難的。Namecoin曾經(jīng)嘗試用它的區(qū)塊鏈存儲域名信息, 并創(chuàng)立了.bit這個去中心化域名。但是, 在處理區(qū)塊鏈和域名信息的兼容性上, 它不能滿足現(xiàn)今DNS系統(tǒng)的需求。它的域名是以先到先得的方式授權(quán)的[5], 并且每個名稱都把其對應(yīng)的全部內(nèi)容存儲在區(qū)塊鏈上[6]。這種管理方式不僅面臨著存儲總量過大的問題, 更重要的是, 這是一種完全去中心化的管理方式, 先到先得的管理方式完全缺乏監(jiān)管, 已經(jīng)導(dǎo)致了嚴(yán)重的域名搶占問題。

由于域名解析系統(tǒng)的本質(zhì)是命名系統(tǒng), 我們也研究了一些較有名氣的去中心化命名系統(tǒng), 如Blockstack和ENS。Blockstack提出的多級驗證結(jié)構(gòu)在保證存儲內(nèi)容真實性的條件下大幅度縮小了去中心化命名系統(tǒng)的存儲總量, 因為它只存儲某個名字對應(yīng)的數(shù)據(jù)哈希值或公鑰代表, 而真實數(shù)據(jù)存儲在下一級系統(tǒng)[7]。然而, Blockstack在解決域名授權(quán)時, 仍采用了完全去中心化的管理方式, 并沒有改善缺乏監(jiān)管的問題。

在實踐中, 中心化和完全去中心化的方式均表現(xiàn)出了它們存在的管理風(fēng)險。因此在設(shè)計我們的系統(tǒng)時考慮到了一種基于聯(lián)盟化管理的方式。中心化管理是一種由一個獨立實體管理系統(tǒng)的管理方式, 去中心化管理是由系統(tǒng)所有參與者或者所有參與的獨立實體共同管理系統(tǒng)的管理方式。我們考慮的聯(lián)盟化管理是一種由部分的、有限個的獨立實體管理系統(tǒng)。其中, ENS在處理根域名時就用到了聯(lián)盟化管理的方式, 它實現(xiàn)了一種基于多重簽名智能合約的管理方式[8-9], 被授權(quán)的管理者可通過調(diào)用多重簽名智能合約對根域名投票, 如果票數(shù)超過閾值, 則該域名可以被建立或刪除。

然而ENS采用聯(lián)盟化管理時在時間和空間上存在效率低下的問題。假如存在一個需要經(jīng)過名成員背書的域名, 則需要這名成員分別發(fā)布調(diào)用這份多重簽名智能合約的交易, 至少需要將份交易以PoW共識的方式同步到所有的分布式節(jié)點上。因此, 實現(xiàn)這樣的投票背書, 需要花費次分布式副本同步, 以及在每個分布式節(jié)點上存儲份交易。然而, DNS區(qū)域文件具有存儲量大, 且變換頻繁的特點(例如.com域名擁有1.47億個域名, 并且區(qū)域文件至少每天更改一次[10-11])。所以, ENS投票決策帶來的時空效率低下的問題, 在DNS系統(tǒng)中是無法接受的。

我們在深入研究DNS和區(qū)塊鏈結(jié)合的難題后, 將需要解決的問題歸結(jié)為兩個。一是需要保證在多變的域名存儲信息中保證存儲總量較小。二是需要實現(xiàn)高效的聯(lián)盟化管理方式。

為了解決以上問題, 我們提出了一種基于聯(lián)盟管理的高效分布式域名系統(tǒng)ECMDNS(Efficient Consortium Management DNS)。本文不僅通過構(gòu)建聯(lián)盟化管理的DNS系統(tǒng), 還通過使用MuSig多重簽名管理, 優(yōu)化混合復(fù)制模型的投票機(jī)制。

為了保證在多變的域名信息中保證存儲總量較小, 我們借鑒了Blockstack中的多級存儲結(jié)構(gòu), 實現(xiàn)了區(qū)分鏈上鏈下的存儲。在區(qū)塊鏈節(jié)點上只保存密鑰信息和完整區(qū)域文件的尋址信息, 完整的區(qū)域文件則存儲在可自定義的存儲位置, 并用區(qū)塊鏈節(jié)點上的密鑰簽名驗證其正確性。

為了保證在在去中心化的系統(tǒng)中保持一定程度的可監(jiān)管性, 又要保證其時空效率。我們調(diào)查了Hyperledger Fabric的混合共識模型, 它把共識分為兩個階段: 用于生成背書信息的預(yù)共識階段, 以及用于以分布式副本形式復(fù)制背書結(jié)果到整個分布式系統(tǒng)的post共識階段。為了實現(xiàn)在投票效率上的優(yōu)化, 我們重點優(yōu)化了預(yù)共識階段。我們將MuSig多重簽名算法應(yīng)用于投票信息背書上, 相較于Hyperledger Fabric原本的解決方案而言, ECMDNS將空間存儲效率優(yōu)化到原本的1/16。在時間效率上, 我們僅需要花費1次分布式副本同步, 就可以完成一項由名成員對同一域名決策進(jìn)行背書的事務(wù)。

本文系統(tǒng)可部署在任意級別的域名中, 可替代根域名、頂級域名等。由于現(xiàn)有中心化域名解析系統(tǒng)已經(jīng)達(dá)到足夠廣泛的應(yīng)用, 在具體實施時可通過逐步替代的手段。在完全替代現(xiàn)有系統(tǒng)前, 但又未發(fā)生中心化風(fēng)險時, 本文系統(tǒng)與現(xiàn)有域名解析系統(tǒng)并存, 并以現(xiàn)有系統(tǒng)數(shù)據(jù)為準(zhǔn), 原有域名解析系統(tǒng)數(shù)據(jù)假定為本文系統(tǒng)數(shù)據(jù)的超集。本文系統(tǒng)的入口為任意用戶可自行搭建的DNS服務(wù)器, 訪問這些DNS服務(wù)器時, 服務(wù)器將查詢本系統(tǒng)的DNS數(shù)據(jù)并返回給用戶。

如果在發(fā)展過程中發(fā)生中心化風(fēng)險, 本文系統(tǒng)的聯(lián)盟成員可選擇停止與原DNS服務(wù)器的數(shù)據(jù)同步。此時本文數(shù)據(jù)將與原服務(wù)器數(shù)據(jù)不同, 并可通過聯(lián)盟化管理的方式抵御中心化風(fēng)險。我們的最終目標(biāo)是替代原DNS服務(wù)器, 并建立由聯(lián)盟化管理的DNS存儲體系。

本文系統(tǒng)與原域名解析系統(tǒng)的區(qū)別只在數(shù)據(jù)來源, 因此并不影響用戶域名解析的效率。

本文的主要貢獻(xiàn)如下:

(1) 分析了當(dāng)前DNS系統(tǒng)和區(qū)塊鏈結(jié)合的現(xiàn)狀, 并總結(jié)了兩者結(jié)合過程產(chǎn)生的難題。

(2) 實現(xiàn)了一種符合當(dāng)前DNS數(shù)據(jù)存儲量大、變換頻繁的特點的去中心化的存儲方法。

(3) 優(yōu)化了Hyperledger Fabric的混合共識模型, 實現(xiàn)了一種基于MuSig多重簽名算法的、高效的、可用于DNS系統(tǒng)與區(qū)塊鏈結(jié)合的聯(lián)盟化管理方式。

(4) 提供DNS區(qū)域文件的存儲和解析。ECMDNS是一個能與現(xiàn)有DNS對接的、兼容性高的新型域名解析系統(tǒng)。

2 相關(guān)工作

我們深入調(diào)查了現(xiàn)有的基于區(qū)塊鏈的域名解析系統(tǒng)、現(xiàn)有的共識系統(tǒng)、現(xiàn)有的背書策略以及現(xiàn)有的用戶信息存儲模型。我們從現(xiàn)有的基于區(qū)塊鏈的域名解析系統(tǒng)中, 總結(jié)出了它們存在的存儲冗余問題和監(jiān)管性問題, 并從用戶信息存儲模型、共識系統(tǒng)、背書策略的角度深入調(diào)查和優(yōu)化, 從而實現(xiàn)了ECMDNS——一個能解決DNS與區(qū)塊鏈結(jié)合而帶來的存儲冗余問題和監(jiān)管性問題的去中心化域名解析系統(tǒng)。

2.1 現(xiàn)有的基于區(qū)塊鏈的域名解析系統(tǒng)

Namecoin

Namecoin是在2011年被提出的第一個基于區(qū)塊鏈的命名系統(tǒng), 并在其命名系統(tǒng)實現(xiàn)的基礎(chǔ)上實現(xiàn)了域名解析。這是第一個達(dá)成有意義、唯一性(或稱安全性)、去中心化三個條件的命名系統(tǒng), 并實現(xiàn)了實時查詢區(qū)塊鏈的域名解析[4]。

Namecoin采用了“先預(yù)定、再注冊”的完全去中心化的方式處理名稱相關(guān)的交易, 以避免在交易發(fā)起時發(fā)生域名搶占行為。但是, Namecoin的注冊方式在本質(zhì)上依然是先來先服務(wù)的搶占注冊, 而這還是導(dǎo)致了十分嚴(yán)重的域名搶占行為[5]。另外, Namecoin將域名相關(guān)的全部信息以json形式存儲在區(qū)塊鏈上[6], 而區(qū)塊鏈上的信息會以分布式副本的形式存儲到所有的全量節(jié)點上, 這會大幅度提高存儲總量。

Namecoin是去中心化域名解析系統(tǒng)的先驅(qū), 同時也給我們提出了一些關(guān)于如何實現(xiàn)一個去中心化域名解析系統(tǒng)應(yīng)當(dāng)考慮的問題。

Blockstack

Blockstack是一個利用區(qū)塊鏈來增強(qiáng)去中心化性的命名系統(tǒng)。它實現(xiàn)了多級驗證的機(jī)制, 可利用現(xiàn)有區(qū)塊鏈的強(qiáng)大算力來緩解區(qū)塊鏈初創(chuàng)時期算力不足的問題。與Namecoin不同, Blockstack沒有把所有內(nèi)容都存放在區(qū)塊鏈上, 也沒有成立自己的公鏈。它把數(shù)據(jù)分為多級存儲, 每一級都會存儲下一級的數(shù)據(jù)驗證(比如公鑰或哈希值), 它的最底層是以強(qiáng)大算力為保證的區(qū)塊鏈[7,12-14]。

這樣的多層驗證機(jī)制, 既能保證用戶可訪問的資料的真實性, 又能大幅度縮減所需要的存儲空間。但是, Blockstack的域名注冊方式與Namecoin相似, 它沒有改變先到先得的注冊制度[15], 仍是完全去中心化的管理機(jī)制, 所以還是存在十分嚴(yán)重的域名搶占問題。

Ethereum Naming Service (ENS)

ENS是一套基于以太坊智能合約的命名系統(tǒng), 它的目標(biāo)是將人容易讀懂的域名與人難以讀懂或難以記憶的標(biāo)識進(jìn)行映射。比如, 它能實現(xiàn)DNS區(qū)域文件解析、以太坊地址解析和以太坊合約ABI解析等。

用戶可以在ENS上設(shè)置一套與現(xiàn)有DNS相似的樹形管理體系, 即下級域名需要在上級域名注冊, 同時下級域名也會受到上級域名的管理。但是, ENS的上級域名對下級域名的管理可以使用智能合約, 從而達(dá)到一種不能人為干涉的去中心化管理。常見的管理方式有先到先得管理和多重簽名智能合約管理等[16]。

其中, ENS根采用了一種聯(lián)盟化的管理方式, 由多重簽名智能合約投票來管理其唯一的頂級域名, 而投票者密鑰則由以太坊社區(qū)可信任的若干成員掌握。這種管理方式在ENS這種唯一頂級域名的情況下顯得非常有用, 因為它將去中心化的范圍縮小到了可監(jiān)管的小群體, 避免了先來先服務(wù)制度所帶來的域名搶占問題。但是, 這種管理方式不適用于管理較多域名的情況。因為每次投票都需要發(fā)送一份交易, 使得它額外產(chǎn)生了更多次數(shù)的交易共識, 同時也需要巨大的存儲開銷。

針對現(xiàn)有系統(tǒng)的分析

Namecoin給出了一種用區(qū)塊鏈存儲真實域名信息的嘗試, 而Blockstack和ENS則分別給出了一種基于區(qū)塊鏈的命名系統(tǒng)的實現(xiàn)方式。從它們的工作中, 我們知曉了基于區(qū)塊鏈的域名解析系統(tǒng)的可行性, 同時也知曉了將DNS與區(qū)塊鏈結(jié)合的難度大, 其難度主要表現(xiàn)在以下幾個方面:

需要實現(xiàn)高效的聯(lián)盟化管理方式。Namecoin和Blockstack均采用了完全去中心化的方式實現(xiàn)命名系統(tǒng)的管理, 使得域名的申請在完全未經(jīng)驗證的情況下完成, 造成域名完全缺乏監(jiān)管, 導(dǎo)致了嚴(yán)重的域名搶占行為。ENS通過多重簽名智能合約實現(xiàn)一種聯(lián)盟化管理, 從而實現(xiàn)在去中心化的情況下保持一定程度的可監(jiān)管性。但是, 如果ENS需要完成一份帶有N個投票對象的交易, 需要經(jīng)過N次PoW共識和N次交易的提交, 它們分別帶來了時間效率低和空間效率低的問題。

需要在多變的域名存儲信息中保證存儲總量較小。Namecoin采用了將區(qū)域文件全量存儲在區(qū)塊鏈上的形式, 這樣做有很好的去中心化的效果, 因為用戶能在任意一個Namecoin節(jié)點上訪問到完整的區(qū)域文件。但是, 區(qū)塊鏈?zhǔn)且粋€以分布式副本為基礎(chǔ)的存儲系統(tǒng), 所有的區(qū)域文件數(shù)據(jù)及其變更信息都將存儲在所有的區(qū)塊鏈節(jié)點上。DNS區(qū)域文件不僅總量大, 而且變更頻繁。例如.com域名擁有1.47億個域名, 并且區(qū)域文件至少每天更改一次[10-11]。如果我們按照Namecoin所用到的存儲方式來存儲DNS區(qū)域文件, 那么會造成非常大的存儲冗余。

以上兩個問題致使DNS系統(tǒng)和區(qū)塊鏈結(jié)合的難度大, 使得很長的時間都沒有能得到廣泛應(yīng)用的解決方案。為了解決現(xiàn)有系統(tǒng)的問題, 我們深入研究了現(xiàn)有的區(qū)塊鏈共識系統(tǒng)、現(xiàn)有的去中心化的用戶信息存儲模型和用于投票的背書策略存儲方法。

2.2 區(qū)塊鏈和共識系統(tǒng)

區(qū)塊鏈安全的本質(zhì)在于將經(jīng)過交易主體背書的交易, 通過共識系統(tǒng)以分布式副本的形式復(fù)制到節(jié)點不能互相信任的分布式系統(tǒng)中, 再借由龐大的分布式系統(tǒng)中大量的交易副本形成更強(qiáng)大的背書[15]。

以比特幣和以太坊為代表的多數(shù)區(qū)塊鏈公鏈的鏈上交易僅擁有少數(shù)交易主體, 每份交易均代表若干主體向若干客體轉(zhuǎn)賬, 或者某個主體調(diào)用智能合約的過程。因此它們僅需要少量的交易主體的簽名就可以完成該交易的背書[3,17-18]。

Hyperledger Fabric的背書過程比較復(fù)雜, 它提出的混合復(fù)制模型(hybrid replication)把共識分為兩個階段: 用于生成背書信息的預(yù)共識階段, 以及用于以分布式副本形式復(fù)制背書結(jié)果到整個分布式系統(tǒng)的post共識階段[19-20]。

在預(yù)共識階段, 為了實現(xiàn)多種數(shù)字簽名算法, Hyperledger Fabric需要把所有投票者的數(shù)字簽名記錄在交易中。但這樣的背書方式和存儲方式產(chǎn)生了不少存儲冗余。

在post共識階段, 根據(jù)對提交交易成員身份的限制, 將區(qū)塊鏈區(qū)分成公鏈和聯(lián)盟鏈, 其中公鏈不設(shè)成員限制, 聯(lián)盟鏈只允許經(jīng)過驗證的成員提交交易[21]。由于可提交交易的成員數(shù)量不同, 區(qū)塊鏈需要采用不同的共識算法實現(xiàn)拜占庭容錯, 聯(lián)盟鏈共識算法的執(zhí)行效率也大幅度優(yōu)于公鏈的共識算法[22-23]。

關(guān)于時間性能, 在同等情況下, 預(yù)共識的時間性能花費很明顯比post共識階段的少。因為預(yù)共識只需要與交易相關(guān)主體進(jìn)行交互, 而post共識階段需要與包括交易相關(guān)主體在內(nèi)的所有節(jié)點交互。

2.3 現(xiàn)有的用戶信息存儲模型

主流的用戶信息模型和交易模型分為兩種, UTXO-base和account-base, 分別以比特幣和以太坊為各自代表[24]。UTXO-base是以密鑰為存儲主體的多輸入多輸出的交易存儲結(jié)構(gòu)和用戶信息模型, 并且每筆交易的輸出不能多次使用。Account-base模型是一種以存儲內(nèi)容的關(guān)鍵信息為主體、完整存儲內(nèi)容為客體的交易存儲結(jié)構(gòu)和用戶信息模型, 存儲內(nèi)容的關(guān)鍵信息的類型可以隨應(yīng)用場景變換而變換(如: 在以太坊里指一串160位二進(jìn)制數(shù)[18]、IPFS里指數(shù)據(jù)哈希值[25]、域名解析存儲里指域名)。

在基于區(qū)塊鏈的域名解析系統(tǒng)中, Namecoin的用戶信息存儲模型基于UTXO-base實現(xiàn), 它的域名信息記錄在其交易輸出中, 存儲時以密鑰為主體, 域名及域名信息為密鑰的對應(yīng)客體。由于域名解析系統(tǒng)也是以域名為主體、域名信息為客體的模型, 所以Namecoin和DNS的存儲主體不一樣。因此Namecoin的交易中每一個域名所能存儲的信息種類十分有限, 比如在一個域名對應(yīng)多個密鑰的需求中, UTXO-base的存儲模型將很難實現(xiàn)DNS信息的存儲。

ENS和Blockstack的交易信息基于account-base模型存儲。這種用戶信息存儲模型的最大好處是能夠改變存儲內(nèi)容關(guān)鍵信息的定義, 從而變動存儲主體, 可以實現(xiàn)某個主體對應(yīng)更多種類的信息存儲。如果我們用account-base存儲模型, 并且把關(guān)鍵信息定義為域名, 存儲內(nèi)容為具體的域名區(qū)域文件數(shù)據(jù), 這樣和現(xiàn)有的DNS系統(tǒng)的存儲模型是相一致的。因此, 在我們的系統(tǒng)中, 也采用了account-base的存儲模型。

2.4 現(xiàn)有用于投票的背書策略的存儲方法

投票是多個主體對同一客體背書的過程, 我們深入研究了ENS和Hyperledger Fabric用于投票的背書策略的生成和存儲的過程。

ENS根采用了由多重簽名智能合約投票來管理頂級域名, 具體執(zhí)行方式是各管理者各自向管理頂級域名的智能合約發(fā)布交易, 每份交易都需要經(jīng)過以太坊的共識算法以分布式副本的方式復(fù)制到所有節(jié)點[8]。

即使我國社會經(jīng)濟(jì)一直處于穩(wěn)定增長的狀態(tài)，但是如果環(huán)境污染問題無法得到及時有效的處理，那么勢必會導(dǎo)致我國經(jīng)濟(jì)的發(fā)展也會因此而受到一定的影響。由于環(huán)境被嚴(yán)重的破壞，導(dǎo)致全球變暖、霧霾天氣越來越多等，這些不僅會影響到我國城鄉(xiāng)的規(guī)劃和建設(shè)發(fā)展，而且還會影響到人們的日常生活。因此，在針對城市進(jìn)行規(guī)劃的時候，一定要意識到環(huán)境的重要性，在遵循環(huán)境保護(hù)的基礎(chǔ)上，開展一系列城鄉(xiāng)規(guī)劃措施。只有這樣做，才能夠促使城鄉(xiāng)規(guī)劃發(fā)展與生態(tài)文明建設(shè)建立良好的協(xié)調(diào)發(fā)展關(guān)系。

Hyperledger Fabric基于混合復(fù)制模型提出了一種用于投票的背書策略的存儲方法, 以實現(xiàn)聯(lián)盟化管理。在發(fā)布某份帶有投票記錄的交易前, 先收集所有投票主體對該交易的簽名, 最后由發(fā)布者將這些簽名記錄在交易中, 再將交易以分布式副本的形式復(fù)制到所有節(jié)點[20]。Hyperledger Fabric提出的存儲方法解決了ENS共識次數(shù)過多的問題, 不管有多少個投票主體, 都只需要發(fā)布一份交易。

為了進(jìn)一步解決背書策略帶來的共識次數(shù)過多和簽名數(shù)量過多的問題, 我們基于Hyperledger Fabric的混合共識模型, 研究了一套基于MuSig多重簽名算法的、用于投票的背書策略的存儲方法。

3 動機(jī)

前文提到了實現(xiàn)DNS系統(tǒng)與區(qū)塊鏈結(jié)合的過程中, 存在兩個基本問題:

(1) 需要在多變的域名存儲信息中保證存儲總量較小

為了解決存儲總量問題, 我們實現(xiàn)了與Blockstack多級驗證結(jié)構(gòu)相似的區(qū)分鏈上鏈下的存儲結(jié)構(gòu), 只將域名對應(yīng)的密鑰存儲在鏈上, 而將完整的區(qū)域文件和與鏈上密鑰對應(yīng)的簽名存儲在鏈下。這樣的存儲方法能在多變的域名存儲信息中保持存儲總量較小, 因為當(dāng)域名區(qū)域文件發(fā)生變動時, 我們并不需要在區(qū)塊鏈上提交新的交易, 可以直接變動該區(qū)域文件及簽名依然能保持完整的驗證鏈, 即由區(qū)塊鏈保證鏈上密鑰的正確性, 由密鑰和鏈下簽名保證區(qū)域文件的完整性。區(qū)分鏈上鏈下的存儲結(jié)構(gòu), 將域名具體規(guī)模與區(qū)塊鏈系統(tǒng)區(qū)分開, 域名區(qū)域文件的大小只影響對應(yīng)單個節(jié)點的域名服務(wù)器的效率, 而與區(qū)塊鏈網(wǎng)絡(luò)整體無關(guān)。

在設(shè)計區(qū)分鏈上鏈下的存儲結(jié)構(gòu)時, 我們設(shè)計了以域名為主體、域名信息為客體的基于account- base設(shè)計的用戶信息存儲模型。我們考慮到域名的數(shù)量是十分有限的, 因此在思考post共識階段時, 設(shè)計了可基于現(xiàn)有的聯(lián)盟鏈共識算法(如RAFT和PBFT)[12,26], 實現(xiàn)新消息在分布式副本中同步。

(2) 需要實現(xiàn)高效的聯(lián)盟化管理方式

為了解決聯(lián)盟化管理的效率問題, 我們參考了Hyperledger Fabric的共識系統(tǒng), 將共識劃分為預(yù)共識和post共識兩個階段[20]。其中, 預(yù)共識是生成聯(lián)盟背書策略的階段(也可以說是交易生成的階段), post共識是將新消息復(fù)制到其他節(jié)點并驗證的階段。

與ENS實現(xiàn)投票監(jiān)管的方式相比, 我們不僅僅優(yōu)化了空間存儲效率, 同時也優(yōu)化了時間性能。在ENS的多重簽名智能合約中, 完成一次帶有N名投票成員的域名申請需要提交N次交易才能完成共識[9]。我們實現(xiàn)的多人投票背書策略可在一份交易中保存這N次投票得到的背書結(jié)果, 因此只需要提交1次交易即可完成共識。

我們基于以上措施實現(xiàn)了ECMDNS, 它分為命名系統(tǒng)和域名解析兩部分內(nèi)容。我們先實現(xiàn)一個去中心化的命名系統(tǒng), 然后再在命名系統(tǒng)的基礎(chǔ)上實現(xiàn)DNS資源記錄存儲, 最后由外部DNS服務(wù)器去讀命名系統(tǒng)的域名信息, 從而實現(xiàn)域名解析。

命名系統(tǒng)基于區(qū)塊鏈實現(xiàn), 一共存在四種交易: 域名新建、域名彈劾、密鑰更新、區(qū)域文件索引更新, 分別實現(xiàn)相應(yīng)功能。其中, 域名新建和域名彈劾的交易利用混合復(fù)制模型結(jié)合MuSig多重簽名的方式來實現(xiàn)多人背書, 密鑰更新和區(qū)域文件索引更新這種僅需要單人背書的交易則利用Schnorr簽名實現(xiàn)背書。

域名解析部分則是在已實現(xiàn)簽名的命名系統(tǒng)中, 存儲域名的相關(guān)公鑰, 然后在完整的區(qū)域文件上附上其對應(yīng)的簽名用作驗證。接著, 用離線備份的方式把區(qū)域文件存儲在域名解析服務(wù)器, 并向用戶提供域名解析。

4 命名系統(tǒng)

我們參考了Blockstack的多級存儲方式, 實現(xiàn)了區(qū)分鏈上鏈下的存儲。我們在區(qū)塊鏈的鏈上存儲了用于驗證交易的鏈上密鑰、用于驗證鏈下DNS區(qū)域文件數(shù)字簽名的鏈下密鑰以及域名區(qū)域文件存儲索引。接著將DNS區(qū)域文件、根據(jù)鏈下密鑰產(chǎn)生的DNS區(qū)域文件數(shù)字簽名存儲在存儲索引對應(yīng)的地方[7]。

為了實現(xiàn)影響域名增刪的功能, 我們采用了更合理的投票方式, 而不是Namecoin和Blockstack的先來先服務(wù)的方式[5,15]。我們的命名系統(tǒng)參考了account-base的用戶模型[24], 將每一個account定義為域名。它是一個以域名為主體的存儲系統(tǒng)中。我們可以賦予某些域名參與投票, 并通過投票決定增加或者刪除其他域名的權(quán)力。

雖然我們與ENS一樣應(yīng)用了多重簽名算法實現(xiàn)多人投票交易的背書, 但我們使用先收集用戶投票、再發(fā)布投票結(jié)果, 而非ENS投票者各自發(fā)布投票的方法。具體來講, 就是基于優(yōu)化的混合共識模型, 設(shè)計了以多人投票作為預(yù)共識階段的背書策略, 以此來減少post共識的次數(shù)并且降低信息的存儲總量。

4.1 用戶信息存儲

4.1.1 身份驗證

我們采用非對稱密鑰的方式來實現(xiàn)身份驗證的功能。其中, 密鑰空間使用了與比特幣和以太坊相同的secp256k1橢圓曲線[18,29], 并運用schnorr signature scheme為運算法則[27], 在具體實現(xiàn)上引用了一個golang實現(xiàn)的比特幣全量節(jié)點庫[30]。我們采用的包括+和*等運算都是基于schnorr signature scheme的運算。

對于某個密鑰來說, 其公鑰能被所有節(jié)點訪問, 而私鑰則只能被極少數(shù)的擁有者訪問。

4.1.2 存儲模型

在域名解析系統(tǒng)中, 域名的變更是不頻繁的, 但域名的密鑰變更是頻繁的。所以我們也采用了account-base的這種以account作為存儲的主體, 而非UTXO-base這種以密鑰作為存儲主體的用戶信息存儲模型。在設(shè)計信息存儲方法時, 我們參考了Blockstack的多級驗證結(jié)構(gòu)[15], 將域名信息區(qū)分為鏈上信息和鏈下信息兩類。其中鏈上信息包含了域名、鏈上密鑰、鏈下密鑰和域名區(qū)域文件索引。鏈下信息包含完整的域名區(qū)域文件和域名區(qū)域文件簽名。

圖1描述了ECMDNS的數(shù)據(jù)存儲分布。其中, ECMDNS的命名系統(tǒng)中存儲鏈上數(shù)據(jù), 完整的DNS數(shù)據(jù)存儲在區(qū)塊鏈以外。ECMDNS實現(xiàn)的account- base模型中, account指某個域名, 而內(nèi)容指的是包含兩種密鑰和索引的鏈上數(shù)據(jù)。存儲鏈上數(shù)據(jù)時, 將數(shù)據(jù)分為公開和私有兩部分, 其中所有公鑰和索引都屬于公開信息, 它應(yīng)能被所有存儲節(jié)點訪問, 而私鑰屬于私有信息, 只能被域名擁有者掌握的節(jié)點存儲。

圖1 ECMDNS數(shù)據(jù)存儲分布圖

Figure 1 ECMDNS data store distribution

其中鏈上命名系統(tǒng)為只存儲gzhu.edu域名私鑰的節(jié)點, 鏈下DNS數(shù)據(jù)存儲系統(tǒng)可被任意用戶訪問

4.2 命名系統(tǒng)邏輯

Namecoin先來先服務(wù)的注冊方式, 以及搶占注冊后的名字能永久被擁有者掌握的命名系統(tǒng)邏輯, 導(dǎo)致產(chǎn)生了很大的監(jiān)督漏洞, 最終引發(fā)嚴(yán)重的域名搶占問題[5]。所以, 我們需要提出一種既符合去中心化的特性, 又能保證一定程度的可監(jiān)管性的的基于聯(lián)盟化管理的命名系統(tǒng)邏輯。

我們的邏輯總共包含四項: 新建域名、更新域名密鑰、更新域名索引以及彈劾域名。其中, 每種邏輯在一次執(zhí)行時都只需要一份交易。在Namecoin的基礎(chǔ)上, 我們增加了刪除域名的操作, 而域名的新建和刪除的方式我們參考了ENS的做法——需要通過一個小群體的投票[8]。這種折衷的方式既考慮了域名去中心化的特性, 又考慮了一定程度的可監(jiān)管性。擁有者更改自身信息的決策, 當(dāng)且僅當(dāng)擁有者自己同意才可以更改。這樣做是為了保障擁有者自身的權(quán)益, 同時也能提高系統(tǒng)運行的效率。

對于更新域名密鑰和更新域名索引的兩項邏輯, 我們使用了Schnorr簽名驗證[27], 也就是在交易上添加該域名的鏈上數(shù)據(jù)密鑰對應(yīng)的簽名。當(dāng)其他節(jié)點接收到該類型的新交易時, 僅需要驗證該交易的Schnorr簽名是否與擁有者的對應(yīng)即可。該部分將在section 5.1中詳細(xì)描述。

對于新增域名和彈劾域名這兩項影響域名總量的功能, 我們都應(yīng)用了預(yù)共識的形式。先在線下收集所有投票成員的MuSig成員簽名, 并聚合成多重簽名記錄在交易上, 從而完成預(yù)共識。當(dāng)其他節(jié)點接收到通過post共識傳輸?shù)慕灰缀? 只需要提取出所有投票者的公鑰, 再驗證即可。該部分將在section 5.2中詳細(xì)描述。

圖2是命名系統(tǒng)的名稱邏輯自動機(jī), ECMDNS的域名可以被群組投票創(chuàng)建和彈劾。域名在被創(chuàng)建和被彈劾的期間, 域名擁有者可以任意次更新對應(yīng)域名的密鑰和完整區(qū)域文件的索引。

4.3 交易內(nèi)容

我們采用了account-base類型的交易, 每份交易的主體是某個域名, 其內(nèi)容則是針對該域名的某種操作。系統(tǒng)的每份交易都包含了三項: 域名、交易項以及背書策略項。

其中, 交易項包含了四種交易的類型, 與前面提到的命名系統(tǒng)自動機(jī)一一對應(yīng), 也就是新增域名、彈劾域名、更新域名密鑰和更新域名索引四項。

另外, 背書策略一共包含兩種, 一種是需要單人簽名的背書策略, 另一種則是需要群體決策的背書策略。其中, 新增域名和刪除域名對應(yīng)的是群體決策背書策略, 而更新域名密鑰和更新域名索引則采用擁有者簽名的背書策略。圖3所對應(yīng)的是交易背書策略和交易執(zhí)行功能的對應(yīng)關(guān)系。

圖2 名稱邏輯自動機(jī)

Figure 2 Name logical automata

域名可被群組決策創(chuàng)建和彈劾, 在創(chuàng)建和彈劾期間擁有者可以更新密鑰和索引

圖3 交易功能圖

Figure 3 Transaction function diagram

每份交易在檢驗時, 驗證者都需要先檢驗交易內(nèi)容是否與背書策略一一對應(yīng), 然后再分別檢驗兩項的正確性。

5 背書策略

ECMDNS的兩種背書策略都是基于secp256k1橢圓曲線和schnorr signature scheme執(zhí)行。因此, 兩種簽名能使用同樣的公私密鑰對簽發(fā), 也就是用于簽發(fā)單人Schnorr簽名的密鑰, 依然能用于簽發(fā)MuSig成員簽名并用于投票。只是生成單重簽名僅需要單個密鑰或單個簽名者, 而生成多重簽名交易需要多個密鑰或多個簽名者, 并且需要經(jīng)過通信來交換密鑰信息。兩種背書策略的目的都是生成可以驗證背書者或若干背書者的交易。

則有:

5.1 單重簽名背書策略

我們使用Schnorr簽名來驗證更新域名密鑰和索引的交易。設(shè)域名擁有者的私鑰為, 則擁有者公鑰為:

并驗證:

如果都成立則簽名正確。

5.2 多重簽名背書策略

圖4 申請MuSig多重簽名的三步交互過程

Figure 4 Three-step interactive process of applying for MuSig

隨機(jī)數(shù)交換: 如果請求者收到所有投票者的隨機(jī)數(shù)哈希, 則代表他們都初步同意該交易。接下來, 請求者將1發(fā)送至所有投票者。在接收到1后, 投票者先檢查列表里是否存在自己先前生成的公開隨機(jī)數(shù)哈希。如果存在, 投票者則將1存儲在本地, 并將R返回給請求者。之后, 請求者將所有投票者對應(yīng)的R記錄在本地, 并令列表2:

如果隨機(jī)數(shù)檢驗結(jié)果匹配, 請求者則將2發(fā)送至所有投票者。

所有投票者再各自檢驗1和2是否匹配, 接著各自計算聚合隨機(jī)數(shù):

最后投票者各自向請求者返回成員簽名s。請求者得到所有成員簽名后, 計算聚合簽名:

并驗證:

是否成立, 如果成立則簽名正確。

5.3 投票法則

投票法則指生成多重簽名算法過程中, 投票者決定是否配合請求者完成多重簽名背書策略的法則。在新增域名或刪除域名的投票法則中, 本應(yīng)當(dāng)由用戶自行設(shè)計投票法則。但考慮到現(xiàn)有的去中心化域名解析系統(tǒng)中, 還沒有投票法則的設(shè)計, 因此我們給出一種實際應(yīng)用中, 所使用的投票法則的設(shè)計方案。

現(xiàn)有的基于聯(lián)盟化管理投票方案中, ENS用多重簽名智能合約的方式實現(xiàn)實時的去中心化的票數(shù)統(tǒng)計, 每個用戶能隨時調(diào)用多重簽名智能合約更改自己的選票。本文所實現(xiàn)的聯(lián)盟化管理的背書策略與Hyperledger Fabric都基于混合共識模型實現(xiàn), 兩者的投票都需要一次性獲取所有投票者的選票。因此本文系統(tǒng)應(yīng)在投票申請發(fā)起時, 投票者應(yīng)該要在由網(wǎng)絡(luò)時延決定的短時間內(nèi), 完成對某個域名的決策。

因此, 我們要求所有投票者均實現(xiàn)了能短時間做出決策的方案。假定了所有投票者都有自己的人工審核機(jī)制, 在生成多重簽名背書策略前, 請求者需要將需要執(zhí)行的交易發(fā)布至投票者完成人工審核。若人工審核通過, 投票者則在服務(wù)器中記錄下該交易的哈希值, 并向請求者返回使用該投票者鏈上密鑰簽署的數(shù)字簽名, 保證不可抵賴。在投票者接收到某個請求者發(fā)來的交易時, 查看數(shù)據(jù)庫是否存在該交易的哈希值, 就能知道是否有通過線下人工審核, 并作出是否投票的判斷。

該投票法則僅作為設(shè)計參考, 實際投票法則應(yīng)該又投票者自定義。

5.4 交易的生成和執(zhí)行

無論何種交易, 它的生成都經(jīng)歷過讀取本地數(shù)據(jù)庫、編寫交易內(nèi)容、根據(jù)交易類型編寫背書策略并執(zhí)行post共識。每個共識節(jié)點接收新交易時, 都需經(jīng)過先檢驗背書策略、再寫入數(shù)據(jù)庫的過程。所有交易內(nèi)容的生成所依賴的數(shù)據(jù)都來自鏈上的公開數(shù)據(jù)庫, 而背書策略的生成會依賴非公開數(shù)據(jù)庫里存放的私鑰信息。

系統(tǒng)的交易生成流程如圖5所示。在交易生成時, 我們需要先確定所需要操作的域名和交易執(zhí)行的具體操作, 接著根據(jù)交易執(zhí)行的操作選擇需要的背書策略。如果交易要執(zhí)行的操作需要用到單重簽名背書策略, 則讀取該域名對應(yīng)鏈上私鑰寫入Schnorr簽名; 如果交易要執(zhí)行的操作需要用到多重簽名背書策略, 則請求者需要將交易發(fā)送至所有投票者來請求多重簽名, 并依據(jù)投票者信息以及多重簽名生成背書策略項, 將背書策略項寫入交易中。然后發(fā)起post共識, 直到所有接收者更新自身狀態(tài)。

圖5 交易生成流程圖

Figure 5 Transaction generation flowchart

圖6 交易驗證流程圖

Figure 6 Transaction validation flowchart

系統(tǒng)的交易驗證流程如圖6所示。當(dāng)某節(jié)點在post共識過程中接收到一份新交易時, 需要先檢驗背書策略類型和交易的操作類型是否匹配。如果交易使用了單重簽名的背書策略, 則需要讀取域名擁有者公鑰, 檢驗交易上的Schnorr簽名與域名擁有者是否匹配; 如果交易使用了多重簽名的背書策略, 則先檢驗簽名成員和身份是否符合要求, 若符合則讀取所有簽名者公鑰, 檢驗MuSig多重簽名與這些簽名者的公鑰是否匹配。若匹配, 仍需要檢驗交易的操作是否符合命名系統(tǒng)邏輯, 比如域名在創(chuàng)建時是否已存在該域名、域名刪除時該域名是否存在。如果其中一項檢查不通過, 則檢查會中斷, 該交易就不能通過檢驗。

6 DNS信息存儲

在執(zhí)行一次DNS查詢時, 用戶一般是以標(biāo)準(zhǔn)的DNS請求訪問某遞歸服務(wù)器, 然后遞歸服務(wù)器通過迭代查詢按照樹形解析的方式由根開始直到查詢到目標(biāo)的IP地址。ECMDNS本質(zhì)上是一個扁平化的查詢系統(tǒng), 它不存在現(xiàn)有系統(tǒng)的樹形結(jié)構(gòu), 所以它可以實現(xiàn)去中心化的單層域名解析。ECMDNS的命名系統(tǒng)以去中心化的方式存儲了每個域名所對應(yīng)的完整區(qū)域文件的索引以及其鏈下驗證密鑰。ECMDNS的DNS存儲操作根據(jù)操作者主要分為兩種: 擁有者操作和解析者操作。

擁有者操作: 擁有者的定義是某個域名擁有其鏈下私鑰的實體, 它需要在不改變區(qū)塊鏈鏈上數(shù)據(jù)的情況下更改DNS區(qū)域文件。在命名系統(tǒng)中存儲了該域名對應(yīng)的索引, 并且該索引是公開的。擁有者需要將該域名對應(yīng)的完整域文件, 以及其使用域名鏈下私鑰生成的區(qū)域文件的Schnorr簽名一同存放在該索引對應(yīng)的位置, 并且該區(qū)域文件需要符合DNS區(qū)域文件的格式[34]。因此, 擁有者需要使用鏈下私鑰生成該區(qū)域文件的Schnorr簽名, 并將該簽名和區(qū)域文件存儲在其對應(yīng)索引的位置, 其簽名的方法與第5.1章提到的單重簽名的生成及驗證方法相同。

解析者操作: 解析者是任何能通過某域名索引, 能夠訪問并得到其完整區(qū)域文件和簽名, 并能使用其鏈下公鑰驗證簽名正確性的實體。解析者面向的是廣大用戶, 它需要以標(biāo)準(zhǔn)的DNS請求和答復(fù)的方式與用戶交互[34]。ECMDNS所采用的方式是服務(wù)器定時訪問命名系統(tǒng), 得到其關(guān)注的域名索引和公鑰, 得到其對應(yīng)的區(qū)域文件和簽名, 最后使用鏈下公鑰驗證簽名的正確性。如果知曉該區(qū)域文件是由擁有者發(fā)布的, 解析者則將區(qū)域文件離線復(fù)制至本地DNS服務(wù)器中, 使得外網(wǎng)用戶可以用原有的方式訪問DNS服務(wù)。

Namecoin使用的是將完整文件存儲在鏈上的方式, 并開發(fā)了可實時根據(jù)接收到的DNS請求讀取節(jié)點信息的Namecoin-DNS[35]。我們認(rèn)為這樣的存儲方式在域名區(qū)域文件較大時, 鏈上存儲總量太大。由于區(qū)塊鏈鏈上空間存儲代價太大, ECMDNS選擇了區(qū)分鏈上鏈下的存儲方式。

但這樣的方式相比Namecoin而言不能保證區(qū)域文件的去中心化, 所以額外添加了區(qū)域文件簽名用于驗證擁有者。因此我們能在區(qū)塊鏈存儲總量較小的條件下完成分布式授權(quán)。同時, 我們認(rèn)為DNS服務(wù)器的訪問量會比區(qū)塊鏈節(jié)點的訪問量大, 如果使用實時訪問的方式會增加區(qū)塊鏈節(jié)點的負(fù)擔(dān), 因此采用了離線DNS區(qū)域文件的方式存儲。

7 應(yīng)用及分析

7.1 應(yīng)用

我們使用了raft作為post共識部分的共識算法[12], 實現(xiàn)了整個完整的系統(tǒng), 并部署在若干服務(wù)器中, 每臺服務(wù)器都模擬一個raft共識節(jié)點。在我們實現(xiàn)的raft共識算法中, 每份交易都會經(jīng)過由若干節(jié)點投票。若票數(shù)過半則更新當(dāng)前狀態(tài), 投票原則是檢驗交易在當(dāng)前數(shù)據(jù)庫中的正確性。我們使用了go 1.14實現(xiàn)了每個共識節(jié)點的邏輯, 并將每個共識節(jié)點部署在一臺服務(wù)器上, 服務(wù)器之間以星形拓?fù)溥B接, 單臺服務(wù)器配置包括操作系統(tǒng)Ubuntu 18.04、單核CPU OctaCore Intel(R) Xeon(R) Silver 4116 CPU @ 2.10GHz、1G內(nèi)存、50G硬盤。由于用到計算資源比較多, 因此我們把實驗環(huán)境部署在鵬城實驗室的靶場上。

實現(xiàn)raft算法時, 我們側(cè)重考慮了兩個重要方面,領(lǐng)導(dǎo)者選舉和新消息投票傳遞。領(lǐng)導(dǎo)者選舉是我們實現(xiàn)主節(jié)點選舉的過程, 它在初始化及原主節(jié)點失效時發(fā)生。我們在所有節(jié)點中內(nèi)置了時鐘, 當(dāng)時鐘歸零則判定為超時。其中, 主節(jié)點心跳包、候選者請求等都可將時鐘重置為隨機(jī)的3～6s, 而成功選舉為候選節(jié)點可將時鐘重置為10～15s, 并且每0.5s檢測一次是否超時。

當(dāng)需要發(fā)起新消息時, 主節(jié)點每0.5s向全部節(jié)點廣播最新的交易或者廣播待更新交易的投票請求。如果收到一半以上節(jié)點投票, 則更新自身狀態(tài), 并在心跳包中將最新狀態(tài)擴(kuò)散出去。在實驗中, 為了讓盡可能多的節(jié)點都按序收到最新狀態(tài), 我們強(qiáng)迫主節(jié)點至少完成兩次廣播后才可以發(fā)起新一輪的新交易投票。

7.2 交易空間性能分析

空間性能分析包括兩項, 一般性分析和實例分析。在一般性分析中, 我們主要研究系統(tǒng)在聯(lián)盟成員增加時的可擴(kuò)展性; 實例分析中, 我們主要研究系統(tǒng)在實際運行時, 所產(chǎn)生的具體開銷是否合理。

7.2.1 一般性分析

在一般性分析中, 我們假設(shè)域名長度為, 私鑰長度為公鑰和簽名長度為2, 域名完整區(qū)域文件索引長度為, 單位為字節(jié)。每份交易中都包含域名、交易項、背書策略項三項, 其中交易項和背書策略項的對應(yīng)關(guān)系已在4.3章提及。其中, 我們用1字節(jié)的空間表示交易類型和背書策略類型。

a)

使用單重簽名背書策略的交易共包含兩種類型, 更新域名密鑰、更新域名索引。

因此, 單重簽名交易的大小僅與域名長度、私鑰長度、域名區(qū)域文件索引長度有關(guān)。而在現(xiàn)有系統(tǒng)中, 這些項的長度都是有限的, 因此單重簽名交易的空間性能可擴(kuò)展性良好。

b)

使用多重簽名背書策略的交易共包含新建域名和彈劾域名兩種, 由于兩種交易全部的信息都記錄在域名以及交易類型種, 因此它們的交易項均只占用1字節(jié)。

7.2.2 實例分析

以域名gzhu.edu.cn為例, 設(shè)其區(qū)域文件索引為“http://202.192.18.1/public”, 簡單計算可知, 域名占用空間=11字節(jié), 域名索引占用空間=26字節(jié)。假設(shè)我們使用=32字節(jié)的私鑰, 其公鑰和簽名均為64字節(jié)。

在單重簽名背書策略的交易中, 代入一般性分析的結(jié)果, 一份更新域名密鑰交易總共占用208字節(jié), 更新域名索引的交易總共占用103字節(jié)。顯然, 該存儲空間占用大小的交易在合理的范圍內(nèi)。

在多重簽名背書策略的交易中, 當(dāng)域名數(shù)量較多時簽名所占用的空間遠(yuǎn)大于其他信息所占用空間, 因此值大小可忽略不計。本文系統(tǒng)調(diào)查了.com域名數(shù)量為1.47億個[36], 因此在對比實驗中設(shè)定域名上限分別為232和264兩種情況進(jìn)行比較, 在密鑰長度相同的情況下與超級賬本所實現(xiàn)的累加簽名預(yù)共識的方法進(jìn)行比較。以下分別對256位和512位兩種密鑰長度分別做了實驗。

當(dāng)設(shè)密鑰長度為定值時, 從圖7和圖8中均顯現(xiàn)相同的趨勢, 累加簽名預(yù)共識方法所生成的交易大小遠(yuǎn)遠(yuǎn)大于域名上限分別為232和264。其中, 若將簽名數(shù)量為現(xiàn)有的國家根數(shù)量(250個), 在256為長度的密鑰前提下, 原本的累加簽名預(yù)共識交易大小為15.6kB, 而上限為232個域名的MuSig預(yù)共識交易僅需要1.04kB。如果考慮可擴(kuò)展性, 即便將上限擴(kuò)展為264個交易也僅占用2.02kB的空間, 仍遠(yuǎn)遠(yuǎn)小于累加簽名預(yù)共識的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個簽名者的情況下。累加簽名預(yù)共識交易大小為31.25kB, 而域名個數(shù)上限為232時占用僅需要1.10kB, 考慮可擴(kuò)展性設(shè)定上限為264也僅占用2.08kB空間。

在以上兩組對比實驗中能看出, 在密鑰長度相同時, MuSig預(yù)共識生成的交易比超級賬本提出的混合共識模型預(yù)共識生成的交易, 在空間占用上有顯著優(yōu)勢。并且如果以現(xiàn)有共250個拉丁字符格式(Latin-character) ccTLD形成一份投票交易為例, 空間占用的優(yōu)勢將變得更加明顯。

比特幣從2020年6月至2020年末的平均交易大小為471字節(jié)[37], 而一份擁有250個國家根背書的交易約占用2份比特幣大小的空間, 說明使用多重簽名背書策略的空間占用是合理的。而更新域名密鑰交易約占用0.43份比特幣平均交易大小的空間, 而更新索引交易僅占用0.21份。

在MuSig預(yù)共識中, 圖6 (a)和圖6 (b)中均存在相同趨勢: 當(dāng)域名上限1增加時, 空間都變得更大。因此, 需要在密鑰長度相同情況下對比可擴(kuò)展性。根據(jù)公式(18)可繪制圖7。

圖9 預(yù)共識交易空間比值圖

Figure 9 Ratio diagram of pre-consensus trading space

由圖9可看出, 在256位密鑰的前提下, 在歷史域名總數(shù)在1<2512時, MuSig使用預(yù)共識的方案比原有混合模型方案要好; 而在512位密鑰前提下, 在歷史域名總數(shù)在1<21024時, MuSig使用預(yù)共識的方案比原有混合模型方案要好; 而這個域名數(shù)量在現(xiàn)有可見的水平下, 是不可能達(dá)到的。

綜上所述, 本文系統(tǒng)的交易在空間性能上是合理的, 且具有良好的可擴(kuò)展性。

7.3 時間性能分析

時間性能分析主要包括兩項, 第一項是針對我們系統(tǒng)優(yōu)化的預(yù)共識階段的時間性能分析, 第二項是整個完整實現(xiàn)的系統(tǒng)的吞吐量分析。時間性能分析的目的在于檢驗系統(tǒng)的在預(yù)共識階段付出額外時間代價, 以及整個系統(tǒng)的吞吐量是否在合理。

7.3.1 預(yù)共識時間性能分析

本文測量了預(yù)共識階段在整個共識階段的時間占用情況。實驗分為兩組, 第一組包含5個共識節(jié)點, 第二組包含10個共識節(jié)點。其中第一組實驗中, 每個共識節(jié)點包含20個投票者密鑰; 第二組實驗中, 每個共識節(jié)點包含10個投票者密鑰。兩組實驗中, 網(wǎng)絡(luò)都總共包含100個投票者。

實驗結(jié)果如圖10所示, 兩組對比試驗有相同趨勢, 只是第二組實驗中傳播完成時間和同步完成時間波動比較大, 特別是同步完成時間這一項。產(chǎn)生波動的原因有兩個: 一是數(shù)據(jù)傳播量會隨著節(jié)點數(shù)量增多而增多, 二是同步完成的條件會隨著節(jié)點數(shù)量增多而變得苛刻, 兩者都會造成更大的波動。

圖10 預(yù)共識時間性能分析

Figure 10 Pre-consensus time performance analysis

但即使產(chǎn)生了這樣的波動, 依然顯示出相同的趨勢。兩組實驗的預(yù)共識完成時間都隨著域名數(shù)量的增加呈線性增加的趨勢, 而且即使在投票成員數(shù)量到達(dá)100的條件下, 預(yù)共識時間在同步完成時間中占比依然較小。這是由于預(yù)共識過程中, 只有第一次接收的時候需要讀取當(dāng)前數(shù)據(jù)庫, 之后的投票階段都能很快的完成, 運算也只是無狀態(tài)的橢圓曲線運算。而post共識是有狀態(tài)的, 實驗中的raft算法需要等待每一項工作完成才能進(jìn)入下一階段的運算, 比如我們會強(qiáng)迫主節(jié)點需要廣播兩次當(dāng)前狀態(tài)才能發(fā)起下一次的投票, 這個過程是必要的也是耗時的。在我們的實驗中, post共識的時間體現(xiàn)在同步完成時間與發(fā)送完成時間之差, 實驗結(jié)果也顯示它們的差異比較大。

實驗說明了我們成功地改進(jìn)了hyperledger fabric的混合復(fù)制模型, 基于MuSig的預(yù)共識階段產(chǎn)生的額外時間代價在可接受范圍內(nèi)。

7.3.2 吞吐量分析

我們測量了區(qū)塊鏈網(wǎng)絡(luò)的吞吐量, 得到若干交易所需要的同步時間, 從而知曉ECMDNS在共識上的時間優(yōu)化。ENS是通過多重簽名智能合約實現(xiàn)了投票, 每次成員投票都需要發(fā)布一份交易完成, 也就是執(zhí)行一次post共識。因此, 我們需要知道執(zhí)行多次post共識所花費的時間, 與前面預(yù)共識時間對比就可以知道優(yōu)化了多少。

實驗結(jié)果如圖11所示, 在兩組測試中, 完成傳播或同步的序號幾乎與對應(yīng)時間成線性關(guān)系, 而且相同的序號對應(yīng)的傳播完成時間和同步完成時間之差比較接近, 這個時間也與前面測得post-consensus時間相似。再次說明了預(yù)共識的時間性能分析中的即使同步時間波動較大, 也是合理的。

8 結(jié)論和未來工作

我們提出了ECMDNS, 一個具基于聯(lián)盟化管理的、存儲總量較小的、共識次數(shù)較少的域名解析系統(tǒng)。首先, 我們采用了區(qū)分鏈上鏈下存儲結(jié)構(gòu), 解決了域名區(qū)域文件過大導(dǎo)致區(qū)塊鏈鏈上節(jié)點存儲總量過大的問題; 接著, 我們采用混合復(fù)制模型并做了優(yōu)化, 在預(yù)共識階段應(yīng)用MuSig多重簽名算法, 解決了投票共識次數(shù)過多的問題, 并進(jìn)一步減少了鏈上節(jié)點存儲總量。在前兩者的基礎(chǔ)上, 我們實現(xiàn)了基于聯(lián)盟化管理的命名系統(tǒng)邏輯, 為ECMDNS加入了群組投票和刪除的功能, 實現(xiàn)了在去中心化條件下的一定程度的可監(jiān)管性。

圖11 吞吐量分析

Figure 11 Throughput analysis

我們給出了ECMDNS的一種具體應(yīng)用方法, 在可自定義的post共識階段中采用raft算法(以及投票法則), 并分析了空間和時間性能。實驗結(jié)果顯示, 我們采用MuSig多重簽名算法將原本混合共識模型的交易優(yōu)化到原來的1/16, 并且時間成本比較小。此外, 我們減少了投票交易的共識次數(shù), 大幅度減少了決策完成的時間。

未來, 我們將進(jìn)一步優(yōu)化ECMDNS。我們將繼續(xù)針對去中心化DNS系統(tǒng)研究存儲優(yōu)化方案。另外, 我們也將進(jìn)一步研究共識算法方面的問題。本文我們主要優(yōu)化了混合共識模型中預(yù)共識過程, 在post共識過程甚至在混合共識模型本身仍有不少優(yōu)化的空間。未來的ECMDNS將會進(jìn)一步和現(xiàn)有DNS系統(tǒng)結(jié)合, 其實現(xiàn)會逐漸透明化。

致謝 國家重點研發(fā)計劃項目(No. 2018YFB1800701); 廣東省重點研發(fā)計劃項目(No. 2020B0101090003); 國家自然科學(xué)基金項目(No. 61902083, No. 62172115, No. 61976064), 廣東省高校創(chuàng)新團(tuán)隊(No. 2020KCXTD007)與廣州市高校創(chuàng)新團(tuán)隊(No. 202032854), 以及廣州市市校基礎(chǔ)研究計劃聯(lián)合資助項目(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. (張宇, 夏重達(dá), 方濱興, 等. 一個自主開放的互聯(lián)網(wǎng)根域名解析體系[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。

本課題得到國家重點研發(fā)計劃項目(No. 2018YFB1800701)資助。

2022-05-06;

2022-06-27;

2023-09-27

鄧錦禧 于2018年在華南農(nóng)業(yè)大學(xué)計算機(jī)科學(xué)與技術(shù)專業(yè)取得學(xué)士學(xué)位。現(xiàn)在在廣州大學(xué)網(wǎng)絡(luò)先進(jìn)技術(shù)研究院計算機(jī)技術(shù)專業(yè)攻讀碩士學(xué)位, 主要研究方向包括區(qū)塊鏈安全等。Email: dengjx1160@gmail. com

韓毅 廣州大學(xué)網(wǎng)絡(luò)空間先進(jìn)技術(shù)研究院研究員, 主要研究方向包括個人隱私保護(hù)、數(shù)據(jù)安全、社交網(wǎng)絡(luò)分析等。Email: hanyi@gzhu.edu.cn

蘇申 哈爾濱工業(yè)大學(xué)博士。廣州大學(xué)網(wǎng)絡(luò)空間先進(jìn)技術(shù)研究院副教授, 廣州大學(xué)-奇安信云安全聯(lián)合實驗室常務(wù)副主任, 主要研究方向包括區(qū)塊鏈安全、DNS安全、路由安全、車聯(lián)網(wǎng)安全等。Email: sushen@ gzhu.edu.cn

郭澤宇 于 2017 年在西安電子科技大學(xué)軟件工程專業(yè)獲得學(xué)士學(xué)位?，F(xiàn)在廣州大學(xué)網(wǎng)絡(luò)空間先進(jìn)技術(shù)研究院電子信息專業(yè)攻讀碩士學(xué)位, 主要研究方向包括區(qū)塊鏈安全等。Email: 2112006095@gzhu. edu.cn

李爽 于 2019年在哈爾濱工業(yè)大學(xué)信息安全專業(yè)獲得學(xué)士學(xué)位, 現(xiàn)攻讀廣州大學(xué)計算機(jī)技術(shù)專業(yè)碩士學(xué)位, 研究興趣包括區(qū)塊鏈和計算機(jī)網(wǎng)絡(luò)安全等。Email: 2111906051@gzhu.edu.cn

田志宏 哈爾濱工業(yè)大學(xué)博士。教授, 博士生導(dǎo)師, 廣州大學(xué)網(wǎng)絡(luò)空間先進(jìn)技術(shù)研究院院長; 廣東省“珠江學(xué)者”特聘教授。長期致力于網(wǎng)絡(luò)攻防對抗、網(wǎng)絡(luò)靶場、主動實時防護(hù)等網(wǎng)絡(luò)空間安全熱點領(lǐng)域的研究工作。Email: tianzhihong@gzhu.edu.cn