余 濤，牛保寧，樊 星

(太原理工大學(xué) 信息與計(jì)算機(jī)學(xué)院，山西 晉中 030600)

0 引 言

從中本聰描繪的比特幣[1]，到Vitalik Buterin提出以太坊[2]，再到Linux基金會(huì)發(fā)起的Hyperledger開(kāi)源區(qū)塊鏈項(xiàng)目[3]，區(qū)塊鏈技術(shù)逐步成熟和普及。Hyperledger Fabric與其它區(qū)塊鏈項(xiàng)目的技術(shù)類似，是一個(gè)使用智能合約、通過(guò)所有參與者共同管理交易的賬本系統(tǒng)，其主要的特點(diǎn)是私有和許可，因此更適用于企業(yè)級(jí)區(qū)塊鏈項(xiàng)目的開(kāi)發(fā)?；贔abric的區(qū)塊鏈系統(tǒng)，能有效解決目前以中心化模式為主的數(shù)據(jù)管理存在的問(wèn)題，克服中心化系統(tǒng)的弊端，回避人為作惡的風(fēng)險(xiǎn)，使鏈上的參與方集體認(rèn)定、共同維護(hù)同一賬本[4]。

區(qū)塊鏈的設(shè)計(jì)目的是在不可信、分布式的環(huán)境中進(jìn)行安全、不可變的價(jià)值轉(zhuǎn)移。區(qū)塊鏈的本質(zhì)可以理解為去中心化的數(shù)據(jù)庫(kù)，但是如果用傳統(tǒng)的數(shù)據(jù)庫(kù)標(biāo)準(zhǔn)來(lái)衡量區(qū)塊鏈，不管是在吞吐量、事務(wù)延遲、容量還是查詢能力上，區(qū)塊鏈的效果均顯不佳[5]。而區(qū)塊鏈的廣泛應(yīng)用必然會(huì)要求對(duì)區(qū)塊鏈數(shù)據(jù)進(jìn)行高效查詢。目前，區(qū)塊鏈查詢方面的研究大致有兩類：一類是通過(guò)區(qū)分記錄節(jié)點(diǎn)能力、優(yōu)化查詢路徑解決泛洪循環(huán)和響應(yīng)消息風(fēng)暴等問(wèn)題[6,7]，這樣做并不能豐富區(qū)塊鏈的查詢功能；另一類是通過(guò)與數(shù)據(jù)庫(kù)連接，利用數(shù)據(jù)庫(kù)系統(tǒng)的查詢能力，豐富查詢功能，實(shí)現(xiàn)區(qū)塊鏈數(shù)據(jù)的高效查詢[5,8-11]，但是，這一途徑存在數(shù)據(jù)庫(kù)中數(shù)據(jù)可篡改的問(wèn)題。針對(duì)后一途徑存在的問(wèn)題，本文將區(qū)塊鏈與關(guān)系型數(shù)據(jù)庫(kù)連接后，增加交易驗(yàn)證機(jī)制，在保證數(shù)據(jù)不可篡改特性的前提下，實(shí)現(xiàn)區(qū)塊鏈豐富的查詢功能和高效的查詢。

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

(1)針對(duì)區(qū)塊鏈查詢方面的不足，提出一種區(qū)塊鏈數(shù)據(jù)的關(guān)系查詢解決方案FabricSQL，將區(qū)塊鏈上的有效交易同步至SQL數(shù)據(jù)庫(kù)中，豐富區(qū)塊鏈系統(tǒng)的查詢功能，優(yōu)化查詢方法；

(2)為增強(qiáng)用戶查詢的準(zhǔn)確性，減少不必要的空間占用，通過(guò)偵聽(tīng)每筆交易的狀態(tài)，實(shí)時(shí)同步區(qū)塊鏈上有效交易的信息，并將交易數(shù)據(jù)轉(zhuǎn)為SQL數(shù)據(jù)庫(kù)要求的格式存儲(chǔ)；

(3)為保證SQL數(shù)據(jù)庫(kù)的數(shù)據(jù)安全問(wèn)題，提出一種交易數(shù)據(jù)存儲(chǔ)驗(yàn)證機(jī)制，每筆交易數(shù)據(jù)對(duì)應(yīng)一個(gè)哈希值，在存儲(chǔ)時(shí)生成，在訪問(wèn)時(shí)驗(yàn)證，保證交易數(shù)據(jù)的安全性。

在設(shè)計(jì)的實(shí)驗(yàn)?zāi)Ｐ虵abricSQL和Hyperledger Fabric區(qū)塊鏈系統(tǒng)上，進(jìn)行多組查詢性能的對(duì)比實(shí)驗(yàn)，結(jié)果表明FabricSQL在保證集體驗(yàn)證維護(hù)、數(shù)據(jù)可回溯以及防篡改特性的同時(shí)，兼?zhèn)潢P(guān)系型數(shù)據(jù)庫(kù)快速查詢、查詢功能豐富的特性。

1 相關(guān)工作

隨著區(qū)塊鏈技術(shù)不斷發(fā)展應(yīng)用，人們對(duì)于區(qū)塊鏈上數(shù)據(jù)查找速度和查找功能的要求隨之增加。針對(duì)區(qū)塊鏈查詢的研究，目前大致分為兩個(gè)方向：一是通過(guò)區(qū)分記錄或賦予節(jié)點(diǎn)不同的查詢能力，優(yōu)化查詢路徑，實(shí)現(xiàn)區(qū)塊數(shù)據(jù)的有效查詢；二是將區(qū)塊鏈系統(tǒng)與數(shù)據(jù)庫(kù)結(jié)合，實(shí)現(xiàn)查詢功能優(yōu)化。

首先，在第一種研究中，賈大宇等[6,7]在ElasticChain模型基礎(chǔ)上，提出一種新的容量可擴(kuò)展區(qū)塊鏈系統(tǒng)的高效查詢方法ElasticQM，在用戶層、查詢層、存儲(chǔ)層和數(shù)據(jù)層實(shí)現(xiàn)創(chuàng)新優(yōu)化，通過(guò)在用戶層設(shè)置數(shù)據(jù)緩存模塊，在查詢層增加超級(jí)節(jié)點(diǎn)、查詢?nèi)~子節(jié)點(diǎn)和查詢驗(yàn)證節(jié)點(diǎn)3種角色，在數(shù)據(jù)層結(jié)合平衡二叉樹(shù)和梅克爾樹(shù)的各自特點(diǎn)建立基于B-M樹(shù)的區(qū)塊鏈存儲(chǔ)結(jié)構(gòu)，提高查詢效率。

Tuan等[12]提出了Blockbench，可以對(duì)集成的私有區(qū)塊鏈系統(tǒng)的整體和組件的性能進(jìn)行評(píng)估，并幫助他們識(shí)別和改進(jìn)性能瓶頸。另外，Blockbench對(duì)3種主要的區(qū)塊鏈系統(tǒng)：Ethereum，Parity和Hyperledger進(jìn)行全面分析，結(jié)果表明，這些系統(tǒng)在傳統(tǒng)的數(shù)據(jù)處理工作負(fù)載中還遠(yuǎn)不能取代現(xiàn)有的數(shù)據(jù)庫(kù)系統(tǒng)。

在第二種研究中，McConaghy等[5]發(fā)布的BigchainDB是一個(gè)區(qū)塊鏈數(shù)據(jù)庫(kù)，其設(shè)計(jì)是從分布式數(shù)據(jù)庫(kù)開(kāi)始，使BigchainDB繼承現(xiàn)代分布式數(shù)據(jù)庫(kù)高吞吐量、低延遲、大容量、豐富的查詢功能等特征的同時(shí)，通過(guò)增加區(qū)塊鏈去中心化、不可篡改和數(shù)字資產(chǎn)創(chuàng)建以及傳輸?shù)奶匦?，使它具有?shù)據(jù)庫(kù)和區(qū)塊鏈的優(yōu)良屬性。2018年BigchainDB 2.0[8]發(fā)布，網(wǎng)絡(luò)中的每個(gè)節(jié)點(diǎn)都有自己本地MongoDB數(shù)據(jù)庫(kù)，并且引入拜占庭容錯(cuò)機(jī)制，允許網(wǎng)絡(luò)中即使有1/3的節(jié)點(diǎn)失敗，也能夠達(dá)成一致意見(jiàn)繼續(xù)進(jìn)行。Bartoletti等[9]提出區(qū)塊鏈分析的通用框架，支持對(duì)比特幣和以太坊兩種加密貨幣進(jìn)行數(shù)據(jù)分析，框架允許將相關(guān)的區(qū)塊鏈數(shù)據(jù)與從外部源檢索的數(shù)據(jù)集成在一起，并將它們組織到一個(gè)數(shù)據(jù)庫(kù)中，再用數(shù)據(jù)庫(kù)管理系統(tǒng)的查詢語(yǔ)言進(jìn)行分析，文獻(xiàn)通過(guò)一系列用例包括分析區(qū)塊鏈元數(shù)據(jù)、按日期劃分的交易數(shù)量、交易費(fèi)和地址標(biāo)簽說(shuō)明框架支持的不同功能。Li Yang等[10]提出EtherQL，是為Ethereum開(kāi)發(fā)的一個(gè)高效查詢層，由同步管理器、鏈處理、持久化框架和開(kāi)發(fā)者接口4個(gè)模塊組成。EtherQL通過(guò)內(nèi)置的Ethereum客戶端實(shí)時(shí)同步來(lái)自Ethereum公共網(wǎng)絡(luò)的區(qū)塊鏈數(shù)據(jù)，并將其存儲(chǔ)在MongoDB數(shù)據(jù)庫(kù)中，提供的接口支持?jǐn)U展查詢、范圍查詢和top-k查詢等分析查詢。北京眾享比特科技有限公司提出ChainSQL[11]，通過(guò)構(gòu)建Ripple與普通數(shù)據(jù)庫(kù)結(jié)合的區(qū)塊鏈數(shù)據(jù)庫(kù)，實(shí)現(xiàn)先入庫(kù)再共識(shí)的方法，將操作以交易的形式記錄在區(qū)塊鏈網(wǎng)絡(luò)中，而真實(shí)數(shù)據(jù)在數(shù)據(jù)庫(kù)中查看，如果共識(shí)不能通過(guò)，則回滾數(shù)據(jù)庫(kù)操作，增加數(shù)據(jù)入庫(kù)的速度。

本文所提出的FabricSQL方法與其它研究相比，是針對(duì)聯(lián)盟鏈Fabric實(shí)現(xiàn)的一種區(qū)塊鏈數(shù)據(jù)關(guān)系查詢解決方案，且設(shè)計(jì)相應(yīng)的模塊解決其它研究中未能解決的數(shù)據(jù)庫(kù)中數(shù)據(jù)易被篡改的問(wèn)題。

2 Fabric系統(tǒng)

Hyperledger Fabric在一個(gè)僅追加復(fù)制的賬本數(shù)據(jù)結(jié)構(gòu)中安全地跟蹤其執(zhí)行歷史，沒(méi)有內(nèi)置的加密貨幣，且具有高度的模塊化，將共識(shí)、執(zhí)行和驗(yàn)證過(guò)程完全分離[13]。在Fabric網(wǎng)絡(luò)中，節(jié)點(diǎn)是通信的主體，包括客戶端節(jié)點(diǎn)、CA節(jié)點(diǎn)、peer節(jié)點(diǎn)和排序服務(wù)節(jié)點(diǎn)，鏈上的節(jié)點(diǎn)共同維護(hù)同一賬本。

Hyperledger Fabric交易流程如圖1所示，交易是由客戶端發(fā)起的，客戶端通過(guò)SDK調(diào)用CA服務(wù)，交易提案經(jīng)SDK創(chuàng)建后，發(fā)送給背書節(jié)點(diǎn)，背書節(jié)點(diǎn)驗(yàn)證簽名并確定提交者是否有權(quán)執(zhí)行操作，同時(shí)調(diào)用鏈碼并將鏈碼的模擬執(zhí)行結(jié)果等提案響應(yīng)返回給客戶端，客戶端判斷執(zhí)行結(jié)果是否一致以及背書策略是否滿足，再將交易提案、模擬執(zhí)行結(jié)果、背書信息封裝為一個(gè)交易，簽名后一并發(fā)給排序服務(wù)節(jié)點(diǎn)，排序服務(wù)節(jié)點(diǎn)將交易排序并將生成的區(qū)塊發(fā)送至提交節(jié)點(diǎn)，提交節(jié)點(diǎn)驗(yàn)證交易的有效性，通過(guò)驗(yàn)證的區(qū)塊會(huì)被追加到區(qū)塊鏈上，與之相關(guān)的狀態(tài)數(shù)據(jù)庫(kù)也會(huì)進(jìn)行更新。

圖1 Hyperledger Fabric交易流程

Hyperledger Fabric的存儲(chǔ)系統(tǒng)由普通的文件和key-value數(shù)據(jù)庫(kù)組成。每個(gè)區(qū)塊的區(qū)塊頭和所有交易數(shù)據(jù)以二進(jìn)制形式寫入blockfile文件中，并將區(qū)塊和交易在blockfile中的索引以key-value的形式保存。歷史數(shù)據(jù)和區(qū)塊索引均存儲(chǔ)在LevelDB數(shù)據(jù)庫(kù)中。而狀態(tài)數(shù)據(jù)庫(kù)記錄最新的交易執(zhí)行結(jié)果，是所有狀態(tài)的最新值，支持LevelDB和CouchDB數(shù)據(jù)庫(kù)。在查詢賬本數(shù)據(jù)時(shí)，從索引數(shù)據(jù)庫(kù)中獲得文件位置指針，再通過(guò)文件位置指針獲取所需的數(shù)據(jù)。

Hyperledger Fabric中包括賬本數(shù)據(jù)、索引數(shù)據(jù)、歷史數(shù)據(jù)和狀態(tài)數(shù)據(jù)等，各種數(shù)據(jù)的存儲(chǔ)方式不同，即便是基于鍵值對(duì)的存儲(chǔ)方式其操作管理的方法也大不相同，在區(qū)塊提交時(shí)，各類存儲(chǔ)操作順序執(zhí)行，極有可能發(fā)生中斷或出錯(cuò)等情況。而且由于數(shù)據(jù)的存儲(chǔ)結(jié)構(gòu)受限導(dǎo)致區(qū)塊鏈僅支持簡(jiǎn)單和有限的查詢。在用戶提出查詢請(qǐng)求后，只能通過(guò)預(yù)先定義的key進(jìn)行查詢，難以實(shí)現(xiàn)復(fù)雜的查詢功能，無(wú)法滿足用戶豐富的需求。

從應(yīng)用開(kāi)發(fā)者角度考慮，區(qū)塊鏈沒(méi)有標(biāo)準(zhǔn)的查詢語(yǔ)言，如果開(kāi)發(fā)人員對(duì)區(qū)塊鏈的內(nèi)部數(shù)據(jù)組織方式、存儲(chǔ)結(jié)構(gòu)沒(méi)有較好的理解，將增大數(shù)據(jù)查詢的難度。當(dāng)用戶的需求發(fā)生變更時(shí)，需要更改鏈碼操作。

3 FabricSQL系統(tǒng)

本章介紹FabricSQL具體細(xì)節(jié)。3.1節(jié)討論提出FabricSQL的思路，3.2節(jié)給出FabricSQL的總體架構(gòu)，3.3節(jié)、3.4節(jié)分別討論重要模塊的技術(shù)細(xì)節(jié)。

3.1 問(wèn)題與解決思路

針對(duì)區(qū)塊鏈查詢方面存在的不足，本文將Fabric與關(guān)系型數(shù)據(jù)庫(kù)MySQL結(jié)合，提出區(qū)塊鏈數(shù)據(jù)的關(guān)系查詢解決方案FabricSQL，從而解決Fabric中各類數(shù)據(jù)存儲(chǔ)方式復(fù)雜、查詢功能有限以及需求變更難以實(shí)現(xiàn)等問(wèn)題。但是，將數(shù)據(jù)從區(qū)塊鏈同步存儲(chǔ)至數(shù)據(jù)庫(kù)的同時(shí)，需要解決下面的問(wèn)題：首先，區(qū)塊鏈中存在的無(wú)效交易如果直接同步至數(shù)據(jù)庫(kù)中，會(huì)對(duì)查詢結(jié)果的正確性產(chǎn)生干擾，這里的無(wú)效交易是指當(dāng)區(qū)塊發(fā)送至提交節(jié)點(diǎn)后，提交節(jié)點(diǎn)會(huì)按順序?qū)K中的交易進(jìn)行背書策略和讀寫沖突檢查，將不滿足背書策略和版本不匹配的交易標(biāo)記為無(wú)效，但是所有有效和無(wú)效的交易最終都會(huì)追加至區(qū)塊鏈上；其次，由于數(shù)據(jù)庫(kù)本身安全能力有限，在使用過(guò)程中會(huì)不可避免暴露數(shù)據(jù)接口，被外部作惡者通過(guò)技術(shù)手段篡改數(shù)據(jù)的案例比比皆是，同時(shí)在使用過(guò)程中管理員的權(quán)限不可控制，存在著不信任因素，因此數(shù)據(jù)庫(kù)容易被作惡者篡改的情況，會(huì)對(duì)數(shù)據(jù)庫(kù)中數(shù)據(jù)的安全性產(chǎn)生影響。

針對(duì)上述問(wèn)題，首先通過(guò)增加對(duì)交易狀態(tài)的偵聽(tīng)，將有效交易同步存儲(chǔ)至數(shù)據(jù)庫(kù)中，從而保證存儲(chǔ)數(shù)據(jù)的正確性。另外提出交易數(shù)據(jù)的存儲(chǔ)驗(yàn)證機(jī)制，在MySQL數(shù)據(jù)庫(kù)中，存儲(chǔ)和驗(yàn)證數(shù)據(jù)時(shí)運(yùn)用加鹽思想，即在經(jīng)過(guò)哈希后的每筆交易數(shù)據(jù)的特定位置增加特定的字符串Salt，從而改變?cè)嫉淖址?，?shí)現(xiàn)數(shù)據(jù)加密，這樣即使知道原有的交易信息，在不知道Salt的情況下，也會(huì)增加一定的破解負(fù)擔(dān)；同時(shí)借鑒區(qū)塊鏈前哈希的思想，將交易生成的哈希值依序咬合，生成最終的交易哈希值存儲(chǔ)在數(shù)據(jù)庫(kù)中。當(dāng)用戶發(fā)出數(shù)據(jù)請(qǐng)求時(shí)，首先完成對(duì)交易數(shù)據(jù)的一致性校驗(yàn)，然后返回給用戶數(shù)據(jù)和校驗(yàn)結(jié)果，從而保證數(shù)據(jù)的安全性。

3.2 總體架構(gòu)

FabricSQL由應(yīng)用層、網(wǎng)絡(luò)層、數(shù)據(jù)處理層和存儲(chǔ)層4個(gè)層次構(gòu)成。系統(tǒng)架構(gòu)圖如圖2所示。

圖2 FabricSQL系統(tǒng)架構(gòu)

應(yīng)用層負(fù)責(zé)與區(qū)塊鏈網(wǎng)絡(luò)交互和查詢邏輯的實(shí)現(xiàn)，包括交互模塊、查詢模塊和校驗(yàn)?zāi)K。交互模塊包含與區(qū)塊鏈網(wǎng)絡(luò)交互的SDK程序在內(nèi)的應(yīng)用程序。查詢模塊在收到用戶查詢申請(qǐng)后，與存儲(chǔ)層交互。校驗(yàn)?zāi)K對(duì)查詢模塊的返回值進(jìn)行一致性校驗(yàn)，通過(guò)驗(yàn)證的結(jié)果返回給交互模塊。

網(wǎng)絡(luò)層由排序服務(wù)節(jié)點(diǎn)、peer節(jié)點(diǎn)、CA節(jié)點(diǎn)構(gòu)成。由于區(qū)塊鏈數(shù)據(jù)的關(guān)系查詢模型FabricSQL是在Hyperledger Fabric系統(tǒng)的基礎(chǔ)上實(shí)現(xiàn)的，所以，網(wǎng)絡(luò)層的結(jié)構(gòu)保持不變。

數(shù)據(jù)處理層包括有效交易獲取模塊和數(shù)據(jù)處理模塊，負(fù)責(zé)組織區(qū)塊鏈上的有效交易數(shù)據(jù)，并轉(zhuǎn)換為可存儲(chǔ)在SQL數(shù)據(jù)庫(kù)中的關(guān)系型數(shù)據(jù)。

存儲(chǔ)層由兩部分組成，分別是存儲(chǔ)區(qū)塊鏈信息的普通文件和存儲(chǔ)由數(shù)據(jù)處理層輸出的交易數(shù)據(jù)的MySQL數(shù)據(jù)庫(kù)，它們存儲(chǔ)著驗(yàn)證通過(guò)的每筆交易信息，不同點(diǎn)是，SQL數(shù)據(jù)庫(kù)只存儲(chǔ)有效交易。

3.3 交易數(shù)據(jù)同步處理

FabricSQL的交易數(shù)據(jù)同步處理模塊在對(duì)區(qū)塊鏈有效交易信息判斷、同步和提取后，處理成SQL數(shù)據(jù)庫(kù)要求的格式存儲(chǔ)。FabricSQL系統(tǒng)模型如圖3所示，一條設(shè)備資產(chǎn)的交易信息在區(qū)塊鏈網(wǎng)絡(luò)中經(jīng)過(guò)背書、打包、成塊和驗(yàn)證后寫入?yún)^(qū)塊鏈中，其數(shù)據(jù)源是用戶提交的原始數(shù)據(jù)，經(jīng)過(guò)SDK程序，實(shí)現(xiàn)對(duì)Fabric-CA節(jié)點(diǎn)和Fabric網(wǎng)絡(luò)的訪問(wèn)。在完成區(qū)塊上鏈后，F(xiàn)abric會(huì)發(fā)出特定的event來(lái)協(xié)助客戶端程序，客戶端通過(guò)SDK捕獲event事件，獲取交易信息的偵聽(tīng)狀態(tài)，并將其提供給數(shù)據(jù)處理模塊處理其中的有效交易，最終將有效交易的數(shù)據(jù)存儲(chǔ)在MySQL數(shù)據(jù)庫(kù)中。

圖3 FabricSQL系統(tǒng)模型

FabricSQL在區(qū)塊鏈網(wǎng)絡(luò)中的交易過(guò)程如算法1所示，首先判斷用戶的身份證書，確定用戶注冊(cè)信息，然后連接區(qū)塊鏈網(wǎng)絡(luò)，當(dāng)交易被認(rèn)可，成功發(fā)送給排序服務(wù)節(jié)點(diǎn)前，需要注冊(cè)偵聽(tīng)器。偵聽(tīng)器存在的目的是檢測(cè)交易狀態(tài)，因?yàn)閰^(qū)塊鏈上的交易數(shù)據(jù)包括有效交易和無(wú)效交易，如果直接將區(qū)塊鏈上的所有交易數(shù)據(jù)直接同步至SQL數(shù)據(jù)庫(kù)中，不僅會(huì)增加存儲(chǔ)負(fù)擔(dān)，還會(huì)對(duì)查詢結(jié)果的正確性產(chǎn)生直接影響。最后，當(dāng)包含交易的塊被提交至區(qū)塊鏈時(shí)，已注冊(cè)的偵聽(tīng)器會(huì)被觸發(fā)。

算法1：FabricSQL在區(qū)塊鏈網(wǎng)絡(luò)中的交易過(guò)程

輸入：用戶提交的原始交易數(shù)據(jù)

輸出：交易上鏈，觸發(fā)偵聽(tīng)器

(1)try {

(2) wallet = new FileSystemWallet(walletPath)

(3) if (!wallet.exists(user)) {

(4) return }

(5) 連接區(qū)塊鏈網(wǎng)絡(luò)，加入通道，調(diào)用鏈碼

(6) transaction=

contract.createTransaction(′transferDevice′)

(7) //完成偵聽(tīng)器的注冊(cè)功能

(8) transaction.addCommitListener({callback

function: Data2SQL})

(9) transaction.submit(transaction args)

(10) 斷開(kāi)區(qū)塊鏈網(wǎng)絡(luò)連接}

(11)catch{異常處理}

數(shù)據(jù)處理層，在偵聽(tīng)器觸發(fā)后，執(zhí)行回調(diào)函數(shù)Data2SQL，通過(guò)對(duì)交易狀態(tài)分析，返回所需的目標(biāo)交易。所以，本模塊以區(qū)塊中的每筆交易作為一個(gè)處理單元，將有效交易的信息進(jìn)行提取、分解，處理成不同的數(shù)據(jù)格式傳遞至后續(xù)的存儲(chǔ)層模塊。FabricSQL的數(shù)據(jù)處理過(guò)程如算法2所示。

算法2：FabricSQL數(shù)據(jù)處理過(guò)程

輸入：鏈上的每筆交易數(shù)據(jù)

輸出：每筆有效交易數(shù)據(jù)

(1)function Data2SQL(error, transId, status, blockNumber) {

(2) if status != VALID:

(3) return

(4) result = 由transId定位的交易信息

(5) obj=JSON.parse(result.transactionEnve-lope.payload.data)

(6) trans_time=result.transactionEnvelope.pay-load.Header.channel_header.timestamp

(7) data=obj[′senderID′,′receiverID′,′trans_time′,′deviceID′,′transId′, ′blockNumber′]

(8) insertData(data)

(9)}

3.4 交易數(shù)據(jù)存儲(chǔ)驗(yàn)證機(jī)制

FabricSQL的交易數(shù)據(jù)存儲(chǔ)驗(yàn)證機(jī)制是在MySQL數(shù)據(jù)庫(kù)中利用Salthash值，實(shí)現(xiàn)對(duì)交易數(shù)據(jù)的存儲(chǔ)和驗(yàn)證。Salthash是指對(duì)每筆交易數(shù)據(jù)進(jìn)行散列后，在數(shù)據(jù)的任意固定位置插入特定的字符串Salt，再進(jìn)行散列操作，這樣可以極大地降低數(shù)據(jù)被篡改的風(fēng)險(xiǎn)。

在FabricSQL存儲(chǔ)層中的區(qū)塊鏈文件系統(tǒng)和關(guān)系型數(shù)據(jù)庫(kù)MySQL都存儲(chǔ)著驗(yàn)證通過(guò)的交易數(shù)據(jù)，不同點(diǎn)是，SQL數(shù)據(jù)庫(kù)中只存儲(chǔ)有效交易的信息。當(dāng)交易數(shù)據(jù)傳至SQL數(shù)據(jù)庫(kù)時(shí)，每條交易數(shù)據(jù)順序追加，更新交易表和哈希表。在SQL數(shù)據(jù)庫(kù)中，交易表各字段的值記錄著每筆交易的重要信息，哈希表存儲(chǔ)著每筆交易的Salthash值，如式(1)所示，它是將Salt值、上一筆交易的Salthash值和此筆交易的哈希值相組合，并使用SHA256加密算法對(duì)其散列，得到的散列值即為此筆交易的最終哈希值。如果為第一筆交易，Salthash值是Salt值和此筆交易信息的哈希值組合哈希后的結(jié)果。FabricSQL在MySQL數(shù)據(jù)庫(kù)存儲(chǔ)數(shù)據(jù)的過(guò)程如算法3所示，首先與數(shù)據(jù)庫(kù)建立連接，然后將數(shù)據(jù)分別插入到對(duì)應(yīng)表中

cur_Salthash=sha256(Salt+pre_Salthash+
sha256(transdata))

(1)

算法3：FabricSQL在MySQL數(shù)據(jù)庫(kù)中存儲(chǔ)數(shù)據(jù)的過(guò)程

輸入：每筆有效交易數(shù)據(jù)

輸出：數(shù)據(jù)存儲(chǔ)在MySQL數(shù)據(jù)庫(kù)中

(1)function insertData(data){

(2) 連接MySQL數(shù)據(jù)庫(kù)

(3) connection.execute(

′insert into t_transactions values(?)′, data)

(4) //pre_Salthash指上一筆交易的Salthash值

(5) pre_Salthash = connection.execute(

′select Salthash from t_hash order by tid

desc limit 1′)

(6) //cur_Salthash指當(dāng)前交易的Salthash值

(7) cur_Salthash=sha256(pre_Salthash+Salt

+sha256(transdata))

(8) connection.execute(′insert into t_hash

values(?)′, (transId, cur_Salthash))

(9) 斷開(kāi)連接

(10)}

為防止數(shù)據(jù)發(fā)生更改的情況，數(shù)據(jù)庫(kù)中不會(huì)存儲(chǔ)Salt值。Salthash值之間的連接方式也使得有一筆交易發(fā)生篡改時(shí)，作惡者需要更改這條交易之后的所有交易的Salthash值，這必然會(huì)提高作惡的成本。所以，Salthash值的存儲(chǔ)和連接方式，實(shí)現(xiàn)交易數(shù)據(jù)不可篡改的特性。SQL數(shù)據(jù)庫(kù)中數(shù)據(jù)存儲(chǔ)的流程如圖4所示。

圖4 MySQL數(shù)據(jù)庫(kù)中數(shù)據(jù)存儲(chǔ)的流程

應(yīng)用層除了完成與區(qū)塊鏈網(wǎng)絡(luò)的交互，也負(fù)責(zé)查詢邏輯的實(shí)現(xiàn)。數(shù)據(jù)查詢校驗(yàn)的流程如圖5所示。當(dāng)收到用戶的查詢申請(qǐng)后，查詢模塊向存儲(chǔ)層提交查詢請(qǐng)求，存儲(chǔ)層將交易表各字段的值和哈希表中上一筆交易的pre_Salthash值，返回給校驗(yàn)?zāi)K，校驗(yàn)?zāi)K將返回值與Salt值相組合，使用SHA256加密算法對(duì)其散列，再將得到的散列值與哈希表返回的此筆交易的cur_Salthash值進(jìn)行比較，如果校驗(yàn)結(jié)果一致，將查詢結(jié)果返回給交互模塊，如果校驗(yàn)結(jié)果不一致，說(shuō)明SQL數(shù)據(jù)庫(kù)中的數(shù)據(jù)有被作惡者篡改的可能，返回的數(shù)據(jù)結(jié)果不可信。如果是數(shù)據(jù)庫(kù)中的第一筆交易，驗(yàn)證原理一致，只是不需要加入pre_Salthash值進(jìn)行驗(yàn)證。當(dāng)要查看用戶或資產(chǎn)的詳細(xì)信息時(shí)，交易表會(huì)關(guān)聯(lián)用戶數(shù)據(jù)表和資產(chǎn)數(shù)據(jù)表，返回用戶所需的全部信息。

4 實(shí)驗(yàn)與分析

4.1 理論分析

為了更好地進(jìn)行對(duì)比實(shí)驗(yàn)，分別搭建了Hyperledger Fabric區(qū)塊鏈系統(tǒng)以及本文所設(shè)計(jì)的FabricSQL系統(tǒng)。在實(shí)驗(yàn)中，Hyperledger Fabric區(qū)塊鏈系統(tǒng)選用相比LevelDB而言，查詢功能更加豐富的CouchDB數(shù)據(jù)庫(kù)作為原區(qū)塊鏈的狀態(tài)數(shù)據(jù)庫(kù)，F(xiàn)abricSQL選擇MySQL作為查詢數(shù)據(jù)庫(kù)，雖然CouchDB支持原生的json和字節(jié)數(shù)組的操作，但是相

圖5 數(shù)據(jù)查詢校驗(yàn)流程

較而言，關(guān)系型數(shù)據(jù)庫(kù)只需要一條簡(jiǎn)單的語(yǔ)句就可以實(shí)現(xiàn)復(fù)雜和豐富的查詢，查詢功能的可擴(kuò)展性強(qiáng)，可以更好的對(duì)數(shù)據(jù)進(jìn)行分析，滿足用戶的需求。

4.2 實(shí) 驗(yàn)

4.2.1 實(shí)驗(yàn)環(huán)境和實(shí)驗(yàn)數(shù)據(jù)

實(shí)驗(yàn)的開(kāi)發(fā)環(huán)境為Intel Core i5-3210M 2.50 GHz CPU和12 GB內(nèi)存的PC機(jī)。利用VMware Workstation14.1.2建立虛擬機(jī)，以模擬真實(shí)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)為內(nèi)存1 GB硬盤大小為20 GB的ubuntu16.04系統(tǒng)。其中，F(xiàn)abric系統(tǒng)，利用IBM的Hyperledger Fabric v1.4.0(https://github.com/hyperledger/fabric.git)開(kāi)源項(xiàng)目搭建環(huán)境，使用Go語(yǔ)言編寫Chaincode，使用Node.js語(yǔ)言編寫用于交互操作的SDK程序，包括用戶注冊(cè)、交易創(chuàng)建和交易查詢等功能；FabricSQL系統(tǒng)在硬件方面與Fabric系統(tǒng)相同，仍在同一計(jì)算機(jī)上使用相同的VMware軟件模擬設(shè)備結(jié)點(diǎn)，每個(gè)結(jié)點(diǎn)所擁有的計(jì)算資源和存儲(chǔ)資源均與Fabric系統(tǒng)的資源相同，保證兩組實(shí)驗(yàn)的硬件資源并無(wú)差異。特殊的是，F(xiàn)abricSQL添加了獨(dú)立的數(shù)據(jù)庫(kù)結(jié)點(diǎn)并在SDK程序中，增加對(duì)交易狀態(tài)判斷、有效交易提取和驗(yàn)證等功能，還針對(duì)MySQL數(shù)據(jù)庫(kù)開(kāi)發(fā)相應(yīng)的工具程序用于實(shí)現(xiàn)數(shù)據(jù)庫(kù)相關(guān)的增刪查改等一系列基本操作。

本實(shí)驗(yàn)的數(shù)據(jù)集來(lái)自設(shè)備資產(chǎn)管理數(shù)據(jù)(https://github.com/Y-tao/FabricSQL)，共6萬(wàn)用戶，約25萬(wàn)條交易數(shù)據(jù)，區(qū)塊鏈上已完成的交易數(shù)據(jù)量大小為1 GB。

4.2.2 實(shí)驗(yàn)分析

在FabricSQL和Fabric系統(tǒng)上分別進(jìn)行多組對(duì)照實(shí)驗(yàn)，通過(guò)查詢數(shù)據(jù)，對(duì)比分析FabricSQL模型的防篡改能力、查詢效率等多項(xiàng)性能。

實(shí)驗(yàn)1：在FabricSQL上，不經(jīng)過(guò)更改數(shù)據(jù)的正確流程，手動(dòng)惡意篡改數(shù)據(jù)庫(kù)內(nèi)的多項(xiàng)原始實(shí)驗(yàn)數(shù)據(jù)，然后進(jìn)行正常的查詢操作，測(cè)試FabricSQL模型的防篡改能力是否有效。

防篡改測(cè)試方案和結(jié)果如圖6所示，當(dāng)更改一筆設(shè)備的擁有者后，執(zhí)行查詢操作，因?yàn)橐恢滦孕ｒ?yàn)無(wú)法通過(guò)，發(fā)現(xiàn)篡改，所以會(huì)有錯(cuò)誤提示。而且，在SQL數(shù)據(jù)庫(kù)的哈希表中，Salthash值首尾相連，如果中間有改動(dòng)，必然會(huì)對(duì)后面的數(shù)據(jù)產(chǎn)生影響。通過(guò)實(shí)驗(yàn)結(jié)果可以發(fā)現(xiàn)，F(xiàn)abricSQL具有良好的防篡改能力。

圖6 FabricSQL防篡改測(cè)試

實(shí)驗(yàn)2：在FabricSQL和基于Fabric的區(qū)塊鏈系統(tǒng)上分別錄入相同的原始數(shù)據(jù)，然后分別查詢一筆交易的響應(yīng)時(shí)間，進(jìn)行對(duì)照實(shí)驗(yàn)。再通過(guò)更改交易量的規(guī)模，觀察分析FabricSQL模型在不同數(shù)據(jù)基數(shù)上的查詢效率及是否比區(qū)塊鏈系統(tǒng)的原始查詢操作有所優(yōu)化。

狀態(tài)數(shù)據(jù)查詢響應(yīng)時(shí)間如圖7所示，由于單個(gè)查詢以毫秒為單位完成，為了最小化隨機(jī)錯(cuò)誤的影響，實(shí)驗(yàn)中查詢時(shí)間是1000個(gè)獨(dú)立查詢的平均時(shí)間。圖中橫坐標(biāo)為已上鏈的交易數(shù)據(jù)量大小，分別為500 M和1000 M，縱坐標(biāo)是以10為基數(shù)的對(duì)數(shù)刻度，反映Fabric和FabricSQL進(jìn)行查詢操作的響應(yīng)時(shí)間，F(xiàn)abricSQL的查詢時(shí)間中已包含對(duì)每筆交易的安全性進(jìn)行驗(yàn)證的時(shí)間代價(jià)。通過(guò)對(duì)實(shí)驗(yàn)結(jié)果分析，可以看出FabricSQL的查詢效率比區(qū)塊鏈系統(tǒng)的原始查詢效率有顯著提升。

圖7 狀態(tài)數(shù)據(jù)的查詢時(shí)間

實(shí)驗(yàn)3：在設(shè)計(jì)的實(shí)驗(yàn)?zāi)Ｐ秃突贔abric的區(qū)塊鏈系統(tǒng)上，基于相同版本號(hào)的多條歷史交易數(shù)據(jù)，分別進(jìn)行溯源查詢操作。再通過(guò)更改交易的版本號(hào)，觀察分析FabricSQL模型在不同版本號(hào)下的查詢效率及是否比區(qū)塊鏈系統(tǒng)的溯源查詢有所優(yōu)化。

歷史數(shù)據(jù)查詢時(shí)間如圖8所示，在數(shù)據(jù)庫(kù)中按照不同的版本號(hào)篩選出候選數(shù)據(jù)，在候選數(shù)據(jù)中隨機(jī)查詢5個(gè)設(shè)備，計(jì)算平均查詢時(shí)間。實(shí)驗(yàn)中，分別在FabricSQL和Fabric上對(duì)版本號(hào)為10，20，30，40，50的交易數(shù)據(jù)進(jìn)行溯源查詢，通過(guò)對(duì)實(shí)驗(yàn)結(jié)果分析，可以看出FabricSQL比區(qū)塊鏈系統(tǒng)的溯源查詢效率有顯著提升，且查詢代價(jià)主要集中于最新版本的查詢時(shí)間。

圖8 歷史數(shù)據(jù)的查詢時(shí)間

5 結(jié)束語(yǔ)

Hyperledger Fabric通過(guò)文件系統(tǒng)和key-value數(shù)據(jù)庫(kù)實(shí)現(xiàn)對(duì)區(qū)塊鏈數(shù)據(jù)的查詢，但是存在著對(duì)其存儲(chǔ)數(shù)據(jù)的訪問(wèn)方法支持有限、查詢功能單一且查詢功能的可擴(kuò)展性不強(qiáng)、查詢效率較低等問(wèn)題。本文針對(duì)區(qū)塊鏈在查詢方面的不足，提出一種區(qū)塊鏈數(shù)據(jù)的關(guān)系查詢解決方案FabricSQL，該方案在區(qū)塊鏈網(wǎng)絡(luò)中完成對(duì)交易數(shù)據(jù)驗(yàn)證和更新后，根據(jù)返回的事件狀態(tài)提取其中有效交易的數(shù)據(jù)，并將其按照防篡改方案存儲(chǔ)至SQL數(shù)據(jù)庫(kù)中，依據(jù)存儲(chǔ)驗(yàn)證機(jī)制實(shí)現(xiàn)對(duì)區(qū)塊鏈數(shù)據(jù)的關(guān)系查詢。在實(shí)驗(yàn)?zāi)Ｐ秃虷yperledger Fabric上進(jìn)行多組查詢性能的對(duì)比實(shí)驗(yàn)結(jié)果表明，本文提出的區(qū)塊鏈數(shù)據(jù)的關(guān)系查詢解決方案FabricSQL具有豐富的查詢功能、良好的防篡改性能以及高效的查詢效率。

區(qū)塊鏈的廣泛應(yīng)用需要良好的查詢性能支持，后續(xù)還需要與其它區(qū)塊鏈數(shù)據(jù)庫(kù)方案在防篡改能力、空間復(fù)雜度和時(shí)間復(fù)雜度等方面進(jìn)行比較，從而改進(jìn)實(shí)驗(yàn)方法，優(yōu)化FabricSQL方案。