胡 錦 玲

(廣州城建職業(yè)學(xué)院，510925，廣州)

1 問(wèn)題提出

隨著Hyperledger Fabric區(qū)塊鏈系統(tǒng)涉及的技術(shù)多樣且架構(gòu)復(fù)雜[1]。區(qū)塊鏈(BlockChain)是一種具有去信任、去中心化、不可篡改、公開(kāi)透明等特性的新興技術(shù)。在各個(gè)主流區(qū)塊鏈技術(shù)中，Hyperledger Fabric由Linux Foundation于2015年發(fā)起[2]，Hyperledger Fabric 是分布式賬本解決方案的平臺(tái)，采用模塊化架構(gòu)，提供高安全性、彈性、靈活性和可擴(kuò)展性。目前已有包括IBM、Intel、百度等各大互聯(lián)網(wǎng)公司在內(nèi)的200余個(gè)成員，著力于發(fā)展跨行業(yè)的企業(yè)級(jí)區(qū)塊鏈的研究,也是時(shí)下火熱的區(qū)塊鏈技術(shù)之一[3]。Hyperledger Fabric不僅支持Java、Go、Node.js在內(nèi)的常見(jiàn)的編程語(yǔ)言用于智能合約的開(kāi)發(fā)，同時(shí)不需要使用基于加密貨幣的共識(shí)機(jī)制來(lái)激勵(lì)昂貴的挖礦或智能合約的執(zhí)行，從而大大降低了系統(tǒng)的運(yùn)營(yíng)成本。

在使用Hyperledger Fabric進(jìn)行業(yè)務(wù)系統(tǒng)開(kāi)發(fā)的過(guò)程中，不可避免地涉及到對(duì)鏈上數(shù)據(jù)的讀取和搜索。但是，由于區(qū)塊鏈的技術(shù)特性，對(duì)區(qū)塊鏈的數(shù)據(jù)讀取需要遍歷整個(gè)區(qū)塊鏈鏈條才能計(jì)算存儲(chǔ)數(shù)據(jù)的當(dāng)前狀態(tài)。盡管Hyperledger Fabric通過(guò)內(nèi)置了LevelDB、CouchDB等數(shù)據(jù)庫(kù)存儲(chǔ)WorldState的方式在一定程度上解決了區(qū)塊鏈數(shù)據(jù)的讀取問(wèn)題[4-5]，但這種方式面對(duì)業(yè)務(wù)系統(tǒng)中高頻且形式復(fù)雜的數(shù)據(jù)訪(fǎng)問(wèn)，在功能和性能上顯然力有不逮。因此，在業(yè)務(wù)開(kāi)發(fā)中通常還需要將鏈上數(shù)據(jù)同步寫(xiě)入第3方數(shù)據(jù)存儲(chǔ)中，進(jìn)而由其解決數(shù)據(jù)的讀取和搜索問(wèn)題。這就需要應(yīng)用開(kāi)發(fā)者來(lái)解決區(qū)塊鏈及第3方數(shù)據(jù)存儲(chǔ)間的數(shù)據(jù)一致性問(wèn)題。

為了支持以同樣的方式更新信息，并實(shí)現(xiàn)一整套賬本功能(交易，查詢(xún)等)，區(qū)塊鏈?zhǔn)褂弥悄芎霞s來(lái)提供對(duì)賬本的受控訪(fǎng)問(wèn)。本文旨在針對(duì)Hyperledger Fabric鏈上數(shù)據(jù)和第3方數(shù)據(jù)存儲(chǔ)間的數(shù)據(jù)同步問(wèn)題，設(shè)計(jì)并實(shí)現(xiàn)了Hyperledger Fabric數(shù)據(jù)協(xié)同中間件，確保兩者間的安全數(shù)據(jù)同步，從而降低開(kāi)發(fā)者的開(kāi)發(fā)成本，提高開(kāi)發(fā)效率。

2 數(shù)據(jù)存儲(chǔ)分析

Hyperledger Fabric支持多鏈[6]。在Hyperledger Fabric中，數(shù)據(jù)存儲(chǔ)一共包括4個(gè)部分：賬本數(shù)據(jù)、狀態(tài)數(shù)據(jù)庫(kù)、歷史記錄數(shù)據(jù)庫(kù)、區(qū)塊索引數(shù)據(jù)庫(kù)，如圖1所示。其中，賬本數(shù)據(jù)以二進(jìn)制文件的形式保存了區(qū)塊鏈上每個(gè)區(qū)塊的具體數(shù)據(jù)。狀態(tài)數(shù)據(jù)庫(kù)則有LevelDB和CouchDB兩種實(shí)現(xiàn)形式，用于存儲(chǔ)賬本中每個(gè)數(shù)據(jù)項(xiàng)的最新值，方便鏈碼執(zhí)行時(shí)快速調(diào)用。歷史記錄數(shù)據(jù)庫(kù)需要通過(guò)配置項(xiàng)開(kāi)啟，開(kāi)啟后在LevelDB中保存數(shù)據(jù)項(xiàng)的版本變化，即哪些區(qū)塊中的交易變更了數(shù)據(jù)項(xiàng)的值。區(qū)塊索引數(shù)據(jù)庫(kù)存儲(chǔ)了區(qū)塊文件的索引指針，以便快速找到對(duì)應(yīng)的區(qū)塊文件。

圖1 Hyperledger Fabric數(shù)據(jù)存儲(chǔ)示意圖

Hyperledger Fabric的這些設(shè)計(jì)很好地滿(mǎn)足了數(shù)據(jù)的簡(jiǎn)單讀寫(xiě)需求，但對(duì)于實(shí)際應(yīng)用中形式更加復(fù)雜的數(shù)據(jù)搜索條件則力有不逮。在很多現(xiàn)實(shí)場(chǎng)景中，用戶(hù)需要對(duì)數(shù)據(jù)進(jìn)行更復(fù)雜的數(shù)據(jù)分析，例如在電子存證場(chǎng)景中，用戶(hù)可能希望以上傳用戶(hù)和上傳時(shí)間為搜索條件對(duì)存證進(jìn)行搜索。而基于KV數(shù)據(jù)庫(kù)設(shè)計(jì)的狀態(tài)數(shù)據(jù)存儲(chǔ)顯然難以應(yīng)對(duì)這種關(guān)系型數(shù)據(jù)庫(kù)擅長(zhǎng)處理的查詢(xún)請(qǐng)求。而在一些情況下，應(yīng)用系統(tǒng)還可能需要區(qū)塊鏈上的數(shù)據(jù)來(lái)生產(chǎn)數(shù)據(jù)報(bào)表或進(jìn)行大數(shù)據(jù)分析，而需要將區(qū)塊鏈數(shù)據(jù)同步到HBase和Hive這樣擅長(zhǎng)處理海量數(shù)據(jù)的存儲(chǔ)中。因此，出于應(yīng)用系統(tǒng)運(yùn)行過(guò)程中高頻且形式復(fù)雜的數(shù)據(jù)讀取搜索和數(shù)據(jù)分析的需要，開(kāi)發(fā)中通常需要將區(qū)塊鏈中存儲(chǔ)的數(shù)據(jù)同步到第3方存儲(chǔ)中，通過(guò)第3方存儲(chǔ)來(lái)實(shí)現(xiàn)復(fù)雜的數(shù)據(jù)搜索需求，并提高系統(tǒng)性能。在這種情況下，如何保證兩者間數(shù)據(jù)同步過(guò)程中的數(shù)據(jù)一致性是需要重點(diǎn)解決的問(wèn)題。為了解決這個(gè)問(wèn)題，本文設(shè)計(jì)并實(shí)現(xiàn)了可插拔的Hyperledger Fabric數(shù)據(jù)協(xié)同中間件，以保證Hyperledger Fabric區(qū)塊鏈與第3方存儲(chǔ)間的安全數(shù)據(jù)同步。

3 數(shù)據(jù)同步訪(fǎng)問(wèn)控制流程設(shè)計(jì)

通常用戶(hù)對(duì)Hyperledger Fabric聯(lián)盟鏈中的數(shù)據(jù)修改通過(guò)調(diào)用鏈碼提交交易的方式實(shí)現(xiàn)。而用戶(hù)發(fā)出的交易提案首先需要發(fā)送到Peer節(jié)點(diǎn)，由Peer節(jié)點(diǎn)調(diào)用鏈碼并對(duì)該提案背書(shū)，進(jìn)而提交到排序節(jié)點(diǎn)，再經(jīng)由排序節(jié)點(diǎn)驗(yàn)證和排序后才能成功寫(xiě)入?yún)^(qū)塊并下發(fā)給Peer節(jié)點(diǎn)，最后由Peer節(jié)點(diǎn)驗(yàn)證并寫(xiě)入各自持有的賬本[4]。從用戶(hù)提交交易提案到數(shù)據(jù)寫(xiě)入賬本的調(diào)用鏈路漫長(zhǎng)，如果同步等待區(qū)塊鏈的鏈碼調(diào)用結(jié)果則會(huì)因?yàn)槁L(zhǎng)的交易提交過(guò)程占用大量系統(tǒng)資源。同時(shí)，數(shù)據(jù)上鏈的過(guò)程中還有因?yàn)榫W(wǎng)絡(luò)波動(dòng)或交易沖突等多種原因失敗的風(fēng)險(xiǎn)，在客戶(hù)端發(fā)出交易提案的同時(shí)直接將數(shù)據(jù)寫(xiě)入第3方存儲(chǔ)可能導(dǎo)致數(shù)據(jù)上鏈?zhǔn)s在第3方存儲(chǔ)中寫(xiě)入成功，因此還需要考慮數(shù)據(jù)上鏈?zhǔn)l件下的數(shù)據(jù)回滾或重試機(jī)制，邏輯將變得臃腫而復(fù)雜。

相比之下，選擇異步的將已經(jīng)確認(rèn)寫(xiě)入Hyperledger Fabric賬本中的數(shù)據(jù)同步到第3方存儲(chǔ)，則可以節(jié)省大量因同步等待而消耗的資源，邏輯也更加簡(jiǎn)單直接。在Hyperledger Fabric聯(lián)盟鏈中，提供了基于通道的Peer節(jié)點(diǎn)事件服務(wù)，在應(yīng)用程序在對(duì)應(yīng)通道注冊(cè)監(jiān)聽(tīng)器后，每當(dāng)通道中有新區(qū)塊產(chǎn)生，該服務(wù)都會(huì)發(fā)送一個(gè)事件到監(jiān)聽(tīng)?wèi)?yīng)用程序中，事件中以envelope的形式包含了具體的區(qū)塊消息。

因此，在具體實(shí)現(xiàn)上，數(shù)據(jù)協(xié)同中間件選擇通過(guò)監(jiān)聽(tīng)Hyperledger Fabric區(qū)塊鏈網(wǎng)絡(luò)中Peer節(jié)點(diǎn)廣播的新增區(qū)塊消息的方式來(lái)異步獲取新增區(qū)塊的數(shù)據(jù)，進(jìn)而分析區(qū)塊中打包的交易及讀寫(xiě)集數(shù)據(jù)。最后，使用消息隊(duì)列將交易對(duì)賬本數(shù)據(jù)的更新通知到第3方存儲(chǔ)。在這個(gè)過(guò)程中，仍需要考慮由于網(wǎng)絡(luò)的不確定性和系統(tǒng)的偶然崩潰等意外導(dǎo)致的數(shù)據(jù)缺失或數(shù)據(jù)重復(fù)的情況，并考慮對(duì)應(yīng)的手段來(lái)確保數(shù)據(jù)的一致性和消息的冪等性。在此基礎(chǔ)上，數(shù)據(jù)協(xié)同中間件的同步工作流程見(jiàn)圖2。

圖2 數(shù)據(jù)同步訪(fǎng)問(wèn)控制流程圖

4 數(shù)據(jù)一致性問(wèn)題解決

實(shí)現(xiàn)數(shù)據(jù)協(xié)同訪(fǎng)問(wèn)控制策略，從圖2中可以看到，數(shù)據(jù)在由區(qū)塊鏈同步到第3方存儲(chǔ)的過(guò)程中，主要經(jīng)過(guò)了2次數(shù)據(jù)傳輸。第1次是從Peer節(jié)點(diǎn)通過(guò)廣播消息的方式，由區(qū)塊鏈傳輸?shù)綌?shù)據(jù)協(xié)同中間件；第2次是由數(shù)據(jù)協(xié)同中間件交至消息隊(duì)列，通知第3方存儲(chǔ)寫(xiě)入數(shù)據(jù)。由于在每個(gè)系統(tǒng)內(nèi)部可以通過(guò)單機(jī)事務(wù)的方式確保操作的原子性，因此這2次數(shù)據(jù)傳輸是最容易發(fā)生數(shù)據(jù)丟失風(fēng)險(xiǎn)的步驟。

經(jīng)過(guò)分析，可能導(dǎo)致產(chǎn)生數(shù)據(jù)不一致風(fēng)險(xiǎn)的具體原因如下。

1)數(shù)據(jù)協(xié)同中間件監(jiān)聽(tīng)區(qū)塊鏈數(shù)據(jù)變更的方式是監(jiān)聽(tīng)Peer節(jié)點(diǎn)發(fā)送的區(qū)塊新增事件，如果由于網(wǎng)絡(luò)波動(dòng)或中間件服務(wù)器宕機(jī)等原因?qū)е卤O(jiān)聽(tīng)事件的丟失，將會(huì)導(dǎo)致數(shù)據(jù)不一致。

2)數(shù)據(jù)協(xié)同中間件收到區(qū)塊鏈系統(tǒng)發(fā)出的消息后，通知第3方存儲(chǔ)寫(xiě)入數(shù)據(jù)的消息丟失。

3)第3方存儲(chǔ)數(shù)據(jù)寫(xiě)入成功后，數(shù)據(jù)協(xié)同中間件沒(méi)有收到確認(rèn)，重復(fù)發(fā)送消息導(dǎo)致數(shù)據(jù)重復(fù)寫(xiě)入。在數(shù)據(jù)協(xié)同中間件中，對(duì)于問(wèn)題1)，使用了CheckPoint機(jī)制記錄區(qū)塊的處理進(jìn)度，在發(fā)生消息丟失時(shí)自動(dòng)要求Peer節(jié)點(diǎn)重發(fā)丟失消息；對(duì)于問(wèn)題2)，數(shù)據(jù)協(xié)同中間件通過(guò)消息隊(duì)列傳遞消息，并使用重試機(jī)制確保消息在傳遞過(guò)程中不會(huì)丟失；對(duì)于有問(wèn)題3)，則需要第3方存儲(chǔ)在收到消息后，通過(guò)本地消息表的方式來(lái)確保消息的冪等性。

4.1 基于CheckPoint數(shù)據(jù)協(xié)同處理工作流程

數(shù)據(jù)協(xié)同中間件通過(guò)監(jiān)聽(tīng)Peer節(jié)點(diǎn)廣播的事件消息的形式獲取區(qū)塊鏈中新增區(qū)塊的具體信息，進(jìn)而通過(guò)分析得到具體交易的讀寫(xiě)集。在監(jiān)聽(tīng)消息的過(guò)程中，可能由于消息丟失、處理異常等原因?qū)е聰?shù)據(jù)出現(xiàn)不一致。因此，數(shù)據(jù)協(xié)同中間件通過(guò)CheckPoint機(jī)制來(lái)確保不會(huì)遺漏處理消息，且在數(shù)據(jù)處理過(guò)程中即使發(fā)生崩潰異常也能保證數(shù)據(jù)一致。具體過(guò)程如下。

1)在監(jiān)聽(tīng)到事件消息后，CheckPoint首先會(huì)對(duì)比收到消息中的區(qū)塊高度和已同步的區(qū)塊高度，確認(rèn)是否存在遺漏的消息。如果存在則會(huì)通知Peer節(jié)點(diǎn)重發(fā)遺漏消息記錄。

2)如果不存在遺漏消息，則會(huì)在數(shù)據(jù)庫(kù)中保存新收到的消息，避免后續(xù)處理失敗時(shí)反復(fù)要求Peer節(jié)點(diǎn)重放事件消息。在保存時(shí)會(huì)判斷消息記錄表中是否已經(jīng)有相同區(qū)塊高度且狀態(tài)為待處理或處理成功的區(qū)塊消息，如果有則保存失敗，流程結(jié)束。CheckPoint保存區(qū)塊消息的記錄表結(jié)構(gòu)見(jiàn)表1。

表1 CheckPoint區(qū)塊消息記錄表

3)如果區(qū)塊消息記錄成功，則解析消息的具體內(nèi)容，得到區(qū)塊中打包的所有交易及其讀寫(xiě)集。

4)通過(guò)交易讀寫(xiě)集獲取數(shù)據(jù)變更項(xiàng)，通過(guò)消息隊(duì)列發(fā)送給第3方存儲(chǔ)。

5)消息如果發(fā)送成功則在記錄表中更新其處理狀態(tài)為處理成功；否則，重試發(fā)送消息。

4.2 消息冪等性保障

通過(guò)CheckPoint機(jī)制和消息隊(duì)列，數(shù)據(jù)協(xié)同中間件能夠保證將Hyperledger Fabric區(qū)塊鏈中寫(xiě)入的數(shù)據(jù)以消息的形式安全地順序交付給第3方存儲(chǔ)。值得注意的是，為了確保發(fā)給第3方的消息不會(huì)丟失，數(shù)據(jù)協(xié)同中間件在消息隊(duì)列中配置了重試機(jī)制，消息的接收方在成功消費(fèi)消息后會(huì)自動(dòng)發(fā)回一條Ack確認(rèn)消息，如果生產(chǎn)者沒(méi)有收到Ack消息，則會(huì)在設(shè)定的重試間隔后重新向消費(fèi)者發(fā)送消息。

因此，第3方存儲(chǔ)在成功消費(fèi)消息并寫(xiě)入數(shù)據(jù)后，向消息隊(duì)列發(fā)回的Ack確認(rèn)消息也有可能因?yàn)榫W(wǎng)絡(luò)波動(dòng)原因丟失，從而導(dǎo)致觸發(fā)重試機(jī)制，消息被重復(fù)消費(fèi)。在這種情況下，需要由消息的消費(fèi)者保證消息的消費(fèi)冪等性。一個(gè)可行的保證消息消費(fèi)冪等性的方法是通過(guò)一張額外的數(shù)據(jù)表記錄消息的消費(fèi)狀態(tài)[7]，如果發(fā)現(xiàn)重復(fù)消息則不寫(xiě)入數(shù)據(jù)。由于消息隊(duì)列中的消息ID可能發(fā)生重復(fù)，而在Hyperledger Fabric的場(chǎng)景下，每一筆交易都會(huì)擁有一個(gè)唯一的交易ID。因此可以通過(guò)交易ID標(biāo)記消息是否已經(jīng)被成功消費(fèi)，避免數(shù)據(jù)的重復(fù)消費(fèi)。記錄消息消費(fèi)狀態(tài)的本地消息表結(jié)構(gòu)見(jiàn)表2。

表2 本地消息表

5 實(shí)驗(yàn)測(cè)試與結(jié)果

部署數(shù)據(jù)協(xié)同中間件后，通過(guò)鏈碼向Hyperledger Fabric區(qū)塊鏈網(wǎng)絡(luò)提交交易寫(xiě)入數(shù)據(jù)，中間件能夠成功接收到Hyperledger Fabric發(fā)出的廣播消息，并將數(shù)據(jù)寫(xiě)入第3方存儲(chǔ)中。結(jié)果如圖3所示。

圖3 數(shù)據(jù)同步效果圖

隨后斷開(kāi)數(shù)據(jù)協(xié)同中間件到Hyperledger Fabric網(wǎng)絡(luò)的連接，并繼續(xù)向Hyperledger Fabric提交交易，模擬廣播消息遺失的情況。在恢復(fù)網(wǎng)絡(luò)連接后，可以看到中間件在收到新的區(qū)塊廣播消息時(shí)，會(huì)自動(dòng)向Hyperledger Fabric請(qǐng)求遺失的消息，如圖4。

圖4 遺失消息效果圖

6 結(jié)論

本文從區(qū)塊鏈數(shù)據(jù)協(xié)同訪(fǎng)問(wèn)控制策略的中間件設(shè)計(jì)與研究，分析了Hyperledger Fabric中數(shù)據(jù)存儲(chǔ)的形式，在此基礎(chǔ)上設(shè)計(jì)并實(shí)現(xiàn)了Hyperledger Fabric數(shù)據(jù)協(xié)同中間件，實(shí)現(xiàn)了Hyperledger Fabric和第3方存儲(chǔ)間的自動(dòng)化數(shù)據(jù)同步，提高開(kāi)發(fā)效率。在此基礎(chǔ)上，通過(guò)CheckPoint

機(jī)制避免遺漏廣播消息導(dǎo)致的數(shù)據(jù)丟失，通過(guò)本地消息表避免數(shù)據(jù)的重復(fù)寫(xiě)入，有效地確保兩者間的數(shù)據(jù)一致性。