基于中繼鏈的聯(lián)盟鏈跨鏈監(jiān)管機制

陸藝仁，朱友文

南京航空航天大學 計算機科學與技術(shù)學院，南京211106

隨著互聯(lián)網(wǎng)技術(shù)的快速發(fā)展，區(qū)塊鏈技術(shù)[1]憑借其鏈上數(shù)據(jù)不可偽造、不可虛構(gòu)、不可篡改等優(yōu)勢，逐漸融入企業(yè)和個人的生活中，并且在物流溯源、去中心化交易所、政務系統(tǒng)等領(lǐng)域大放異彩。區(qū)塊鏈從功能和規(guī)模上可以分為三類[2]，公鏈、私有鏈、聯(lián)盟鏈。考慮到數(shù)據(jù)的隱私和安全，當前多數(shù)企業(yè)用戶在部署業(yè)務時會選擇使用聯(lián)盟鏈。由于聯(lián)盟鏈底層實現(xiàn)差距較大，無法形成有效的數(shù)據(jù)共享，從而形成一個個數(shù)據(jù)孤島，這給聯(lián)盟鏈的發(fā)展以及監(jiān)管帶來了很大的不便，也促進了跨鏈技術(shù)的發(fā)展。

跨鏈技術(shù)[3-4]是指實現(xiàn)區(qū)塊鏈之間數(shù)據(jù)共享與互操作的技術(shù)，現(xiàn)有跨鏈協(xié)議大多數(shù)注重于鏈與鏈之間資產(chǎn)原子交換，且絕大多數(shù)基于公鏈，注重數(shù)據(jù)共享的聯(lián)盟鏈跨鏈領(lǐng)域存在較大空白。

比特幣是區(qū)塊鏈的開始，引入智能合約后的以太坊則是區(qū)塊鏈2.0的代表。起初智能合約只負責一些簡單的鏈上存儲與計算，隨著區(qū)塊鏈應用場景的不斷豐富，業(yè)務場景越發(fā)復雜，鏈上計算的復雜度也隨之上升，在DeFi[5]之類的金融應用中計算結(jié)果錯誤可能造成嚴重損失，因此對鏈上計算正確性監(jiān)管的需求也日益增加。

目前現(xiàn)有的跨鏈技術(shù)研究多數(shù)是基于公鏈，聯(lián)盟鏈跨鏈并沒有比較完善的機制，也沒有既定于跨鏈監(jiān)管場景的框架。本文提出了一種基于中繼鏈的鏈上計算跨鏈監(jiān)管框架，實現(xiàn)了對鏈上計算正確性的監(jiān)管，使用中繼鏈技術(shù)保證了跨鏈過程可溯源與跨鏈結(jié)果不可篡改，通過給接入鏈劃分身份保證了跨鏈可控，并且設計了一套用于跨鏈監(jiān)管的通信協(xié)議以確保監(jiān)管過程的安全性。具體貢獻如下：

（1）針對跨鏈監(jiān)管的場景，提出了一種基于中繼鏈的聯(lián)盟鏈跨鏈監(jiān)管機制，采用中繼鏈的跨鏈方式讓跨鏈全過程中產(chǎn)生的信息上鏈存儲，使得跨鏈操作可溯源。

（2）設計了一套用于進行鏈上計算監(jiān)管的通信流程，實現(xiàn)對鏈上不同類別計算的監(jiān)管與驗證，保證了監(jiān)管過程中的安全性。

（3）針對不同的計算資源和類型，制定了不同的Proof 以驗證計算的正確性，驗證計算的開銷要小于原本被監(jiān)管鏈上的計算，以線性規(guī)劃計算為例示例了整體的監(jiān)管流程。

1 相關(guān)研究

現(xiàn)有的跨鏈技術(shù)主要有公證人機制、中繼（側(cè)鏈）機制、哈希時間鎖、分布式私鑰控制等。

公證人機制是一種相對其他幾種機制來說中心化較強的跨鏈機制，其使用中心化機構(gòu)實現(xiàn)了可信第三方，這種模式雖然交易處理速度快，兼容性強，技術(shù)架構(gòu)簡單，但存在安全與信任問題，以及單點故障等缺陷。目前使用公證人機制實現(xiàn)跨鏈的最具有代表性的項目是瑞波（Ripple）的Interledger Protoco（lILP）[6]，ILP 協(xié)議允許兩個不同的區(qū)塊鏈系統(tǒng)通過第三方“連接器”來互相自由地轉(zhuǎn)換貨幣。戴炳榮等[7]針對公信人節(jié)點的可信度問題，利用改進的PageRank 算法可以對公證人對可信度進行更好的評估；王灑灑等[8]使用橢圓曲線算法與零知識證明設計了一套用于跨鏈的身份認證系統(tǒng)，實現(xiàn)了跨鏈過程中的高效身份認證。

中繼（側(cè)鏈）是一種更為靈活的跨鏈方式，“中間人”僅僅充當數(shù)據(jù)收集者的角色，目標鏈收到發(fā)送鏈數(shù)據(jù)后由接收鏈自行驗證，完成交易的確認，驗證交易的方式由兩者區(qū)塊鏈系統(tǒng)結(jié)構(gòu)決定。采用這種跨鏈機制的代表性協(xié)議有BTC-Relay[9]、Cosmos[10]、Polkadot[11]等。以BTC-Relay 為例，主要采用SPV（simplified payment verification）證明進行交易的驗證，通過在以太坊上部署智能合約實現(xiàn)對BTC區(qū)塊頭的驗證。Liu等[12]提出了一種異構(gòu)區(qū)塊鏈互操作框架HyperService，通過開發(fā)一種跨鏈專用的編程語言，實現(xiàn)異構(gòu)區(qū)塊鏈的互操作；葉少杰等[13]提出了一種通用的跨鏈協(xié)議，并實現(xiàn)了跨鏈平臺BitXHub。

哈希時間鎖是一種實現(xiàn)異鏈間資產(chǎn)交換的跨鏈技術(shù)，它要求交易的發(fā)起者和接收者在給定時間內(nèi)給出正確哈希值才可取走鎖定在合約內(nèi)的資產(chǎn)。代表項目為閃電網(wǎng)絡HTLC（hashed timelock contract）[14]。分布式私鑰控制是將鏈上資產(chǎn)的所有權(quán)和使用權(quán)切割來降低跨鏈過程中中心化的風險，最著名的項目為Fusion[15]，一個為加密金融應用提供服務的基礎(chǔ)平臺。

盡管目前公鏈的跨鏈機制十分豐富，由于兩者之間跨鏈的目標相差較大，聯(lián)盟鏈更重要的是實現(xiàn)鏈與鏈之間的數(shù)據(jù)互通與合約互操作，現(xiàn)有公鏈跨鏈機制都難以在聯(lián)盟鏈上有效應用。

現(xiàn)有的聯(lián)盟鏈跨鏈框架有微眾銀行的WeCross[16]、陸羽跨鏈協(xié)議[17]等。WeCross框架實現(xiàn)了一個完整的身份系統(tǒng)以及統(tǒng)一的跨鏈消息與資產(chǎn)協(xié)議，缺點是接入鏈身份信息存儲在中心化的服務器之中，安全性和可靠性得不到保障，跨鏈過程的請求無法進行保存和溯源，沒有對接入鏈進行身份劃分，導致跨鏈操作合法性無法得到保證。陸羽協(xié)議與之類似。佘維等[18]針對能源交易場景提出的跨鏈模型MCST-HEB可以實現(xiàn)分布式能源的有效互補，但無法實現(xiàn)合約之間的互相調(diào)用，并且使用場景較為局限。He等[19]針對共享充電樁評分場景，提出了一種基于多鏈的可信評分計算機制，但是同樣存在跨鏈通信流程缺乏監(jiān)管的問題。

2 跨鏈監(jiān)管框架設計

為了打通鏈與鏈之間的通信，實現(xiàn)“以鏈治鏈”的聯(lián)盟鏈治理與監(jiān)管，本文提出了一種基于中繼鏈的鏈上計算跨鏈監(jiān)管框架。該框架一共由三層組成，每一層由數(shù)個關(guān)鍵組件組成，實現(xiàn)了整體框架的解耦合和模塊化，為升級改造和落地應用提供了巨大的便利，整體架構(gòu)如圖1所示。

圖1 跨鏈框架架構(gòu)圖Fig.1 Cross-chain framework architecture

2.1 統(tǒng)一資源層

由于不同聯(lián)盟鏈之間的底層實現(xiàn)相差較大，為了實現(xiàn)跨鏈通信時消息格式的統(tǒng)一，在接入鏈上層抽象出統(tǒng)一資源層，對區(qū)塊鏈底層結(jié)構(gòu)進行抽象和封裝，統(tǒng)一資源層并不關(guān)心具體聯(lián)盟鏈內(nèi)部的細節(jié)，包括共識算法、區(qū)塊結(jié)構(gòu)、加密算法等，接入鏈只需要通過跨鏈路由向中繼鏈注冊自己的身份信息和鏈上資源。聯(lián)盟鏈中一般采用基于PBFT的共識算法；接入鏈中主要資源是智能合約，合約負責在鏈上根據(jù)不同的業(yè)務場景完成各種類型的計算，其數(shù)據(jù)來源主要是鏈上賬本，并且在計算完成后將結(jié)果寫入賬本中；智能合約主要以虛擬化容器的形式隔離運行在區(qū)塊鏈系統(tǒng)中。

2.2 跨鏈路由層

跨鏈路由層主要由接入鏈SDK（software development kit）、RPC（remote procedure call）組件以及密碼學組件構(gòu)成。接入鏈SDK 可以實現(xiàn)在接入鏈上部署監(jiān)管合約、調(diào)用合約函數(shù)、讀取賬本數(shù)據(jù)等功能；RPC組件主要用于響應合約調(diào)用以及與中繼鏈進行通信；密碼學組件主要提供對稱加密和公鑰簽名算法，實現(xiàn)消息的加解密以及身份認證。

接入鏈SDK 主要是接入鏈的任何語言的SDK，通過SDK可以實現(xiàn)對接入鏈的全局掌控，包括添加用戶、部署合約、調(diào)用合約等。在跨鏈監(jiān)管框架中，接入鏈SDK主要負責調(diào)用合約以及從合約賬本中讀取數(shù)據(jù)，通過與RPC 組件結(jié)合的方式提供了BaaS（blockchain as a service）功能。

RPC組件主要為跨鏈路由提供了RPC通信的功能，RPC組件中既包含了接收請求的RPC server，也包含發(fā)起請求的RPC client。在跨鏈監(jiān)管框架中，RPC組件是監(jiān)管過程中的核心部分，主要負責調(diào)用中繼鏈的合約注冊信息，以及實現(xiàn)鏈與鏈之間的數(shù)據(jù)傳輸。

密碼學組件主要包含對稱加密算法組件和公鑰簽名算法組件。為了確保監(jiān)管過程的安全性，監(jiān)管全程的通信會使用對稱加密算法加密，每一輪監(jiān)管過程的密鑰都由中繼鏈隨機生成。公鑰加密組件主要負責實現(xiàn)身份認證，跨鏈路由使用私鑰對將要發(fā)送的消息進行簽名，被監(jiān)管鏈接收到請求后向中繼鏈的身份合約申請公鑰進行鑒權(quán)，判斷監(jiān)管鏈的身份是否合法。

2.3 中繼鏈層

中繼鏈層是跨鏈框架的關(guān)鍵層，也是跨鏈通信的主要實現(xiàn)層。中繼鏈主要是由聯(lián)盟鏈構(gòu)成，擁有獨立的共識算法，其主要組件有智能合約、RPC 組件以及密碼學組件。

智能合約部分主要由身份信息合約與跨鏈記錄合約組成。身份信息合約主要記錄了接入鏈的身份信息，通過將接入鏈的身份信息上鏈存儲，保證了身份信息的安全性。跨鏈記錄合約主要保存跨鏈過程中發(fā)生的全部通信消息，通過將跨鏈信息上鏈存儲，實現(xiàn)了監(jiān)管過程可溯源。

RPC 組件為中繼鏈提供了與接入鏈互聯(lián)互通的能力，既可以接受來自跨鏈路由的請求，也可以通過發(fā)起RPC請求的方式進行請求的轉(zhuǎn)發(fā)。

密碼學組件主要用于生成密鑰和解密消息，其中產(chǎn)生的對稱加密密鑰會發(fā)送給監(jiān)管鏈與被監(jiān)管鏈；非對稱加密過程中會產(chǎn)生一個密鑰對，其中私鑰會發(fā)送給申請注冊接入的聯(lián)盟鏈，公鑰則存放于身份信息合約中，用于對監(jiān)管者身份進行鑒權(quán)。由于通信過程中消息都是經(jīng)過對稱加密后發(fā)送，在進行跨鏈請求時對溯源造成了影響，因此密碼學組件會將消息解密后以明文的形式存入跨鏈記錄合約中。

3 跨鏈監(jiān)管通信流程設計

在鏈上計算時，業(yè)務中經(jīng)常會出現(xiàn)一些較為復雜的運算，本章會示例監(jiān)管鏈對目標鏈上計算結(jié)果正確性驗證的全過程。這個過程分為4 個階段，注冊階段、協(xié)商階段、請求階段、返回階段。整體跨鏈網(wǎng)絡拓撲如圖2所示。

圖2 跨鏈框架網(wǎng)絡拓撲圖Fig.2 Cross-chain framework network topology

3.1 注冊階段

為了實現(xiàn)跨鏈監(jiān)管框架的可控性與安全性，任何接入跨鏈框架的區(qū)塊鏈首先需要去中繼鏈登記自己的身份信息。其中監(jiān)管鏈需要注冊的主要信息有跨鏈路由的RPC地址與端口號、接入鏈類別，即為監(jiān)管鏈或被監(jiān)管鏈。被監(jiān)管鏈除了上述信息之外，需要額外向中繼鏈注冊當前鏈上的計算資源，最后中繼鏈針對密碼學組件會將生成的私鑰Sk發(fā)送給請求鏈，公鑰Pk則存入身份信息合約中。注冊階段整體流程如圖3所示，消息結(jié)構(gòu)如表1所示。

表1 注冊消息結(jié)構(gòu)Table 1 Registration message structure

圖3 注冊過程泳道圖Fig.3 Registration process swimlane diagram

在注冊過身份信息之后，為了避免監(jiān)管給被監(jiān)管鏈帶來額外的計算開銷，監(jiān)管鏈會為特定的計算資源制定對應的監(jiān)管合約，并且通過鏈下的方式部署監(jiān)管合約至被監(jiān)管鏈上。監(jiān)管合約的主要作用是實現(xiàn)非侵入式的監(jiān)管，不需要修改原本業(yè)務合約的代碼邏輯。監(jiān)管合約在收到監(jiān)管請求后，會從鏈上讀取計算時的參數(shù)和結(jié)果，并且針對不同的計算類型制作Proof，監(jiān)管鏈可以利用Proof 快速驗證被監(jiān)管鏈鏈上計算的正確性，從而實現(xiàn)了對被監(jiān)管鏈非侵入式的監(jiān)管。

3.2 協(xié)商階段

為了保障監(jiān)管過程中通信的安全性，監(jiān)管過程中的消息需要進行加密，因此在發(fā)起監(jiān)管之前會有一次密鑰協(xié)商階段，在通信全程中會使用中繼鏈生產(chǎn)的對稱加密密鑰k對消息進行對稱加密，并且在每一次監(jiān)管結(jié)束后上一輪對密鑰都會銷毀，保證了通信過程中的安全性。

3.3 請求階段

請求階段主要是由監(jiān)管鏈發(fā)起，中繼鏈接收到請求后，通過消息中的CID 進行鏈上查詢獲得對應通信地址后，調(diào)用RPC服務實現(xiàn)請求的轉(zhuǎn)發(fā)。監(jiān)管請求消息結(jié)構(gòu)如表2所示，監(jiān)管流程見圖4。

表2 監(jiān)管消息結(jié)構(gòu)Table 2 Supervision message structure

圖4 監(jiān)管流程泳道圖Fig.4 Supervision process swimlane diagram

（1）監(jiān)管鏈管理員通過調(diào)用監(jiān)管鏈中的監(jiān)管合約發(fā)起一輪監(jiān)管。監(jiān)管合約中的RPC client 會將請求m發(fā)送至當前鏈的跨鏈路由中，請求中主要字段和含義如表2所示，跨鏈路由會對請求使用上一階段申請的密鑰k對請求進行加密后，使用RPC 組件發(fā)送密文Sm至中繼鏈的RPC server中。

（2）中繼鏈的RPC server在收到來自監(jiān)管鏈的請求Sm之后，首先使用密鑰k對消息進行解密并對請求鏈的身份進行鑒權(quán)，如果消息合法則將明文信息m存入跨鏈記錄合約中。通過消息中的TCID，從身份信息合約中索引到被監(jiān)管鏈的RPC 地址后，將加密后到消息Sm轉(zhuǎn)發(fā)至目標跨鏈路由中。

（3）被監(jiān)管鏈的RPC 組件在接收到監(jiān)管請求后，首先對消息進行解密，被監(jiān)管鏈跨鏈路由使用消息中的SCID 字段向中繼鏈的身份信息合約發(fā)起請求從而獲取對應監(jiān)管鏈的公鑰。最后使用公鑰對消息中的Sign 字段進行簽名驗證。身份驗證通過后調(diào)用監(jiān)管合約，合約根據(jù)消息中的CalcType 字段，隨機抽取對應計算類型的業(yè)務合約中的數(shù)條數(shù)據(jù)，并構(gòu)造用于快速驗證計算的Proof。

3.4 返回階段

返回階段主要是被監(jiān)管鏈利用監(jiān)管請求消息與賬本數(shù)據(jù)封裝完成返回消息之后，利用中繼鏈將消息轉(zhuǎn)發(fā)回監(jiān)管鏈中，監(jiān)管鏈對計算數(shù)據(jù)進行校驗后產(chǎn)生結(jié)果并返回的過程。返回消息結(jié)構(gòu)見表3。

表3 返回消息結(jié)構(gòu)Table 3 Return message structure

被監(jiān)管鏈跨鏈路由取出賬本中的監(jiān)管數(shù)據(jù)后構(gòu)造返回消息，使用對稱加密處理消息后通過RPC組件將請求發(fā)送至中繼鏈。中繼鏈解密消息將消息進行上鏈存儲，同時將消息異步發(fā)送至監(jiān)管鏈的跨鏈路由中。

監(jiān)管鏈跨鏈路由接收并解密消息后會將消息中的Proof 字段取出作為參數(shù)調(diào)用監(jiān)管合約，監(jiān)管合約進行對應的驗證計算后，將監(jiān)管結(jié)果與監(jiān)管數(shù)據(jù)上鏈存儲。

如果驗證過程中發(fā)現(xiàn)計算結(jié)果存在錯誤，則可通過中繼鏈告知被監(jiān)管鏈，此時被監(jiān)管鏈的工作人員可通過監(jiān)管過程發(fā)生的消息記錄對鏈上數(shù)據(jù)進行排查與溯源。

3.5 示例

以線性規(guī)劃計算為例，說明本文提出的聯(lián)盟鏈上跨鏈監(jiān)管框架。由于線性規(guī)劃計算一般計算較為復雜，為了降低驗證時計算開銷，這里使用初始線性規(guī)劃問題的對偶問題[20]對計算正確性進行快速驗證。

假設線性規(guī)劃的初始問題如式（1）所示。

通過轉(zhuǎn)化初始問題，得到的對偶問題如式（2）所示。

在計算線性規(guī)劃問題時，通常會引入松弛變量將問題轉(zhuǎn)變?yōu)闃藴市秃笄蠼猓跏紗栴}與對偶問題的標準型如下：

被監(jiān)管鏈計算初始問題時，在業(yè)務合約中通過索引取得業(yè)務賬本中用戶上傳的數(shù)據(jù)，完成業(yè)務計算后調(diào)用監(jiān)管合約，監(jiān)管合約會將初始問題轉(zhuǎn)化為對偶問題后求解，監(jiān)管合約完成運算將初始問題的解組合為矩陣后上鏈，并且由于線性規(guī)劃的向量組成的矩陣是稀疏矩陣，將結(jié)果壓縮后上鏈存儲可以減少賬本的存儲壓力。最終監(jiān)管合約賬本中存儲的解的結(jié)構(gòu)如表4所示。

表4 業(yè)務合約存儲結(jié)構(gòu)Table 4 Business contract store structure

為了避免對線性規(guī)劃計算的參數(shù)冗余存儲，業(yè)務合約賬本中只保存計算參數(shù)的數(shù)據(jù)對應的索引，在返回階段跨鏈路由會根據(jù)索引獲得真實數(shù)據(jù)后再發(fā)送至監(jiān)管鏈。

監(jiān)管鏈在獲取到數(shù)據(jù)后，使用監(jiān)管合約對計算進行驗證。驗證計算為：

最終結(jié)果為0 時，代表驗證計算返回值為正確，否則認為驗證不通過。

監(jiān)管結(jié)束后監(jiān)管合約會將本輪的監(jiān)管結(jié)果寫入賬本中，監(jiān)管賬本中存儲結(jié)構(gòu)見表5。

表5 監(jiān)管合約存儲結(jié)構(gòu)Table 5 Supervision contract storage structure

結(jié)論1如果被監(jiān)管鏈線性規(guī)劃運算計算錯誤，那么本方案可以通過監(jiān)管鏈驗證并得知該錯誤。

證明由于空間限制，本文只證明當線性規(guī)劃問題有可行解的情況下通過對偶問題可以驗證計算的正確性，無界/無可行解的情況與之類似。

假設被監(jiān)管鏈上線性規(guī)劃問題計算錯誤，即計算結(jié)果x1并非最優(yōu)解，則存在不等式（5）：

由不等式（6）及其對偶性易知，當x和y為線性規(guī)劃問題及其對偶問題的最優(yōu)解時，必存在z和w嚴格相等。

被監(jiān)管鏈上的監(jiān)管合約計算結(jié)果無誤，也就是y為對偶問題的最優(yōu)解，則有不等式（7）：

這與z和w嚴格相等違背，可知x1并非原本線性規(guī)劃問題的最優(yōu)解，從而得知被監(jiān)管鏈計算錯誤，完成了對結(jié)論1的證明。

4 方案對比和實驗模擬

4.1 對比分析

現(xiàn)有跨鏈框架都無法應用于跨鏈監(jiān)管的主要原因是跨鏈過程缺少權(quán)限控制，跨鏈監(jiān)管場景應明確跨鏈數(shù)據(jù)流動的方向，監(jiān)管鏈的權(quán)限應該高于被監(jiān)管鏈，被監(jiān)管鏈應無權(quán)調(diào)用監(jiān)管鏈的合約，從而保證監(jiān)管過程的安全性。本文方案在下文中統(tǒng)一簡寫為CCSF（cross-chain supervision framework）。

本文提出的基于中繼鏈的跨鏈監(jiān)管框架則較好地解決了上述問題，實現(xiàn)了接入鏈的權(quán)限管理，同時利用中繼鏈去中心化的特性有效保證了身份信息與跨鏈記錄的安全性，且實現(xiàn)了跨鏈記錄可溯源。表6從功能與應用場景上對比了CCSF和現(xiàn)有的其他方案，可見CCSF在功能較為全面的同時可以良好地適用于跨鏈監(jiān)管場景。

表6 方案對比Table 6 Scheme comparison

4.2 實驗模擬

本文測試利用了三條聯(lián)盟鏈構(gòu)成了一套跨鏈計算監(jiān)管系統(tǒng)，仿真使用的聯(lián)盟鏈框架為Hyperledger Fabric 1.4，其中兩條為被監(jiān)管鏈，一條為中繼鏈；RPC通信協(xié)議選擇TCP 協(xié)議，調(diào)用參數(shù)編碼方式選擇JSON編碼；用于進行線性規(guī)劃運算的測試數(shù)據(jù)集來自于OR-Library[21]；測試指標為發(fā)起監(jiān)管請求直至請求完成后監(jiān)管結(jié)果更新結(jié)束的耗時。實驗環(huán)境的機器配置如表7所示。

表7 測試機器配置表Table 7 Configuration of test machine

每條Fabric 區(qū)塊鏈由3 個組織構(gòu)成，每個組織擁有2個節(jié)點。其中RelayChain為中繼鏈，主要負責轉(zhuǎn)發(fā)跨鏈消息，存儲跨鏈身份信息與記錄跨鏈消息；TargetChain為被監(jiān)管鏈，主要負責鏈上業(yè)務計算；Supervisor 為監(jiān)管鏈，主要負責發(fā)起監(jiān)管請求，并且將監(jiān)管結(jié)果上鏈存儲。具體區(qū)塊鏈與合約信息如表8所示。

表8 測試區(qū)塊鏈系統(tǒng)配置Table 8 Test blockchain system configuration

實驗測試了在100次跨鏈監(jiān)管過程中，每一步驟的平均耗時，如表9所示。

表9 跨鏈各步驟耗時Table 9 Time-consuming for each step in cross-chain

可以看到，RegistChain操作需要將身份信息寫入鏈上，身份信息中公鑰部分體積較大，因此耗時需要2 s左右；SendCrossChainMsg 是中繼鏈收到消息后根據(jù)消息進行轉(zhuǎn)發(fā)的過程，其中只涉及到鏈上數(shù)據(jù)的讀取，因此是耗時最短的操作；GetPubKeybyId 用于接入鏈公鑰查詢，但是傳輸RSA 公鑰耗時較高；GetCrossChainMsgTo是指監(jiān)管鏈發(fā)出監(jiān)管請求后直到被監(jiān)管鏈收到請求的過程，由于過程中不涉及鏈上數(shù)據(jù)寫入，因此耗時相對較短；GetCrossChainMsgBack記錄的是從被監(jiān)管鏈接收到監(jiān)管請求后直到監(jiān)管鏈完成監(jiān)管的過程，其中包含耗時較多的讀取計算數(shù)據(jù)，構(gòu)造Proof以及驗證Proof等幾個步驟，因此耗時最長。

總體來說涉及到數(shù)據(jù)上鏈的操作耗時比僅讀取鏈上數(shù)據(jù)長，這是因為Fabric需要為鏈上數(shù)據(jù)變更的交易產(chǎn)生區(qū)塊并且更新世界狀態(tài)，因此實驗符合預期。為了保證跨鏈過程的安全性，消息簽名主要使用RSA 算法進行簽名，RSA 的密鑰傳輸產(chǎn)生了大量的網(wǎng)絡通信消耗，因此總體操作耗時較長。

本文同時將CCSF與WeCross以及BitXHub進行了對比，具體對比見圖5，其中跨鏈路由配置指接入鏈配置跨鏈路由的步驟耗時；跨鏈注冊是指向中繼鏈注冊當前區(qū)塊鏈信息的耗時；跨鏈共享操作指從接入鏈發(fā)送一條消息到另一條接入鏈的耗時；跨鏈合約調(diào)用指接入鏈調(diào)用另一條接入鏈合約直到交易完成的耗時；跨鏈轉(zhuǎn)賬是指兩條接入鏈之間的原子交易耗時，本質(zhì)上是一種特殊的跨鏈合約調(diào)用。

圖5 方案耗時對比圖Fig.5 Scheme time-consuming comparison chart

可以看見CCSF 在保證了跨鏈過程更加安全可靠的同時，耗時對比WeCross除了注冊階段都有一定的提升，其主要原因是CCSF 采用的RPC 調(diào)用協(xié)議要快于WeCross的HTTP通信協(xié)議。注冊階段速度慢于WeCross的原因主要如下：WeCross 的身份信息采用單點Mysql數(shù)據(jù)庫存儲，雖說存儲速度較快但是存在單點故障等安全性問題。CCSF將身份信息保存在去中心化的聯(lián)盟鏈中，有效保證了身份信息的安全性，但會在聯(lián)盟鏈中產(chǎn)生一筆交易，因此會發(fā)生世界狀態(tài)的改變，從而導致了該步驟耗時明顯高于WeCross。由于BitXHub會對跨鏈交易中的Merkle Path 進行驗證，整體跨鏈耗時略高于CCSF。

5 典型攻擊

傳統(tǒng)跨鏈框架一般存在中間人攻擊、跨鏈橋單點故障、越權(quán)跨鏈等風險，本文方案可以較好地抵御上述攻擊：

（1）中間人攻擊：在跨鏈網(wǎng)絡中存在大量的跨鏈消息使用傳統(tǒng)傳輸協(xié)議進行傳輸，因此存在中間人攻擊的風險。本文方案通過給接入鏈分發(fā)簽名證書，并且對跨鏈消息進行簽名與加密，在跨鏈路由中對消息合法性進行驗證，抵御了中間人對跨鏈請求篡改和重放等攻擊手段。

（2）跨鏈橋單點故障：傳統(tǒng)跨鏈網(wǎng)絡中繼器數(shù)量較少，存在單點故障的風險。本文方案中使用聯(lián)盟鏈作為中繼鏈進行跨鏈請求的鑒權(quán)與轉(zhuǎn)發(fā)，因此具有區(qū)塊鏈去中心化的優(yōu)點，結(jié)點可以動態(tài)地加入與退出聯(lián)盟鏈網(wǎng)絡，因此不存在單點故障的風險。

（3）越權(quán)跨鏈：在跨鏈網(wǎng)絡中存在越權(quán)攻擊的風險，本文通過在中繼鏈中部署合約對接入鏈進行權(quán)限劃分，通過驗證跨鏈消息中的身份信息字段保證了跨鏈請求的合法性，避免了非法跨鏈監(jiān)管請求被執(zhí)行。

6 總結(jié)與展望

本文提出了一種基于中繼鏈的跨鏈監(jiān)管框架，并且在跨鏈框架基礎(chǔ)上，設計了一套用于執(zhí)行跨鏈監(jiān)管的通信協(xié)議，最后以監(jiān)管鏈上線性規(guī)劃計算為例，展示了通過跨鏈技術(shù)實現(xiàn)對聯(lián)盟鏈鏈上計算進行監(jiān)管的全流程。通過將身份信息使用聯(lián)盟鏈存儲，實現(xiàn)了身份信息的去中心化與不可篡改，保證了身份信息的安全性；將跨鏈過程中的消息記錄上鏈存儲，實現(xiàn)了跨鏈過程可溯源，為監(jiān)管提供了便利；每一輪監(jiān)管過程中使用對稱加密，保證了通信過程的安全性。跨鏈路由可能存在單點故障等安全隱患，因此如何將跨鏈路由去中心化，減少跨鏈過程中的通信次數(shù)，讓身份驗證過程更加高效都是未來值得研究的問題。