基于區塊鏈的持久標識符系統①

孫善鵬,田 野,李 琢,王毅蒙,劉 佳,王 姝,郭志斌

1(中國科學院 計算機網絡信息中心,北京 100190)

2(中國科學院大學,北京 100049)

3(中國工業互聯網研究院,北京 100102)

在包括科學數據、工業數據在內的若干領域中,數據總量迅速增長,據IDC 預測[1],2025年全球數據存儲總量將達到175 ZB,其中大量價值數據需要被長期保存并分享,這就需要為數據本身賦予某種名稱,使用戶可以通過名稱對數據本身進行訪問.

對于在線數據而言,往往通過URL 對其進行命名并藉由DNS 及相應Web 服務向用戶提供數據訪問能力,在這種方式下可以通過人為管理URL 到數據的映射來保證用戶通過特定URL 訪問數據的穩定性[2],但當數據服務面臨遷移、合并時,通過原URL進行數據訪問不可避免會遇到訪問失敗問題,這就需要為其賦予持久化標識符將數據對象身份與其Web位置相分離以允許通過標識符明確指代對應數據對象,從而保證標識符持久可解析,為了達成這一目的,出現了包括Handle、ARK、PRUL 在內的超過10 種標識符系統嘗試為數據提供名稱及解析服務,但隨著時間推移,其中部分系統不再提供服務,造成這種情況的主要原因一方面是其標識符系統結構過于依賴于中心化基礎設施[3],另一方面是標識符服務提供者大多未找到合適的盈利模式以至于不可持續發展.因此需要加強現有標識符系統的解析服務長期可用性與標識符數據完整性,最終保證標識符解析持久性,同時由于現有標識符系統服務規模普遍較小,無法像DNS 系統一樣提供廣泛的緩存基礎設施,所以在標識符解析流程中還需通過與客戶端物理位置接近的服務節點為客戶端提供解析服務,以加速標識符解析速度.

因此我們設計了基于區塊鏈的持久標識符系統,并兼容現有標識符解析系統進行了初步實現:通過基于區塊鏈的存儲層使多節點間互相形成冗余,允許提供多節點解析服務以避免單點服務失效以保持解析服務的持久性,并通過多節點中的近地節點服務優化標識符解析速度,同時通過區塊鏈鏈式結構及其共識機制保證標識符數據安全性.

本文余下章節中,第1 部分將介紹持久性標識符和區塊鏈的相關研究工作,第2 部分將介紹基于區塊鏈的持久標識符,第3 部分將對所提方案進行系統設計并于第4 部分中進行系統實驗結果分析,第5 部分對基于區塊鏈的持久性標識符的下一步發展以及挑戰做了簡要分析并總結全文.

1 相關工作

如何保證標識符解析服務持久性及數據正確性一直是域名、身份隱私及數據領域研究者長期關注的問題.

Namecoin[4]基于區塊鏈提供了類似DNS 解析的功能,通過向類比特幣[5]系統的交易事務數據中添加額外信息來將.bit 域名映射到指定位置,借助于區塊鏈系統的去中心化特性避免網絡審查以保證域名解析服務持久性從而允許信息自由發布,但由于Namecoin 易于遭受51%攻擊，Ali 等重新設計了可跨鏈的Blockstack系統[6],以保證域名解析數據源可靠性,雖然Namecoin及Blockstack 對DNS 解析服務持久性及數據源可靠性做出了初步嘗試,但其與現有域名系統相互獨立,需要用戶使用另外的解析系統.HandShake[7]基于區塊鏈系統通過鏈上具有根區數據的完全節點代替現有DNS根區文件與根區服務器,從而對DNS 頂級域進行管理,同時使用輕量級節點用于資源證明,從而希望能與現有DNS 體系兼容形成完整的DNS 解析體系,但該系統僅為代替根區服務.

此外,PPK 技術社區在2015年設計了基于比特幣的奧丁號(Open Data Index Name,ODIN)[8],它使用區塊號+塊內序號作為標識符來唯一確定一個區塊內事務,如600 000.100 表示將標識符信息寫入第600 000塊內第100 條事務,從而使解析可以直接定位到區塊中具體的數據.W3C 工作組也在2014年開始進行去中心化標識符的討論[9],并在2019年成立了去中心化標識符工作組發布了首個公開工作草案[10],以期設計一種符合URI 規范的可驗證的去中心化標識符以獨立于任何中心化驗證機構.

為了解決持久標識符系統單點故障問題,Bolikowski等[11]提出了將標識符及其對應數據與擁有者公鑰信息保存在區塊鏈中的持久標識符生成和管理方案,試圖通過區塊鏈系統解決單點故障對標識符壽命及長期保存造成的影響,但在該方案中每個區塊僅存放單一用戶的標識符,這將導致每區塊數據密度過低對存儲資源造成了浪費.Golodoniuc 等[12]設計了一種類似P2P文件共享網絡基于DHT 式結構以Magnet Link 作為名稱的持久標識符系統,期望在所有級別上去中心化來增加系統容錯能力從而保證其可靠性.Sicilia 等[13]對持久標識符模型進行建模并描述了如何將標識符及其元數據存儲于IPFS[14]及以太坊[15]為標識符提供持久化服務.

上述工作初步闡述了如何通過去中心化系統增加系統可靠性從而保證標識符解析持久性，但這些工作都對標識符系統進行了重新設計，無法在兼容現有系統的情況下，使客戶端直接遷移到去中心化的標識符解析系統.

2 基于區塊鏈的持久標識符模型

傳統標識符系統解析服務在解析流程中依賴于系統的分布式結構而具有一定的魯棒性,但最終解析行為往往依賴于單一數據源,這使得解析服務面臨著末端服務單點失效導致解析失敗的可能,現有系統主要依靠構建冗余服務來解決這一問題.同時,雖然標識符系統協議可能在數據報文中定義了消息憑據通過類似DNSSEC的機制提供簽名驗證能力來保證解析數據在其傳輸過程中的真實性與完整性,但當數據源被攻擊后,無法保證數據本身的安全性從而解析錯誤的標識符數據.

而基于區塊鏈作為標識存儲層為成員間數據一致性做出了保證,使系統參與節點間形成冗余,當用戶發起解析請求時,所有系統參與節點皆可完成對請求的響應,這樣就避免了單節點崩潰或不再服務所導致的該節點命名空間內標識符解析失效情況.同時當單節點崩潰事故發生后,崩潰節點只需重新接入區塊鏈網絡,待區塊鏈數據同步完成后掃描全部數據重建標識符索引,即可再次提供服務.在數據安全性上,區塊鏈的鏈式結構也簡化了數據正確性驗證流程,增加了攻擊者的數據篡改成本,同時結合具體系統所采用的共識機制保證正確數據的一致性同步,保障了存儲節點內標識符數據的安全性.

2.1 模型概述

為了兼容現有標識符系統,圖1中基于區塊鏈的持久標識符模型總體上分為標識符系統訪問層、區塊鏈服務層兩層結構.現有標識符系統訪問層繼續保持對外提供標識符解析與管理服務的能力,區塊鏈服務層則基于智能合約為標識系統訪問層提供區塊鏈存儲服務及對塊內標識符數據進行操作的能力,同時基于共識算法為節點間數據一致性提供保障.

圖1 基于區塊鏈的持久標識符模型

2.2 區塊概述

由于對現有標識符系統訪問層進行重用,所以將不會直接基于區塊鏈為用戶提供標識符管理能力,因此不會將管理者密鑰等數據直接存儲至區塊結構中,具體結構如圖2所示.

圖2 持久標識符的區塊設計

圖2中每個區塊將存儲多個操作符事務數據以增加區塊利用率,并存儲基于事務數據形成的Merkle Tree 根節點值作為當前區塊Hash 值,該值是基于當前區塊內所有事務數據的Hash 值構造而成(如圖2右側所示),同時每一區塊將存儲前一區塊Hash 值以形成鏈式結構,從而允許對數據完整性與正確性進行驗證,若某事務數據被攻擊者修改后,將影響包括被篡改數據所在區塊Hash 值及其后的所有區塊中的前繼Hash值,若當前區塊鏈鏈長度為L,被攻擊區塊號為X,X塊內事務數據量為M,則攻擊者篡改單節點內某一標識符數據的時間復雜度T為l og2M+1+L?X.

針對區塊事務內的標識符數據而言,在其生命周期內將經歷如圖3所示的狀態轉換,主要會涉及3 種狀態,包括標識符發布、標識符修改、標識符刪除.

圖3 標識符生命周期狀態轉換圖

具體地講,3 種狀態總共涉及5 種操作:創建標識符、新增值、更改值、刪除值、刪除標識符.為了緩解區塊鏈存儲壓力,不應在鏈上存儲每次標識符操作后完整標識符數據,而是存儲當前操作造成的數據變化,即進行增量式的存儲,因此當標識符被創建時,存儲其初始數據,而當進行后續操作時,并不完全重新存儲全部標識符數據,而僅需存儲變更數據同時附帶指向上一版本標識符的指針即可.

上述標識符操作中,標識符創建和刪除僅會被執行一次或0 次,其余標識符值相關操作次數雖然與值數據變更頻度有關,但對于單個標識符而言,其不同類型的操作次數有限且較少的,這為增量存儲但快速組合成完整標識符數據提供了有利條件,因此一條事務數據具體包括:

(1)標識符;

(2)前繼標識符數據位置;

(3)標識符值.

基于增量式標識符存儲使對標識符修改記錄進行內容追溯成為可能,當數據標識符使用者將元數據存儲在標識符系統中時,即可根據歷史元數據生成相應的數據描述變化信息,允許數據科學家從數據關系等角度對其進行進一步的分析.

但通常情況下單個標識符數據量較少,若將每次操作都封裝成單個事務寫入區塊則會面臨事務結構數據(事務頭、簽名等)比事務內有效負載數據更大的情況,因此應設計某種策略將符合策略的標識符數據批量封裝至同一事務內以節省頻繁存儲事務結構信息帶來的存儲空間浪費,本文中事務封裝策略通過事務結構大小ST與事務負載大小SP確定,當SP/ST>1 時將會封裝當前所有等待數據至同一事務中寫入區塊.

3 基于區塊鏈的標識符系統實現

現有持久標識符系統大多基于Handle 系統[16–18]提供服務,雖然該系統被設計為半中心化結構,使系統中某單節點臨時失效或完全不可用的情況下不會影響到系統整體解析流程的平穩、不間斷運行,但這種單點失效情況依然影響了該節點所負責的命名空間內標識符的可解析性,本節將在接下來闡述如何將Handle 系統移植到基于Hyperledger Fabric[19]的區塊鏈之上以使其成為在存儲層面可去中心化的系統.

3.1 系統結構

為了兼容現有Handle 系統,首先需要使其保持現有的GHR、LHS 式層級結構,以保證用戶進行標識符解析時解析流程不被改變.其次對于傳統Handle 服務提供者而言,依賴于Key-Value 數據庫或關系型數據庫提供對Handle 及其值的單節點存儲服務,這種單節點存儲及訪問服務存在的不可靠性帶來了使解析服務崩潰風險,而當數據存儲層遷移至區塊鏈之上后,區塊鏈參與節點將得益于全局一致性賬本互為冗余,同時可以提供多節點全量標識符解析服務.從系統結構上看,考慮到現有Handle 節點間服務的互相獨立,應允許原有的Primary 節點、Multi-Primary 節點、Mirror節點都可以與基于區塊鏈的Handle 節點同時共存于整個體系之中,最終系統整體結構如圖4所示.

以Hyperledger Fabric 作為區塊鏈服務為例,持久化標識符聯盟中的每個參與成員都將在各自的Handle服務中集成Fabric Peer 節點以代替原有數據存儲系統,將各自身份注冊至MSP 之中,以確保對區塊鏈系統的操作權限,并基于Raft 協議使參與成員提供排序服務,其區塊鏈網絡結構如圖5所示.

3.2 存儲層次結構

對于一個具體的標識符服務節點而言,其標識符注冊數量通常處于較大的數量級,所以對于每個標識符服務都需要具有類似標識符目錄的機制對當前服務節點管理的標識符進行索引從而允許解析服務快速的定位標識符數據所在區塊以讀取數據,因此將索引數據存儲于Hyperledger Fabric 世界狀態數據庫中,使其與具體區塊鏈數據文件分離,如圖6所示.

圖4 包含基于區塊鏈服務的Handle 系統結構

圖5 區塊鏈網絡結構

圖6 存儲層次結構

為了不影響Handle 系統用戶的現有信息系統,基于區塊鏈的標識符系統將繼續遵循Handle 協議規范規定的Handle 標識符數據結構以提供完整的Handle 數據存儲,基于2.2 節中所描述的方案進行標識符數據存儲,其中Handle 號及最新數據存儲在世界狀態數據庫之中,因此事務內有效數據僅包括:

(1)前繼標識符信息位置(除創建標識符操作外),包括事務ID與在該事務中的寫集下標;

(2)Handle 值列表,包括Index、Type、Value、TTL、Timestamp、Reference、admin_read、admin_write、pub_read、pub_write.

3.3 標識符事務

以12346/abc為例,其具體事務存儲示例如圖7.

圖7(a)代表handle 號為12346/abc的handle 被創建,其handle 值包括一條Index為1的URL 類型的值http://hdl.handle.net,其TTL為24 小時,創建時間為927314334000,引用為空,管理員可讀且可寫,公眾可讀但不可寫.

圖7(b)代表對標識符12346/abc 添加一條新值,它的前繼操作存儲在事務ID為100的事務內寫集下標為1的位置,值內容是Index為2的DES 類型的值“Handle resolver”,其TTL為24 小時,創建時間為927314335000,引用為空,管理員可讀且可寫,公眾可讀但不可寫.

圖7(c)代表是對標識符12346/abc 中Index為2的值進行修改,其前繼操作存儲在事務ID為101的事務內寫集下標為1的位置,具體值被修改為“A Handle resolver”.

圖7(d)為刪除12346/abc 中Index為2的值,其前繼操作存儲在事務ID為102的事務內寫集下標為1的位置.

圖7 標識符操作事務

3.4 標識符解析與操作

Handle 系統具有GHR/LHS 兩層結構,并且基于Handle 協議規范具有詳細的數據交互流程設計,因此不論在解析還是操作流程上都應遵循基本的Handle交互模式.

(1)標識符解析流程

解析基本流程如圖8所示.

當用戶通過解析器向系統發起標識符解析請求時:①首先會通過解析器向GHR 請求LHS 服務地址;②接著GHR 將返回負責用戶欲解析的標識符前綴信息,其中包含了所有參與區塊鏈的成員節點信息,③接下來解析器將向獲取到的LHS 發送具體解析請求;④LHS 接收到解析請求后首先檢索緩存,若命中則直接返回標識符數據;⑤若不命中則調用存儲層;⑥觸發當前節點集成的Fabric 服務的標識符檢索智能合約;⑦合約將檢索世界狀態數據庫得到最新標識符狀態數據,若該數據標志位非新建標志或刪除標志則說明檢索到的僅為最新增量數據;⑧于是需要依據最新增量數據的前繼數據索引字段去區塊鏈存儲中相應的區塊檢索歷史數據繼而組合出完整標識符數據;⑨之后將其寫入緩存并返回給訪問層,其后訪問層基于用戶是否具有相應值條目的讀取權限篩選出最終數據,以響應解析器的請求.

(2)標識符操作流程

當解析器發起標識符操作請求時,整體流程與解析請求流程類似,但首先需經歷操作權限驗證,其中標識符創建與標識符值修改/刪除流程略有不同:

①標識符創建:當請求到達Handle 系統后,若請求為標識符創建請求則首先根據Handle 規范驗證其權限.

②標識符值修改/刪除:首先進行標識符檢索,其后根據標識符數據進行權限驗證.

圖8 解析請求流程示意圖

權限驗證通過后將觸發當前節點智能合約,節點成功背書后,即可將數據寫入緩存提供服務,以保證服務時效性.其后當前節點Orderer 服務將數據發送至當前的Raft Leader 處,Leader 將該請求包含的Handle 數據依照前文第3 節所述格式打包成事務,同步至其它LHS的對等節點中.

4 實驗與分析

4.1 實驗環境與方案

實驗環境主要采用一臺CPU 規格為AMD R5 3500U,內存規格為DDR4 2133 MHz,硬盤規格為WDC SN520的主機作為宿主機,使用VirtualBox 6.0 進行虛擬化提供運行環境,基于Handle Software v9.2與Hyperledger Fabric v1.4 進行基于區塊鏈的標識符系統開發,對照組為基于BerkeleyDB 及MySQL的Handle 系統.

上述基于Hyperledger Fabric的系統中包含由5 個LHS 節點以組成持久標識符區塊鏈系統,在進行測試時,使用單客戶端10 線程,每個線程發送基于TCP發送2000 次請求,每個請求之間有10 毫秒的延遲以避免客戶端主機端口耗盡,同時停用標識符系統緩存.測試項目主要包括標識符解析性能測試、標識符操作性能測試、標識符服務單點失效測試、標識符服務內存消耗測試、標識符存儲資源消耗測試.

4.2 實驗分析

4.2.1 標識符解析性能測試

在標識符解析性能實驗中,測試腳本通過向系統解析預先創建的標識符來進行解析性能測試,測試結果如表1所示.

表1 解析性能測試

從表1中可見基于Hyperledger Fabric的Handle系統標識符解析吞吐量略低,其平均解析響應時間慢于基于其他存儲層的Handle 系統,這意味著對于需要高性能的標識符解析場景而言,仍需進一步優化標識符解析流程同時需提供高效的緩存服務以減少標識符解析時的區塊鏈區塊文件的查詢次數.

4.2.2 標識符操作性能測試

在標識符操作性能實驗中,測試腳本通過向系統批量創建標識符來進行操作性能測試,測試結果如表2所示.

表2 操作性能測試

可見基于Hyperledger Fabric的Handle 系統對的標識符操作響應時間慢于基于其他存儲層的Handle系統,需要進一步優化標識符存儲流程以提供多級數據寫入策略來保證系統對標識符操作的及時響應.

4.2.3 標識符單點失效測試

為了進行單點失效測試,在實驗中將設置5 個持久標識符服務參與節點,分別編號A～E,在節點運行過程中,對標識符服務進行持續解析請求,在此過程中隨機反復停止并恢復節點的服務,行為示例如表3所示,解析客戶端持續統計解析成功率,結果如表4所示.測試結果表明基于區塊鏈的標識符解析系統通過互冗余為任一參與方LHS 所管理的前綴命名空間內標識符提供多節點的解析服務可以有效避免單一LHS的解析服務單點失效所帶來的解析失敗問題.

表3 單點失效測試行為示例

表4 單點失效解析測試

4.2.4 標識符存儲資源消耗測試

基于區塊鏈的標識符系統存儲了所有標識符歷史數據,同時每條數據都被打包成事務以組成區塊,這將存儲更多的事務及區塊結構信息,所以會比傳統Handle系統消耗更多的存儲資源,存儲資源消耗對比如圖9所示,標識符存儲受事務及區塊結構數據影響較大,可按需進一步考量存儲策略及數據壓縮策略以節省存儲資源.

圖9 存儲資源消耗對比圖

5 結論與展望

本文闡述了一種基于區塊鏈的持久標識符系統并基于Handle 系統對其進行了初步實現.通過對已有標識符系統訪問層的兼容,使現有系統從技術上獲得了延續性,同時通過區塊鏈系統的分布式一致性賬本優勢使原有系統獲得更多的數據完整性與解析服務長期可用性,從而保障標識符解析持久性.然而,基于區塊鏈的持久標識符系統具有大量的標識符服務參與成員,且參與成員的標識符注冊量較多,這將對其成員服務節點造成過多的存儲壓力,在接下來研究中我們將繼續探究如何對壓縮標識符數據同時改善事務打包策略或基于鏈外存儲方式,以期節省存儲資源,同時優化解析流程從而保持高性能的解析能力.