一種面向區(qū)塊鏈的鏈下數(shù)據(jù)庫(kù)高吞吐量可驗(yàn)證查詢方法

隋 源，汪 衛(wèi)，鄧 雪

1(復(fù)旦大學(xué) 軟件學(xué)院 數(shù)據(jù)庫(kù)與海量信息處理實(shí)驗(yàn)室，上海 200433)2(復(fù)旦大學(xué) 計(jì)算機(jī)科學(xué)技術(shù)學(xué)院 數(shù)據(jù)庫(kù)與海量信息處理實(shí)驗(yàn)室，上海 200433)3(珠海復(fù)旦創(chuàng)新研究院，廣東 珠海 518057)

E-mail：18212010027@fudan.edu.cn

1 引 言

從2009年最初的比特幣開始，區(qū)塊鏈技術(shù)也不單單局限于加密數(shù)字貨幣的應(yīng)用，更多的研究逐漸的將重點(diǎn)放在如何將數(shù)據(jù)管理能夠與區(qū)塊鏈更好的結(jié)合.區(qū)塊鏈本質(zhì)上是一個(gè)去中心化的不可篡改的分布式賬本，區(qū)塊鏈技術(shù)是集成數(shù)據(jù)庫(kù)、共識(shí)機(jī)制、密碼學(xué)、分布式數(shù)據(jù)存儲(chǔ)等多個(gè)方向的應(yīng)用研究.區(qū)塊鏈網(wǎng)絡(luò)中每個(gè)節(jié)點(diǎn)都是互相獨(dú)立的個(gè)體，彼此不信任對(duì)方，通過密碼學(xué)的手段網(wǎng)絡(luò)中的所有節(jié)點(diǎn)選舉出背書節(jié)點(diǎn)，并定期更換背書節(jié)點(diǎn)，維護(hù)一個(gè)哈希加密的鏈?zhǔn)綌?shù)據(jù)結(jié)構(gòu).從數(shù)據(jù)庫(kù)的角度看待區(qū)塊鏈，區(qū)塊鏈?zhǔn)且粋€(gè)存儲(chǔ)了大量時(shí)間戳數(shù)據(jù)的數(shù)據(jù)庫(kù).區(qū)塊鏈自身需要大量的共識(shí)和密碼計(jì)算來保證自身的效率，這就導(dǎo)致了傳統(tǒng)結(jié)構(gòu)的區(qū)塊鏈的系統(tǒng)吞吐量都比較低，不能滿足用戶的需要.

區(qū)塊鏈本身具有防篡改的特性，隨著區(qū)塊鏈在其他領(lǐng)域的應(yīng)用和發(fā)展，例如金融、供應(yīng)鏈、物流等領(lǐng)域，用戶對(duì)可驗(yàn)證查詢的需求也越來越高，比如用戶想要查詢“昨天晚上六點(diǎn)”這樣的歷史數(shù)據(jù)，可驗(yàn)證查詢是指提供查詢服務(wù)的節(jié)點(diǎn)在把查詢結(jié)果返回給請(qǐng)求查詢的用戶的同時(shí)，也會(huì)返回一個(gè)可以證明查詢結(jié)果正確可靠的數(shù)據(jù)結(jié)構(gòu).區(qū)塊鏈數(shù)據(jù)管理研究方向是從數(shù)據(jù)庫(kù)的角度，運(yùn)用成熟的傳統(tǒng)的數(shù)據(jù)庫(kù)技術(shù)來解決區(qū)塊鏈系統(tǒng)存在的問題.由此很多數(shù)據(jù)庫(kù)化的區(qū)塊鏈系統(tǒng)和新的方法被提出.區(qū)塊鏈數(shù)據(jù)管理是一個(gè)全新的方向，主要涉及的領(lǐng)域有數(shù)據(jù)溯源、查詢驗(yàn)證、版本控制等等.許多的數(shù)據(jù)庫(kù)研究機(jī)構(gòu)IBM，Oracle和SAP以及諸如FlureedDB[1]，BigchainDB[2]，和SwarmDB[3]，也都在致力于研究成熟的數(shù)據(jù)庫(kù)技術(shù)如何在區(qū)塊鏈中加以利用.

為此，本文提出了一種通過增加鏈下數(shù)據(jù)庫(kù)層的方式，增加系統(tǒng)的每秒事務(wù)吞吐量，如圖1所示是一種增加鏈下數(shù)據(jù)庫(kù)層的方法示意圖.鏈下數(shù)據(jù)庫(kù)負(fù)責(zé)存儲(chǔ)全部的數(shù)據(jù)，鏈下數(shù)據(jù)庫(kù)的類型可以是一個(gè)性能成熟強(qiáng)大的關(guān)系型或者是NoSQL類型的數(shù)據(jù)庫(kù)，本文中鏈下數(shù)據(jù)庫(kù)采用了HBase(1)https：//hbase.apache.org/，首先HBase適合海量數(shù)據(jù)，這對(duì)于區(qū)塊鏈源源不斷產(chǎn)生時(shí)間序列數(shù)據(jù)的情況是一個(gè)很好的優(yōu)勢(shì).它的易拓展、高并發(fā)的特點(diǎn)，對(duì)于本身是分布式的區(qū)塊鏈網(wǎng)絡(luò)有著很大的幫助.鏈下數(shù)據(jù)庫(kù)按批次的將全部數(shù)據(jù)存儲(chǔ)，并計(jì)算每個(gè)批次的消息摘要值，存放在區(qū)塊鏈上.這樣的結(jié)構(gòu)，鏈下數(shù)據(jù)庫(kù)可以提供性能的保證，區(qū)塊鏈可以提供安全的保證.

本文工作如下：

提出一種區(qū)塊鏈結(jié)合鏈下數(shù)據(jù)庫(kù)的模式，以應(yīng)對(duì)系統(tǒng)每秒吞吐量比較高的應(yīng)用場(chǎng)景；

基于這種模式，提出了一種可以根據(jù)信任程度不同的多模式可驗(yàn)證查詢方法和一種異步可驗(yàn)證查詢方法；

對(duì)于鏈下數(shù)據(jù)庫(kù)結(jié)合區(qū)塊鏈的方式，進(jìn)行了與沒有鏈下數(shù)據(jù)庫(kù)的區(qū)塊鏈的對(duì)比試驗(yàn)，并驗(yàn)證了可驗(yàn)證查詢的效率.

2 區(qū)塊鏈數(shù)據(jù)管理面臨問題及挑戰(zhàn)

2.1 相關(guān)工作

目前區(qū)塊鏈的研究已經(jīng)不止局限于代幣，國(guó)外目前已經(jīng)有了一些區(qū)塊鏈在工業(yè)領(lǐng)域應(yīng)用的研究，大致可以分為幾個(gè)方面：

提升事務(wù)處理速度(TPS)：由于區(qū)塊鏈的防篡改特性，必須使用大量的密碼學(xué)和共識(shí)機(jī)制來保證系統(tǒng)的安全穩(wěn)定，這就導(dǎo)致了大部分的區(qū)塊鏈系統(tǒng)的事物處理能力遇到了瓶頸，為了提升系統(tǒng)的事務(wù)處理能力，Ankur Sharma等人[4]通過重新組織事務(wù)順序，識(shí)別事務(wù)語(yǔ)義來減少失效事務(wù)的數(shù)量，并盡早的識(shí)別確定失效的事務(wù)，來提升事務(wù)處理的能力.通過改變區(qū)塊鏈系統(tǒng)的結(jié)構(gòu)也可以達(dá)到提升系統(tǒng)的事務(wù)處理能力，Hung Dang[5]通過分片的方式，并行產(chǎn)生區(qū)塊，這種并行出塊的結(jié)構(gòu)在以太坊等區(qū)塊鏈系統(tǒng)中也得到了利用.

還有的研究[6-11]通過增加外源數(shù)據(jù)庫(kù)來實(shí)現(xiàn)提升事務(wù)處理能力的效果，因?yàn)橐恍┏墒斓臄?shù)據(jù)庫(kù)的事務(wù)處理能力很強(qiáng)，可以通過把數(shù)據(jù)放在線下，加密證據(jù)放在線上的方式來達(dá)到提升事務(wù)處理速度的效果.

可驗(yàn)證查詢：區(qū)塊鏈與傳統(tǒng)數(shù)據(jù)庫(kù)相比，不可篡改的特性是一個(gè)很大的優(yōu)勢(shì)，但是目前大部分的區(qū)塊鏈系統(tǒng)并不支持可驗(yàn)證查詢，Cheng Xu 等人[6]通過更改區(qū)塊結(jié)構(gòu)，來支持可驗(yàn)證的查詢，并且保證查詢結(jié)果的完整性，并且在效率上也有一定的保證.

版本控制：分叉問題是區(qū)塊鏈系統(tǒng)的一個(gè)缺陷，比特幣和以太坊自從誕生以來都經(jīng)過了很多次硬分叉.但是Sheng Wang 等人[7]通過一種Merkle有向圖(Merkle DAG)的數(shù)據(jù)結(jié)構(gòu)，將這種缺陷利用到了版本控制技術(shù)領(lǐng)域中，有效的解決了版本之間的空間效率問題.

數(shù)據(jù)溯源：在現(xiàn)有區(qū)塊鏈中查詢數(shù)據(jù)歷史只能通過重放所有交易來完成，這種方法適用于大規(guī)模，離線分析，但不適合在線事務(wù)處理.在工業(yè)應(yīng)用領(lǐng)域溯源查詢往往是比較常見的.PingchengRuan等人[8]通過在Hyperledger和一個(gè)名為ForkBase的區(qū)塊鏈優(yōu)化存儲(chǔ)系統(tǒng)之上實(shí)現(xiàn)了LineageChain，支持高效的溯源查詢并且可以有效的利用空間資源.

2.2 相關(guān)技術(shù)——Hyperledger Fabric

Hyperledger Fabric(2)https：//www.hyperledger.org/use/fabric是IBM提出的一種聯(lián)盟鏈區(qū)塊鏈系統(tǒng)，在這個(gè)網(wǎng)絡(luò)中，每個(gè)節(jié)點(diǎn)都是已知的，每個(gè)節(jié)點(diǎn)都運(yùn)行著一個(gè)賬本的實(shí)例，除此之外每個(gè)節(jié)點(diǎn)存儲(chǔ)著一份當(dāng)前狀態(tài)的數(shù)據(jù).該系統(tǒng)有著高效的事務(wù)處理流，分為模擬、排序、驗(yàn)證、提交4個(gè)階段.在模擬階段，client向?qū)eer的指定子集(背書節(jié)點(diǎn))提交事務(wù)建議.背書節(jié)點(diǎn)根據(jù)其當(dāng)前狀態(tài)的本地副本模擬交易.在排序階段，排序服務(wù)在所有接收到的事務(wù)之間建立全局順序，并以塊的粒度將排序好的事務(wù)分配給網(wǎng)絡(luò)的所有peer.在驗(yàn)證階段，所有對(duì)peer根據(jù)背書分別驗(yàn)證所接收塊內(nèi)的事務(wù).在提交階段，將塊追加到本地賬本，并將有效交易記錄所做的更改應(yīng)用于當(dāng)前狀態(tài).

Hyperledger Fabric是一種聯(lián)盟鏈的架構(gòu)，所有的節(jié)點(diǎn)在整個(gè)網(wǎng)絡(luò)中每時(shí)每刻都是已知的.每個(gè)節(jié)點(diǎn)都被分配到一個(gè)組織中，這意味著每個(gè)節(jié)點(diǎn)被所在的組織管理和監(jiān)督.在一個(gè)組織中，所有節(jié)點(diǎn)都互相信任，每個(gè)節(jié)點(diǎn)都運(yùn)行一個(gè)Fabric的本地實(shí)例，實(shí)例包括全網(wǎng)賬本的副本，具體是全網(wǎng)的交易事務(wù)的有序序列(即包括有效事務(wù)，又包括無(wú)效事務(wù)).除了全網(wǎng)賬本的副本以外，每個(gè)節(jié)點(diǎn)還以狀態(tài)數(shù)據(jù)庫(kù)的形式包含當(dāng)前狀態(tài)，除了在模擬階段和驗(yàn)證階段都扮演重要角色的節(jié)點(diǎn)之外，還有一個(gè)名為排序服務(wù)的單獨(dú)節(jié)點(diǎn)，它是排序階段的核心組件，被認(rèn)為是值得信任的.

2.3 面臨問題及挑戰(zhàn)

目前的在食品藥品等制造生產(chǎn)中，數(shù)據(jù)防偽、數(shù)據(jù)溯源等是很重要的技術(shù)，用戶或者監(jiān)管部門需要知道每個(gè)環(huán)節(jié)中的數(shù)據(jù)，每個(gè)環(huán)節(jié)的數(shù)據(jù)也要保證安全可靠防篡改.考慮這樣一個(gè)場(chǎng)景，在某種食品藥品生產(chǎn)運(yùn)輸銷售的過程中，涉及到，生產(chǎn)商，運(yùn)輸商，銷售商，消費(fèi)者和一些監(jiān)管部門.

當(dāng)消費(fèi)者拿到自己購(gòu)買的商品后，若想知道該商品是否是符合生產(chǎn)標(biāo)準(zhǔn)的，就需要溯源可驗(yàn)證查詢的支持.例如在運(yùn)輸?shù)倪^程中，運(yùn)輸環(huán)境需要低于一定的溫度，那么運(yùn)輸商就需要按照時(shí)間序列將溫度、濕度等信息進(jìn)行保存.傳統(tǒng)的溯源的方法的數(shù)據(jù)庫(kù)僅僅考慮了數(shù)據(jù)的存儲(chǔ)，并沒有考慮存儲(chǔ)數(shù)據(jù)的安全性.

區(qū)塊鏈本身有防篡改的特性，在防偽溯源領(lǐng)域有先天的優(yōu)勢(shì)，但是由于大量的共識(shí)算法導(dǎo)致區(qū)塊鏈的每秒事務(wù)吞吐量(TPS)遇到了瓶頸.普通的關(guān)系型數(shù)據(jù)庫(kù)或者NoSQL并不能提供防篡改的安全性保障.

由于在這里想解決的問題是提升區(qū)塊鏈的每秒事務(wù)吞吐量(TPS)，一些以代幣為基礎(chǔ)的區(qū)塊鏈應(yīng)用在事務(wù)吞吐量角度的缺陷較為嚴(yán)重，Bitcoin(3)https：//bitcoin.org/en/、Ethereum(4)https：//ethereum.org/這些系統(tǒng)在事務(wù)吞吐量方面的表現(xiàn)并沒有任何優(yōu)勢(shì).而一些以物聯(lián)網(wǎng)為基礎(chǔ)的區(qū)塊鏈應(yīng)用平臺(tái)在事務(wù)吞吐量方面優(yōu)勢(shì)就很明顯，如Hyperledger Fabric、IOTA(5)https：//www.iota.org/.

Hyperledger Fabric是一個(gè)開源的聯(lián)盟鏈框架，繼承獨(dú)立的開放協(xié)議和標(biāo)準(zhǔn)，通過框架方法和專用模塊，包括各區(qū)塊鏈的共識(shí)機(jī)制和存儲(chǔ)方式，以及身份服務(wù)、訪問控制和智能合約.但是Hyperledger Fabric在真正部署應(yīng)用的過程中還存在很多不足：

1) 事務(wù)處理速度不夠，通過實(shí)驗(yàn)獲得到當(dāng)使用CouchDB作為狀態(tài)數(shù)據(jù)庫(kù)時(shí)TPS在300個(gè)/秒左右，這樣的事務(wù)處理能力是遠(yuǎn)遠(yuǎn)不夠的；

2) 查詢功能不夠完備，底層數(shù)據(jù)庫(kù)是levelDB，只支持簡(jiǎn)單的等值查詢.

為了解決以上的兩個(gè)問題，本文的思路是在Hyperledger Fabric架構(gòu)的基礎(chǔ)上引入一個(gè)外源數(shù)據(jù)庫(kù)，由外源數(shù)據(jù)庫(kù)提供存儲(chǔ)及查詢效率的保證，區(qū)塊鏈提供數(shù)據(jù)安全的保證.

3 鏈下數(shù)據(jù)庫(kù)改進(jìn)的Hyperledger Fabric架構(gòu)

3.1 高吞吐量Hyperledger Fabric+外源數(shù)據(jù)庫(kù)架構(gòu)

雖然Hyperledger Fabric的每秒事務(wù)吞吐量較傳統(tǒng)結(jié)構(gòu)的區(qū)塊鏈相比已經(jīng)有了很大的提升，但是并沒有達(dá)到關(guān)系型或者NoSQL類型數(shù)據(jù)庫(kù)那樣高的標(biāo)準(zhǔn)，為了更進(jìn)一步的提升每秒事務(wù)吞吐量，在Hyperledger的基礎(chǔ)上加入一層外源數(shù)據(jù)庫(kù)，外源數(shù)據(jù)庫(kù)為區(qū)塊鏈提供事務(wù)吞吐量.

圖1 鏈下數(shù)據(jù)庫(kù)架構(gòu)Fig.1 Off-chain database schema

以HBase作為一個(gè)例子，HBase作為一個(gè)鏈下數(shù)據(jù)庫(kù)，存放所有的數(shù)據(jù)，并將數(shù)據(jù)按照批次進(jìn)行打包計(jì)算消息摘要值，僅將消息摘要值存放到區(qū)塊鏈上，這樣的做法會(huì)大大提升每秒事務(wù)吞吐量.這樣的一個(gè)HBase作為區(qū)塊鏈的鏈下數(shù)據(jù)庫(kù)架構(gòu)如圖1所示.

圖1中有4種類型的節(jié)點(diǎn)分別是client、peer、order和data center.節(jié)點(diǎn)作用見表1，Data center節(jié)點(diǎn)負(fù)責(zé)存儲(chǔ)所有數(shù)據(jù)，并定期檢查數(shù)據(jù)安全性；client節(jié)點(diǎn)負(fù)責(zé)與用戶進(jìn)行交互，與peer節(jié)點(diǎn)進(jìn)行通信；peer節(jié)點(diǎn)是核心節(jié)點(diǎn)，負(fù)責(zé)背書、記賬，將智能合約變成狀態(tài)更新發(fā)送給order節(jié)點(diǎn)，peer節(jié)點(diǎn)還存儲(chǔ)了區(qū)塊鏈中所有的交易數(shù)據(jù)，即每個(gè)批次的數(shù)據(jù)的消息摘要值，并不是所有的數(shù)據(jù)，全數(shù)據(jù)在data center節(jié)點(diǎn)中存儲(chǔ)；order節(jié)點(diǎn)提供排序服務(wù)，將peer發(fā)送給order的交易數(shù)據(jù)排序并產(chǎn)生區(qū)塊，廣播給全網(wǎng)的peer節(jié)點(diǎn).

表1 節(jié)點(diǎn)類型及作用Table 1 Node types and functions

在某食品生產(chǎn)銷售的過程中，有生產(chǎn)商、運(yùn)輸商、銷售商和消費(fèi)者群體這幾個(gè)相互獨(dú)立的組織，他們之間互相不信任.那么生產(chǎn)商、運(yùn)輸商和銷售商就可以構(gòu)成3個(gè)組織，每個(gè)組織都實(shí)時(shí)的產(chǎn)生自己的數(shù)據(jù)并存放到鏈下數(shù)據(jù)庫(kù)中，并通過3個(gè)組織的區(qū)塊鏈網(wǎng)絡(luò)對(duì)數(shù)據(jù)進(jìn)行加密，區(qū)塊鏈?zhǔn)沟镁€下數(shù)據(jù)庫(kù)中的數(shù)據(jù)不可篡改.

3.2 數(shù)據(jù)更新維護(hù)方法

溯源系統(tǒng)中，數(shù)據(jù)是實(shí)時(shí)產(chǎn)生，例如在運(yùn)輸?shù)倪^程中傳感器產(chǎn)生時(shí)間序列數(shù)據(jù)，這些時(shí)間序列數(shù)據(jù)需要實(shí)時(shí)的存入，通過client節(jié)點(diǎn)發(fā)送給data center節(jié)點(diǎn)，data center節(jié)點(diǎn)首先緩存這些數(shù)據(jù)，當(dāng)數(shù)據(jù)達(dá)到一定數(shù)量時(shí)(如100條)，數(shù)據(jù)中心節(jié)點(diǎn)將這一定數(shù)量的數(shù)據(jù)打包成一個(gè)批次，并計(jì)算消息摘要值.之后data center將消息摘要值通過peer節(jié)點(diǎn)添加到區(qū)塊鏈上.

為了方便說明，給出一個(gè)例子：假設(shè)只有一個(gè)組織(例如生產(chǎn)商)，生產(chǎn)商需要將生產(chǎn)過程中的數(shù)據(jù)存入到鏈下數(shù)據(jù)庫(kù)中并且存證以便消費(fèi)者或者監(jiān)管部門查詢.組織內(nèi)部有client節(jié)點(diǎn)、peer節(jié)點(diǎn)、order節(jié)點(diǎn)和數(shù)據(jù)中心節(jié)點(diǎn)，client節(jié)點(diǎn)源源不斷的接收到時(shí)間序列數(shù)據(jù)(例如傳感器數(shù)據(jù))，假設(shè)client收到的數(shù)據(jù)，并向data center節(jié)點(diǎn)(HBase)發(fā)送.

組織1的data center節(jié)點(diǎn)設(shè)置每10條數(shù)據(jù)為一個(gè)批次，時(shí)刻到時(shí)刻，組織1的data center節(jié)點(diǎn)插入了10條數(shù)據(jù)如表2所示.

t1時(shí)刻到t2時(shí)刻，組織1的data center節(jié)點(diǎn)生成了10條數(shù)據(jù)如表3所示.

Data center節(jié)點(diǎn)將傳感器時(shí)刻到時(shí)刻的數(shù)據(jù)作為第1批次的數(shù)據(jù)打包在一起，并計(jì)算消息摘要值，為方便說明，消息摘要值采用SHA256計(jì)算方法.

根據(jù)表2中傳感器時(shí)刻到數(shù)據(jù)構(gòu)建一個(gè)二維數(shù)據(jù)，所計(jì)算出來的消息摘要值為911c6da8a8da020fe625d98553f23383，data center節(jié)點(diǎn)將它保存，并且通過client節(jié)點(diǎn)將存到區(qū)塊鏈中.

表2 第1批次的數(shù)據(jù)Table 2 First batch data

表3 第2批次的數(shù)據(jù)Table 3 Second batch data

同理，表3中的數(shù)據(jù)計(jì)算出消息摘要值為f725063aa16bed9c971df65473c0b312，data center節(jié)點(diǎn)同樣將它保存，并且通過cli節(jié)點(diǎn)將存到區(qū)塊鏈中.

算法1.數(shù)據(jù)插入算法(Insert Data)

輸入：一段時(shí)間序列數(shù)據(jù)Vector

輸出：true or false

數(shù)據(jù)中心節(jié)點(diǎn)Data Center：

1.functionBoolean

插入數(shù)據(jù)(Vector，data，invoke)

2. 數(shù)據(jù)緩沖區(qū).append(data)

3.while(緩沖區(qū)達(dá)到數(shù)據(jù)塊大小){

4. Hx=計(jì)算消息摘要(數(shù)據(jù)緩沖區(qū))

5. putDB(Hx)//將Hx放入數(shù)據(jù)中心中

6. putBLC(Hx) //將Hx放入?yún)^(qū)塊鏈中

7.returntrue

8. }

9. return true

算法1的1-2行表示當(dāng)數(shù)據(jù)量沒有達(dá)到預(yù)先設(shè)定的數(shù)據(jù)塊大小時(shí)，將數(shù)據(jù)暫時(shí)放入緩沖區(qū)；3-7行表示，如果緩沖區(qū)中的數(shù)據(jù)達(dá)到預(yù)先設(shè)定的數(shù)據(jù)塊大小，則計(jì)算數(shù)據(jù)塊消息摘要，并放入數(shù)據(jù)庫(kù)和區(qū)塊鏈中.

如圖2所示，data1數(shù)據(jù)代表傳感器第一個(gè)批次的數(shù)據(jù)，data center節(jié)點(diǎn)將它計(jì)算消息摘要值并將它同時(shí)存放在data center和區(qū)塊鏈中，算法1說明了數(shù)據(jù)插入的過程.

3.3 數(shù)據(jù)存放方式

在生產(chǎn)銷售溯源場(chǎng)景中，在生產(chǎn)商生產(chǎn)的過程中，需要將全數(shù)據(jù)記錄在data center節(jié)點(diǎn)，比如需要記錄的傳感器溫度，傳感器將溫度數(shù)據(jù)實(shí)時(shí)的傳送給data center節(jié)點(diǎn)，區(qū)塊鏈負(fù)責(zé)對(duì)data center節(jié)點(diǎn)進(jìn)行加密.

圖2 插入數(shù)據(jù)示意圖Fig.2 Insert data schema

Data center節(jié)點(diǎn)在整個(gè)結(jié)構(gòu)中起著很重要的作用，它負(fù)責(zé)存儲(chǔ)全數(shù)據(jù)，定期檢查數(shù)據(jù)的安全可靠性，為全網(wǎng)提供可靠的查詢服務(wù)，所以data center節(jié)點(diǎn)的安全性是很重要的一個(gè)環(huán)節(jié).單純的集中式的data center節(jié)點(diǎn)會(huì)存在容易被攻擊、宕機(jī)后只有一個(gè)節(jié)點(diǎn)無(wú)法再繼續(xù)提供服務(wù)的問題.為了解決這些問題，data center節(jié)點(diǎn)不應(yīng)該僅僅有中心化模式，在這里考慮3種模式的data center，第1種是中心化的data center節(jié)點(diǎn)；第2種是data center節(jié)點(diǎn)不只有一個(gè)，而是有很多個(gè)備份；第3種是采用分布式數(shù)據(jù)庫(kù)，通過Hadoop搭建分布式HBase.

3.3.1 中心化HBase

中心化的HBase所有的組織公用一個(gè)data center節(jié)點(diǎn)，在實(shí)際的溯源場(chǎng)景中，如圖3(a)所示，這個(gè)HBase節(jié)點(diǎn)存儲(chǔ)全網(wǎng)的數(shù)據(jù)，包括生產(chǎn)商、運(yùn)輸商、和銷售商的數(shù)據(jù)，定期打包批次數(shù)據(jù)，并為全網(wǎng)提供查詢和驗(yàn)證支持.

3.3.2 備份HBase

單節(jié)點(diǎn)的HBase缺陷是很明顯的，比如當(dāng)唯一好的HBase節(jié)點(diǎn)收到攻擊時(shí)，沒有其他備份節(jié)點(diǎn)，在唯一的HBase節(jié)點(diǎn)宕機(jī)之后，無(wú)法保證整個(gè)網(wǎng)絡(luò)的正確有效的運(yùn)行.

第2種網(wǎng)絡(luò)結(jié)構(gòu)是HBase節(jié)點(diǎn)有多個(gè)備份，在圖3(b)中，每個(gè)組織都有一個(gè)HBase節(jié)點(diǎn)，每個(gè)HBase節(jié)點(diǎn)都保存著全網(wǎng)的所有數(shù)據(jù)，當(dāng)其中某一個(gè)HBase節(jié)點(diǎn)出現(xiàn)問題宕機(jī)時(shí)，其余的HBase節(jié)點(diǎn)可以繼續(xù)保證全網(wǎng)的運(yùn)行.

3.3.3 分布式HBase

多備份的HBase節(jié)點(diǎn)雖然可以保證一定的安全可靠性，但是缺少有效的數(shù)據(jù)同步的方法，不同之間的HBase節(jié)點(diǎn)之間保證數(shù)據(jù)的一致較為困難.為此data center節(jié)點(diǎn)可以采用分布式數(shù)據(jù)庫(kù)，例如HBase可以通過Hadoop支持實(shí)現(xiàn)分布式.

如圖3(c)，分布式HBase通過DFS的支持，作為全網(wǎng)的data center節(jié)點(diǎn)，這里data center節(jié)點(diǎn)已經(jīng)不是一個(gè)中心化的結(jié)構(gòu)了，區(qū)塊鏈為分布式的外源數(shù)據(jù)庫(kù)(HBase)提供了安全性的保障.

圖3 數(shù)據(jù)不同存放方式Fig.3 Different storage methods of data

4 高吞吐量多模式可驗(yàn)證查詢方法

4.1 多模式可驗(yàn)證應(yīng)用場(chǎng)景

在溯源的過程中，可驗(yàn)證查詢是非常重要的技術(shù)，例如生產(chǎn)商、運(yùn)輸商、銷售商、用戶之間互相不信任.外源數(shù)據(jù)庫(kù)不止為整個(gè)網(wǎng)絡(luò)提供吞吐量的支持，還為全網(wǎng)提供多模式可驗(yàn)證查詢的支持.區(qū)塊鏈本身具有防篡改的特性，利用這個(gè)防篡改的特性，可以為用戶提供可驗(yàn)證查詢，即用戶請(qǐng)求查詢時(shí)，提供查詢服務(wù)的節(jié)點(diǎn)(HBase節(jié)點(diǎn))，在返回查詢結(jié)果的同時(shí)，返回給用戶一個(gè)可以證明查詢結(jié)果完整正確的數(shù)據(jù)結(jié)構(gòu).

當(dāng)用戶向HBase節(jié)點(diǎn)請(qǐng)求查詢時(shí)，HBase首先通過查詢接口將符合條件的數(shù)據(jù)，根據(jù)查詢結(jié)果的數(shù)據(jù)的批次，找到同批次的所有數(shù)據(jù)，將它們按照時(shí)間戳重新排列起來，重新計(jì)算消息散列值，并從區(qū)塊鏈中查詢到該批數(shù)據(jù)未被篡改過的最初的消息摘要值，將新計(jì)算的消息散列值與從區(qū)塊鏈上拿到的消息散列值進(jìn)行比對(duì)，驗(yàn)證查詢結(jié)果是否是正確的.

圖4 多模式驗(yàn)證查詢流程圖Fig.4 Multi-schema validation query

根據(jù)請(qǐng)求查詢的節(jié)點(diǎn)對(duì)data center節(jié)點(diǎn)信任程度不同，可以采用不同模式的驗(yàn)證查詢方式，當(dāng)請(qǐng)求查詢的節(jié)點(diǎn)對(duì)data center信任程度較低時(shí)，需要采用代價(jià)比較高的全數(shù)據(jù)驗(yàn)證方式；當(dāng)請(qǐng)求查詢的節(jié)點(diǎn)對(duì)data center信任程度中等時(shí)，可以采用代價(jià)相對(duì)沒有那么高的data center節(jié)點(diǎn)代替驗(yàn)證的查詢方式；當(dāng)請(qǐng)求查詢的節(jié)點(diǎn)對(duì)data center的信任程度比較高時(shí)，可以采用代價(jià)較小的簡(jiǎn)單驗(yàn)證查詢方式.多模式驗(yàn)證查詢的流程圖見圖4.

圖5 多模式數(shù)據(jù)驗(yàn)證Fig.5 Multi-mode verifiable query method

4.2 簡(jiǎn)單驗(yàn)證查詢

當(dāng)請(qǐng)求查詢的節(jié)點(diǎn)對(duì)HBase節(jié)點(diǎn)信任程度較高的時(shí)候，驗(yàn)證查詢的方式可以采用簡(jiǎn)單驗(yàn)證查詢.

Client節(jié)點(diǎn)首先向HBase節(jié)點(diǎn)發(fā)送查詢請(qǐng)求，HBase節(jié)點(diǎn)查詢到結(jié)果和結(jié)果的批次信息，通過批次信息在區(qū)塊鏈中查詢到最初的未被篡改的消息摘要值，將這個(gè)消息散列值與在HBase中的消息散列值進(jìn)行比較，若比較結(jié)果是相同的則，說明查詢結(jié)果沒有問題，若比較結(jié)果是不同的則說明查詢結(jié)果有可能是偽造的.簡(jiǎn)單驗(yàn)證查詢示意圖見圖5.

簡(jiǎn)單驗(yàn)證查詢過程的系統(tǒng)開銷主要來自于從區(qū)塊鏈中取得到消息摘要值，除此之外簡(jiǎn)單驗(yàn)證查詢的查詢效率與傳統(tǒng)數(shù)據(jù)庫(kù)基本相同，事實(shí)上查詢效率大部分取決于鏈下數(shù)據(jù)庫(kù)的種類，采用NoSQL或者關(guān)系型數(shù)據(jù)庫(kù)都可以保證系統(tǒng)的高吞吐量.

4.3 Data Center節(jié)點(diǎn)代替驗(yàn)證查詢

當(dāng)請(qǐng)求查詢的節(jié)點(diǎn)對(duì)HBase節(jié)點(diǎn)的信任程度中等時(shí)，可以采用data center代替驗(yàn)證的查詢方式，算法2說明了Data center節(jié)點(diǎn)代替驗(yàn)證查詢的步驟.

算法2.DC代替驗(yàn)證查詢 (DC Validation Query)

輸入：查詢條件

輸出：查詢結(jié)果和查詢結(jié)果是否有效(true or false)

客戶端Client：

1.function(查詢結(jié)果，查詢結(jié)果是否有效) DCVQ(查詢條件)：

2. 查詢結(jié)果，查詢結(jié)果是否有效=DCVQ_DC(查詢條件)

3.if(查詢結(jié)果有效)

4.return(查詢結(jié)果，查詢結(jié)果有效)

5.else

6.return(null，查詢結(jié)果無(wú)效)

數(shù)據(jù)中心Data center

7.function(查詢結(jié)果，查詢結(jié)果是否有效) DCVQ_DC(查詢條件)

8. 查詢結(jié)果=getDB(查詢條件)

9. 數(shù)據(jù)中心中的消息摘要值=計(jì)算消息摘要(查詢結(jié)果)

10. 區(qū)塊鏈中的消息摘要值=getBLC(查詢條件)

11.if(數(shù)據(jù)中心中的消息摘要值==區(qū)塊鏈中的消息摘要值)

12.return(查詢結(jié)果，查詢結(jié)果有效)

13.else

14. return (null，查詢結(jié)果無(wú)效)

算法2的1-6行是請(qǐng)求查詢的客戶端節(jié)點(diǎn)進(jìn)行的操作，在第2行客戶端節(jié)點(diǎn)向數(shù)據(jù)中心節(jié)點(diǎn)請(qǐng)求查詢結(jié)果和結(jié)果的真實(shí)性.與簡(jiǎn)單驗(yàn)證查詢不同的是從數(shù)據(jù)中心節(jié)點(diǎn)拿到數(shù)據(jù)塊需要重新計(jì)算消息摘要值，再與區(qū)塊鏈中消息摘要值進(jìn)行對(duì)比返回結(jié)果.

當(dāng)請(qǐng)求查詢的節(jié)點(diǎn)向HBase節(jié)點(diǎn)請(qǐng)求查詢時(shí)，HBase首先在自身查詢出符合條件的數(shù)據(jù)和批次信息，之后根據(jù)批次信息查詢出同批次的所有數(shù)據(jù)，并按照時(shí)間戳排序(將同批次數(shù)據(jù)按照存入HBase時(shí)的數(shù)據(jù)排列即可)，重新計(jì)算該批數(shù)據(jù)的消息摘要值.根據(jù)查詢結(jié)果的區(qū)塊信息在區(qū)塊鏈中查詢到該批次數(shù)據(jù)的最初消息散列值，將重新計(jì)算的消息散列值與區(qū)塊鏈中的消息散列值進(jìn)行對(duì)比，若比較結(jié)果是相同的則說明查詢結(jié)果沒有問題，若比較結(jié)果是不同的則說明查詢結(jié)果有可能是偽造的.Data center節(jié)點(diǎn)代替驗(yàn)證查詢示意圖見圖5.

Data Center節(jié)點(diǎn)代替驗(yàn)證查詢方法開銷與簡(jiǎn)單驗(yàn)證查詢相比多了將數(shù)據(jù)塊重新計(jì)算消息摘要的過程.由于數(shù)據(jù)塊在磁盤中是按照順序存放的，讀取磁盤開銷代價(jià)并不是很大，計(jì)算消息摘要代價(jià)也在級(jí)別，所以可以保證系統(tǒng)的高吞吐量.

4.4 全數(shù)據(jù)驗(yàn)證查詢

當(dāng)請(qǐng)求查詢的節(jié)點(diǎn)對(duì)HBase節(jié)點(diǎn)的信任程度較差時(shí)，就需要采用全數(shù)據(jù)驗(yàn)證查詢的方法，全數(shù)據(jù)驗(yàn)證方法的方式是將與查詢結(jié)果同批次的數(shù)據(jù)都返回給請(qǐng)求查詢的節(jié)點(diǎn)，請(qǐng)求查詢的節(jié)點(diǎn)自己驗(yàn)證數(shù)據(jù)的真實(shí)性，所以全數(shù)據(jù)查詢驗(yàn)證代價(jià)開銷比較高.算法3說明了全數(shù)據(jù)查詢過程步驟.

HBase節(jié)點(diǎn)收到請(qǐng)求查詢節(jié)點(diǎn)的查詢請(qǐng)求后，首先查詢到符合條件的結(jié)果，根據(jù)查詢結(jié)果的批次信息找到同批次的所有數(shù)據(jù)，并將這些同批次所有的數(shù)據(jù)返回給請(qǐng)求查詢的client節(jié)點(diǎn).請(qǐng)求查詢的client節(jié)點(diǎn)還要在區(qū)塊鏈中查詢到最初存入的未被篡改過的消息摘要值.Client節(jié)點(diǎn)通過重新計(jì)算批次數(shù)據(jù)的消息摘要值并與區(qū)塊鏈中查詢到的消息散列值進(jìn)行對(duì)比，來確定查詢結(jié)果是否真實(shí)可靠.全數(shù)據(jù)驗(yàn)證查詢示意圖見圖5.

算法3.全數(shù)據(jù)驗(yàn)證查詢 (Full Data Validation Query)

輸入：查詢條件

輸出：查詢結(jié)果和查詢結(jié)果是否有效(true or false)

客戶端Client：

1.function(查詢結(jié)果，查詢結(jié)果是否有效) FDVQ(查詢條件)：

2. 查詢結(jié)果=FDVQ_DC(查詢條件)

3. 數(shù)據(jù)中心中的消息摘要值=計(jì)算消息摘要(查詢結(jié)果)

4. 區(qū)塊鏈中的消息摘要值=getBLC(查詢條件)

6.return(查詢結(jié)果，查詢結(jié)果有效)

7.else

8.return(null，查詢結(jié)果無(wú)效)

數(shù)據(jù)中心Data Center：

9.function(查詢結(jié)果)FDVQ_DC(查詢條件)：

10. 查詢結(jié)果=getDB(查詢條件)

11.return查詢結(jié)果

算法3的1-8行是請(qǐng)求查詢的客戶端節(jié)點(diǎn)進(jìn)行的操作，在第2行客戶端節(jié)點(diǎn)向數(shù)據(jù)中心節(jié)點(diǎn)請(qǐng)求完整數(shù)據(jù)塊，第3行客戶端節(jié)點(diǎn)計(jì)算消息摘要值，第4行客戶端節(jié)點(diǎn)向區(qū)塊鏈請(qǐng)求消息摘要值，第5-8行進(jìn)行消息摘要值對(duì)比并返回結(jié)果.

例如在表2中的數(shù)據(jù)，在存儲(chǔ)過程中被修改，見表4.

表4 第1批次被篡改數(shù)據(jù)Table 4 First batch of tampered data

某個(gè)查詢節(jié)點(diǎn)想查詢數(shù)據(jù)編號(hào)為3的數(shù)據(jù)：

Query：Select * from Table1 where 數(shù)據(jù)編號(hào)=3;

表5 查詢結(jié)果Table 5 Query results

無(wú)論采用簡(jiǎn)單驗(yàn)證查詢、data center節(jié)點(diǎn)代替查詢驗(yàn)證查詢還是全數(shù)據(jù)驗(yàn)證查詢方式，查詢到的結(jié)果見表5.

數(shù)據(jù)中心節(jié)點(diǎn)根據(jù)被篡改過后的數(shù)據(jù)計(jì)算出消息摘要值為7981c3f689896fb560bc5590b8e8192e，而在區(qū)塊鏈中拿到的哈希摘要值為911c6da8a8da020fe625d98553f23383，兩者值不同.若采用了data center節(jié)點(diǎn)代替驗(yàn)證查詢和全數(shù)據(jù)驗(yàn)證查詢的方式，請(qǐng)求查詢的用戶節(jié)點(diǎn)會(huì)發(fā)現(xiàn)查詢結(jié)果可能存在問題，而若采用了簡(jiǎn)單驗(yàn)證查詢的方式，則說明請(qǐng)求查詢的用戶節(jié)點(diǎn)對(duì)data center節(jié)點(diǎn)的信任程度較高且data center較為安全不易被篡改和攻擊.

與DataCenter節(jié)點(diǎn)代替驗(yàn)證查詢不同的是，數(shù)據(jù)中心節(jié)點(diǎn)和區(qū)塊鏈需要把數(shù)據(jù)塊和消息摘要值返回給用戶節(jié)點(diǎn)用戶自己進(jìn)行驗(yàn)證，而驗(yàn)證所帶來的開銷與DataCenter節(jié)點(diǎn)代替驗(yàn)證查詢基本是相同的，系統(tǒng)高吞吐量的性能即可得到保證.

5 實(shí)驗(yàn)評(píng)估

5.1 實(shí)驗(yàn)配置

5.1.1 實(shí)驗(yàn)環(huán)境

實(shí)驗(yàn)集群的硬件環(huán)境為雙核心四線程CPU Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz，內(nèi)存為16G(2×8192 MB (16G) 1600MHz)，硬盤轉(zhuǎn)速為5400rmp.操作系統(tǒng)版本為Ubuntu18.04，Golang版本為go1.12.6 Linux/amd64，Hyperledger Fabric版本為hyperledger/fabric release-1.3.0.

5.1.2 網(wǎng)絡(luò)參數(shù)

1)單機(jī)單節(jié)點(diǎn)配置參數(shù)

單機(jī)單節(jié)點(diǎn)是將所有的組件(包括order、peer、client、HBase節(jié)點(diǎn))部署在一臺(tái)服務(wù)器上，節(jié)點(diǎn)名稱及數(shù)量見表6.

表6 單機(jī)單節(jié)點(diǎn)配置參數(shù)Table 6 Configuration parameters of single machine and single node

2) 多機(jī)多節(jié)點(diǎn)配置參數(shù)

多機(jī)多節(jié)點(diǎn)將每個(gè)組件放在不同的計(jì)算機(jī)上，形成一個(gè)集群，所采用的節(jié)點(diǎn)配置及數(shù)量見表7.

表7 多機(jī)多節(jié)點(diǎn)配置參數(shù)Table 7 Configuration parameters of multi-machine and multi-node

5.2 吞吐量測(cè)試

5.2.1 無(wú)HBase測(cè)試

為了對(duì)比試驗(yàn)的方便，對(duì)不加HBase只有Fabric的網(wǎng)絡(luò)進(jìn)行吞吐量測(cè)試.

1)不同存儲(chǔ)方式對(duì)性能的影響

在Hyperledger Fabric中，數(shù)據(jù)以key-value形式的文檔數(shù)據(jù)存儲(chǔ)，在實(shí)驗(yàn)中數(shù)據(jù)存儲(chǔ)采用了兩種方式，分別是一對(duì)象一個(gè)文檔和一個(gè)歷史版本一個(gè)文檔.一對(duì)象一文檔指的是每個(gè)對(duì)象中用數(shù)組或者其他數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)歷史版本信息.這種結(jié)構(gòu)的數(shù)據(jù)會(huì)將每個(gè)對(duì)象的歷史版本信息存在一個(gè)文檔內(nèi)，數(shù)據(jù)特點(diǎn)：文檔數(shù)量少，每個(gè)文檔尺寸大.一個(gè)歷史版本一文檔指的是每個(gè)對(duì)象的id+時(shí)間信息代表一個(gè)歷史版本的信息.這種結(jié)構(gòu)的數(shù)據(jù)會(huì)將一個(gè)對(duì)象的每個(gè)版本信息都存儲(chǔ)為一個(gè)文檔，數(shù)據(jù)特點(diǎn)：文檔數(shù)量多，單個(gè)文檔尺寸小.

圖6 存儲(chǔ)方式和索引對(duì)性能的影響Fig.6 Influence of index and storge types on query performance

為了測(cè)試不同存儲(chǔ)方式對(duì)性能的影響，本文測(cè)試了不同存儲(chǔ)方式下的插入效率、修改效率、查詢效率.首先測(cè)試了插入50000條數(shù)據(jù)所需要的總時(shí)間，如圖6(a)所示，實(shí)驗(yàn)結(jié)果表明一對(duì)象一文檔插入每條數(shù)據(jù)所需要的平均時(shí)間為0.08s，而一歷史版本一文檔插入每條數(shù)據(jù)所需要的平均時(shí)間為0.10s；本文還測(cè)試了不同存儲(chǔ)方式下的修改性能，實(shí)驗(yàn)方法是隨機(jī)對(duì)數(shù)據(jù)庫(kù)中的數(shù)據(jù)進(jìn)行修改50000次，實(shí)驗(yàn)結(jié)果表明一對(duì)象一文檔每次修改的平均時(shí)間為0.08s，一歷史版本一文檔的每次修改的平均時(shí)間為0.11s；在測(cè)試查詢效率的過程中，分為簡(jiǎn)單查詢測(cè)試和范圍查詢測(cè)試，簡(jiǎn)單查詢測(cè)試是指按照HBase中的列名進(jìn)行查詢，范圍查詢測(cè)試是指查詢的屬性是一個(gè)數(shù)值范圍，在實(shí)驗(yàn)中，一對(duì)象一文檔在簡(jiǎn)單查詢測(cè)試中每次需要0.07s的時(shí)間，一歷史版本一文檔在范圍查詢測(cè)試中每次需要0.09s.

2)索引對(duì)查詢性能的影響

CouchDB支持對(duì)數(shù)據(jù)進(jìn)行構(gòu)建索引，在一對(duì)象一文檔的情況下，本文測(cè)試了索引對(duì)范圍查詢效率的影響，如圖6(b)所示，實(shí)驗(yàn)結(jié)果表明有索引的查詢效率要比無(wú)索引的查詢效率高.

5.2.2 多機(jī)多節(jié)點(diǎn)外源數(shù)據(jù)庫(kù)測(cè)試

實(shí)驗(yàn)所采用的數(shù)據(jù)是索非亞空氣質(zhì)量數(shù)據(jù)集(6)https：//www.kaggle.com/hmavrodiev/sofia-air-quality-dataset，是傳感器類型的時(shí)間序列數(shù)據(jù).

將HBase節(jié)點(diǎn)加入整個(gè)集群中，其中數(shù)據(jù)再HBase中的存儲(chǔ)結(jié)構(gòu)見表8.

1)單節(jié)點(diǎn)與多節(jié)點(diǎn)性能測(cè)試

在實(shí)際應(yīng)用的場(chǎng)景中，往往都是分布式、并行的結(jié)構(gòu)，本文將單節(jié)點(diǎn)和多節(jié)點(diǎn)的性能進(jìn)行了實(shí)驗(yàn)對(duì)比.首先測(cè)試了插入17709數(shù)據(jù)，分別統(tǒng)計(jì)了鏈下數(shù)據(jù)庫(kù)(HBase)和區(qū)塊鏈的性能表現(xiàn)，同時(shí)測(cè)試了與驗(yàn)證相關(guān)的操作性能表現(xiàn)，分別是每批次平均插入所需要的時(shí)間(每批次默認(rèn)200條數(shù)據(jù))和平均每次驗(yàn)證查詢所需要的時(shí)間.其中每一批次的數(shù)據(jù)插入過程中涉及到驗(yàn)證的環(huán)節(jié)是批次數(shù)據(jù)需要進(jìn)行計(jì)算消息摘要值，驗(yàn)證查詢中涉及到驗(yàn)證的環(huán)節(jié)就是將查詢結(jié)果同批次的數(shù)據(jù)重新計(jì)算消息摘要值.

表8 HBase存儲(chǔ)結(jié)構(gòu)Table 8 HBase storage structure

如圖8(a)所示，實(shí)驗(yàn)結(jié)果表明，鏈下數(shù)據(jù)庫(kù)的效率是很高的，而且與無(wú)鏈下數(shù)據(jù)庫(kù)相比，系統(tǒng)的吞吐量也有明顯的提升.在單節(jié)點(diǎn)和多節(jié)點(diǎn)驗(yàn)證相關(guān)的測(cè)試中，多節(jié)點(diǎn)的表現(xiàn)較單節(jié)點(diǎn)相比有一點(diǎn)提升.

圖7 鏈下數(shù)據(jù)庫(kù)與區(qū)塊鏈資源占比分析Fig.7 Analysis of resource of off-chain database and block chain

如圖7所示了每次插入數(shù)據(jù)HBase和區(qū)塊鏈所占用的時(shí)間，不論是單節(jié)點(diǎn)還是多節(jié)點(diǎn)，HBase所占用的時(shí)間遠(yuǎn)遠(yuǎn)沒有區(qū)塊鏈占用的時(shí)間多.

2)多節(jié)點(diǎn)吞吐量及并發(fā)性實(shí)驗(yàn)

實(shí)驗(yàn)中有3個(gè)組織并且在一個(gè)通道內(nèi)，其中有兩個(gè)組織在并發(fā)的插入數(shù)據(jù)或者進(jìn)行驗(yàn)證查詢.

如圖8(b)所示，實(shí)驗(yàn)結(jié)果表明，多節(jié)點(diǎn)并行時(shí)的HBase與區(qū)塊鏈相比依然在執(zhí)行時(shí)占用了較少的時(shí)間.在驗(yàn)證相關(guān)的測(cè)試中，每個(gè)節(jié)點(diǎn)的每批次數(shù)據(jù)平均插入時(shí)間大概在1.3s左右，平均每次的驗(yàn)證查詢時(shí)間在1.45s左右.

在加入HBase外源數(shù)據(jù)庫(kù)后，整個(gè)架構(gòu)的系統(tǒng)吞吐能力有很大的提升，插入數(shù)據(jù)系統(tǒng)吞吐量由每秒2個(gè)變?yōu)槊棵?5個(gè)左右，驗(yàn)證查詢也有著不錯(cuò)的效果.

圖8 單節(jié)點(diǎn)多節(jié)點(diǎn)測(cè)試對(duì)比Fig.8 Comparison of single node and multi-node

5.3 鏈下數(shù)據(jù)庫(kù)與區(qū)塊鏈性能對(duì)比

為了說明區(qū)塊鏈加鏈下數(shù)據(jù)庫(kù)的架構(gòu)的性能優(yōu)勢(shì)，將區(qū)塊鏈和鏈下數(shù)據(jù)庫(kù)性能進(jìn)行了對(duì)比試驗(yàn)，如圖9所示.

圖9 鏈下數(shù)據(jù)庫(kù)與區(qū)塊鏈TPS對(duì)比Fig.9 Compare of off-chain database and block chain

實(shí)驗(yàn)表明，當(dāng)只使用HyperledgerFabric時(shí)，系統(tǒng)每秒處理事務(wù)數(shù)量?jī)H為3左右，當(dāng)加入HBase以后，架構(gòu)的系統(tǒng)每秒處理事務(wù)數(shù)量有了很大的提升，在75個(gè)左右.而只使用HBase的系統(tǒng)每秒處理事務(wù)數(shù)量在85個(gè)左右.該實(shí)驗(yàn)說明區(qū)塊鏈加鏈下數(shù)據(jù)庫(kù)的架構(gòu)，在保證了安全性的同時(shí)，也有不錯(cuò)的系統(tǒng)吞吐量性能.

6 結(jié) 論

本文提出了一種區(qū)塊鏈結(jié)合線下數(shù)據(jù)庫(kù)的模式，采用該模式能讓區(qū)塊鏈網(wǎng)絡(luò)具有較強(qiáng)的事務(wù)吞吐能力，鏈下數(shù)據(jù)庫(kù)還為整個(gè)區(qū)塊鏈網(wǎng)絡(luò)提供查詢、存儲(chǔ)服務(wù).在這個(gè)模式的基礎(chǔ)上，本文提出了一種多模式可驗(yàn)證查詢和異步可驗(yàn)證查詢的方法，根據(jù)節(jié)點(diǎn)之家信任程度的不同，提供不同代價(jià)花費(fèi)的驗(yàn)證查詢方式.通過Hyperledger Fabric平臺(tái)和HBase構(gòu)建了一個(gè)外源數(shù)據(jù)庫(kù)區(qū)塊鏈平臺(tái)，并進(jìn)行了實(shí)驗(yàn)，實(shí)驗(yàn)結(jié)果表明該模式使得區(qū)塊鏈網(wǎng)絡(luò)具有更高的事務(wù)吞吐能力和驗(yàn)證查詢能力.

接下來的工作要將鏈下數(shù)據(jù)庫(kù)與區(qū)塊鏈能夠更好的結(jié)合，到目前為止鏈下數(shù)據(jù)庫(kù)還是獨(dú)立于區(qū)塊鏈的存在，并不是區(qū)塊鏈的一部分，以Hbase為例子，將ledgerDB換為Hbase這樣的更加高效的、查詢更加強(qiáng)大的數(shù)據(jù)庫(kù)，通過Hbase維護(hù)Merkle Tree這樣的數(shù)據(jù)結(jié)構(gòu)，讓外源數(shù)據(jù)庫(kù)成為區(qū)塊鏈的一個(gè)內(nèi)部組件；節(jié)點(diǎn)之間的關(guān)系管理方面：目前為止節(jié)點(diǎn)之間的信任模型還不完善，可以嘗試引入圖的概念，建立節(jié)點(diǎn)網(wǎng)絡(luò)，量化節(jié)點(diǎn)之間的信任關(guān)系.