王盛姣，董建亮，熊 航，李 京

（中國(guó)科學(xué)技術(shù)大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院，安徽 合肥 230026）

0 引言

隨著比特幣[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)證了其有效性。

1 相關(guā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)題。

2 Fabric 介紹

2.1 Fabric 架構(gòu)

（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)。

2.2 執(zhí)行-排序-驗(yà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ú)效。

2.3 Fabric 交易沖突

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ù)

3 基于緩存機(jī)制的Hyperledger Fabric 并發(fā)沖突檢測(cè)

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è)和處理。

3.1 沖突檢測(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)行背書。

3.2 基于沖突檢測(cè)的三階段交易流程

在新增沖突檢測(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)證交易緩存。

4 實(shí)驗(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ù)量占所有交易的比例。

4.1 無(wú)沖突時(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。

4.2 不同沖突程度下性能分析

圖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++。

5 結(jié)論

本文分析了Hyperledger Fabric 上沖突交易產(chǎn)生的原因，并且提出了一種利用緩存交易寫集的方式，通過(guò)在Peer 節(jié)點(diǎn)上設(shè)置沖突檢測(cè)模塊，在執(zhí)行階段檢測(cè)交易之間的并發(fā)沖突性并進(jìn)行處理。實(shí)驗(yàn)結(jié)果表明，本文的方法能夠有效增加系統(tǒng)吞吐量，降低交易時(shí)延，提高成功交易的比例。