李旭

（廣東省深圳市北京大學(xué)深圳研究生院 廣東省深圳市 518071）

1 背景

進年來隨著以互聯(lián)網(wǎng)為代表的信息技術(shù)高速發(fā)展推動了整個社會運轉(zhuǎn)數(shù)字化的進程，每時每刻在社會運轉(zhuǎn)各個場景：消費、企業(yè)管理、金融、工業(yè)制造、安全監(jiān)控、醫(yī)療等領(lǐng)域都在產(chǎn)生大量的數(shù)據(jù)，而很多數(shù)據(jù)是極為有價值的資產(chǎn)甚至數(shù)據(jù)是一個企業(yè)的核心競爭力已是社會的普遍共識。在這個背景下數(shù)據(jù)作為一種資產(chǎn)進行交易開始有較為迫切的訴求，但是數(shù)據(jù)交易也面臨諸多挑戰(zhàn)。如何解決這些挑戰(zhàn)成為一個意義的課題。

2 本文主要工作

當(dāng)前數(shù)據(jù)交易產(chǎn)業(yè)和技術(shù)研究還處在初期階段，無論還是產(chǎn)業(yè)標準以及商業(yè)化還是技術(shù)研究都不太成熟。

數(shù)據(jù)交易的特點：

（1）數(shù)據(jù)易泄漏：數(shù)據(jù)作為特殊的商品，區(qū)別與實物商品，可以無輕松的復(fù)制拷貝，一旦泄漏難以追回。這使得數(shù)據(jù)賣家在交易數(shù)據(jù)過程中特別謹慎。

（2）所見即所得：傳統(tǒng)商品的所有權(quán)都有一個顯式的、公認的證明，數(shù)據(jù)商品沒有了傳統(tǒng)所有權(quán)的概念，擁有數(shù)據(jù)商品也更為簡單，成本更低，看過即擁有了數(shù)據(jù)商品，就能獲得效用。

（3）交易的數(shù)據(jù)規(guī)?？赡茌^大，需要考慮海量數(shù)據(jù)存儲、交割的性能。

基于上述原因數(shù)據(jù)資產(chǎn)的交易對交易安全有著更高的訴求。目前產(chǎn)業(yè)界較為知名的數(shù)據(jù)交易市場有國內(nèi)的貴陽大數(shù)據(jù)交易所以及國外的azure在線數(shù)據(jù)市場。其模式都是通過權(quán)威的中心化機構(gòu)作為信用背書進行交易，機構(gòu)從中收取的交易費用。這種傳統(tǒng)中心化的數(shù)據(jù)交易平臺主要的問題是交易成本高，并且即便有第三方的權(quán)威機構(gòu)背書，由于數(shù)據(jù)交易的特殊性還是存在信任問題。

基于上述問題近年來學(xué)者開始嘗試基于區(qū)塊鏈技術(shù)構(gòu)建交易系統(tǒng)，試圖解決交易信任以及數(shù)據(jù)安全問題比如：Prabal Banerjee等人探索了區(qū)塊鏈交易市場設(shè)計挑戰(zhàn)和方向，楊茂江提出的基于密碼和區(qū)塊鏈結(jié)合的數(shù)據(jù)交易平臺設(shè)計，提出了一種去中心化的數(shù)據(jù)交易思路，邵曉蓓設(shè)計的區(qū)塊鏈交易系統(tǒng)，提出一種線上支付線下數(shù)據(jù)交割的設(shè)計方案。Haoqian Zhang提出了一種去中心化的信息分享方案。Benet 設(shè)計了星際文件系統(tǒng)，旨在連接所有有相同的文件系統(tǒng)的計算機設(shè)備，對分布式數(shù)據(jù)的安全共享與存儲提供了較好的思路。

總的來說這個方向目前還在探索階段，不太成熟。目前的設(shè)計主要問題是：

（1）數(shù)據(jù)如何安全交割沒有具體的設(shè)計。

（2）數(shù)據(jù)交割和支付過程分離，需要線上支付線下交割數(shù)據(jù)或只考慮數(shù)據(jù)交割。

本文旨在設(shè)計一種新型的基于聯(lián)盟鏈技術(shù)的數(shù)據(jù)資產(chǎn)交易平臺，從數(shù)據(jù)發(fā)布到交易執(zhí)行全部在鏈上完成，同時支持第三方電子支付平臺進行支付。交易和支付過程無需借助線下渠道完成。從技術(shù)上保證交易過程數(shù)據(jù)資產(chǎn)安全，可以降低交易雙方的信任成本。

3 基于聯(lián)盟鏈的數(shù)據(jù)交易平臺設(shè)計

3.1 系統(tǒng)實現(xiàn)方案概述

經(jīng)過技術(shù)調(diào)研，考慮到使用場景以及大數(shù)據(jù)量存儲、交易的性能問題，系統(tǒng)的整體設(shè)計決定聯(lián)盟鏈技術(shù)上實現(xiàn)?；A(chǔ)區(qū)塊鏈平臺實現(xiàn)參考較為成熟的fisco聯(lián)盟鏈，依托fisco聯(lián)盟鏈基礎(chǔ)平臺完成如下工作：

（1）引入了輕節(jié)點和全節(jié)點兩種不同聯(lián)盟鏈節(jié)點，兩種節(jié)點配合實現(xiàn)數(shù)據(jù)交易合約的執(zhí)行，在一定程度上犧牲去中心程度來提升數(shù)據(jù)交割性能。同時在節(jié)點存儲設(shè)計上擴展了世界態(tài)state數(shù)據(jù)結(jié)構(gòu)，引入數(shù)據(jù)資產(chǎn)索引樹(data storage trie)結(jié)構(gòu)、數(shù)據(jù)資產(chǎn)摘要倒排索引池（data abstract inverted index pool）支撐數(shù)據(jù)的加密存儲與交割。

（2）實現(xiàn)一種預(yù)編譯的特殊智能合約：數(shù)據(jù)交易智能合約，可以方便發(fā)布合約并在合約執(zhí)行時可以對接三方電子支付系統(tǒng)，支付后自動執(zhí)行鏈上數(shù)據(jù)交割工作。

（3）基于PBFT算法實現(xiàn)合約交易執(zhí)行共識。

3.2 整體架構(gòu)

本文所描述的區(qū)塊鏈交易平臺由三部分組成：全節(jié)點、聯(lián)盟鏈網(wǎng)絡(luò)、輕節(jié)點。如圖1所示。

圖1：架構(gòu)概要

輕節(jié)點：輕節(jié)點由加盟的賣家或買家維護，用于保存某個賣家發(fā)布的數(shù)據(jù)資產(chǎn)、買家買到的數(shù)據(jù)資產(chǎn)、數(shù)據(jù)資產(chǎn)摘要并通過賣家的密鑰對數(shù)據(jù)資產(chǎn)進行加密后存儲，為提升效率降低輕節(jié)點的負載，每個輕節(jié)點只保留對應(yīng)賣家賬號發(fā)布的數(shù)據(jù)資產(chǎn)、以及對應(yīng)的數(shù)據(jù)資產(chǎn)摘要。但每個輕節(jié)點都保留有全網(wǎng)的區(qū)塊頭鏈以及當(dāng)前賣家賬號狀態(tài)樹。賣家通過輕節(jié)點發(fā)布數(shù)據(jù)后會生成一份交易智能合約。

全節(jié)點：保存有全網(wǎng)的區(qū)塊鏈交易記錄、全網(wǎng)數(shù)據(jù)資產(chǎn)摘要索引、交易智能合約。同時提供成員接入和認證管理、提供數(shù)據(jù)摘要查詢能力、發(fā)起智能交易合約執(zhí)行、智能交易合約執(zhí)行結(jié)果數(shù)據(jù)維護。但是中節(jié)點不保存賣家數(shù)據(jù)資產(chǎn)信息只保存數(shù)據(jù)資產(chǎn)摘要信息。中心節(jié)點一般由平臺開發(fā)方、大機構(gòu)、大賣家、監(jiān)管機構(gòu)部署。

聯(lián)盟鏈網(wǎng)絡(luò)：輕節(jié)點和全節(jié)點通訊和執(zhí)行基礎(chǔ)能力，實現(xiàn)區(qū)塊同步、共識機制、合約執(zhí)行、連接輕節(jié)點和中心節(jié)點網(wǎng)絡(luò)、同步數(shù)據(jù)摘要索引。

交易節(jié)點的分層架構(gòu)設(shè)計：

區(qū)塊鏈基礎(chǔ)服務(wù)：實現(xiàn)區(qū)塊鏈的鏈式數(shù)據(jù)結(jié)構(gòu)、交易執(zhí)行引擎和存儲驅(qū)動、區(qū)塊鏈的基礎(chǔ)P2P網(wǎng)絡(luò)通信、共識機制和區(qū)塊同步機制。

管理層：實現(xiàn)區(qū)塊鏈的數(shù)據(jù)資產(chǎn)管理、合約管理、用戶權(quán)限管理。

接口層：對用戶提供http服務(wù)，封裝交易平臺能力。

輕節(jié)點和中心節(jié)點的區(qū)別：

（1）輕節(jié)點不提供全網(wǎng)數(shù)據(jù)資產(chǎn)摘要索引，該索引只存在與全節(jié)點中，因此買家查詢數(shù)據(jù)摘要信息需要路由到中心節(jié)點查詢。

（2）合約執(zhí)行流程輕節(jié)點和中心節(jié)點職責(zé)不同。合約執(zhí)行主要由中心節(jié)點發(fā)起調(diào)度執(zhí)行，輕節(jié)點參與合約執(zhí)行驗證、共識以及提供本地數(shù)據(jù)。詳細見2.5章節(jié)。

3.3 節(jié)點存儲設(shè)計

全局的數(shù)據(jù)存儲基于全局數(shù)據(jù)存儲設(shè)計如下所示。在傳統(tǒng)聯(lián)盟鏈設(shè)計基礎(chǔ)上新增數(shù)據(jù)結(jié)構(gòu)，用于存儲賬戶擁有的數(shù)據(jù)資產(chǎn)索引。

其中數(shù)據(jù)資產(chǎn)文件只會存儲在輕節(jié)點中，數(shù)據(jù)資產(chǎn)摘要倒排索引只存在全節(jié)點中。數(shù)據(jù)資產(chǎn)索引樹在輕節(jié)點和全節(jié)點中都會存儲。

3.3.1 賬戶狀態(tài)account state

有兩種類型的賬戶：

用戶持有 – 私鑰的所有者控制

交易合約 – 一種由代碼控制，部署在網(wǎng)絡(luò)上的智能交易合約。

字段名稱 類型 描述nonce Unit64顯示從帳戶發(fā)送的交易數(shù)量的計數(shù)器balance 這個地址擁有的 Wei 數(shù)量codeHash Byte[]該哈希表示以太坊虛擬機 (EVM) 上的帳戶代碼storageRoot Byte[]存儲hash dataHash Byte[]數(shù)據(jù)資產(chǎn)存儲hash

3.3.2 交易transtation

記錄交易結(jié)構(gòu)信息

字段名稱 類型 描述type enum 交易類型，表明該交易是創(chuàng)建合約還是調(diào)用合約交易nonce u256 消息發(fā)送方提供的隨機數(shù)，用于唯一標識交易value u256 轉(zhuǎn)賬數(shù)額，目前不需要receiveAddress h160 交易接收方地址gasPrice u256 本次交易的gas的單價gas u256 次交易允許最多消耗的gas數(shù)量data Byte[]與交易相關(guān)的數(shù)據(jù)，或者是創(chuàng)建合約時的初始化參數(shù)chainId u256 記錄本次交易所屬的鏈信息/業(yè)務(wù)信息groupId u256 記錄本次交易所屬的群組extraData Byte[]預(yù)留字段，記錄交易信息

3.3.3 區(qū)塊頭

字段名稱 類型 描述parentHash h256 父區(qū)塊的哈希值stateRoot h256 狀態(tài)樹的根哈希值transactionsRoot h256 交易樹的根哈希值receiptsRoot h256 收據(jù)樹的根哈希值dbHash h256 分布式存儲通過計算哈希值來記錄一區(qū)塊中寫入的數(shù)據(jù)number int64_t 本區(qū)塊的塊號，塊號從0號開始計算gasLimit u256 本區(qū)塊中所有交易消耗的Gas上限gasUsed u256 本區(qū)塊中所有交易使用的Gas之和timestamp int64_t 打包區(qū)塊的unix時間戳

3.3.4 數(shù)據(jù)資產(chǎn)信息datainfo

記錄數(shù)據(jù)資產(chǎn)存儲相關(guān)信息

字段名稱 類型 描述dataAbstractHash Byte[]數(shù)據(jù)摘要索引hash dataHash Byte[]數(shù)據(jù)內(nèi)容hash dataFileAddress Byte[]數(shù)據(jù)存儲文件地址

3.4 預(yù)編譯交易合約運行交互流程

整體交互協(xié)議設(shè)計如圖2所示：描述了預(yù)編譯交易合約（以下簡稱合約）的發(fā)布、執(zhí)行流程。

圖2：數(shù)據(jù)交易智能合約執(zhí)行流程

3.4.1 預(yù)編譯合約

所謂預(yù)編譯合約會被區(qū)塊執(zhí)行引擎所調(diào)用，區(qū)塊驗證器通過區(qū)塊執(zhí)行引擎來執(zhí)行區(qū)塊，執(zhí)行引擎執(zhí)行區(qū)塊時，會根據(jù)被調(diào)用合約的地址，來判斷使用EVM還是預(yù)編譯合約引擎。

當(dāng)被調(diào)用的合約地址是EVM合約時，執(zhí)行引擎會創(chuàng)建并執(zhí)行EVM來執(zhí)行交易；當(dāng)被調(diào)用合約地址是已注冊的預(yù)編譯合約地址時，執(zhí)行引擎通過調(diào)用地址對應(yīng)的預(yù)編譯合約接口來執(zhí)行交易。本方案中的交易智能合約即采用預(yù)編譯合約的方式實現(xiàn)。

3.4.2 合約發(fā)布

賣家通過本地本地輕節(jié)點發(fā)布合約。

（1）輕節(jié)點獲取到賣家賬號公鑰，通過公鑰加密待交易的數(shù)據(jù)，將加密后的數(shù)據(jù)作為文件存儲。同時將數(shù)據(jù)摘要信息打包生成數(shù)據(jù)摘要索引以便提供搜索。

（2）輕節(jié)點加載預(yù)編譯數(shù)據(jù)交易合約模版，向全網(wǎng)發(fā)起數(shù)據(jù)交易合約交易廣播。

（3）其他節(jié)點執(zhí)行發(fā)布合約交易，將本次合約寫入本地區(qū)塊中。中心節(jié)點在交易過程中扮演著核心作用，因此系統(tǒng)必須在超過1/3的中心節(jié)點寫入合約成功后發(fā)布發(fā)布才算成功。

3.4.3 合約執(zhí)行

買家通過本地的輕節(jié)點發(fā)起合約執(zhí)行。

（1）輕節(jié)點首先會找到一個中心節(jié)點發(fā)起合約執(zhí)行請求，中心節(jié)點接到到該請求后自動執(zhí)行合約代碼，根據(jù)請求調(diào)用三方電子支付系統(tǒng)生成支付鏈接或付款碼。

（2）買家根據(jù)中心節(jié)點合約執(zhí)行生產(chǎn)的付款碼使用第三方電子支付系統(tǒng)支付。支付成功后第三方電子支付系統(tǒng)根據(jù)回調(diào)地址通知中心節(jié)點支付是否成功。

（3）如果支付成功，中心節(jié)點根據(jù)合約記錄周到對應(yīng)的賣家輕節(jié)點地址，以及本地支付的買家輕節(jié)點地址。然后發(fā)起數(shù)據(jù)傳輸指令。

（4）買賣雙方輕節(jié)點根據(jù)中心節(jié)點指令建立安全通訊信道，通過握手協(xié)議生成本次傳輸數(shù)據(jù)的密鑰。賣家輕節(jié)點在內(nèi)存中通過賣家私鑰對數(shù)據(jù)解密，并通過安全信道將數(shù)據(jù)發(fā)送到買家輕節(jié)點中。

（5）買家輕節(jié)點收到數(shù)據(jù)后通知中心節(jié)點數(shù)據(jù)交割完成。

（6）中心節(jié)點收到數(shù)據(jù)交割完成消息后更新本地狀態(tài)數(shù)據(jù)，并將本次交易快照打包后廣播。其他節(jié)點驗證交易并更新本地交易記錄，完成合約執(zhí)行。

3.5 合約共識算法

一個合約在某個中心節(jié)點執(zhí)行完成后需要在全網(wǎng)達成共識。本文共識算法設(shè)計基于PBFT算法設(shè)計，適用于本交易平臺交易的共識。

算法共有無種消息：

PrepareReqPacket:

包含區(qū)塊的請求包，由leader產(chǎn)生并向所有Replica節(jié)點廣播，Replica節(jié)點收到Prepare包后，驗證PrepareReq簽名、執(zhí)行區(qū)塊并緩存區(qū)塊執(zhí)行結(jié)果，達到防止拜占庭節(jié)點作惡、保證區(qū)塊執(zhí)行結(jié)果的最終確定性的目的；

SignReqPacket:

帶有區(qū)塊執(zhí)行結(jié)果的簽名請求，由收到Prepare包并執(zhí)行完區(qū)塊的共識節(jié)點產(chǎn)生，SignReq請求帶有執(zhí)行后區(qū)塊的hash以及該hash的簽名，分別記為SignReq.block_hash和SignReq.sig，節(jié)點將SignReq廣播到所有其他共識節(jié)點后，其他節(jié)點對SignReq(即區(qū)塊執(zhí)行結(jié)果)進行共識；

CommitReqPacket:

用于確認區(qū)塊執(zhí)行結(jié)果的提交請求，由收集滿(2*f+1)個block_hash相同且來自不同節(jié)點SignReq請求的節(jié)點產(chǎn)生，CommitReq被廣播給所有其他共識節(jié)點，其他節(jié)點收集滿(2*f+1)個block_hash相同、來自不同節(jié)點的CommitReq后，將本地節(jié)點緩存的最新區(qū)塊上鏈；

ReplayReqPacket：

確認CommitReqPacket請求的回復(fù)消息。

ViewChangeReqPacket:

視圖切換請求，當(dāng)leader無法提供正常服務(wù)(如網(wǎng)絡(luò)連接不正常、服務(wù)器宕機等)時,其他共識節(jié)點會主動觸發(fā)視圖切換，ViewChangeReq中帶有該節(jié)點即將切換到的視圖(記為toView，為當(dāng)前視圖加一)，某節(jié)點收集滿(2*f+1)個視圖等于toView、來自不同節(jié)點的ViewChangeReq后，會將當(dāng)前視圖切換為toView。

算法流程描述如下：

3.5.1 REQUEST

交易合約執(zhí)行過程中某個被選中執(zhí)行的全節(jié)點（執(zhí)行節(jié)點）執(zhí)行交易合約，驗證支付結(jié)果通過后更新本地數(shù)據(jù)庫支付狀態(tài)，向主節(jié)點（一定是全節(jié)點）p發(fā)送請求。o: 請求的具體操作，這里是支付結(jié)果以及交易記錄更新，t: 請求時客戶端追加的時間戳，c：輕節(jié)點標識。REQUEST: 包含交易的執(zhí)行結(jié)果內(nèi)容m，以及消息摘要d(m)。執(zhí)行節(jié)點對請求進行簽名。

3.5.2 PRE-PREPARE

主節(jié)點（只能是全節(jié)點）收到執(zhí)行節(jié)點請求，需要進行以下交驗：

a.請求消息簽名是否正確。

非法請求丟棄。正確請求，分配一個編號n，編號n主要用于對執(zhí)行節(jié)點的請求進行排序。然后廣播一條消息PrepareReqPacket,m>消息給其他副本節(jié)點（包含全節(jié)點和輕節(jié)點）。v：視圖編號，d執(zhí)行節(jié)點消息摘要，m消息內(nèi)容。進行主節(jié)點簽名。n是要在某一個范圍區(qū)間內(nèi)的[h,H]。

為了保持消息較小。

3.5.3 PREPARE

副本節(jié)點（包含主節(jié)點和輕節(jié)點）i收到主節(jié)點的PrepareReqPacket消息，需要進行以下校驗：

a.主節(jié)點PrepareReqPacket消息簽名是否正確。

b.當(dāng)前副本節(jié)點是否已經(jīng)收到了一條在同一v下并且編號也是n，但是簽名不同的PrepareReqPacket消息。沒有收到是合法的 這是為了以防主節(jié)點作惡，將不同的請求分到相同的n,從而在其他節(jié)點產(chǎn)生請求混亂 因為在短時間會有很多請求，各個請求通過v和n區(qū)分，從而相同請求在各個節(jié)點一起執(zhí)行。

c.d與m的摘要是否一致。

d.n是否在區(qū)間[h,H]內(nèi)。非法請求丟棄。正確請求，副本節(jié)點i向其他節(jié)點包括主節(jié)點發(fā)送一條SignReqPacket消息,v,n,d與上述PrepareReqPacket消息內(nèi)容相同，i是當(dāng)前副本節(jié)點編號。不傳m，因為每個節(jié)點已經(jīng)有PrepareReqPacket了，所以有請求m，之后就不用再傳m了，只需要傳簽名d來驗證即可，節(jié)省流量。SignReqPacket進行副本節(jié)點i的簽名。每一步都要由發(fā)送方進行簽名，防止偽造。

3.5.4 COMMIT

主節(jié)點和副本節(jié)點收到SignReqPacket消息，需要進行以下校驗：

a.副本節(jié)點SignReqPacket消息簽名是否正確。

b.當(dāng)前副本節(jié)點是否已經(jīng)收到了同一視圖v下的n。

c.n是否在區(qū)間[h,H]內(nèi)。

d.d是否和當(dāng)前已收到PrepareReqPacket中的d相同非法請求丟棄。如果副本節(jié)點i收到了2f+1個驗證通過的SignReqPacket消息（表明至少有f+1個誠實節(jié)點在視圖v中發(fā)送了序列號為n的PrepareReqPacket消息或者是SignReqPacket消息），則向其他節(jié)點包括主節(jié)點發(fā)送一條CommitReqPacket,m>消息，v,n,d,i與上述SignReqPacket消息內(nèi)容相同。CommitReqPacket進行副本節(jié)點i的簽名。記錄CommitReqPacket消息到日志中，用于View Change過程中恢復(fù)未完成的請求操作。記錄其他副本節(jié)點發(fā)送的SignReqPacket消息到log中。

CommitReqPacket消息的內(nèi)容SignReqPacketPrepare消息內(nèi)容相同，但消息類型和數(shù)字簽名是不同的，所以可以區(qū)分。

3.5.5 REPLY

主節(jié)點和副本節(jié)點收到CommitReqPacket消息，需要進行以下校驗：

a.副本節(jié)點CommitReqPacket消息簽名是否正確。

b.當(dāng)前副本節(jié)點是否已經(jīng)收到了同一視圖v下的n。

c.d與m的摘要是否一致。

d.n是否在區(qū)間[h,H]內(nèi)。非法請求丟棄。如果副本節(jié)點i收到了2f+1個驗證通過的CommitReqPacket消息，說明當(dāng)前網(wǎng)絡(luò)中的大部分節(jié)點已經(jīng)達成共識，運行客戶端的請求操作o，并返回ReplayReqPacket給執(zhí)行節(jié)點，r：是請求操作結(jié)果，客戶端如果收到f+1個相同的ReplayReqPacket消息，說明執(zhí)行節(jié)點發(fā)起的交易結(jié)果已經(jīng)達成全網(wǎng)共識，否則客戶端需要判斷是否重新發(fā)送請求給主節(jié)點。記錄其他副本節(jié)點發(fā)送的CommitReqPacket消息到log中。

3.5.6 VIEW CHANGE：

當(dāng)共識超時時，系統(tǒng)會試圖切換到更高的視圖(將要切換到的視圖toView加一)，并觸發(fā)ViewChange處理流程；節(jié)點收到ViewChange包時，也會觸發(fā)ViewChange處理流程：

（1）判斷ViewChange包是否有效，有效的View Change請求中帶有的塊高值必須不小于當(dāng)前節(jié)點最高塊高，視圖必須大于當(dāng)前節(jié)點視圖。

（2）緩存有效ViewChange包，防止相同的View Change請求被處理多次，也作為判斷節(jié)點是否可以切換視圖的統(tǒng)計依據(jù)。

（3）收集ViewChange包，若收到的ViewChange包中附帶的view等于本節(jié)點的即將切換到的視圖toView且本節(jié)點收集滿2*f+1來自不同節(jié)點view等于toView的ViewChange包，則說明超過三分之二的節(jié)點要切換到toView視圖，切換當(dāng)前視圖到toView。

5 交易性能評估

交易效率受到很多方面的影響，本實驗在普通商用服務(wù)器（8核16G）部署3臺中心節(jié)點2臺輕節(jié)點，整體性能表現(xiàn)上交易TPS與交易數(shù)據(jù)大小強相關(guān)，主要的瓶頸在數(shù)據(jù)交割傳輸以及數(shù)據(jù)加解密。測試過程中mock外部三方電子支付系統(tǒng)交互。性能表現(xiàn)：

數(shù)據(jù)10byte左右，交易峰值TPS在1700左右，交易數(shù)據(jù)大小超過1mb后性能急劇下降到10TPS左右,交易時間近似等于p2p數(shù)據(jù)交割時間。可見系統(tǒng)性能優(yōu)化方向主要在數(shù)據(jù)交割部分。如圖3所示。

圖3：交易性能數(shù)據(jù)

6 總結(jié)

本文通過在傳統(tǒng)的聯(lián)盟鏈技術(shù)上改進：引入輕節(jié)點和中心節(jié)點，并設(shè)計預(yù)編譯數(shù)據(jù)交易合約協(xié)議和共識算法打通三方電子支付系統(tǒng)實現(xiàn)數(shù)據(jù)資產(chǎn)的線上交易和數(shù)據(jù)線上交割。較好的保護了數(shù)據(jù)在交易過程的安全性，通過技術(shù)手段提升了交易雙方的信任感，同時降低了雙方的交易成本。

不足之處是本方案考慮到交易性能、數(shù)據(jù)存儲成本、數(shù)據(jù)交割成本，采用半去中心化的技術(shù)，海量的敏感數(shù)據(jù)只存儲在本地輕節(jié)點中，在一定程度上會降低交易合約執(zhí)行的可靠性。同時面對大數(shù)據(jù)量的數(shù)據(jù)交割時性能會是一個瓶頸，如何將輕節(jié)點數(shù)據(jù)存儲完全分布式化并保證交易性能以及數(shù)據(jù)安全有待進一步研究。