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

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

0 引言

隨著比特幣[1]熱潮的出現(xiàn)，其背后的區(qū)塊鏈技術(shù)廣受關(guān)注。區(qū)塊鏈是一種分布式賬本技術(shù)，具有去中心化、 數(shù)據(jù)可信、 不可篡改和可溯源等優(yōu)點。區(qū)塊鏈構(gòu)建了點對點對等網(wǎng)絡(luò)，由網(wǎng)絡(luò)中的對等節(jié)點集體維護賬本，運用數(shù)據(jù)加密和區(qū)塊+鏈式數(shù)據(jù)結(jié)構(gòu)來存儲驗證數(shù)據(jù)，通過共識機制產(chǎn)生新區(qū)塊，利用以太坊虛擬機[2]或docker 容器等技術(shù)提供對智能合約的支持，具有可編程功能。

隨著研究和發(fā)展的深入，區(qū)塊鏈已經(jīng)有了較多實際應(yīng)用，如醫(yī)療數(shù)據(jù)安全共享[3]、供應(yīng)鏈管理系統(tǒng)[4]、物聯(lián)網(wǎng)訪問控制[5]、數(shù)字版權(quán)[6]等。

區(qū)塊鏈根據(jù)節(jié)點是否可以自由加入分為非許可鏈和許可鏈。Hyperledger Fabric(Fabric)[7]是一個受關(guān)注度較高的許可鏈平臺，具有開源、高度模塊化、可定制、可插拔的特點。當前大多數(shù)的區(qū)塊鏈采用排序-執(zhí)行(Order-Execute, OE)交易處理模型，系統(tǒng)串行處理交易使得性能受到限制。因此，F(xiàn)abric提出了執(zhí)行-排序-驗證 (Execute-Order-Validate,EOV)的交易處理模型。在執(zhí)行階段，客戶端發(fā)送交易請求到相應(yīng)節(jié)點，節(jié)點響應(yīng)請求將帶有處理結(jié)果的交易返回給客戶端。在排序階段，Orderer 節(jié)點將客戶端發(fā)來的交易按序打包成區(qū)塊，并廣播給節(jié)點。在驗證階段，節(jié)點接收到區(qū)塊后串行化驗證交易并更新賬本。Fabric 通過背書策略去配置不同交易請求所需要的節(jié)點數(shù)目，實現(xiàn)執(zhí)行階段交易的并發(fā)處理。除此之外，F(xiàn)abric 還引入組織的概念，組織節(jié)點之間并發(fā)地處理發(fā)送給該組織的交易，提高了系統(tǒng)的并發(fā)能力。

已有研究結(jié)果[8]表明，F(xiàn)abric 性能顯著優(yōu)于比特幣和以太坊。Fabric 內(nèi)部集成了身份管理、業(yè)務(wù)數(shù)據(jù)分離、隱私數(shù)據(jù)保護等功能，使其受到廣泛的使用，其中大部分的企業(yè)級區(qū)塊鏈項目在Fabric 網(wǎng)絡(luò)上進行[9]。因此，F(xiàn)abric 在學(xué)術(shù)和工業(yè)上都具有研究價值。

并發(fā)性為Fabric 帶來優(yōu)越性能的同時也帶來了一些問題。當并發(fā)的交易需要修改相同的數(shù)據(jù)時，會出現(xiàn)交易并發(fā)沖突，而Fabric 上交易之間互相隔離，執(zhí)行和排序階段都不會檢測和處理沖突，所以驗證階段中部分沖突交易會被標記為無效。無效交易的驗證占用了系統(tǒng)計算和存儲的資源，導(dǎo)致性能下降。已有工作表明[10]，部分并發(fā)情況下交易的成功率只有不到1/4。因此想要提升Fabric 的性能，交易并發(fā)沖突成為亟待解決的問題。

本文針對交易并發(fā)沖突進行Fabric 性能優(yōu)化研究，提出一種基于Fabric 實現(xiàn)的沖突檢測與處理的方法，即FabricDT。將沖突的檢測提前到背書階段，以減少后續(xù)排序和驗證環(huán)節(jié)的系統(tǒng)開銷，從而提高系統(tǒng)的吞吐量，通過實驗驗證了其有效性。

1 相關(guān)工作

已經(jīng)有不少研究學(xué)者提出了解決Fabric 并發(fā)沖突的方法，從解決思路上主要可以分為兩類。

第一類方式是在客戶端消解交易沖突。Zhang等人[11]提出在客戶端中添加一個緩存隊列用來緩存從背書節(jié)點返回的交易，判斷交易間的沖突性，將沖突交易鎖住，并監(jiān)聽區(qū)塊更新事件。當有區(qū)塊更新之后，會檢測緩存中鎖住的交易，若鎖因為區(qū)塊更新被釋放，則由緩存重新將此交易作為請求發(fā)出。但是，這只能解決單個客戶端的沖突交易，無法處理多個客戶端間的沖突。Xu 等人[12]提出客戶端對交易預(yù)處理，更改沖突交易對應(yīng)的數(shù)據(jù)庫索引，并在交易提交之后將臨時索引歸并到原索引，幾乎可以成功處理所有的沖突交易。但是，實現(xiàn)節(jié)點統(tǒng)一生成和歸并臨時索引需要一個可信的分布式鎖服務(wù)來同步訪問，會耗費大量的網(wǎng)絡(luò)資源。

第二類方式是在排序階段，分析交易之間沖突依賴關(guān)系，并通過丟棄部分交易和重排序的方式去得到一個無沖突的交易順序并打包成區(qū)塊。Sharma等人[10]最先以此為思路提出了Fabric++，它在排序階段首先分析交易的沖突關(guān)系建立依賴圖，計算圖中的強連通分量以此得到不可解的沖突，然后丟棄強連通分量中度最多的交易直到依賴圖中不存在閉環(huán)，最后利用拓撲排序生成一個不沖突的交易順序并打包成區(qū)塊。之后Ruan 等人[13]提出Fabric-Sharp，相較于Fabric++對沖突的處理粒度更細，考慮了沖突類型和跨塊沖突。此類方法存在一定問題，即在排序階段集中分析沖突關(guān)系，使用圖類算法求解，當交易數(shù)目較多時容易造成性能瓶頸。

此外，有一些方法針對Fabric 中并發(fā)沖突進行優(yōu)化。Gorenflo 等人[14]提出Execute-Orderer-Execute的交易流程，他認為一筆交易如果只是驗證階段因為沖突問題被標記為無效，這筆交易整個執(zhí)行流程上并沒有任何信任問題，因此可以在驗證階段發(fā)現(xiàn)沖突時，由節(jié)點本地執(zhí)行交易得到最新的結(jié)果。然而，該方法忽視了Fabric 構(gòu)建的許可鏈中仍然存在信任問題，不同節(jié)點可能會惡意寫入錯誤數(shù)據(jù)導(dǎo)致賬本數(shù)據(jù)出錯。

Nasirifard 等人[15]提出使用特定的無沖突復(fù)制數(shù)據(jù)類型 (Conflict-free Replicated Data Type, CRDT)[16]去解決沖突問題。將交易執(zhí)行的讀寫集合轉(zhuǎn)換為特定的數(shù)據(jù)對象和相關(guān)操作，而這些數(shù)據(jù)對象和操作構(gòu)成代數(shù)半格，滿足可交換的特點，在將轉(zhuǎn)換之后的數(shù)據(jù)對象逐步更新到賬本后，就不存在沖突的問題。但這個方法也有一個缺陷，即對應(yīng)不同的交易需要單獨設(shè)計與之對應(yīng)的CRDT 數(shù)據(jù)結(jié)構(gòu)，缺乏通用性。

綜上所述，現(xiàn)有的并發(fā)沖突解決方案具有明顯的局限性，存在檢測能力弱、通信代價大、時間復(fù)雜度較高和缺乏通用性等問題。

2 Fabric 介紹

2.1 Fabric 架構(gòu)

（1）Fabric 賬 本。Fabric 的 賬 本 包 含 兩 部 分：鏈式結(jié)構(gòu)和鍵值數(shù)據(jù)庫。鏈式結(jié)構(gòu)即傳統(tǒng)意義上的區(qū)塊鏈賬本，記錄了所有歷史交易?？蛻舳税l(fā)送的交易在執(zhí)行過程中經(jīng)常需要讀取鏈上數(shù)據(jù)，為了更快地完成交易，F(xiàn)abric 內(nèi)置了一個鍵值數(shù)據(jù)庫，用來記錄當前鏈上所有數(shù)據(jù)和最新狀態(tài)。鍵值數(shù)據(jù)庫的每一條數(shù)據(jù)由鍵和版本號組成，其中鍵表示了具體的數(shù)據(jù)對象，版本號記錄了數(shù)據(jù)當前值和對應(yīng)交易所在塊號和交易序號。以表1 第一行為例，賬戶A中的余額為100，將其余額修改為100 的交易是第23 個區(qū)塊中的第32 條交易。

表1 鍵值數(shù)據(jù)庫

（2）鏈碼。鏈碼是Fabric 中智能合約的具體實現(xiàn)，包含了應(yīng)用的處理邏輯，支持Golang、Node.js、Java語言。Fabric 提供接口使得客戶端能夠以交易的形式調(diào)用鏈碼與賬本交互。

（3）Peer。Peer 節(jié)點是維護賬本和鏈碼，響應(yīng)客戶端交易請求，驗證區(qū)塊內(nèi)容的基本單位。當接收到客戶端的交易請求時，執(zhí)行對應(yīng)的鏈碼，訪問賬本數(shù)據(jù)，并返回執(zhí)行結(jié)果給客戶端（也稱為背書）；當接收到新區(qū)塊時，會結(jié)合當前賬本驗證區(qū)塊內(nèi)容，以確保新區(qū)塊對賬本的更改合理合法。另外，Peer 節(jié)點按照組織進行劃分，一個Peer 節(jié)點只能屬于一個組織，內(nèi)部包含多個Peer 節(jié)點，不同組織之間的節(jié)點互不信任，同一個組織的節(jié)點相互信任。

（4）Orderer 節(jié) 點。Orderer 節(jié) 點 主 要 功 能 是 產(chǎn) 生區(qū)塊，它接收客戶端發(fā)送的交易，并將其打包成區(qū)塊發(fā)送給Peer 節(jié)點。

（5）背書策略。Fabric 對每個鏈碼都會設(shè)置背書策略，它聲明了一筆合法的交易需要哪些組織進行背書。以“3outof(Org1,Org2,Org3,Org4,Org5)”為例，調(diào)用該鏈碼的交易必須得到Org1、Org2、Org3、Org4 和Org5 五個組織中三個以上的背書結(jié)果。因此客戶端會將交易請求至少發(fā)送給三個組織中進行背書；當?shù)玫阶銐虮硶鴷r，會對比執(zhí)行結(jié)果是否一致，如不一致則說明網(wǎng)絡(luò)中可能存在惡意的節(jié)點企圖非法修改鏈上數(shù)據(jù)。如果惡意組織的數(shù)量小于三個，客戶端通過對比交易結(jié)果就能檢測到異常，從而實現(xiàn)了3/5 容錯。一個合適的背書策略既能達到預(yù)想的容錯，又減少了所需要的背書節(jié)點數(shù)量從而提升了整體性能。

（6）客戶端?？蛻舳耸怯脩襞c鏈交互的工具。用戶通過客戶端發(fā)起交易請求，指定需要調(diào)用的鏈碼和參數(shù)，并根據(jù)對應(yīng)的背書策略將請求發(fā)送給對應(yīng)的組織節(jié)點。

2.2 執(zhí)行-排序-驗證的交易處理流程

以圖1 為例，來具體說明Fabric 系統(tǒng)的交易處理流程。

圖1 執(zhí)行-排序-驗證流程

（1）執(zhí)行階段?？蛻舳税凑毡硶呗詫⒔灰渍埱蟀l(fā)送到不同的背書節(jié)點。節(jié)點在接收到請求之后，會以本地賬本為數(shù)據(jù)庫執(zhí)行相關(guān)鏈碼。在鏈碼的執(zhí)行過程中，將其需要讀取和修改的數(shù)據(jù)以讀寫集的形式保存，即執(zhí)行結(jié)果，并附上節(jié)點簽名作為背書返回給客戶端。

假設(shè)客戶端發(fā)起交易請求“A 賬戶向B 賬戶轉(zhuǎn)賬15”的交易請求，某一背書節(jié)點賬本的鍵值數(shù)據(jù)庫如表1 所示，其背書結(jié)果如表2 所示。節(jié)點背書的執(zhí)行結(jié)果中，讀集包含了讀取數(shù)據(jù)A 和B 的版本號，寫集保存了需要修改的值，并在末尾對結(jié)果進行簽名。

需要注意的是執(zhí)行階段鏈碼的執(zhí)行結(jié)果并沒有更改Fabric 賬本。客戶端在接收到結(jié)果后，會進行簽名驗證和背書策略的驗證：背書數(shù)量是否滿足背書策略，不同節(jié)點的執(zhí)行結(jié)果中的讀寫集是否一致。

（2）排序階段。當客戶端驗證交易合法之后，會將其發(fā)送給Orderer 節(jié)點。當達到出塊條件時，Orderer 節(jié)點會將交易打包成區(qū)塊，并發(fā)送給不同組織的Peer 節(jié)點。

表2 背書結(jié)果

（3）驗證階段。Peer 節(jié)點在接收到區(qū)塊后會根據(jù)區(qū)塊更新賬本。

（4）修改過程。驗證簽名、背書策略、讀集版本號是否與當前鍵值數(shù)據(jù)庫中的一致，若都一致則按照寫集更改鍵值數(shù)據(jù)庫，并補全對應(yīng)的塊號和交易號；否則將交易標記為無效。

2.3 Fabric 交易沖突

Fabric 系統(tǒng)中交易可以并發(fā)執(zhí)行，當多個交易讀寫相同的數(shù)據(jù)時，會導(dǎo)致交易并發(fā)沖突。這些沖突交易在驗證階段標記無效，降低了Fabric 性能。沖突交易定義如下：

定義1 沖突交易：客戶端發(fā)送兩筆交易請求Tx1 和Tx2，背書節(jié)點執(zhí)行后分別得到交易讀寫集：ReadSet (Tx1)、WriteSet (Tx1)、ReadSet (Tx2)、WriteSet(Tx2)。假設(shè)Tx1 和Tx2 并發(fā)執(zhí)行，且以下條件任意為 真 時，Tx1 和Tx2 互 相 沖 突。當Tx1 先 于Tx2 驗證，且滿足條件（1）或者（3）時，Tx2 為沖突交易。

（1）WriteSet(Tx1)∩ReadSet(Tx2)≠?

（2）ReadSet(Tx1)∩WriteSet(Tx2)≠?

（3）WriteSet(Tx1)∩WriteSet(Tx2)≠?

以圖2 為例說明交易沖突的影響。

圖2 沖突交易實例

假設(shè)目前網(wǎng)絡(luò)上所有Peer 節(jié)點的賬本都一致，區(qū)塊數(shù)量為25，鍵值數(shù)據(jù)庫中的內(nèi)容如表1 所示，此時兩個客戶端發(fā)起了兩筆交易請求，內(nèi)容為Tx1：“ 從A 轉(zhuǎn) 帳15 到B”，Tx2：“ 從A 轉(zhuǎn) 帳5 到C”，并且兩筆交易都得到了合法的結(jié)果，那么Tx1的 執(zhí) 行 結(jié) 果 為 讀 集＜A: 版 本 號＜100,23,32 ＞，B:版本 號＜43,23,13 ＞ ＞，寫 集 為＜A:值＜85 ＞, B:值＜58 ＞＞，Tx2 執(zhí)行結(jié)果的讀集為＜A: 版本號＜100,23,32＞,C:版 本 號＜91,19,4 ＞ ＞，寫 集 為＜A:值＜95 ＞, B:值＜96＞＞。

客戶端得到結(jié)果后，驗證通過并發(fā)送給Orderer節(jié)點，Orderer 節(jié)點將這兩筆交易打包為成第26 個區(qū)塊，塊內(nèi)序號分別為1 和2，然后Orderer 節(jié)點將區(qū)塊發(fā)送給Peer 節(jié)點，進入驗證階段。

驗證階段，Peer 節(jié)點首先驗證到第一筆交易，在驗證讀寫集時，發(fā)現(xiàn)讀集與當前賬本狀態(tài)一致，驗證通過，并更改鍵值數(shù)據(jù)庫到表3 形式，然后驗證第二筆交易，在驗證讀寫集時發(fā)現(xiàn)讀集中的＜A:版本號＜100,23,32＞＞與當前鍵值數(shù)據(jù)庫中內(nèi)容不相同，則將第二筆交易標記為無效，然后驗證后續(xù)的交易。

表3 鍵值數(shù)據(jù)庫

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

Fabric 中交易并發(fā)執(zhí)行可能出現(xiàn)交易沖突，因執(zhí)行階段和排序階段沒有任何沖突檢測機制，沖突交易只能在驗證階段被判斷為無效，從而浪費了系統(tǒng)的計算資源等，影響了系統(tǒng)的性能。

本文針對交易沖突提出了一個沖突檢測方案，在交易流程的執(zhí)行階段，Peer 節(jié)點本地維護一個緩存去記錄還未提交的交易所訪問的鏈上數(shù)據(jù)，并以此對接收到的背書請求進行沖突檢測和處理。

3.1 沖突檢測模塊

為了盡早地檢測到交易之間的沖突，本文在Peer 節(jié)點上新增一個未驗證交易緩存用來記錄交易情況，并基于此進行沖突檢測。以圖3 為例，來說明如何進行緩存的更新，和交易沖突的檢測與處理。

3.1.1 未驗證交易緩存的構(gòu)建與更新

當一個交易請求通過執(zhí)行階段時，客戶端除了會將交易發(fā)送給Orderer 節(jié)點，同樣也會發(fā)送給之前的背書節(jié)點。背書節(jié)點在接收到交易時讀取其寫集，以其鍵值(key)、交易ID(txID)和時間戳(time)組成鍵值對(key,＜txID,time＞)存入緩存。

圖3 總體設(shè)計

當Peer 節(jié)點接收到新區(qū)塊進行驗證時，若區(qū)塊中存在與緩存中相同的交易ID，那么Peer 節(jié)點會刪除緩存中對應(yīng)ID 的所有記錄。

另外，可能存在網(wǎng)絡(luò)原因?qū)е驴蛻舳税l(fā)送給Orderer 節(jié)點的交易出現(xiàn)丟失、延遲的情況，這將使得未驗證交易緩存無法及時刪除對應(yīng)交易ID 的記錄，這部分鍵永遠留在緩存中，會影響后續(xù)交易的沖突檢測。為了解決這一問題，Peer 節(jié)點內(nèi)部設(shè)置一個時間閾值，對緩存中超過閾值的數(shù)據(jù)清除。

3.1.2 交易沖突的檢測與處理

Fabric 沖突是因為不同交易之間要讀取和修改數(shù)據(jù)鍵相同，而由上小節(jié)可知，未驗證交易緩存中記錄了網(wǎng)絡(luò)中通過執(zhí)行階段但還未寫入賬本的交易要修改的數(shù)據(jù)鍵，如果后續(xù)有客戶端發(fā)送交易請求，需要讀取緩存中的鍵，在最終的驗證階段，這一筆交易極大概率是要與之前的交易相沖突。

因此，當Peer 節(jié)點接收到交易請求時，會獲取請求所讀取的數(shù)據(jù)鍵，如果該鍵存在于緩存中，則返回背書失敗的結(jié)果，否則對其進行背書。

3.2 基于沖突檢測的三階段交易流程

在新增沖突檢測處理模塊之后，其三階段交易流程可由圖4 表示，具體如下。

（1）執(zhí)行階段?？蛻舳烁鶕?jù)背書策略將交易請求發(fā)送到部分背書節(jié)點。背書節(jié)點根據(jù)請求調(diào)用相關(guān)鏈碼，得到讀寫集，然后本地進行沖突檢測，若不沖突，則將背書結(jié)果返回給客戶端，否則返回背書失敗。

（2）排序階段?？蛻舳嗽诮邮盏奖硶Y(jié)果之后，會將交易發(fā)送給Orderer 節(jié)點和之前的背書節(jié)點，背書節(jié)點會對未驗證交易緩存進行更新，Orderer 節(jié)點則會打包交易成區(qū)塊，并發(fā)送給Peer 節(jié)點。

圖4 交易處理流程

（3）驗證階段。Peer 節(jié)點在接收到區(qū)塊之后，會驗證區(qū)塊更新賬本，同時遍歷區(qū)塊內(nèi)所有交易寫集并更新未驗證交易緩存。

4 實驗

為了證明該方法的有效性，本節(jié)實現(xiàn)了FabricDT 并設(shè)計了兩個實驗。第一個實驗是驗證在無沖突交易的情況，F(xiàn)abricDT 相對于Fabric 并沒有明顯的性能下降；第二個實驗是對比現(xiàn)有先進的算法Fabric++，以證明存在并發(fā)沖突交易的情況下FabricDT 性能的優(yōu)越性。

實驗的硬件配置為Intel(R) Xeon(R) CPU E5-2660 v3 @ 2.60GHz，內(nèi)存為256 GB，通 過1 Gb/s以太網(wǎng)交換機連接，操作系統(tǒng)版本為Ubuntu 18.04，Golang 版 本 為go1.16.10。Fabric 網(wǎng) 絡(luò) 設(shè) 置 為一個Orderer 節(jié)點，兩個組織，分別為Org1、Org2，每個組織都包含兩個Peer 節(jié)點，其中一個Peer 節(jié)點安裝鏈碼設(shè)置為背書節(jié)點，另外有一個客戶端用來發(fā)送交易。Orderer 節(jié)點、Peer 節(jié)點和客戶端分別部署在不同的服務(wù)器上，出塊設(shè)置如表4 所示。

本節(jié)設(shè)計了一個模擬銀行系統(tǒng)業(yè)務(wù)的鏈碼，包含despoit、transfer、query 三種交易類型。despoit 用來向賬戶增加一定金額，transfer 用來將一定金額從一個賬戶轉(zhuǎn)移到另一個賬戶(這兩種寫交易會修改區(qū)塊鏈賬本)，query 用于查詢賬戶余額。鏈碼的背書策略設(shè)置為“And(Org1,Org2)”。實驗按比例生成讀交易和寫交易，讀交易的比例為Pq，寫交易中despoit 和transfer 隨機生成。所有實驗都會預(yù)先創(chuàng)建10 000 個賬戶，生成隨機數(shù)初始化賬戶余額。此外，實驗設(shè)置通過Zipfian[17]分布生成交易訪問的賬戶，以構(gòu)造出沖突交易。沖突程度隨分布偏度的增加而增大[18]，當分布偏度為0 時均勻地隨機訪問所有賬戶（如圖5 所示）。

表4 出塊設(shè)置

圖5 不同Zipfian 分布偏度下交易沖突程度

為了衡量Fabric 系統(tǒng)性能，本節(jié)實驗基于測試結(jié)果統(tǒng)計了如下指標：

（1）吞吐量：單位時間內(nèi)客戶端成功驗證提交的交易數(shù)量。

（2）平均交易時延：所有交易從發(fā)起到最后提交所需的時間的平均值。

（3）成功率：成功驗證提交的交易數(shù)量占所有交易的比例。

4.1 無沖突時性能分析

為了驗證FabricDT 并不會帶來巨大的額外開銷，以造成性能下降，首先在無交易沖突的情況下去對比FabricDT 和Fabric。在發(fā)送速率為5 0 tps、100 tps、150 tps、200 tps、250 tps、300 tps時，持續(xù)發(fā)送50s 交易，吞吐量和平均交易時延結(jié)果（如圖6 所示）。

從圖中可以看出，當發(fā)送速率從50 tps 增加到200 tps 時，系統(tǒng)的吞吐量增加，而平均交易時延有所下降，在這個階段，負載并未飽和，背書節(jié)點能夠響應(yīng)客戶端請求，Orderer 節(jié)點能夠處理此量級的交易，每秒的交易數(shù)量不足以觸發(fā)區(qū)塊最大交易數(shù)量的出塊條件。而當發(fā)送速率超過200 tps 時，吞吐量達到瓶頸并穩(wěn)定在200 tps 左右，此時Fabric 系統(tǒng)無法處理更多的交易，此時增加交易發(fā)送速率，必然導(dǎo)致一部分交易在排序階段或驗證階段等待。因此，發(fā)送速率為250 tps 和300 tps 時，平均交易時延突然增加。

可以看到，F(xiàn)abricDT 與Fabric 在吞吐量和交易時延上基本沒有差距，F(xiàn)abricDT 在無交易沖突時，不會造成明顯的性能下降。對比FabricDT 和 Fabric增加的平均交易時延、交易沖突檢測的時間開銷和維護未驗證交易緩存的空間開銷，可以看出各項損耗都在可以接受范圍之內(nèi)（如表5 所示）。

實驗結(jié)果顯示系統(tǒng)的吞吐量上限在200 tps 左右，在后續(xù)的實驗中為了使系統(tǒng)處于滿負荷狀態(tài)，將發(fā)送速率設(shè)置在250 tps。

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

圖6 無沖突時交易吞吐量和平均交易時延

表5 資源損耗

對比FabricDT、Fabric++和Fabric 在存在沖突交易時的性能差距。通過將讀交易的比例Pq分別設(shè)置為5%、50%、95%，將Zipfian 分布的偏度從0 調(diào)整到2，步長為0.5，以實現(xiàn)不同程度的沖突交易，交易發(fā)送速率固定為250 tps，測試不同設(shè)置下的性能，結(jié)果可如圖7、圖8 和表6 所示。

可以看到，F(xiàn)abricDT 在絕大多數(shù)情況下能夠在吞吐量和平均交易時延上優(yōu)于Fabric 和Fabric++。

圖7(a)和圖7(b)顯示，在不同的Zipfian 分布偏度下，F(xiàn)abricDT 吞吐量均大于Fabric 和Fabric++系統(tǒng)的吞吐量。但是，在圖7(c)中三個方法的差距不大，并且在偏度為0 和0.5 時，F(xiàn)abricDT 和Fabric++的吞吐量略低于Fabric，是因為寫交易的比例只占5%，沖突程度也比較低，因此沖突交易所占的總體交易比例很小，利用額外的機制去解決這些沖突的代價高于它所帶來的收益，造成了系統(tǒng)性能下降，但是下降幅度非常小。

可以看到，F(xiàn)abricDT 在整體上要比Fabric 和Fabric++擁有更低的時延 （如圖8 所示）。原因是FabricDT 將沖突檢測放在了第一個階段，即執(zhí)行階段，對不沖突的交易不會造成明顯的性能損失。而對沖突的交易，F(xiàn)abricDT 直接將其標記為無效，節(jié)省了系統(tǒng)資源，從而極大地降低了時延。因此，F(xiàn)abricDT 整體上具有最低的時延。

圖7 不同沖突程度下交易吞吐量

圖8 不同沖突程度下平均交易時延

表6 不同沖突程度下交易成功率

隨著偏度的增加(從1 增加到2)，F(xiàn)abricDT 會出現(xiàn)時延增加的情況，原因是隨著沖突增加，執(zhí)行階段未驗證交易緩存的大小會增加，進行沖突判斷和后續(xù)對緩存的更新所需要的時間也會增加； 同時，平均交易時延指標只統(tǒng)計了所有提交到區(qū)塊的交易時延，在執(zhí)行階段標記為無效的交易不參與統(tǒng)計，也導(dǎo)致了平均交易時延的上升。但是從實驗結(jié)果看，即使出現(xiàn)時延超過Fabric 和Fabric++，它們之間的差距也很小且可接受，而在其他情況下，F(xiàn)abricDT 都要優(yōu)于兩者。

FabricDT 在任何情況下都具有最高的交易成功率（如表6 所示）。因此，可以認為FabricDT 在總體性能上勝過Fabric 和Fabric++。

5 結(jié)論

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