王盛姣,董建亮,熊 航,李 京
(中國(guó)科學(xué)技術(shù)大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院,安徽 合肥 230026)
隨著比特幣[1]熱潮的出現(xiàn),其背后的區(qū)塊鏈技術(shù)廣受關(guān)注。區(qū)塊鏈?zhǔn)且环N分布式賬本技術(shù),具有去中心化、 數(shù)據(jù)可信、 不可篡改和可溯源等優(yōu)點(diǎn)。區(qū)塊鏈構(gòu)建了點(diǎn)對(duì)點(diǎn)對(duì)等網(wǎng)絡(luò),由網(wǎng)絡(luò)中的對(duì)等節(jié)點(diǎn)集體維護(hù)賬本,運(yùn)用數(shù)據(jù)加密和區(qū)塊+鏈?zhǔn)綌?shù)據(jù)結(jié)構(gòu)來(lái)存儲(chǔ)驗(yàn)證數(shù)據(jù),通過(guò)共識(shí)機(jī)制產(chǎn)生新區(qū)塊,利用以太坊虛擬機(jī)[2]或docker 容器等技術(shù)提供對(duì)智能合約的支持,具有可編程功能。
隨著研究和發(fā)展的深入,區(qū)塊鏈已經(jīng)有了較多實(shí)際應(yīng)用,如醫(yī)療數(shù)據(jù)安全共享[3]、供應(yīng)鏈管理系統(tǒng)[4]、物聯(lián)網(wǎng)訪問(wèn)控制[5]、數(shù)字版權(quán)[6]等。
區(qū)塊鏈根據(jù)節(jié)點(diǎn)是否可以自由加入分為非許可鏈和許可鏈。Hyperledger Fabric(Fabric)[7]是一個(gè)受關(guān)注度較高的許可鏈平臺(tái),具有開源、高度模塊化、可定制、可插拔的特點(diǎn)。當(dāng)前大多數(shù)的區(qū)塊鏈采用排序-執(zhí)行(Order-Execute, OE)交易處理模型,系統(tǒng)串行處理交易使得性能受到限制。因此,F(xiàn)abric提出了執(zhí)行-排序-驗(yàn)證 (Execute-Order-Validate,EOV)的交易處理模型。在執(zhí)行階段,客戶端發(fā)送交易請(qǐng)求到相應(yīng)節(jié)點(diǎn),節(jié)點(diǎn)響應(yīng)請(qǐng)求將帶有處理結(jié)果的交易返回給客戶端。在排序階段,Orderer 節(jié)點(diǎn)將客戶端發(fā)來(lái)的交易按序打包成區(qū)塊,并廣播給節(jié)點(diǎn)。在驗(yàn)證階段,節(jié)點(diǎn)接收到區(qū)塊后串行化驗(yàn)證交易并更新賬本。Fabric 通過(guò)背書策略去配置不同交易請(qǐng)求所需要的節(jié)點(diǎn)數(shù)目,實(shí)現(xiàn)執(zhí)行階段交易的并發(fā)處理。除此之外,F(xiàn)abric 還引入組織的概念,組織節(jié)點(diǎn)之間并發(fā)地處理發(fā)送給該組織的交易,提高了系統(tǒng)的并發(fā)能力。
已有研究結(jié)果[8]表明,F(xiàn)abric 性能顯著優(yōu)于比特幣和以太坊。Fabric 內(nèi)部集成了身份管理、業(yè)務(wù)數(shù)據(jù)分離、隱私數(shù)據(jù)保護(hù)等功能,使其受到廣泛的使用,其中大部分的企業(yè)級(jí)區(qū)塊鏈項(xiàng)目在Fabric 網(wǎng)絡(luò)上進(jìn)行[9]。因此,F(xiàn)abric 在學(xué)術(shù)和工業(yè)上都具有研究?jī)r(jià)值。
并發(fā)性為Fabric 帶來(lái)優(yōu)越性能的同時(shí)也帶來(lái)了一些問(wèn)題。當(dāng)并發(fā)的交易需要修改相同的數(shù)據(jù)時(shí),會(huì)出現(xiàn)交易并發(fā)沖突,而Fabric 上交易之間互相隔離,執(zhí)行和排序階段都不會(huì)檢測(cè)和處理沖突,所以驗(yàn)證階段中部分沖突交易會(huì)被標(biāo)記為無(wú)效。無(wú)效交易的驗(yàn)證占用了系統(tǒng)計(jì)算和存儲(chǔ)的資源,導(dǎo)致性能下降。已有工作表明[10],部分并發(fā)情況下交易的成功率只有不到1/4。因此想要提升Fabric 的性能,交易并發(fā)沖突成為亟待解決的問(wèn)題。
本文針對(duì)交易并發(fā)沖突進(jìn)行Fabric 性能優(yōu)化研究,提出一種基于Fabric 實(shí)現(xiàn)的沖突檢測(cè)與處理的方法,即FabricDT。將沖突的檢測(cè)提前到背書階段,以減少后續(xù)排序和驗(yàn)證環(huán)節(jié)的系統(tǒng)開銷,從而提高系統(tǒng)的吞吐量,通過(guò)實(shí)驗(yàn)驗(yàn)證了其有效性。
已經(jīng)有不少研究學(xué)者提出了解決Fabric 并發(fā)沖突的方法,從解決思路上主要可以分為兩類。
第一類方式是在客戶端消解交易沖突。Zhang等人[11]提出在客戶端中添加一個(gè)緩存隊(duì)列用來(lái)緩存從背書節(jié)點(diǎn)返回的交易,判斷交易間的沖突性,將沖突交易鎖住,并監(jiān)聽區(qū)塊更新事件。當(dāng)有區(qū)塊更新之后,會(huì)檢測(cè)緩存中鎖住的交易,若鎖因?yàn)閰^(qū)塊更新被釋放,則由緩存重新將此交易作為請(qǐng)求發(fā)出。但是,這只能解決單個(gè)客戶端的沖突交易,無(wú)法處理多個(gè)客戶端間的沖突。Xu 等人[12]提出客戶端對(duì)交易預(yù)處理,更改沖突交易對(duì)應(yīng)的數(shù)據(jù)庫(kù)索引,并在交易提交之后將臨時(shí)索引歸并到原索引,幾乎可以成功處理所有的沖突交易。但是,實(shí)現(xiàn)節(jié)點(diǎn)統(tǒng)一生成和歸并臨時(shí)索引需要一個(gè)可信的分布式鎖服務(wù)來(lái)同步訪問(wèn),會(huì)耗費(fèi)大量的網(wǎng)絡(luò)資源。
第二類方式是在排序階段,分析交易之間沖突依賴關(guān)系,并通過(guò)丟棄部分交易和重排序的方式去得到一個(gè)無(wú)沖突的交易順序并打包成區(qū)塊。Sharma等人[10]最先以此為思路提出了Fabric++,它在排序階段首先分析交易的沖突關(guān)系建立依賴圖,計(jì)算圖中的強(qiáng)連通分量以此得到不可解的沖突,然后丟棄強(qiáng)連通分量中度最多的交易直到依賴圖中不存在閉環(huán),最后利用拓?fù)渑判蛏梢粋€(gè)不沖突的交易順序并打包成區(qū)塊。之后Ruan 等人[13]提出Fabric-Sharp,相較于Fabric++對(duì)沖突的處理粒度更細(xì),考慮了沖突類型和跨塊沖突。此類方法存在一定問(wèn)題,即在排序階段集中分析沖突關(guān)系,使用圖類算法求解,當(dāng)交易數(shù)目較多時(shí)容易造成性能瓶頸。
此外,有一些方法針對(duì)Fabric 中并發(fā)沖突進(jìn)行優(yōu)化。Gorenflo 等人[14]提出Execute-Orderer-Execute的交易流程,他認(rèn)為一筆交易如果只是驗(yàn)證階段因?yàn)闆_突問(wèn)題被標(biāo)記為無(wú)效,這筆交易整個(gè)執(zhí)行流程上并沒有任何信任問(wèn)題,因此可以在驗(yàn)證階段發(fā)現(xiàn)沖突時(shí),由節(jié)點(diǎn)本地執(zhí)行交易得到最新的結(jié)果。然而,該方法忽視了Fabric 構(gòu)建的許可鏈中仍然存在信任問(wèn)題,不同節(jié)點(diǎn)可能會(huì)惡意寫入錯(cuò)誤數(shù)據(jù)導(dǎo)致賬本數(shù)據(jù)出錯(cuò)。
Nasirifard 等人[15]提出使用特定的無(wú)沖突復(fù)制數(shù)據(jù)類型 (Conflict-free Replicated Data Type, CRDT)[16]去解決沖突問(wèn)題。將交易執(zhí)行的讀寫集合轉(zhuǎn)換為特定的數(shù)據(jù)對(duì)象和相關(guān)操作,而這些數(shù)據(jù)對(duì)象和操作構(gòu)成代數(shù)半格,滿足可交換的特點(diǎn),在將轉(zhuǎn)換之后的數(shù)據(jù)對(duì)象逐步更新到賬本后,就不存在沖突的問(wèn)題。但這個(gè)方法也有一個(gè)缺陷,即對(duì)應(yīng)不同的交易需要單獨(dú)設(shè)計(jì)與之對(duì)應(yīng)的CRDT 數(shù)據(jù)結(jié)構(gòu),缺乏通用性。
綜上所述,現(xiàn)有的并發(fā)沖突解決方案具有明顯的局限性,存在檢測(cè)能力弱、通信代價(jià)大、時(shí)間復(fù)雜度較高和缺乏通用性等問(wèn)題。
(1)Fabric 賬 本。Fabric 的 賬 本 包 含 兩 部 分:鏈?zhǔn)浇Y(jié)構(gòu)和鍵值數(shù)據(jù)庫(kù)。鏈?zhǔn)浇Y(jié)構(gòu)即傳統(tǒng)意義上的區(qū)塊鏈賬本,記錄了所有歷史交易??蛻舳税l(fā)送的交易在執(zhí)行過(guò)程中經(jīng)常需要讀取鏈上數(shù)據(jù),為了更快地完成交易,F(xiàn)abric 內(nèi)置了一個(gè)鍵值數(shù)據(jù)庫(kù),用來(lái)記錄當(dāng)前鏈上所有數(shù)據(jù)和最新狀態(tài)。鍵值數(shù)據(jù)庫(kù)的每一條數(shù)據(jù)由鍵和版本號(hào)組成,其中鍵表示了具體的數(shù)據(jù)對(duì)象,版本號(hào)記錄了數(shù)據(jù)當(dāng)前值和對(duì)應(yīng)交易所在塊號(hào)和交易序號(hào)。以表1 第一行為例,賬戶A中的余額為100,將其余額修改為100 的交易是第23 個(gè)區(qū)塊中的第32 條交易。
表1 鍵值數(shù)據(jù)庫(kù)
(2)鏈碼。鏈碼是Fabric 中智能合約的具體實(shí)現(xiàn),包含了應(yīng)用的處理邏輯,支持Golang、Node.js、Java語(yǔ)言。Fabric 提供接口使得客戶端能夠以交易的形式調(diào)用鏈碼與賬本交互。
(3)Peer。Peer 節(jié)點(diǎn)是維護(hù)賬本和鏈碼,響應(yīng)客戶端交易請(qǐng)求,驗(yàn)證區(qū)塊內(nèi)容的基本單位。當(dāng)接收到客戶端的交易請(qǐng)求時(shí),執(zhí)行對(duì)應(yīng)的鏈碼,訪問(wèn)賬本數(shù)據(jù),并返回執(zhí)行結(jié)果給客戶端(也稱為背書);當(dāng)接收到新區(qū)塊時(shí),會(huì)結(jié)合當(dāng)前賬本驗(yàn)證區(qū)塊內(nèi)容,以確保新區(qū)塊對(duì)賬本的更改合理合法。另外,Peer 節(jié)點(diǎn)按照組織進(jìn)行劃分,一個(gè)Peer 節(jié)點(diǎn)只能屬于一個(gè)組織,內(nèi)部包含多個(gè)Peer 節(jié)點(diǎn),不同組織之間的節(jié)點(diǎn)互不信任,同一個(gè)組織的節(jié)點(diǎn)相互信任。
(4)Orderer 節(jié) 點(diǎn)。Orderer 節(jié) 點(diǎn) 主 要 功 能 是 產(chǎn) 生區(qū)塊,它接收客戶端發(fā)送的交易,并將其打包成區(qū)塊發(fā)送給Peer 節(jié)點(diǎn)。
(5)背書策略。Fabric 對(duì)每個(gè)鏈碼都會(huì)設(shè)置背書策略,它聲明了一筆合法的交易需要哪些組織進(jìn)行背書。以“3outof(Org1,Org2,Org3,Org4,Org5)”為例,調(diào)用該鏈碼的交易必須得到Org1、Org2、Org3、Org4 和Org5 五個(gè)組織中三個(gè)以上的背書結(jié)果。因此客戶端會(huì)將交易請(qǐng)求至少發(fā)送給三個(gè)組織中進(jìn)行背書;當(dāng)?shù)玫阶銐虮硶鴷r(shí),會(huì)對(duì)比執(zhí)行結(jié)果是否一致,如不一致則說(shuō)明網(wǎng)絡(luò)中可能存在惡意的節(jié)點(diǎn)企圖非法修改鏈上數(shù)據(jù)。如果惡意組織的數(shù)量小于三個(gè),客戶端通過(guò)對(duì)比交易結(jié)果就能檢測(cè)到異常,從而實(shí)現(xiàn)了3/5 容錯(cuò)。一個(gè)合適的背書策略既能達(dá)到預(yù)想的容錯(cuò),又減少了所需要的背書節(jié)點(diǎn)數(shù)量從而提升了整體性能。
(6)客戶端。客戶端是用戶與鏈交互的工具。用戶通過(guò)客戶端發(fā)起交易請(qǐng)求,指定需要調(diào)用的鏈碼和參數(shù),并根據(jù)對(duì)應(yīng)的背書策略將請(qǐng)求發(fā)送給對(duì)應(yīng)的組織節(jié)點(diǎn)。
以圖1 為例,來(lái)具體說(shuō)明Fabric 系統(tǒng)的交易處理流程。
圖1 執(zhí)行-排序-驗(yàn)證流程
(1)執(zhí)行階段。客戶端按照背書策略將交易請(qǐng)求發(fā)送到不同的背書節(jié)點(diǎn)。節(jié)點(diǎn)在接收到請(qǐng)求之后,會(huì)以本地賬本為數(shù)據(jù)庫(kù)執(zhí)行相關(guān)鏈碼。在鏈碼的執(zhí)行過(guò)程中,將其需要讀取和修改的數(shù)據(jù)以讀寫集的形式保存,即執(zhí)行結(jié)果,并附上節(jié)點(diǎn)簽名作為背書返回給客戶端。
假設(shè)客戶端發(fā)起交易請(qǐng)求“A 賬戶向B 賬戶轉(zhuǎn)賬15”的交易請(qǐng)求,某一背書節(jié)點(diǎn)賬本的鍵值數(shù)據(jù)庫(kù)如表1 所示,其背書結(jié)果如表2 所示。節(jié)點(diǎn)背書的執(zhí)行結(jié)果中,讀集包含了讀取數(shù)據(jù)A 和B 的版本號(hào),寫集保存了需要修改的值,并在末尾對(duì)結(jié)果進(jìn)行簽名。
需要注意的是執(zhí)行階段鏈碼的執(zhí)行結(jié)果并沒有更改Fabric 賬本??蛻舳嗽诮邮盏浇Y(jié)果后,會(huì)進(jìn)行簽名驗(yàn)證和背書策略的驗(yàn)證:背書數(shù)量是否滿足背書策略,不同節(jié)點(diǎn)的執(zhí)行結(jié)果中的讀寫集是否一致。
(2)排序階段。當(dāng)客戶端驗(yàn)證交易合法之后,會(huì)將其發(fā)送給Orderer 節(jié)點(diǎn)。當(dāng)達(dá)到出塊條件時(shí),Orderer 節(jié)點(diǎn)會(huì)將交易打包成區(qū)塊,并發(fā)送給不同組織的Peer 節(jié)點(diǎn)。
表2 背書結(jié)果
(3)驗(yàn)證階段。Peer 節(jié)點(diǎn)在接收到區(qū)塊后會(huì)根據(jù)區(qū)塊更新賬本。
(4)修改過(guò)程。驗(yàn)證簽名、背書策略、讀集版本號(hào)是否與當(dāng)前鍵值數(shù)據(jù)庫(kù)中的一致,若都一致則按照寫集更改鍵值數(shù)據(jù)庫(kù),并補(bǔ)全對(duì)應(yīng)的塊號(hào)和交易號(hào);否則將交易標(biāo)記為無(wú)效。
Fabric 系統(tǒng)中交易可以并發(fā)執(zhí)行,當(dāng)多個(gè)交易讀寫相同的數(shù)據(jù)時(shí),會(huì)導(dǎo)致交易并發(fā)沖突。這些沖突交易在驗(yàn)證階段標(biāo)記無(wú)效,降低了Fabric 性能。沖突交易定義如下:
定義1 沖突交易:客戶端發(fā)送兩筆交易請(qǐng)求Tx1 和Tx2,背書節(jié)點(diǎn)執(zhí)行后分別得到交易讀寫集:ReadSet (Tx1)、WriteSet (Tx1)、ReadSet (Tx2)、WriteSet(Tx2)。假設(shè)Tx1 和Tx2 并發(fā)執(zhí)行,且以下條件任意為 真 時(shí),Tx1 和Tx2 互 相 沖 突。當(dāng)Tx1 先 于Tx2 驗(yàn)證,且滿足條件(1)或者(3)時(shí),Tx2 為沖突交易。
(1)WriteSet(Tx1)∩ReadSet(Tx2)≠?
(2)ReadSet(Tx1)∩WriteSet(Tx2)≠?
(3)WriteSet(Tx1)∩WriteSet(Tx2)≠?
以圖2 為例說(shuō)明交易沖突的影響。
圖2 沖突交易實(shí)例
假設(shè)目前網(wǎng)絡(luò)上所有Peer 節(jié)點(diǎn)的賬本都一致,區(qū)塊數(shù)量為25,鍵值數(shù)據(jù)庫(kù)中的內(nèi)容如表1 所示,此時(shí)兩個(gè)客戶端發(fā)起了兩筆交易請(qǐng)求,內(nèi)容為Tx1:“ 從A 轉(zhuǎn) 帳15 到B”,Tx2:“ 從A 轉(zhuǎn) 帳5 到C”,并且兩筆交易都得到了合法的結(jié)果,那么Tx1的 執(zhí) 行 結(jié) 果 為 讀 集<A: 版 本 號(hào)<100,23,32 >,B:版本 號(hào)<43,23,13 > >,寫 集 為<A:值<85 >, B:值<58 >>,Tx2 執(zhí)行結(jié)果的讀集為<A: 版本號(hào)<100,23,32>,C:版 本 號(hào)<91,19,4 > >,寫 集 為<A:值<95 >, B:值<96>>。
客戶端得到結(jié)果后,驗(yàn)證通過(guò)并發(fā)送給Orderer節(jié)點(diǎn),Orderer 節(jié)點(diǎn)將這兩筆交易打包為成第26 個(gè)區(qū)塊,塊內(nèi)序號(hào)分別為1 和2,然后Orderer 節(jié)點(diǎn)將區(qū)塊發(fā)送給Peer 節(jié)點(diǎn),進(jìn)入驗(yàn)證階段。
驗(yàn)證階段,Peer 節(jié)點(diǎn)首先驗(yàn)證到第一筆交易,在驗(yàn)證讀寫集時(shí),發(fā)現(xiàn)讀集與當(dāng)前賬本狀態(tài)一致,驗(yàn)證通過(guò),并更改鍵值數(shù)據(jù)庫(kù)到表3 形式,然后驗(yàn)證第二筆交易,在驗(yàn)證讀寫集時(shí)發(fā)現(xiàn)讀集中的<A:版本號(hào)<100,23,32>>與當(dāng)前鍵值數(shù)據(jù)庫(kù)中內(nèi)容不相同,則將第二筆交易標(biāo)記為無(wú)效,然后驗(yàn)證后續(xù)的交易。
表3 鍵值數(shù)據(jù)庫(kù)
Fabric 中交易并發(fā)執(zhí)行可能出現(xiàn)交易沖突,因執(zhí)行階段和排序階段沒有任何沖突檢測(cè)機(jī)制,沖突交易只能在驗(yàn)證階段被判斷為無(wú)效,從而浪費(fèi)了系統(tǒng)的計(jì)算資源等,影響了系統(tǒng)的性能。
本文針對(duì)交易沖突提出了一個(gè)沖突檢測(cè)方案,在交易流程的執(zhí)行階段,Peer 節(jié)點(diǎn)本地維護(hù)一個(gè)緩存去記錄還未提交的交易所訪問(wèn)的鏈上數(shù)據(jù),并以此對(duì)接收到的背書請(qǐng)求進(jìn)行沖突檢測(cè)和處理。
為了盡早地檢測(cè)到交易之間的沖突,本文在Peer 節(jié)點(diǎn)上新增一個(gè)未驗(yàn)證交易緩存用來(lái)記錄交易情況,并基于此進(jìn)行沖突檢測(cè)。以圖3 為例,來(lái)說(shuō)明如何進(jìn)行緩存的更新,和交易沖突的檢測(cè)與處理。
3.1.1 未驗(yàn)證交易緩存的構(gòu)建與更新
當(dāng)一個(gè)交易請(qǐng)求通過(guò)執(zhí)行階段時(shí),客戶端除了會(huì)將交易發(fā)送給Orderer 節(jié)點(diǎn),同樣也會(huì)發(fā)送給之前的背書節(jié)點(diǎn)。背書節(jié)點(diǎn)在接收到交易時(shí)讀取其寫集,以其鍵值(key)、交易ID(txID)和時(shí)間戳(time)組成鍵值對(duì)(key,<txID,time>)存入緩存。
圖3 總體設(shè)計(jì)
當(dāng)Peer 節(jié)點(diǎn)接收到新區(qū)塊進(jìn)行驗(yàn)證時(shí),若區(qū)塊中存在與緩存中相同的交易ID,那么Peer 節(jié)點(diǎn)會(huì)刪除緩存中對(duì)應(yīng)ID 的所有記錄。
另外,可能存在網(wǎng)絡(luò)原因?qū)е驴蛻舳税l(fā)送給Orderer 節(jié)點(diǎn)的交易出現(xiàn)丟失、延遲的情況,這將使得未驗(yàn)證交易緩存無(wú)法及時(shí)刪除對(duì)應(yīng)交易ID 的記錄,這部分鍵永遠(yuǎn)留在緩存中,會(huì)影響后續(xù)交易的沖突檢測(cè)。為了解決這一問(wèn)題,Peer 節(jié)點(diǎn)內(nèi)部設(shè)置一個(gè)時(shí)間閾值,對(duì)緩存中超過(guò)閾值的數(shù)據(jù)清除。
3.1.2 交易沖突的檢測(cè)與處理
Fabric 沖突是因?yàn)椴煌灰字g要讀取和修改數(shù)據(jù)鍵相同,而由上小節(jié)可知,未驗(yàn)證交易緩存中記錄了網(wǎng)絡(luò)中通過(guò)執(zhí)行階段但還未寫入賬本的交易要修改的數(shù)據(jù)鍵,如果后續(xù)有客戶端發(fā)送交易請(qǐng)求,需要讀取緩存中的鍵,在最終的驗(yàn)證階段,這一筆交易極大概率是要與之前的交易相沖突。
因此,當(dāng)Peer 節(jié)點(diǎn)接收到交易請(qǐng)求時(shí),會(huì)獲取請(qǐng)求所讀取的數(shù)據(jù)鍵,如果該鍵存在于緩存中,則返回背書失敗的結(jié)果,否則對(duì)其進(jìn)行背書。
在新增沖突檢測(cè)處理模塊之后,其三階段交易流程可由圖4 表示,具體如下。
(1)執(zhí)行階段??蛻舳烁鶕?jù)背書策略將交易請(qǐng)求發(fā)送到部分背書節(jié)點(diǎn)。背書節(jié)點(diǎn)根據(jù)請(qǐng)求調(diào)用相關(guān)鏈碼,得到讀寫集,然后本地進(jìn)行沖突檢測(cè),若不沖突,則將背書結(jié)果返回給客戶端,否則返回背書失敗。
(2)排序階段??蛻舳嗽诮邮盏奖硶Y(jié)果之后,會(huì)將交易發(fā)送給Orderer 節(jié)點(diǎn)和之前的背書節(jié)點(diǎn),背書節(jié)點(diǎn)會(huì)對(duì)未驗(yàn)證交易緩存進(jìn)行更新,Orderer 節(jié)點(diǎn)則會(huì)打包交易成區(qū)塊,并發(fā)送給Peer 節(jié)點(diǎn)。
圖4 交易處理流程
(3)驗(yàn)證階段。Peer 節(jié)點(diǎn)在接收到區(qū)塊之后,會(huì)驗(yàn)證區(qū)塊更新賬本,同時(shí)遍歷區(qū)塊內(nèi)所有交易寫集并更新未驗(yàn)證交易緩存。
為了證明該方法的有效性,本節(jié)實(shí)現(xiàn)了FabricDT 并設(shè)計(jì)了兩個(gè)實(shí)驗(yàn)。第一個(gè)實(shí)驗(yàn)是驗(yàn)證在無(wú)沖突交易的情況,F(xiàn)abricDT 相對(duì)于Fabric 并沒有明顯的性能下降;第二個(gè)實(shí)驗(yàn)是對(duì)比現(xiàn)有先進(jìn)的算法Fabric++,以證明存在并發(fā)沖突交易的情況下FabricDT 性能的優(yōu)越性。
實(shí)驗(yàn)的硬件配置為Intel(R) Xeon(R) CPU E5-2660 v3 @ 2.60GHz,內(nèi)存為256 GB,通 過(guò)1 Gb/s以太網(wǎng)交換機(jī)連接,操作系統(tǒng)版本為Ubuntu 18.04,Golang 版 本 為go1.16.10。Fabric 網(wǎng) 絡(luò) 設(shè) 置 為一個(gè)Orderer 節(jié)點(diǎn),兩個(gè)組織,分別為Org1、Org2,每個(gè)組織都包含兩個(gè)Peer 節(jié)點(diǎn),其中一個(gè)Peer 節(jié)點(diǎn)安裝鏈碼設(shè)置為背書節(jié)點(diǎn),另外有一個(gè)客戶端用來(lái)發(fā)送交易。Orderer 節(jié)點(diǎn)、Peer 節(jié)點(diǎn)和客戶端分別部署在不同的服務(wù)器上,出塊設(shè)置如表4 所示。
本節(jié)設(shè)計(jì)了一個(gè)模擬銀行系統(tǒng)業(yè)務(wù)的鏈碼,包含despoit、transfer、query 三種交易類型。despoit 用來(lái)向賬戶增加一定金額,transfer 用來(lái)將一定金額從一個(gè)賬戶轉(zhuǎn)移到另一個(gè)賬戶(這兩種寫交易會(huì)修改區(qū)塊鏈賬本),query 用于查詢賬戶余額。鏈碼的背書策略設(shè)置為“And(Org1,Org2)”。實(shí)驗(yàn)按比例生成讀交易和寫交易,讀交易的比例為Pq,寫交易中despoit 和transfer 隨機(jī)生成。所有實(shí)驗(yàn)都會(huì)預(yù)先創(chuàng)建10 000 個(gè)賬戶,生成隨機(jī)數(shù)初始化賬戶余額。此外,實(shí)驗(yàn)設(shè)置通過(guò)Zipfian[17]分布生成交易訪問(wèn)的賬戶,以構(gòu)造出沖突交易。沖突程度隨分布偏度的增加而增大[18],當(dāng)分布偏度為0 時(shí)均勻地隨機(jī)訪問(wèn)所有賬戶(如圖5 所示)。
表4 出塊設(shè)置
圖5 不同Zipfian 分布偏度下交易沖突程度
為了衡量Fabric 系統(tǒng)性能,本節(jié)實(shí)驗(yàn)基于測(cè)試結(jié)果統(tǒng)計(jì)了如下指標(biāo):
(1)吞吐量:?jiǎn)挝粫r(shí)間內(nèi)客戶端成功驗(yàn)證提交的交易數(shù)量。
(2)平均交易時(shí)延:所有交易從發(fā)起到最后提交所需的時(shí)間的平均值。
(3)成功率:成功驗(yàn)證提交的交易數(shù)量占所有交易的比例。
為了驗(yàn)證FabricDT 并不會(huì)帶來(lái)巨大的額外開銷,以造成性能下降,首先在無(wú)交易沖突的情況下去對(duì)比FabricDT 和Fabric。在發(fā)送速率為5 0 tps、100 tps、150 tps、200 tps、250 tps、300 tps時(shí),持續(xù)發(fā)送50s 交易,吞吐量和平均交易時(shí)延結(jié)果(如圖6 所示)。
從圖中可以看出,當(dāng)發(fā)送速率從50 tps 增加到200 tps 時(shí),系統(tǒng)的吞吐量增加,而平均交易時(shí)延有所下降,在這個(gè)階段,負(fù)載并未飽和,背書節(jié)點(diǎn)能夠響應(yīng)客戶端請(qǐng)求,Orderer 節(jié)點(diǎn)能夠處理此量級(jí)的交易,每秒的交易數(shù)量不足以觸發(fā)區(qū)塊最大交易數(shù)量的出塊條件。而當(dāng)發(fā)送速率超過(guò)200 tps 時(shí),吞吐量達(dá)到瓶頸并穩(wěn)定在200 tps 左右,此時(shí)Fabric 系統(tǒng)無(wú)法處理更多的交易,此時(shí)增加交易發(fā)送速率,必然導(dǎo)致一部分交易在排序階段或驗(yàn)證階段等待。因此,發(fā)送速率為250 tps 和300 tps 時(shí),平均交易時(shí)延突然增加。
可以看到,F(xiàn)abricDT 與Fabric 在吞吐量和交易時(shí)延上基本沒有差距,F(xiàn)abricDT 在無(wú)交易沖突時(shí),不會(huì)造成明顯的性能下降。對(duì)比FabricDT 和 Fabric增加的平均交易時(shí)延、交易沖突檢測(cè)的時(shí)間開銷和維護(hù)未驗(yàn)證交易緩存的空間開銷,可以看出各項(xiàng)損耗都在可以接受范圍之內(nèi)(如表5 所示)。
實(shí)驗(yàn)結(jié)果顯示系統(tǒng)的吞吐量上限在200 tps 左右,在后續(xù)的實(shí)驗(yàn)中為了使系統(tǒng)處于滿負(fù)荷狀態(tài),將發(fā)送速率設(shè)置在250 tps。
圖6 無(wú)沖突時(shí)交易吞吐量和平均交易時(shí)延
表5 資源損耗
對(duì)比FabricDT、Fabric++和Fabric 在存在沖突交易時(shí)的性能差距。通過(guò)將讀交易的比例Pq分別設(shè)置為5%、50%、95%,將Zipfian 分布的偏度從0 調(diào)整到2,步長(zhǎng)為0.5,以實(shí)現(xiàn)不同程度的沖突交易,交易發(fā)送速率固定為250 tps,測(cè)試不同設(shè)置下的性能,結(jié)果可如圖7、圖8 和表6 所示。
可以看到,F(xiàn)abricDT 在絕大多數(shù)情況下能夠在吞吐量和平均交易時(shí)延上優(yōu)于Fabric 和Fabric++。
圖7(a)和圖7(b)顯示,在不同的Zipfian 分布偏度下,F(xiàn)abricDT 吞吐量均大于Fabric 和Fabric++系統(tǒng)的吞吐量。但是,在圖7(c)中三個(gè)方法的差距不大,并且在偏度為0 和0.5 時(shí),F(xiàn)abricDT 和Fabric++的吞吐量略低于Fabric,是因?yàn)閷懡灰椎谋壤徽?%,沖突程度也比較低,因此沖突交易所占的總體交易比例很小,利用額外的機(jī)制去解決這些沖突的代價(jià)高于它所帶來(lái)的收益,造成了系統(tǒng)性能下降,但是下降幅度非常小。
可以看到,F(xiàn)abricDT 在整體上要比Fabric 和Fabric++擁有更低的時(shí)延 (如圖8 所示)。原因是FabricDT 將沖突檢測(cè)放在了第一個(gè)階段,即執(zhí)行階段,對(duì)不沖突的交易不會(huì)造成明顯的性能損失。而對(duì)沖突的交易,F(xiàn)abricDT 直接將其標(biāo)記為無(wú)效,節(jié)省了系統(tǒng)資源,從而極大地降低了時(shí)延。因此,F(xiàn)abricDT 整體上具有最低的時(shí)延。
圖7 不同沖突程度下交易吞吐量
圖8 不同沖突程度下平均交易時(shí)延
表6 不同沖突程度下交易成功率
隨著偏度的增加(從1 增加到2),F(xiàn)abricDT 會(huì)出現(xiàn)時(shí)延增加的情況,原因是隨著沖突增加,執(zhí)行階段未驗(yàn)證交易緩存的大小會(huì)增加,進(jìn)行沖突判斷和后續(xù)對(duì)緩存的更新所需要的時(shí)間也會(huì)增加; 同時(shí),平均交易時(shí)延指標(biāo)只統(tǒng)計(jì)了所有提交到區(qū)塊的交易時(shí)延,在執(zhí)行階段標(biāo)記為無(wú)效的交易不參與統(tǒng)計(jì),也導(dǎo)致了平均交易時(shí)延的上升。但是從實(shí)驗(yàn)結(jié)果看,即使出現(xiàn)時(shí)延超過(guò)Fabric 和Fabric++,它們之間的差距也很小且可接受,而在其他情況下,F(xiàn)abricDT 都要優(yōu)于兩者。
FabricDT 在任何情況下都具有最高的交易成功率(如表6 所示)。因此,可以認(rèn)為FabricDT 在總體性能上勝過(guò)Fabric 和Fabric++。
本文分析了Hyperledger Fabric 上沖突交易產(chǎn)生的原因,并且提出了一種利用緩存交易寫集的方式,通過(guò)在Peer 節(jié)點(diǎn)上設(shè)置沖突檢測(cè)模塊,在執(zhí)行階段檢測(cè)交易之間的并發(fā)沖突性并進(jìn)行處理。實(shí)驗(yàn)結(jié)果表明,本文的方法能夠有效增加系統(tǒng)吞吐量,降低交易時(shí)延,提高成功交易的比例。
網(wǎng)絡(luò)安全與數(shù)據(jù)管理2022年6期