基于多角色節(jié)點(diǎn)的區(qū)塊鏈可擴(kuò)展方案研究與設(shè)計(jì)

戴 波，賴旬陽，胡 凱，馬 舒，陳 波，姜清妍，鄭 妘

(1.國網(wǎng)浙江電力有限公司 信息通信分公司，浙江 杭州 310019；2.國網(wǎng)浙江電力有限公司 浙江德清縣供電有限公司，浙江 德清 313200；3.浙江工業(yè)大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院，浙江 杭州 310023)

2009年，區(qū)塊鏈隨著比特幣[1]的出現(xiàn)初次被人知曉。此后，區(qū)塊鏈技術(shù)在包括金融、醫(yī)療、司法、教育、供應(yīng)鏈和電力等多個(gè)領(lǐng)域得到擴(kuò)展應(yīng)用。區(qū)塊鏈技術(shù)是一種全新的分布式基礎(chǔ)架構(gòu)，采用一種基于時(shí)間戳的“區(qū)塊+鏈?zhǔn)健睌?shù)據(jù)結(jié)構(gòu)，結(jié)合分布式共識(shí)算法、密碼學(xué)方法和智能合約等多種機(jī)制，能夠確保鏈上數(shù)據(jù)可信、安全，還能進(jìn)行數(shù)據(jù)操作。近年來，涌現(xiàn)了很多區(qū)塊鏈框架[2-4]，現(xiàn)有的經(jīng)驗(yàn)表明：要將區(qū)塊鏈大規(guī)模應(yīng)用于實(shí)際場景，仍存在許多挑戰(zhàn)[5]，主要表現(xiàn)在3個(gè)方面：1) 可擴(kuò)展性，區(qū)塊鏈的擴(kuò)展必須以增大交易吞吐量為代價(jià)，要滿足多鏈場景下的應(yīng)用需求同時(shí)必須滿足高性能和可擴(kuò)展性兩方面的要求；2) 可監(jiān)管性，區(qū)塊鏈具有去中心化的特性，但常需一個(gè)中心化的監(jiān)管機(jī)構(gòu)用以保證對(duì)系統(tǒng)的控制，以便執(zhí)行特定的業(yè)務(wù)邏輯和策略；3) 隱私保護(hù)，區(qū)塊鏈上的交易是公開的，在實(shí)際應(yīng)用中要求數(shù)據(jù)只能與相關(guān)方分享。已有方案雖然提出加密交易，但此類方法要求密鑰管理基礎(chǔ)設(shè)施，且仍然允許系統(tǒng)中其余節(jié)點(diǎn)了解交易。

為解決上述問題，筆者提出了一種基于多角色節(jié)點(diǎn)的的區(qū)塊鏈可擴(kuò)展方案，并將節(jié)點(diǎn)定義為多種角色，構(gòu)建相互聯(lián)系又相互獨(dú)立的子鏈，每條子鏈自行維護(hù)私有賬本，只有成員節(jié)點(diǎn)才能發(fā)起交易、訪問交易，以此保證交易的隱私性。同時(shí)，本方案支持不限數(shù)量的子鏈，不同子鏈可并行運(yùn)行不同的共識(shí)協(xié)議，隨時(shí)進(jìn)行跨鏈資產(chǎn)轉(zhuǎn)移，并能保證系統(tǒng)的安全性和可靠性，具有極大的可擴(kuò)展性。此外，筆者方案中的監(jiān)管者角色可通過智能合約來執(zhí)行特定策略，負(fù)責(zé)監(jiān)管整個(gè)網(wǎng)絡(luò)的運(yùn)行。

1 相關(guān)工作

1.1 區(qū)塊鏈監(jiān)管技術(shù)

在區(qū)塊鏈技術(shù)應(yīng)用中存在監(jiān)管體系缺失、數(shù)據(jù)分散和難以兼顧隱私保護(hù)等問題。在食品安全方面，Tao等[6]提出了層次化的多域區(qū)塊鏈(HMDBC)網(wǎng)絡(luò)結(jié)構(gòu)和2次檢查機(jī)制，可以支持對(duì)區(qū)塊鏈的及時(shí)糾正和替換。惡意監(jiān)督節(jié)點(diǎn)由區(qū)域節(jié)點(diǎn)共同管理，監(jiān)督節(jié)點(diǎn)進(jìn)行輔助驗(yàn)證以及上級(jí)區(qū)域的仲裁。Liu等[7]提出基于區(qū)塊鏈的草藥質(zhì)量和安全監(jiān)管模型，利用區(qū)塊鏈的不變性和可追溯性來管理草藥的生產(chǎn)、加工和交易流程，并結(jié)合分段信息加密方法，對(duì)企業(yè)的私人信息進(jìn)行加密。

現(xiàn)有的區(qū)塊鏈監(jiān)管機(jī)制都在同一條鏈中進(jìn)行，只能針對(duì)特定的領(lǐng)域進(jìn)行管理，且無法根據(jù)實(shí)際情況進(jìn)行特定的策略調(diào)整，存在不可擴(kuò)展的弊端。

1.2 跨鏈技術(shù)

目前，區(qū)塊鏈行業(yè)被眾多平臺(tái)和協(xié)議所隔離，從而形成各式各樣的區(qū)塊鏈孤島，使得當(dāng)前區(qū)塊鏈互操作性有限。不同區(qū)塊鏈之間資產(chǎn)轉(zhuǎn)移的限制降低了用戶的可用性和舒適度，并阻礙了區(qū)塊鏈生態(tài)系統(tǒng)的發(fā)展。

Gao等[8]探索了如何在資產(chǎn)轉(zhuǎn)移的背景下實(shí)現(xiàn)兩個(gè)異構(gòu)區(qū)塊鏈之間的相互操作，并提出基于數(shù)據(jù)遷移Oracle構(gòu)建跨鏈資產(chǎn)轉(zhuǎn)移架構(gòu)，在2個(gè)異構(gòu)區(qū)塊鏈之間打開通道進(jìn)行資產(chǎn)轉(zhuǎn)移，但該架構(gòu)缺少身份驗(yàn)證的環(huán)節(jié)，安全性較低。Borkowski等[9]提出DeXTT跨區(qū)塊鏈轉(zhuǎn)移協(xié)議，該協(xié)議可用于以分散的方式同時(shí)記錄任意數(shù)量的區(qū)塊鏈上的資產(chǎn)轉(zhuǎn)移。在DeXTT原型中，使用智能合約實(shí)現(xiàn)交易。Pang等[10]為區(qū)塊鏈互操作性架構(gòu)提出了一種新的共識(shí)協(xié)議MPoS，該協(xié)議能夠增強(qiáng)跨鏈系統(tǒng)中的令牌網(wǎng)絡(luò)效應(yīng)，并極大地?cái)U(kuò)展區(qū)塊鏈系統(tǒng)的用戶基礎(chǔ)。通過實(shí)驗(yàn)分析，證明了MPoS協(xié)議相較于傳統(tǒng)的單令牌PoS共識(shí)協(xié)議，可以提供更好的安全性。

與上述方法不同，筆者提出的方案支持不限數(shù)量的子鏈，不同子鏈可并行運(yùn)行不同的共識(shí)協(xié)議，隨時(shí)進(jìn)行跨鏈資產(chǎn)轉(zhuǎn)移[11]，并能夠同時(shí)保證系統(tǒng)的安全性和可靠性。

1.3 隱私保護(hù)技術(shù)

An等[12]提出基于區(qū)塊鏈2次驗(yàn)證和共識(shí)(TCNS)的去中心化隱私保護(hù)模型。TCNS的原型是通過一種橢圓曲線算法進(jìn)行驗(yàn)證的匿名策略，以保護(hù)用戶身份的隱私。Liu等[13]提出一種基于聯(lián)盟鏈的隱私保護(hù)的醫(yī)學(xué)數(shù)據(jù)共享方案，設(shè)計(jì)鏈上鏈下的存儲(chǔ)模型以減輕區(qū)塊鏈的存儲(chǔ)負(fù)擔(dān)，并引入一種改進(jìn)的代理重加密方案，以確保數(shù)據(jù)僅可以由授權(quán)數(shù)據(jù)請(qǐng)求者訪問，達(dá)到保護(hù)數(shù)據(jù)隱私的目的。

區(qū)塊鏈技術(shù)在監(jiān)管技術(shù)、跨鏈以及隱私保護(hù)等方面雖然都得到了改進(jìn)與發(fā)展，但是通過對(duì)上述現(xiàn)狀對(duì)比發(fā)現(xiàn)(表1)，相關(guān)學(xué)術(shù)研究無法兼顧3者的平衡。為此，筆者提出了一種基于多角色節(jié)點(diǎn)的區(qū)塊鏈可擴(kuò)展方案，以此實(shí)現(xiàn)區(qū)塊鏈的可擴(kuò)展和可監(jiān)管，并兼顧節(jié)點(diǎn)隱私保護(hù)。

表1 相關(guān)研究對(duì)比分析Table 1 Comparison of related studies

2 區(qū)塊鏈可擴(kuò)展方案

2.1 總體架構(gòu)

系統(tǒng)模型中各類節(jié)點(diǎn)構(gòu)建起一個(gè)許可鏈網(wǎng)絡(luò)，并以分布式應(yīng)用的形式支持智能合約，例如以太坊和Fabric中的智能合約。

系統(tǒng)中的節(jié)點(diǎn)承擔(dān)以下角色：1) 客戶端(Clients)發(fā)布交易；2) 驗(yàn)證者(Validators)參與共識(shí)；3) 審計(jì)員(Auditors)通過訂閱被動(dòng)接收系統(tǒng)中的交易事件；4) 監(jiān)管者(Regulators)執(zhí)行策略進(jìn)行管理，不必參與共識(shí)并且一個(gè)節(jié)點(diǎn)能同時(shí)承擔(dān)多種角色。

筆者設(shè)計(jì)的系統(tǒng)架構(gòu)如圖1所示，不同角色對(duì)應(yīng)不同職責(zé)。監(jiān)管者發(fā)布策略，統(tǒng)一管理子鏈；驗(yàn)證節(jié)點(diǎn)參與共識(shí)并維護(hù)子鏈賬本，共享業(yè)務(wù)邏輯可以發(fā)生交易；審計(jì)節(jié)點(diǎn)訂閱并接收交易事件，進(jìn)一步驗(yàn)證交易。假定節(jié)點(diǎn)不會(huì)主動(dòng)與無關(guān)節(jié)點(diǎn)分享交易信息。

圖1 基于多角色節(jié)點(diǎn)的區(qū)塊鏈可擴(kuò)展架構(gòu)設(shè)計(jì)Fig.1 Blockchain extensible architecture design based on multi-role nodes

2.2 子鏈構(gòu)建

在本方案中，子鏈?zhǔn)且粋€(gè)自行維護(hù)的分布式私有賬本，由網(wǎng)絡(luò)中的一組節(jié)點(diǎn)組成，這些節(jié)點(diǎn)參與共識(shí)并維護(hù)賬本，一個(gè)節(jié)點(diǎn)可以同時(shí)加入多條子鏈。每條子鏈自行維護(hù)對(duì)私有賬本的訪問控制權(quán)限，訪問控制方法由鏈上的驗(yàn)證節(jié)點(diǎn)和監(jiān)管者的策略定義。與側(cè)鏈[14-15]不同，筆者對(duì)子鏈?zhǔn)褂玫牡讓庸沧R(shí)沒有限制，只要共識(shí)協(xié)議不違反監(jiān)管者的規(guī)定即可。此外，筆者方案還支持跨鏈資產(chǎn)轉(zhuǎn)移。子鏈構(gòu)建流程見圖2。

圖2 子鏈構(gòu)建流程圖Fig.2 Subchain construction flow chart

在構(gòu)建子鏈時(shí)，節(jié)點(diǎn)首先需要就鏈上的驗(yàn)證節(jié)點(diǎn)、共識(shí)協(xié)議和訪問策略達(dá)成協(xié)議，圖2描述了用于選舉發(fā)起者、鏈ID和底層的共識(shí)協(xié)議的算法。首先，所有節(jié)點(diǎn)在鏈上廣播自己的ID和所選擇的共識(shí)協(xié)議，節(jié)點(diǎn)接收到來自各個(gè)其他節(jié)點(diǎn)的信息后，驗(yàn)證所有的ID是否被驗(yàn)證，并構(gòu)建子鏈數(shù)據(jù)結(jié)構(gòu)信息chain_info；其次，判斷ID信息是否從監(jiān)管者得到，若是，則對(duì)chain_info簽名得到sigi，并對(duì)多有節(jié)點(diǎn)同步和sigi，并收集sigk，若不是，則繼續(xù)等待，直到收到監(jiān)管者發(fā)送的信息，進(jìn)行簽名，并向監(jiān)管者獲取所有節(jié)點(diǎn)的sigk；最后，驗(yàn)證所有簽名是否準(zhǔn)確，若準(zhǔn)確，則構(gòu)建子鏈，并返回子鏈信息，否則產(chǎn)生錯(cuò)誤。

需要說明的是，審計(jì)節(jié)點(diǎn)經(jīng)過子鏈批準(zhǔn)后可訂閱其中的交易推送，并對(duì)交易進(jìn)行審計(jì)管理，確保交易準(zhǔn)確有效。

2.3 策略監(jiān)管

筆者方案中的監(jiān)管者節(jié)點(diǎn)負(fù)責(zé)驗(yàn)證交易是否合法且遵循策略。監(jiān)管者不參與共識(shí)，只負(fù)責(zé)通過智能合約將監(jiān)管策略推送給特定子鏈。筆者引入的策略目錄合約(Policy directory contract)提供注冊、搜索和更新等功能，用于管理策略合約，該合約托管在監(jiān)管者中，部署在鏈上。目錄合約監(jiān)聽監(jiān)管者發(fā)布的策略發(fā)布或更新事件，自動(dòng)將新的策略合約部署在各個(gè)子鏈上，并注冊在目錄合約中。

子鏈上的所有智能合約都包含一個(gè)到策略目錄合約的反饋。驗(yàn)證交易時(shí)，交易會(huì)被轉(zhuǎn)發(fā)到策略目錄合約，目錄合約選擇合適的策略驗(yàn)證交易，驗(yàn)證通過后子鏈上的智能合約才能夠執(zhí)行。該方法保證只要有足夠多的誠實(shí)節(jié)點(diǎn)，監(jiān)管策略就能夠被正確執(zhí)行，不需要監(jiān)管者的主動(dòng)干預(yù)。

2.4 跨鏈資產(chǎn)轉(zhuǎn)移

在某些應(yīng)用場景中，資產(chǎn)需要在不同子鏈之間流轉(zhuǎn)。例如，2個(gè)屬于不同區(qū)域(即位于不同子鏈)的工業(yè)互聯(lián)網(wǎng)廠區(qū)之間的資產(chǎn)轉(zhuǎn)移。為了解決這類問題，筆者提供了跨鏈資產(chǎn)轉(zhuǎn)移方案。

假定s和r屬于2條不同的子鏈，將資產(chǎn)m從發(fā)送者s轉(zhuǎn)移到接受者r的過程如圖3所示。s發(fā)起交易，先向它所屬的子鏈(以下簡稱s鏈)發(fā)出一個(gè)轉(zhuǎn)移資產(chǎn)的請(qǐng)求。s鏈上的所有驗(yàn)證節(jié)點(diǎn)驗(yàn)證該交易，包括檢查資產(chǎn)m的總量是否超過上限，s是否持有資產(chǎn)m等。如果驗(yàn)證通過，驗(yàn)證者節(jié)點(diǎn)將執(zhí)行交易，從s的賬戶上移除資產(chǎn)m，并返回許可給s。一旦s收集到足夠多(數(shù)量由底層共識(shí)協(xié)議決定)的許可，s就能構(gòu)建一個(gè)最終證明，證明s鏈批準(zhǔn)該交易且此交易確實(shí)在該鏈上執(zhí)行。轉(zhuǎn)移令牌指定了資產(chǎn)的接收鏈，因此不會(huì)被其他鏈接收。接著，s向r所屬的鏈(以下簡稱r鏈)發(fā)送該最終證明。接收鏈驗(yàn)證最終證明以及該交易是否符合監(jiān)管策略。驗(yàn)證通過，r鏈將資產(chǎn)m移動(dòng)到r的賬戶上，并返回一個(gè)帶有r鏈最終證明的收到令牌給s；否則r鏈會(huì)返回一個(gè)拒絕令牌，s可以用其來恢復(fù)自己的賬戶資產(chǎn)。發(fā)送鏈和接收鏈通過s和r間的直連通道進(jìn)行通信。如果s在規(guī)定的時(shí)延內(nèi)既沒有收到接收令牌也沒有收到拒絕令牌，那么它可以向r鏈的另一個(gè)節(jié)點(diǎn)重新發(fā)送請(qǐng)求。轉(zhuǎn)移操作應(yīng)具有原子性[8]：發(fā)送者和接收者的賬戶需要同時(shí)更新，異步過程這時(shí)無法滿足原子性的要求，方案禁止，超時(shí)導(dǎo)致的隱式回滾是需要通過接收令牌進(jìn)行回滾處理。如果交易成功，每條鏈內(nèi)就只需要進(jìn)行一次共識(shí)；否則，發(fā)送鏈需額外執(zhí)行一次共識(shí)來回滾發(fā)送節(jié)點(diǎn)的賬戶資產(chǎn)。

1—s發(fā)布一個(gè)transfer交易；2—節(jié)點(diǎn)驗(yàn)證并執(zhí)行transfer；3—s收集transfer的授權(quán)證書，并轉(zhuǎn)發(fā)給r；4—r發(fā)布一個(gè)transferf交易；5—節(jié)點(diǎn)驗(yàn)證并執(zhí)行transferf；6—r收集授權(quán)證書，并返回receipt或reject令牌；7—如果交易在接收鏈上失敗了，s發(fā)布rejectf來恢復(fù)自己的賬戶。圖3 跨鏈資產(chǎn)轉(zhuǎn)移圖Fig.3 Cross-chain asset transfer diagram

3 設(shè)計(jì)與實(shí)現(xiàn)

筆者將方案與Hyperledger Fabric v0.6集成，進(jìn)行了系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)。Hyperledger Fabric因不支持多賬本和跨鏈功能，所以要對(duì)Hyperledger Fabric進(jìn)行功能擴(kuò)展。

3.1 子鏈實(shí)現(xiàn)

子鏈通過擴(kuò)展Fabric的成員服務(wù)實(shí)現(xiàn)。假定監(jiān)管者負(fù)責(zé)協(xié)調(diào)整個(gè)網(wǎng)絡(luò)的成員服務(wù)，用于記錄所有已注冊的子鏈和鏈上的成員信息(即IP地址、TCP端口和節(jié)點(diǎn)ID)。每條子鏈一經(jīng)形成，就需要向監(jiān)管者注冊。

一個(gè)節(jié)點(diǎn)可能需要維護(hù)多個(gè)獨(dú)立賬本，每個(gè)賬本對(duì)應(yīng)一條它們加入的子鏈。筆者修改Fabric節(jié)點(diǎn)的核心代碼，當(dāng)節(jié)點(diǎn)加入一條新的子鏈時(shí)，它就會(huì)創(chuàng)建數(shù)據(jù)庫來存儲(chǔ)賬本。筆者使用Fabric的鍵值數(shù)據(jù)庫RocksDB來實(shí)現(xiàn)，節(jié)點(diǎn)將在Chain-to-ledgers數(shù)據(jù)結(jié)構(gòu)中維護(hù)一個(gè)指向新創(chuàng)建的數(shù)據(jù)庫的指針。Chain-to-ledgers是一個(gè)映射，它存儲(chǔ)(Chain_id, ledger_db)鍵值對(duì)，主要為該節(jié)點(diǎn)加入的子鏈以及指向數(shù)據(jù)庫的指針，數(shù)據(jù)庫中存儲(chǔ)了子鏈內(nèi)的交易。添加新驗(yàn)證的交易時(shí)，就需要訪問該數(shù)據(jù)結(jié)構(gòu)。

除此之外，筆者還向節(jié)點(diǎn)的核心代碼中添加Chain-to-consensus和Chain-to-peers數(shù)據(jù)結(jié)構(gòu)。Chain-to-consenses是一個(gè)映射，存儲(chǔ)(Chain_id, consensus_plugin)鍵值對(duì)，主要為節(jié)點(diǎn)加入的子鏈和對(duì)應(yīng)的共識(shí)協(xié)議。以上提到子鏈的鏈ID和共識(shí)協(xié)議是由其成員節(jié)點(diǎn)商定的，當(dāng)有節(jié)點(diǎn)加入時(shí)，它會(huì)將這些數(shù)據(jù)傳遞給Fabric中的對(duì)等節(jié)點(diǎn)，以便將其存儲(chǔ)在Chain-to-consensus中。Chain-to-peer也是一個(gè)映射，存儲(chǔ)(Chain_id, peers_list)鍵值對(duì)，主要為節(jié)點(diǎn)加入的子鏈以及這個(gè)子鏈的對(duì)等節(jié)點(diǎn)列表。節(jié)點(diǎn)在達(dá)成一致時(shí)，會(huì)得到一個(gè)同樣參與這條子鏈的對(duì)等節(jié)點(diǎn)列表。因此，當(dāng)有節(jié)點(diǎn)加入新鏈時(shí)，也需要將對(duì)等節(jié)點(diǎn)列表傳遞給Fabric中的對(duì)等節(jié)點(diǎn)。

每當(dāng)子鏈成功地驗(yàn)證一個(gè)交易時(shí)，每個(gè)節(jié)點(diǎn)會(huì)訪問Chain-to-ledgers映射，查詢該鏈的數(shù)據(jù)庫指針，并訪問數(shù)據(jù)庫將交易記錄到私有賬本中。

3.2 監(jiān)管策略實(shí)施

監(jiān)管者通過鏈碼來執(zhí)行策略，監(jiān)管者需要為每個(gè)策略提供一個(gè)或多個(gè)鏈碼。每條子鏈必須將監(jiān)管者策略鏈碼與自己的鏈碼整合部署。

監(jiān)管者節(jié)點(diǎn)提供一個(gè)策略目錄鏈碼來管理策略鏈碼，這種特殊的鏈碼部署在每條子鏈中，用于監(jiān)聽監(jiān)管者發(fā)出的策略鏈碼更新事件(圖4)，通過Fabric的消息框架推送鏈碼更新來實(shí)現(xiàn)。監(jiān)聽到更新事件后，策略目錄鏈碼會(huì)下載新的策略鏈碼部署到子鏈中。

圖4 策略鏈碼圖Fig.4 Strategy chain code diagram

鏈碼執(zhí)行交易時(shí)，會(huì)將交易傳遞給策略目錄鏈碼，后者查找已部署的策略鏈碼列表，并轉(zhuǎn)發(fā)交易到具體策略鏈碼，策略鏈碼驗(yàn)證交易，并將結(jié)果返回給策略目錄鏈碼。驗(yàn)證過程中，只有所有的策略驗(yàn)證都通過，這個(gè)交易才算被驗(yàn)證合法，此時(shí)鏈碼會(huì)繼續(xù)處理交易。

3.3 資產(chǎn)轉(zhuǎn)移實(shí)現(xiàn)

筆者允許在交易雙方節(jié)點(diǎn)間建立直接通道，通過TLS發(fā)送資產(chǎn)轉(zhuǎn)移消息。交易在其數(shù)據(jù)中包含了目標(biāo)子鏈的ID，接收者節(jié)點(diǎn)只會(huì)向目標(biāo)鏈的成員節(jié)點(diǎn)廣播這個(gè)交易，該節(jié)點(diǎn)從Chain-to-peers映射中查找子鏈的對(duì)等節(jié)點(diǎn)列表，以便發(fā)送交易。然后，接收節(jié)點(diǎn)以Chain_id和Chaincode_id作為標(biāo)識(shí)，向目標(biāo)鏈碼發(fā)送一個(gè)調(diào)用請(qǐng)求。

4 性能評(píng)估

針對(duì)上述區(qū)塊鏈方案進(jìn)行性能評(píng)估，本系統(tǒng)使用Golang語言實(shí)現(xiàn)，主要測試交易性能和系統(tǒng)性能開銷。實(shí)驗(yàn)環(huán)境中，使用基于Windows 10操作系統(tǒng)的臺(tái)式機(jī)，處理器為Intel CoreTM I9 2.60 GHz，內(nèi)存為16 GB。下述實(shí)驗(yàn)在筆者架構(gòu)與Hyperledger Fabric v0.6的集成版本上測試。

4.1 交易性能

交易性能是區(qū)塊鏈系統(tǒng)的一個(gè)重要指標(biāo)，在實(shí)際運(yùn)行中，可能會(huì)有大量交易同時(shí)并發(fā)執(zhí)行，其中主要性能消耗在于驗(yàn)證對(duì)等節(jié)點(diǎn)執(zhí)行跨鏈共識(shí)、驗(yàn)證交易并入鏈的過程。本實(shí)驗(yàn)將設(shè)置16次，其中8次為入鏈交易，8次為查詢，交易并發(fā)量分別設(shè)定為50，100，150，200，250，300，350，400次/s，對(duì)比不同并發(fā)情況下交易確認(rèn)的平均時(shí)延和吞吐量，以及交易的成功率，并監(jiān)控服務(wù)器cpu和內(nèi)存使用情況。實(shí)驗(yàn)使用Hyperledger Caliper工具，該工具可對(duì)Hyperledger進(jìn)行性能測試，適應(yīng)本方案需求。

圖5～7分別為實(shí)驗(yàn)中每秒交易數(shù)與交易時(shí)延、吞吐量和交易成功率的關(guān)系，圖8為發(fā)送速率與服務(wù)器性能的關(guān)系。圖5顯示入鏈交易的時(shí)延與每秒交易并發(fā)量成正相關(guān)，且近似線性關(guān)系，查詢交易的時(shí)延隨著交易并發(fā)的上升有略微的波動(dòng)，但幅度較小，且始終處于較低的數(shù)值；圖6顯示入鏈交易的吞吐量在50～150次/s始終是上升趨勢，在150次/s之后就不再大幅上升，查詢交易吞吐量則始終與每秒交易數(shù)成正相關(guān)增大；圖7顯示隨著每秒交易數(shù)的上升，交易成功率下降，經(jīng)分析造成該結(jié)果的原因可能是交易過程中數(shù)據(jù)量增大，消息阻塞，增大了響應(yīng)時(shí)延，導(dǎo)致用戶端接受交易信息超時(shí)，無法達(dá)成交易；圖8顯示隨著每秒交易數(shù)增大，服務(wù)器性能消耗也逐步上升。

圖5 交易時(shí)延Fig.5 Trading delay

圖6 交易吞吐量Fig.6 Transaction throughput

圖7 交易成功率Fig.7 Transaction success rate

圖8 交易性能消耗Fig.8 Trading performance consumption

提高交易性能的主要瓶頸在于需要入鏈的交易在發(fā)起后由節(jié)點(diǎn)進(jìn)行共識(shí)，并打包成塊，影響因素主要是節(jié)點(diǎn)的數(shù)量和服務(wù)器性能等；不需要入鏈的查詢交易時(shí)延相對(duì)穩(wěn)定，且與吞吐量成正相關(guān)，因?yàn)椴樵儾恍枰ㄟ^區(qū)塊鏈的共識(shí)，只是獲取狀態(tài)信息，所以在性能影響上沒有太大波動(dòng)。

對(duì)于交易性能的提升，主要可以從網(wǎng)絡(luò)架構(gòu)和服務(wù)器性能上著手。共識(shí)機(jī)制主要依賴于子鏈上節(jié)點(diǎn)的數(shù)量，節(jié)點(diǎn)數(shù)量越多，需要的網(wǎng)絡(luò)延遲和共識(shí)時(shí)間便越長，所以選擇合適數(shù)量的節(jié)點(diǎn)，對(duì)于系統(tǒng)性能提升有一定的幫助。同時(shí)，服務(wù)器配置的提高，也可以降低算法運(yùn)行過程中的時(shí)延，提高交易吞吐量。

4.2 系統(tǒng)性能

在本系統(tǒng)中，除了交易之外，其他部分也會(huì)產(chǎn)生額外的開銷，例如對(duì)子鏈的構(gòu)建、共識(shí)機(jī)制的運(yùn)行等會(huì)造成性能開銷，策略鏈碼目錄在監(jiān)聽監(jiān)管者發(fā)出的策略鏈碼更新事件后需要同步更新后的鏈碼，并部署到子鏈上，此時(shí)也產(chǎn)生額外的性能開銷。為了綜合評(píng)估系統(tǒng)性能，實(shí)驗(yàn)?zāi)M仿真環(huán)境更新策略鏈碼事件，并測試查詢交易的時(shí)延、吞吐量和成功率等參數(shù)。本次實(shí)驗(yàn)使用apache-jmeter發(fā)送交易請(qǐng)求，啟動(dòng)1 000個(gè)并發(fā)線程發(fā)送請(qǐng)求，循環(huán)100次。

實(shí)驗(yàn)總共發(fā)送了100 000個(gè)交易請(qǐng)求，其中有效樣本為93 252個(gè)，發(fā)送交易總耗時(shí)174 s，其中平均時(shí)延為1 265 ms，錯(cuò)誤率為0%，交易吞吐量為548.4次/s。實(shí)驗(yàn)雖然模擬仿真環(huán)境，但仍較理想化，實(shí)際運(yùn)行中必然會(huì)有所延遲；考慮到網(wǎng)絡(luò)等因素，預(yù)計(jì)實(shí)際查詢交易吞吐量會(huì)降低，平均時(shí)延會(huì)延長到1.5 s，但足以滿足應(yīng)用需求。也可以通過提高硬件配置來降低算法運(yùn)行時(shí)延或者采用負(fù)載均衡等提升系統(tǒng)性能。

結(jié)合交易性能測試和系統(tǒng)性能測試，該系統(tǒng)在一定的吞吐量下可以達(dá)到穩(wěn)定，并正常使用，符合預(yù)期設(shè)計(jì)目標(biāo)，測試通過。

綜上所述，與已有Hyperledger Fabric v0.6版本比較，集成版本能夠私有地、并行地運(yùn)行多個(gè)不同的共識(shí)協(xié)議來提高系統(tǒng)的可擴(kuò)展性。同時(shí)，該解決方案包括一個(gè)“不介入”的監(jiān)管者，其負(fù)責(zé)高效管理整個(gè)網(wǎng)絡(luò)，并能夠使用智能合約執(zhí)行特定策略等工作，且交易性能和系統(tǒng)性能能夠達(dá)到預(yù)期水準(zhǔn)，能夠兼顧隱私保護(hù)、可擴(kuò)展和高管理效率[16]。

5 結(jié) 論

區(qū)塊鏈技術(shù)自提出以來便被廣泛應(yīng)用于教育、醫(yī)療、金融和工業(yè)等諸多領(lǐng)域，并不斷擴(kuò)展到每個(gè)行業(yè)之中，隨著區(qū)塊鏈應(yīng)用的增加，不同區(qū)塊鏈之間產(chǎn)生的信息孤島問題也日益嚴(yán)重。筆者提出了一個(gè)基于多角色節(jié)點(diǎn)的區(qū)塊鏈可擴(kuò)展方案，方案為系統(tǒng)中的節(jié)點(diǎn)設(shè)定不同的角色，組成若干個(gè)相互聯(lián)系又相互獨(dú)立的子鏈，子鏈的數(shù)量不受限制，不同的子鏈可運(yùn)行不同的共識(shí)協(xié)議，子鏈間可通過跨鏈資產(chǎn)轉(zhuǎn)移實(shí)現(xiàn)價(jià)值流轉(zhuǎn)和信息交換。監(jiān)管者能夠在區(qū)塊鏈網(wǎng)絡(luò)中強(qiáng)制實(shí)施策略，以實(shí)現(xiàn)對(duì)系統(tǒng)的監(jiān)管。本方案不涉及底層共識(shí)協(xié)議，因此可以與現(xiàn)有的區(qū)塊鏈平臺(tái)集成。結(jié)果表明：筆者方案能夠更好地結(jié)合領(lǐng)域產(chǎn)業(yè)需求，實(shí)現(xiàn)定制化的應(yīng)用，為區(qū)塊鏈服務(wù)于各行各業(yè)及聯(lián)通各行各業(yè)提供新思路。