基于智能合約的細(xì)粒度數(shù)據(jù)交易計量驗證方法

唐經(jīng)緯，王玲芳，李楊

（1.中國科學(xué)院大學(xué)，北京 100049；2.中國科學(xué)院聲學(xué)研究所國家網(wǎng)絡(luò)新媒體工程技術(shù)研究中心，北京 100190）

在大數(shù)據(jù)時代，單一數(shù)據(jù)價值有限，數(shù)據(jù)不斷地被收集分析，才能用于引領(lǐng)科技創(chuàng)新和經(jīng)濟增長[1]。數(shù)據(jù)流通交易是釋放數(shù)據(jù)價值的有效途徑，也是不可避免的趨勢和需求[2]，現(xiàn)已有大量中心化數(shù)據(jù)交易平臺出現(xiàn)，但存在隱私和安全等問題。信息中心網(wǎng)絡(luò)是一種以數(shù)據(jù)信息為中心的網(wǎng)絡(luò)架構(gòu)，包括NDN、MobilityFirst、SEANet[3]等項目，其分布式的數(shù)據(jù)交付模式可解決中心式數(shù)據(jù)交易如單點故障的部分問題，但此模式又給數(shù)據(jù)服務(wù)的計量提出了新的需求，且存在分布式場景下的安全與隱私問題[4]。

隨著區(qū)塊鏈技術(shù)不斷發(fā)展，各行業(yè)都在探索與區(qū)塊鏈的結(jié)合應(yīng)用[5-6]，引入?yún)^(qū)塊鏈能一定程度解決第三方服務(wù)的不可信問題[2]。針對分布式場景下的數(shù)據(jù)交易，文中提出一種基于區(qū)塊鏈上Merkle 樹的細(xì)粒度數(shù)據(jù)交易計量及驗證方法，并通過在以太坊私有鏈上的部署實現(xiàn)驗證。

1 相關(guān)研究

1.1 數(shù)據(jù)交易平臺

現(xiàn)有的數(shù)據(jù)交易平臺主要可以分為集中式和分布式兩類[7]。

集中式數(shù)據(jù)交易平臺主要由互聯(lián)網(wǎng)企業(yè)以及政府兩類組織機構(gòu)運營，集中式數(shù)據(jù)交易模式又可分為托管模式和聚合模式[7]。托管模式數(shù)據(jù)所有方將數(shù)據(jù)上傳至第三方數(shù)據(jù)交易中心托管數(shù)據(jù)，所有者對數(shù)據(jù)的后續(xù)使用與交易可能失去控制。聚合式數(shù)據(jù)所有方各自保存和管理自身數(shù)據(jù)，一定程度解決托管式失去對數(shù)據(jù)控制的問題，但是聚合平臺有能力在數(shù)據(jù)流經(jīng)平臺時，獲取并留存數(shù)據(jù)[8]。此外集中模式均存在單點故障問題。

分布式平臺主要結(jié)合區(qū)塊鏈，建立一個無第三方的數(shù)據(jù)交易平臺，交易鏈上記錄，避免單點故障，各方用戶通過鏈上記錄達成協(xié)商，直接發(fā)起交易。文獻[9]設(shè)計了一種基于區(qū)塊鏈的自動數(shù)據(jù)交易框架，數(shù)據(jù)加密上傳，但需用戶主動上傳數(shù)據(jù)到中心式的存儲服務(wù)器。文獻[4,10]構(gòu)建基于區(qū)塊鏈的計算任務(wù)市場架構(gòu)以及文獻[11]提出的數(shù)據(jù)交易解決方案，均將數(shù)據(jù)在鏈下分布式存儲，無第三方保存數(shù)據(jù)副本的問題。但兩個方案需要在鏈下非匿名通信協(xié)商交易。

1.2 區(qū)塊鏈技術(shù)

區(qū)塊鏈?zhǔn)且环N分布式數(shù)字賬本系統(tǒng)，將數(shù)據(jù)區(qū)塊按照時間順序組合成鏈?zhǔn)浇Y(jié)構(gòu)，由去中心化系統(tǒng)中各節(jié)點共享和維護[12]。區(qū)塊鏈憑借不可篡改性以及可追溯性，使得其在數(shù)據(jù)資產(chǎn)交易領(lǐng)域有所應(yīng)用，區(qū)塊鏈可以構(gòu)建數(shù)據(jù)資產(chǎn)交易的索引，幫助數(shù)據(jù)溯源確權(quán)。以太坊區(qū)塊鏈?zhǔn)状我胫悄芎霞s[13]，為區(qū)塊鏈提供更多數(shù)字貨幣外的應(yīng)用場景[6]。區(qū)塊鏈常用共識算法有工作量證明（Proof of Work，PoW）、權(quán)益證明（Proof of Stake，PoS）等[14]。

1.3 數(shù)據(jù)存儲技術(shù)

區(qū)塊鏈的數(shù)據(jù)存儲根據(jù)存儲位置分為鏈上存儲和鏈下存儲。

在區(qū)塊鏈上進行大量數(shù)據(jù)的存儲是不可接受的[15]，在區(qū)塊鏈存儲數(shù)據(jù)會導(dǎo)致所有節(jié)點均存儲副本，在節(jié)點數(shù)眾多時開銷巨大，以太坊通過燃?xì)赓M設(shè)計來限制用戶的存儲和計算。

常見與區(qū)塊鏈結(jié)合的存儲方式是基于分布式存儲的鏈下存儲方案，指將數(shù)據(jù)的哈希值或鏈下存儲的索引存于鏈上，如星際文件系統(tǒng)（Inter Planetary File System，IPFS）[16]。結(jié)合IPFS 進行數(shù)據(jù)存儲時在鏈上存儲數(shù)據(jù)的索引哈希值，能夠保證數(shù)據(jù)到鏈下查詢獲取并驗證是否篡改。

2 方法設(shè)計

文中提出一種區(qū)塊鏈上智能合約中基于Merkle樹的數(shù)據(jù)塊細(xì)粒度數(shù)據(jù)交易及驗證方法，結(jié)合IPFS存儲，提供數(shù)據(jù)交易、數(shù)據(jù)獲取過程中細(xì)粒度計量和驗證。該方法可以在鏈上無需信任地完成密鑰交付，在數(shù)據(jù)獲取過程多次進行結(jié)算，基于Merkle 樹的驗證方法也提供了不同大小數(shù)據(jù)交易的伸縮能力。

2.1 數(shù)據(jù)存儲

鏈上存儲采用基于智能合約的存儲。在以太坊虛擬機（Ethereum Virtual Machine，EVM）的智能合約中，計算與存儲均需要以gas 為單位的執(zhí)行開銷支付費用，為限制用戶向鏈上大量存儲，設(shè)置了每32 B 的鏈上數(shù)據(jù)存儲開銷為20 000 gas，作為對比加法操作開銷為3 gas，乘法操作為5。因此鏈上數(shù)據(jù)通常只存儲賬戶狀態(tài)數(shù)據(jù)、交易數(shù)據(jù)以及智能合約數(shù)據(jù)，保證賬本的可觀察性、可驗證性及智能合約的可執(zhí)行性。

鏈下存儲采用IPFS。IPFS 將文件存儲為默克爾有向無環(huán)圖（Merkle Directed Acyclic Graph，Merkle-DAG），文件被拆分為擁有獨自的哈希指紋作為標(biāo)識的數(shù)據(jù)塊，標(biāo)識稱為內(nèi)容標(biāo)識符（Content Identifier，CID）用于訪問數(shù)據(jù)塊或文件，數(shù)據(jù)塊再通過鏈接節(jié)點呈樹結(jié)構(gòu)排列連接[17]。每一個數(shù)據(jù)塊將被賦予CID，以Merkle-DAG 的形式分塊存儲，分塊均擁有獨立CID，并作為索引構(gòu)建有向無環(huán)圖，鏈接分塊需要增加鏈接塊從而能夠?qū)⒎謮K恢復(fù)數(shù)據(jù)文件，鏈接塊同樣將擁有獨立CID。在該方案中需要利用此特性，因此存儲數(shù)據(jù)時DO 需要提取原始數(shù)據(jù)（Original Data，OD）的CID 用于后續(xù)加密傳輸。而數(shù)據(jù)在IPFS存儲時各數(shù)據(jù)塊均為數(shù)據(jù)密文（Encrypted Data，ED）。

2.2 數(shù)據(jù)加密

由于非對稱加密和對稱加密的性能差距顯著，對稱加密適用于加密大文件，采用非對稱加密和對稱加密兩階段的方式，IPFS 數(shù)據(jù)采用AES 對稱加密處理，對稱密鑰SKAES進行非對稱加密處理。

對稱加密階段，將需要上傳到IPFS 的文件進行AES 的ECB 模式加密，數(shù)據(jù)切割成分組長度相等的塊，各塊獨立加密[18]，在IPFS 按數(shù)據(jù)塊獲取后也能夠單獨解密，不需要其他數(shù)據(jù)塊就能正確得到塊的明文。使用IPFS 存儲的默認(rèn)數(shù)據(jù)塊大小為256 kB，在進行AES 加密時能夠在不進行填充的情況下加密，密文數(shù)據(jù)塊與明文數(shù)據(jù)塊的占用存儲空間相同。最末尾數(shù)據(jù)塊可能存在未存滿情況，僅需根據(jù)AES 加密需求進行少量填充。而CID 作為獲取數(shù)據(jù)的索引，在鏈上同樣需要進行加密，得到多個CID密文Enc(CID,SKAES)，CID 密文數(shù)量為需要上鏈的數(shù)據(jù)量。

非對稱加密階段，DO 監(jiān)聽數(shù)據(jù)請求者(Data User，DU)向鏈上發(fā)起的交易請求，請求發(fā)生時DO 能夠獲得DU 的公鑰PKDU，則使用PKDU加密AES 對稱密鑰SKAES得到密鑰密文Enc(SKAES,PKDU)然后上鏈，從而保證密鑰傳輸?shù)陌踩?。DU 監(jiān)聽到DO 的上鏈日志，則用自己的以太坊地址的私鑰SKDU進行解密得到SKAES，再解密Enc(CID,SKAES)，得到實際存儲的CID 再進行數(shù)據(jù)的獲取。由于提供的CID 只能獲取整個數(shù)據(jù)的一部分，因此需要多次獲取多份CID 才能夠下載到完整的數(shù)據(jù)，從而實現(xiàn)細(xì)粒度的數(shù)據(jù)交易控制。根據(jù)此特性，可以控制數(shù)據(jù)的獲取粒度為分塊數(shù)量，從而在數(shù)據(jù)獲取的過程中即可進行價值計量。而在數(shù)據(jù)的存儲階段則可以設(shè)置IPFS 的Merkle-DAG 分支數(shù)量，若分支數(shù)量較小則能夠以更小的粒度進行計量。

2.3 身份注冊及數(shù)據(jù)注冊

該文方案中，注冊包含用戶身份注冊及數(shù)據(jù)注冊兩類。各身份實體均是EVM 模型下的外部賬戶，通過公私鑰對的形式向區(qū)塊鏈注冊。身份注冊將在鏈上對DO 及DU 身份進行記錄，數(shù)據(jù)在交易合約中進行注冊，供后續(xù)下載時索引和使用。合約管理方（Contract Manager，CM）可以要求實體用戶提供真實身份及注冊匿名賬號的映射關(guān)系，進行監(jiān)管。由于鏈上數(shù)據(jù)的透明性，映射信息的提供和保管均由CM在鏈下進行。針對匿名問題，盡管用戶以匿名地址的方式加入?yún)^(qū)塊鏈網(wǎng)絡(luò)，但仍有被獲取真實信息、追蹤到真實實體的可能[19]。該方案中一個實體可以通過多個不同賬戶注冊，從而一定程度上避免追蹤，但是在注冊階段要求實體主動向CM 提供對應(yīng)關(guān)系，從而保障賬戶均受監(jiān)管。數(shù)據(jù)注冊流程如圖1 所示。

圖1 數(shù)據(jù)注冊流程圖

數(shù)據(jù)注冊時提供元數(shù)據(jù)，包括描述信息、所有者、數(shù)據(jù)大小、價格、CID 密文等，DO 可以根據(jù)自己的數(shù)據(jù)價值進行定價，總價值需要與數(shù)據(jù)的大小錨定。該方法支持在較大數(shù)據(jù)傳輸時，確保已下載的數(shù)據(jù)和已支付的款項相一致，而非在交易結(jié)束后進行一次性的結(jié)算。一個文件的各部分?jǐn)?shù)據(jù)有可能存儲有用的數(shù)據(jù)信息，因此在傳輸過程中出現(xiàn)故障時，該方法可以保證支付金額和獲取數(shù)據(jù)的價值對等。

2.4 數(shù)據(jù)獲取

在數(shù)據(jù)獲取階段采用多輪微驗證及微支付完成，具體獲取流程如圖2 所示。該方法中針對鏈上存儲開銷進行優(yōu)化，使用區(qū)塊鏈中事件日志的形式進行消息存放，較大程度減少執(zhí)行開銷。

圖2 數(shù)據(jù)交易流程圖

1）DU 訂閱數(shù)據(jù)注冊合約，根據(jù)訂閱的鏈上日志發(fā)現(xiàn)自己需求的數(shù)據(jù)，主動向鏈上發(fā)起交易請求，發(fā)起請求時提供己方公鑰PKDU給DO，用于加密對稱密鑰SKAES。隨后DO 根據(jù)日志請求，響應(yīng)對稱密鑰密文Enc(SKAES,PKDU)。

2）DO 在鏈上監(jiān)聽到DU 的日志請求，上傳單輪次的IPFS 數(shù)據(jù)CID 密文Enc(CID,SKAES)進行傳輸，并通過數(shù)據(jù)交易合約自動調(diào)用通證質(zhì)押合約，進行當(dāng)前交易部分的數(shù)據(jù)的微支付，實現(xiàn)單次密文調(diào)用。

3）數(shù)據(jù)獲取和驗證同時進行，DU 向臨近區(qū)塊鏈節(jié)點訂閱日志，收到屬于自己的日志消息則用己方私鑰SKDU解密得到CID 明文，再向IPFS 發(fā)起數(shù)據(jù)下載。當(dāng)完成下載后通過交易發(fā)起時收到的對稱密鑰對數(shù)據(jù)塊進行解密，完成數(shù)據(jù)獲取。再利用解密的數(shù)據(jù)，通過構(gòu)建Merkle 樹的方法獲得Merkle 根，向鏈上發(fā)起驗證日志記錄。若直接獲取所有數(shù)據(jù)塊的CID，則獲取日志和驗證日志條數(shù)將與數(shù)據(jù)塊數(shù)量一致，而單個文件被分塊存儲后可能由數(shù)萬塊構(gòu)成，因此獲取以及驗證的代價極大。該方法中利用IPFS的DAG 結(jié)構(gòu)，DO 僅提供中間鏈接節(jié)點，從而DU 能夠自行獲取子節(jié)點，減少獲取開銷；再利用Merkle 樹將數(shù)據(jù)塊統(tǒng)一驗證，減少驗證開銷。Merkle 樹的構(gòu)建需要單輪獲取的所有數(shù)據(jù)塊明文，逐一生成塊的哈希值，作為Merkle 樹的葉節(jié)點內(nèi)容。中間節(jié)點哈希值由它的兩個子節(jié)點內(nèi)容的哈希值再次進行哈希獲得，根節(jié)點則是整棵樹結(jié)構(gòu)的最頂部節(jié)點，同樣由兩個子節(jié)點內(nèi)容的哈希值組成。構(gòu)建完成后將根節(jié)點哈希值記錄上鏈，DO 監(jiān)聽到反饋的驗證日志，對比日志中的Merkle 根哈希值和己方生成的哈希值是否一致，完成微驗證。

4）數(shù)據(jù)在DU 獲取并在DO 驗證通過后，DO 重復(fù)執(zhí)行第2）、3）步，直到DU 獲取到全部數(shù)據(jù)塊，結(jié)束數(shù)據(jù)獲取過程。

3 實驗評估

該方案采用以太坊PoW 共識私有鏈進行測試，測試環(huán)境：Intel(R) Xeon(R) Silver 4208 CPU@2.10 GHz，128G 內(nèi)存，CentOS Linux release 7.9.2009(Core)操作系統(tǒng)，以太坊使用geth 客戶端實例，golang版本1.17.3。

使用PoW 共識算法的情況下，共識速度為平均13～15 s 生成一個新區(qū)塊，遠(yuǎn)慢于智能合約數(shù)據(jù)交易處理速度的毫秒量級，因此交易過程中性能瓶頸會出現(xiàn)在共識算法產(chǎn)生新區(qū)塊處，在測試時不考慮共識速度影響。通過實驗得到相關(guān)智能合約函數(shù)調(diào)用開銷如表1 所示。

表1 智能合約函數(shù)調(diào)用開銷

函數(shù)調(diào)用中單次開銷最大為constructor，但該函數(shù)用于在合約首次部署上鏈時調(diào)用，且合約全生命周期中僅調(diào)用一次，因此不是開銷總和最大方法。表中requestData 函數(shù)雖然單次調(diào)用開銷最小，但是其調(diào)用次數(shù)與數(shù)據(jù)大小相關(guān)，若單輪獲取量較少，則能夠控制為更小的計量以及驗證的粒度，但調(diào)用總開銷增加。

不同數(shù)據(jù)大小下，驗證方法的執(zhí)行開銷對比如圖3 所示。基準(zhǔn)方法為基于每個數(shù)據(jù)塊CID 進行驗證，優(yōu)化方法為該方案采用的基于Merkle 樹的方式聚合驗證。從圖中可以看出，當(dāng)數(shù)據(jù)較小時，兩種方法的開銷基本一致，而當(dāng)數(shù)據(jù)量增大到10 MB 及以上時，兩方法開銷差異增大，10 MB 數(shù)量級時開銷優(yōu)化方法執(zhí)行開銷比基準(zhǔn)方法降低65%。該文方法的優(yōu)勢在于數(shù)據(jù)量較大時，通過Merkle 樹進行聚合的驗證，極大降低了與區(qū)塊鏈的驗證次數(shù)，如在100 MB數(shù)據(jù)大小時，該文方法驗證次數(shù)相比對比方法降低99.75%，因此減少執(zhí)行開銷。

圖3 不同數(shù)據(jù)大小驗證方法執(zhí)行開銷對比

不同數(shù)據(jù)大小下，驗證耗時對比如圖4 所示。如前文所述，實驗的PoW 共識速度為平均出塊時間15 s，遠(yuǎn)大于驗證耗時，因此對比中排除共識生成區(qū)塊耗時，僅包含交易驗證交互的時間。

圖4 不同數(shù)據(jù)大小驗證耗時對比

從圖4 中可發(fā)現(xiàn)，在數(shù)據(jù)量較小時，兩種方法的驗證耗時均在50 μs 量級，但在數(shù)據(jù)量增大時優(yōu)化方法的驗證耗時一直保持在50 μs 量級，而基準(zhǔn)方法則會隨著數(shù)據(jù)大小增加而線性增加，在數(shù)據(jù)大小為500 MB 時，優(yōu)化方法比基準(zhǔn)方法驗證耗時減少88%。在驗證時由于Merkle 樹可以直接驗證單輪傳輸?shù)乃袛?shù)據(jù)塊，因此只需要向鏈上發(fā)送一個樹根哈希值即可驗證，而每塊均獨立驗證的方式則需要接收數(shù)據(jù)塊數(shù)量的哈希值，驗證時間隨塊數(shù)量線性增加。

4 結(jié)束語

文中研究了現(xiàn)有數(shù)據(jù)交易方案及其缺陷，提出了一種基于Merkle 樹的快速驗證方法，結(jié)合IPFS 存儲，實現(xiàn)數(shù)據(jù)塊細(xì)粒度交易計量，最后進行實驗驗證。實驗結(jié)果表明，該方法能夠?qū)崿F(xiàn)數(shù)據(jù)塊級別細(xì)粒度的數(shù)據(jù)計量，在鏈上高效穩(wěn)定完成計量、交易與驗證。該文方案適用于大數(shù)據(jù)服務(wù)，仍有部分設(shè)計需要改進，如數(shù)據(jù)獲取時發(fā)生錯誤可能導(dǎo)致需重新獲取錯誤部分的索引并下載，導(dǎo)致效率低下；無整合眾多的小型數(shù)據(jù)能力。在未來工作中，需進一步研究設(shè)計以改進上述問題。