文 攀，王 濤，朱宇坤，陳瑞東

(1.電子科技大學，四川 成都 611731； 2.中國電子科技集團公司第五十四研究所，河北 石家莊 050081)

0 引言

區(qū) 塊 鏈(Blockchain)[1]技 術 作 為 繼 云 計 算、物聯(lián)網(wǎng)、大數(shù)據(jù)、人工智能之后的又一項具有重大影響的技術，在金融、物流等領域已得到廣泛推廣，顯現(xiàn)出廣闊的應用前景。但在現(xiàn)實應用場景中，企業(yè)往往會基于自身的業(yè)務場景，而采用不同的區(qū)塊鏈平臺。這些業(yè)務往往需要與其他的業(yè)務進行交互，而不同的區(qū)塊鏈平臺所采用的共識算法往往是不同的，這就造成了區(qū)塊鏈平臺之間不能相互信任的問題。所以如何實現(xiàn)各種區(qū)塊鏈底層的互聯(lián)互通成為整個區(qū)塊鏈生態(tài)發(fā)展的極大挑戰(zhàn)。

早在2016年，以太坊的創(chuàng)始人Vitalik Buterin就針對跨鏈技術，總結(jié)出了三類跨鏈技術實現(xiàn)方式[2]——公證人機制、側(cè)鏈中繼鏈和哈希鎖定。之后隨著人們對跨鏈技術的深入研究，誕生出第4種跨鏈技術：分布式私鑰控制技術。此后，國內(nèi)外跨鏈技術的研究，大多數(shù)都是圍繞這4種技術。而本文擬采用側(cè)鏈中繼鏈的方式，再通過文中設計的技術架構(gòu)以及適配協(xié)議實現(xiàn)異構(gòu)聯(lián)盟鏈之間的智能合約交互，讓兩異構(gòu)聯(lián)盟鏈的互操作性成為一種可能。

1 區(qū)塊鏈跨鏈技術

1.1 跨鏈技術

跨鏈技術(Cross-chain Technology)[3]，意圖突破鏈與鏈之間的信任障礙，使鏈與鏈之間具備進行相互操作的業(yè)務交易能力?？珂溂夹g主要解決的問題有以下4點：

① 鏈間資產(chǎn)安全轉(zhuǎn)移?，F(xiàn)階段的跨鏈資產(chǎn)轉(zhuǎn)移主要依靠第三方的中心化交易所，資產(chǎn)的安全性完全取決于第三方的中心化交易所?？珂溂夹g利用技術手段來確保資產(chǎn)的安全，而不是依靠第三方的機構(gòu)或人。

② 實現(xiàn)資產(chǎn)的鏈上凍結(jié)。類似于現(xiàn)實中金融行業(yè)的資產(chǎn)凍結(jié),跨鏈技術提供一種在鏈上凍結(jié)資產(chǎn)的方式。

③ 跨鏈可信交互。不同的業(yè)務可能會使用各個平臺的智能合約，而不同的業(yè)務之間，又有可能會有關聯(lián)信息交互?？珂溂夹g為基于異構(gòu)區(qū)塊鏈底層之間的業(yè)務交互提供了置信可能。

④ 提升區(qū)塊鏈的應用可擴展性。區(qū)塊鏈的吞吐量以及可擴展性一直以來都是區(qū)塊鏈的性能瓶頸[4]，而跨鏈技術是區(qū)塊鏈鏈間擴展業(yè)務模式和跨域業(yè)務信息可信交互的重要技術支撐。

目前，跨鏈技術主要有3個亟需解決的難題。一是保證跨鏈交易滿足原子交換[5]：即雙方的交易要么同時發(fā)生，要么同時不發(fā)生，二者是一個整體不可分割；二是跨鏈信任關系傳遞實現(xiàn)比較困難：跨鏈涉及到鏈與鏈之間的價值流動，同時又不能改變原鏈特性，因此跨鏈需要根據(jù)原鏈的相關特性進行適配性開發(fā)[6]；三是交易速度提升：隨著區(qū)塊鏈技術的發(fā)展，跨鏈的需求會越來越強烈，但是目前的跨鏈技術很難滿足大規(guī)模的跨鏈交易。

現(xiàn)今的跨鏈技研究中，大多數(shù)的跨鏈項目用于解決鏈之間資產(chǎn)的轉(zhuǎn)移以及凍結(jié)等方面的問題。對于跨鏈智能合約的安全交互方面，研究相對較少。本文針對跨鏈智能合約的可信交互問題，基于中繼鏈的技術，提出一種適用于異構(gòu)聯(lián)盟鏈的智能合約安全交互框架。

1.2 主要跨鏈技術對比

目前主流的跨鏈技術有4種，分別是公證人機制、側(cè)鏈中繼鏈機制、哈希鎖定技術以及分布式私鑰控制技術。從鏈之間的互操作性、信任模型、交易速度、跨鏈資產(chǎn)抵押以及實現(xiàn)難度等多方面進行分析，得出結(jié)果如表1所示。

表1 主流跨鏈技術對比

本文采用中繼鏈的方式主要基于以下三點原因：

① 安全性：公證人機制的安全性完全取決于跨鏈雙方共同信任的第三方，如果第三方作惡，跨鏈的安全性完全得不到保障。

② 實現(xiàn)難度：哈希鎖定以及分布式私鑰控制技術主要用于解決跨鏈資產(chǎn)轉(zhuǎn)移或者是凍結(jié)，要使用這兩種技術實現(xiàn)跨鏈智能合約的安全交互，實現(xiàn)難度非常困難。

2 基于中繼鏈的跨鏈技術

2.1 跨鏈交互模型設計

針對目前異構(gòu)聯(lián)盟鏈之間的交互困難，本文提出一種適用于異構(gòu)聯(lián)盟鏈底層平臺的跨鏈模型，模型構(gòu)建如圖1所示。

圖1 系統(tǒng)模型Fig.1 System mode

定義1 本文異構(gòu)聯(lián)盟鏈的跨鏈模型(Cross-chain Model for Heterogeneous Alliance Chains，HAC-CCM)的最小五元組為HAC-CCM=(Ca,Pa-r,Cr,Pr-b,Cb)。式中，Ca為業(yè)務A所采用的聯(lián)盟鏈底層平臺A；Pa-r為連通聯(lián)盟鏈A與Cr的平行鏈；Cr為間接連接兩異構(gòu)區(qū)塊鏈的中繼鏈；Pr-b為連接中繼鏈Cr與Cb的平行鏈；Cb為業(yè)務B所采用的聯(lián)盟鏈底層平臺B。其中，聯(lián)盟鏈底層平臺可以任意增加，為了避免聯(lián)盟鏈底層平臺通過平行鏈進行兩兩交互的復雜度出現(xiàn)組合級別的增加，在HAC-CCM中引入了中繼鏈，所有的平行鏈都通過中繼鏈Cr進行交互。

定義2 本模型需要構(gòu)建原鏈與中繼鏈之間的平行鏈P，P=(Ca,Si,PR,Td)，其中Si為智能合約集，智能合約集主要包含兩個智能合約S1和S2。其中S1是代理合約，S2是注冊合約；PR是一個輕客戶端，其作用是接收對方區(qū)塊頭的信息，以便于執(zhí)行類似于SPV驗證；Td是開源的Tendermint[13]共識算法，平行鏈與中繼鏈采用相同的Tendermint共識算法，便于交互。

定義3 本模型中的中繼鏈Cr，Cr=(Td)，Td是與平行鏈系相同的共識算法。

模型中，首先在平行鏈中集成對應聯(lián)盟鏈模塊，平行鏈就能與聯(lián)盟鏈進行交互。同時，通過平行鏈中設置處理聯(lián)盟鏈跨鏈請求的智能合約。由于區(qū)塊鏈是用于多主機狀態(tài)機復制的系統(tǒng)。區(qū)塊鏈接口(ABCI[14])定義了復制引擎(區(qū)塊鏈)和狀態(tài)機(應用程序)之間的邊界。使用套接字協(xié)議，在一個進程中運行的共識引擎可以管理在另一個進程中運行的應用程序狀態(tài)。在此利用ABCI接口協(xié)議可以方便平行鏈中集成的聯(lián)盟鏈模塊與Tendermint共識進程進行連接。

在HAC-CCM的運行過程中，中繼鏈與平行鏈之間的信息交互過程也較為重要。中繼鏈需要轉(zhuǎn)發(fā)平行傳來的跨鏈請求以及請求對應的簡單證明數(shù)據(jù)。

2.2 系統(tǒng)架構(gòu)設計

為了實現(xiàn)異構(gòu)聯(lián)盟鏈中智能合約的交互，設計如圖2所示的系統(tǒng)架構(gòu)。

圖2 系統(tǒng)架構(gòu)Fig.2 System Structure

除去最下面的異構(gòu)聯(lián)盟鏈的底層平臺，本系統(tǒng)分為3層：接口層、傳輸層和驗證層。為了降低跨鏈系統(tǒng)對原有系統(tǒng)的修改，設計了接口層，以實現(xiàn)系統(tǒng)的“非侵入式”開發(fā)。在接口層中主要有兩個接口:智能合約接口和ABCI接口。其中智能合約接口對跨鏈智能合約調(diào)用進行統(tǒng)一規(guī)范；而ABCI接口用于規(guī)范跨鏈信息交換的規(guī)范。傳輸層包含兩個協(xié)議:Gossip和grpc協(xié)議。其中Gossip協(xié)議用于平行鏈和中繼鏈節(jié)點間的通信，而grps協(xié)議用于消息的訂閱與廣播。驗證層也包含兩個模塊：Merkle-Tree驗證和身份驗證。Merkle-Tree結(jié)構(gòu)可以快速歸納和校驗跨鏈交易區(qū)塊數(shù)據(jù)的完整性[15]，身份認證用于驗證用戶身份，以確認用戶是否有權(quán)限調(diào)用智能合約。

2.3 智能合約集接口設計

不同的業(yè)務可能有不同的智能合約，為了能夠統(tǒng)一調(diào)用異構(gòu)聯(lián)盟鏈中的智能合約，本文設計了統(tǒng)一的智能合約調(diào)用接口。使得用戶在調(diào)用異構(gòu)聯(lián)盟鏈的智能合約時無需關注其具體使用的語言以及聯(lián)盟鏈底層架構(gòu)，只需要傳入相應的參數(shù)，經(jīng)過統(tǒng)一的處理之后獲取調(diào)用返回值。具體接口功能如表2所示。

表2 智能合約集接口描述表

智能合約調(diào)用接口，偽代碼如下所示。

智能合約集接口type SmartCode interface{∥只讀調(diào)用func Get(args string)∥讀寫調(diào)用func Set(args string) string∥注冊事件回調(diào)func Register(callback EventCallback)}

2.4 ABCI接口實現(xiàn)

ABCI接口規(guī)定的函數(shù)接口非常多，但是主要需要實現(xiàn)的接口如表3所示。

表3 ABCI主要接口

2.5 基于Merkle樹的簡單驗證

系統(tǒng)引入Merkle樹結(jié)構(gòu)，以便可以對交易信息的完整性和真實性進行快速校驗。當交易信息在進行跨鏈操作時，由于區(qū)塊鏈系統(tǒng)的封閉性，不能對其他區(qū)塊鏈的交易信息進行校驗，利用Merkle樹對其他鏈的交易進行校驗，可以保證傳入?yún)^(qū)塊鏈數(shù)據(jù)的正確性，保障整個系統(tǒng)的狀態(tài)始終處于正確狀態(tài)。

3 模擬運行過程

假設，使用Fabric的組織A需查詢位于FISCO BCOS上面的數(shù)據(jù)。以單邊交互為例，跨鏈交互的過程如圖3所示。

圖3 模擬跨鏈交互過程 Fig.3 Simulate Cross-chain Interaction Process

① 首先A調(diào)用Fabric上的智能合約，并進行鑒權(quán)；

② 通過Fabric 上的智能合約調(diào)用平行鏈A中的注冊智能合約，發(fā)送請求數(shù)據(jù)以及相應的交易證明；

③ 將請求信息以及相應的交易證明存儲到任務隊列；

④ 通過ABCI將Fabric中的請求及相應證明共識轉(zhuǎn)換到Tendermint共識系統(tǒng)中；

⑤ 平行鏈A傳輸經(jīng)過Tendermint共識的請求及相應的證明；

⑥ 中繼鏈接收到的請求及相應的證明進行安全路由；

⑦ 向平行鏈B轉(zhuǎn)發(fā)請求及相應的證明；

⑧ 當平行鏈B接收到請求以及相應的證明之后，通過SPV輕客戶端對請求進行驗證，如果通過則進入步驟⑨，否則不處理；

⑨ 通過ABCI接口將Tendermint中的共識消息，轉(zhuǎn)換到中繼鏈B中的FISCO BCOS系統(tǒng)中；

⑩ 將收到的請求信息，作為參數(shù)傳入中繼鏈中的代理合約；

4 實驗結(jié)果分析

4.1 軟硬件測試環(huán)境

本文的測試的軟硬件環(huán)境如表4所示。

表4 軟硬件測試環(huán)境

4.2 實驗及結(jié)果分析

本模型系統(tǒng)的性能，可以通過統(tǒng)計系統(tǒng)每秒處理的調(diào)用請求數(shù)量進行衡量。在測試過程中，以10次/s調(diào)用為步長進行增加，確定其交易所需要的時間。本次通過FISCO BCOS聯(lián)盟鏈調(diào)用Fabric的Fabcar智能合約，利用其提供的函數(shù)通過CarID查詢汽車的相關信息進行測試，得到圖4所示的結(jié)果。

圖4 調(diào)用處理時間Fig.4 Call processing time

從圖4可以看出，系統(tǒng)處理異構(gòu)聯(lián)盟鏈的極限大致在100次/s。經(jīng)過分析發(fā)現(xiàn)系統(tǒng)性能的主要是受到Tendermint共識效率以及根據(jù)ABCI接口進行共識轉(zhuǎn)化的影響。由于整個系統(tǒng)在一臺計算機上模擬進行，網(wǎng)絡條件較好，沒有涉及到網(wǎng)絡阻塞情況對系統(tǒng)的吞吐率的影響。同時，在模擬運行時CUP的使用率幾乎達到100%，可能會對系統(tǒng)的處理效率有較大的影響。

5 結(jié)論

本文通過在區(qū)塊鏈網(wǎng)絡中引入中繼鏈，以及設計平行鏈的方式，構(gòu)建了一種適用于異構(gòu)聯(lián)盟鏈間的交互模型。本模型與其他跨鏈項目區(qū)別在于能夠?qū)崿F(xiàn)異構(gòu)聯(lián)盟鏈之間智能合約的相互調(diào)用交互，而其他模型基于中繼鏈的解決方案主要是解決跨鏈資產(chǎn)的轉(zhuǎn)移。本模型還處于初步探索階段，對于其安全性還未進行有效分析和驗證。同時，模型處理交互請求的效率以及吞吐量等也有待在后續(xù)的工作中進一步優(yōu)化，希望今后在此方面與更多的學者一起共同努力。