WeCross技術(shù)白皮書：區(qū)塊鏈跨鏈協(xié)作平臺

1、第一章 WeCross 設(shè)計背景與理念設(shè)計背景：行業(yè)現(xiàn)狀與挑戰(zhàn)近年來，區(qū)塊鏈行業(yè)經(jīng)歷了高速發(fā)展，誕生許多形態(tài)各異的底層技術(shù)平臺， 基于這些平臺建設(shè)的區(qū)塊鏈應(yīng)用百花齊放。隨著應(yīng)用生態(tài)本身的發(fā)展壯大，越來越多應(yīng)用在既有用戶和價值積累基礎(chǔ)上，為追求更大的網(wǎng)絡(luò)效應(yīng)，產(chǎn)生了與其他應(yīng)用實現(xiàn)交互、建立關(guān)聯(lián)的外延需求，于是整個區(qū)塊鏈生態(tài)需要一個更加開放、易于協(xié)作、多方共贏的交互環(huán)境。由于目前區(qū)塊鏈平臺技術(shù)實現(xiàn)上存在多維異構(gòu)性，在應(yīng)用和數(shù)據(jù)上存在“孤島效應(yīng)”，無論是基于不同平臺或者同一個平臺構(gòu)建的不同應(yīng)用，都難以便捷地跨平臺聯(lián)通協(xié)作，區(qū)塊鏈生態(tài)要向下一階段演化需要“超越平臺、鏈接應(yīng)用”的創(chuàng)新性解決方案。為了應(yīng)對

2、這一挑戰(zhàn)，旨在搭建鏈與鏈之間可信交互渠道的跨鏈技術(shù)逐漸成為業(yè)界關(guān)注的焦點，業(yè)界普遍認同高效通用的跨鏈技術(shù)是實現(xiàn)萬鏈互聯(lián)的關(guān)鍵?？珂溂夹g(shù)能夠連通分散的區(qū)塊鏈生態(tài)孤島，成為區(qū)塊鏈整體向外拓展的橋梁紐帶。當前，業(yè)界在跨鏈領(lǐng)域已有初步的探索和積累，討論較多的跨鏈方案有公證人機制、中繼、側(cè)鏈、哈希鎖定和分布式密鑰控制等。較早出現(xiàn)的 BTC-Relay 使用側(cè)鏈技術(shù)來實現(xiàn)區(qū)塊鏈數(shù)字資產(chǎn)之間的單向跨鏈。Ripple提出的跨鏈價值傳輸協(xié)議 ILP 采用哈希鎖定的方案來解決跨賬本之間的支付問題。Cosmos和 Polkadot，則關(guān)注如何建立通用跨鏈開發(fā)框架，分別提出了Tendermint 和 Substrat

3、e 的開發(fā)框架，它們的跨鏈核心設(shè)計是基于中繼鏈的思想。上述跨鏈方案，僅適用于面向數(shù)字資產(chǎn)的跨鏈轉(zhuǎn)移場景，難以擴展涵蓋到更為廣闊的應(yīng)用場景。微眾銀行在 2018 年提出“公眾聯(lián)盟鏈”的概念，將聯(lián)盟鏈進一步升華為面向公眾提供服務(wù)的聯(lián)盟鏈，公眾作為“鏈”的服務(wù)對象，可通過公開網(wǎng)絡(luò)訪問聯(lián)盟鏈提供的服務(wù)，聯(lián)盟是“鏈”的屬主和運營方，通過“鏈”實現(xiàn)信息與價值交換。公眾聯(lián)盟鏈并非單一區(qū)塊鏈生態(tài)，而是一種全新的區(qū)塊鏈商業(yè)應(yīng)用跨域融合形態(tài)。要支撐這樣的融合形態(tài)，需要能夠支持多鏈并行、跨鏈通信以及處理來自互聯(lián)網(wǎng)海量交易的能力。在公眾聯(lián)盟鏈的大生態(tài)中，必然需要應(yīng)對底層平臺異構(gòu)化、應(yīng)用場景多樣化等特點，構(gòu)建公眾聯(lián)盟鏈

4、的可信跨鏈交互面臨著更大的挑戰(zhàn)。底層架構(gòu)不同，互通難：業(yè)內(nèi)已有多種區(qū)塊鏈平臺，這些平臺在整體架構(gòu)設(shè)計上存在很大的不同，包括計算、存儲、網(wǎng)絡(luò)等各個方面。例如，Hyperledger Fabric 采用 Endorser- Orderer-Comitter 三層架構(gòu)，交易先經(jīng)過 Endorser 節(jié)點進行預(yù)執(zhí)行背書，得到狀態(tài)讀寫集 RW-Set返回客戶端，客戶端再次打包交易發(fā)送至Orderer，Orderer打包排序后交給 Commiter 節(jié)點進行落盤存儲。同為金融級、企業(yè)級的區(qū)塊鏈平臺 FISCO BCOS，交易在客戶端完成簽名之后被發(fā)送到區(qū)塊鏈節(jié)點，節(jié)點將交易打包成區(qū)塊，并且交給 EVM 執(zhí)

5、行，狀態(tài)數(shù)據(jù)以 MPT 樹狀組織存儲。不難看出，這兩個底層平臺在架構(gòu)上存在巨大差別，不僅交易處理時序不同，計算與存儲結(jié)構(gòu)也不同，想讓交易直接在兩個平臺互通，存在較大挑戰(zhàn)。數(shù)據(jù)結(jié)構(gòu)不同， 互認難：不同區(qū)塊鏈平臺的數(shù)據(jù)結(jié)構(gòu)設(shè)計往往各不相同。例如， FISCO BCOS 的區(qū)塊結(jié)構(gòu)中，區(qū)塊頭包含三個默克爾根字段：世界狀態(tài)根 state-root、交易根tx-root、交易回執(zhí)根receipt-root，這些字段可用于交易和執(zhí)行結(jié)果的存在性證明。而Hyperledger Fabric，以其最新發(fā)布的穩(wěn)定版本（v1.4）為例，使用一個 DataHash字段來標記該塊的數(shù)據(jù)變化，其區(qū)塊頭設(shè)計中并沒有默克爾

6、根的相關(guān)字段，不容易實現(xiàn)類似交易存在性證明機制。基于默克爾樹的存在性驗證是常用的跨鏈認證手段，但由于不同區(qū)塊鏈平臺數(shù)據(jù)結(jié)構(gòu)和預(yù)期的應(yīng)用場景不同，并非所有平臺都支持，所以想要實現(xiàn)數(shù)據(jù)互認依舊存在著一定挑戰(zhàn)。接口協(xié)議不同，互聯(lián)難：常見的網(wǎng)絡(luò)傳輸編碼協(xié)議有Protobuf、JSON和二進制等協(xié)議。這些編碼協(xié)議各有其優(yōu)勢與適用場景。例如，Protobuf 協(xié)議具備支持語言多、格式緊湊、易于擴展的優(yōu)勢，被 Hyperledger Fabric 選用為 P2P 網(wǎng)絡(luò)傳輸消息包的編碼協(xié)議。而二進制編碼協(xié)議有編碼速度快、格式緊湊和可自由定制的優(yōu)勢，被 FISCO BCOS 選用為 P2P 網(wǎng)絡(luò)傳輸消息包的編碼

7、協(xié)議。除此之外，因為架構(gòu)與數(shù)據(jù)結(jié)構(gòu)的不同，不同平臺暴露的訪問接口在功能和格式字段方面也大不相同。綜上所述，由于接口與協(xié)議的不兼容，這些平臺間難以互聯(lián)通信。安全機制不同，互信難：區(qū)塊鏈安全涉及面很廣，包括共識記賬模式的安全、數(shù)據(jù)傳輸安全、數(shù)據(jù)存儲安全、準入機制安全以及接口訪問權(quán)限安全控制等多方面。由于區(qū)塊鏈設(shè)計的安全邊界往往是以平臺范圍為界，以確保用這個平臺建設(shè)的一個區(qū)塊鏈實例內(nèi)部是安全的。當涉及到鏈和鏈之間、平臺和平臺之間進行銜接時，會因為多種安全機制參差不齊，且敏感數(shù)據(jù)跨越安全邊界，如共識者列表不同、準入機制嚴格程度有高低、權(quán)限配置差異等因素，導(dǎo)致平臺之間的互信條件不成立。業(yè)務(wù)模式不同，互訪

8、難：區(qū)塊鏈技術(shù)已經(jīng)在眾多應(yīng)用領(lǐng)域初露頭角，以 FISCO BCOS披露的落地場景為例，已經(jīng)覆蓋政務(wù)、金融、溯源、文化、游戲等眾多行業(yè)。不同業(yè)務(wù)場景的合約邏輯千差萬別，各個場景都是內(nèi)在閉環(huán)的系統(tǒng)。要打通場景之間的互訪，例如要實現(xiàn)金融場景區(qū)塊鏈與政務(wù)場景區(qū)塊鏈有關(guān)備案信息的互通跨鏈，會面臨比傳統(tǒng)數(shù)字資產(chǎn)跨鏈更復(fù)雜的業(yè)務(wù)邏輯，過程中任意一個環(huán)節(jié)的疏漏都可能導(dǎo)致異常使跨鏈失敗，如何保障整體銜接過程中事務(wù)和事務(wù)之間的完整性和一致性將會是巨大的挑戰(zhàn)。除了上述由于不同平臺架構(gòu)差異而導(dǎo)致的挑戰(zhàn)，基于相同區(qū)塊鏈平臺的多個區(qū)塊鏈之間也存在著顯著的跨鏈挑戰(zhàn)。受限于區(qū)塊鏈本身的架構(gòu)特征，單鏈架構(gòu)難以同時滿足高安全、高

9、性能和高擴展三個需求，無法應(yīng)對需要承載海量數(shù)據(jù)的服務(wù)場景。盡管可以借鑒傳統(tǒng)互聯(lián)網(wǎng)海量服務(wù)的經(jīng)驗，采取多通道、多群組或多鏈架構(gòu)等方式進行平行擴展，但有別于傳統(tǒng)互聯(lián)網(wǎng)服務(wù)，區(qū)塊鏈應(yīng)用作為多方參與的弱信任業(yè)務(wù)模式，多方之間既有協(xié)作也有博弈。即便對于構(gòu)建在同一個平臺上的區(qū)塊鏈應(yīng)用，也需要構(gòu)建一個多方可信的渠道對平行擴展之后的通道、群組和多鏈進行可信數(shù)據(jù)互聯(lián)。因此，同 / 異構(gòu)區(qū)塊鏈平臺都需要依賴于跨鏈解決方案來連接信任孤島，實現(xiàn)信任在更大范圍內(nèi)的傳遞，推動區(qū)塊鏈應(yīng)用生態(tài)的深度融合發(fā)展。設(shè)計理念：4S 原則面對區(qū)塊鏈應(yīng)用生態(tài)中互聯(lián)互通的諸多挑戰(zhàn)，我們從底層平臺的架構(gòu)設(shè)計開始深層次思考，在眾多主流平臺中探

10、尋可信融合連通所需的“最小化”抽象設(shè)計，充分考慮跨鏈交互的安全、擴展和可用性問題，提出跨鏈方案需遵循的 4S 原則。Synergetic：跨鏈業(yè)務(wù)高效協(xié)同跨鏈的目標是打通區(qū)塊鏈業(yè)務(wù)之間的高墻，連接眾多信任孤島，讓信任得到更大范圍的傳遞。為了使這些基于眾多區(qū)塊鏈平臺的業(yè)務(wù)能夠無縫協(xié)同，首先需要設(shè)計普適通用的數(shù)據(jù)結(jié)構(gòu)和交互協(xié)議，使不同區(qū)塊鏈平臺之間數(shù)據(jù)格式轉(zhuǎn)化和網(wǎng)絡(luò)協(xié)議適配所產(chǎn)生的代價降到最低。WeCross 遵循滿足跨鏈業(yè)務(wù)高效協(xié)同的設(shè)計理念，根據(jù)“一次適配，隨處可用”原則，提煉跨鏈交互必需的“核心接口子集”，設(shè)計通用數(shù)據(jù)結(jié)構(gòu)和網(wǎng)絡(luò)協(xié)議，解決因設(shè)計目標不同而導(dǎo)致的各平臺接口差異性難題。Secur

11、e：跨鏈操作安全可信區(qū)塊鏈的重要特征之一是通過多中心化、共識機制以及密碼學(xué)技術(shù)來實現(xiàn)數(shù)據(jù)可信存取。但這種安全機制往往只能在一個區(qū)塊鏈平臺內(nèi)部形成閉環(huán)，在兩個或者多個區(qū)塊鏈平臺之間進行交互訪問時，需要進一步突破原有平臺的安全邊界，建立更強的安全保障機制。WeCross 遵循保障跨鏈操作安全可信的設(shè)計理念，引入 CA 身份認證機制，對通信鏈路進行加密加固，嚴格限制訪問權(quán)限，設(shè)計多維度的默克爾證明機制，以及多種原子事務(wù)機制，保障跨鏈交互全流程數(shù)據(jù)的可信性。Scalable：跨鏈網(wǎng)絡(luò)分層可擴展跨鏈不僅能夠支持異構(gòu)區(qū)塊鏈之間互聯(lián)，也能夠幫助同構(gòu)區(qū)塊鏈平臺進行擴展。常見的多通道、多群組和多鏈等擴展方案都需

12、要依賴跨鏈組件打通通道、群組以及鏈與鏈之間的交互。隨著跨鏈業(yè)務(wù)協(xié)作的演進，越來越多的業(yè)務(wù)有相互連接的需求，一對一的跨鏈將演變成一對多、多對多、甚至更為復(fù)雜的拓撲結(jié)構(gòu)。這就要求跨鏈組件本身具備足夠的靈活性，能夠應(yīng)對多種復(fù)雜的網(wǎng)絡(luò)模型和業(yè)務(wù)需求。WeCross 遵循支持跨鏈網(wǎng)絡(luò)分層擴展的設(shè)計理念，設(shè)計跨鏈路由協(xié)議與模塊，支持多個區(qū)塊鏈分布式互聯(lián)，承載樹型、星型等各種拓撲架構(gòu)，支持多層次縱深跨鏈協(xié)作。同時，設(shè)計多方共建、共治的治理架構(gòu)，實現(xiàn)跨鏈網(wǎng)絡(luò)的可持續(xù)擴展。Swift：跨鏈接入高效便捷由于區(qū)塊鏈平臺存在多樣化特性，開發(fā)者每接入一個新的區(qū)塊鏈平臺就需要學(xué)習(xí)一套區(qū)塊鏈開發(fā)運維流程，跨越不同區(qū)塊鏈平臺

13、的接入將導(dǎo)致學(xué)習(xí)成本的增加。WeCross 遵循為開發(fā)者提供高效便捷接入方式的理念，設(shè)計通用 SDK、交互式控制臺以及可視化瀏覽器等全套開發(fā)組件，簡化跨鏈交互流程，設(shè)計“所見即所得”的運維工具，支持一鍵發(fā)起跨鏈操作。綜上，4S 設(shè)計理念以業(yè)務(wù)協(xié)同為核心，在多個關(guān)鍵維度上追求跨鏈操作的高安全性、高擴展性和高易用性，以應(yīng)對未來形式多樣、層出不窮的跨鏈應(yīng)用場景。第二章 WeCross 整體架構(gòu)設(shè)計以融合連通各大主流區(qū)塊鏈平臺（例如 FISCO BCOS 和 Hyperledger Fabric）為目標定位，基于對當前行業(yè)現(xiàn)狀、應(yīng)用場景和區(qū)塊鏈技術(shù)發(fā)展的全面分析，WeCross 對主流區(qū)塊鏈平臺體系進

14、行標準化抽象提煉，并以此設(shè)計跨鏈整體架構(gòu)。區(qū)塊鏈體系抽象為打通異構(gòu)區(qū)塊鏈之間的交互，首先為這些異構(gòu)區(qū)塊鏈設(shè)計統(tǒng)一的“語言”，即統(tǒng)一的體系結(jié)構(gòu)抽象?；诮y(tǒng)一的體系結(jié)構(gòu)，異構(gòu)區(qū)塊鏈之間找到雙方都能理解的“語言”，互聯(lián)互通才有可能實現(xiàn)?；诳珂溗璧年P(guān)鍵要求，WeCross 在核心數(shù)據(jù)結(jié)構(gòu)、區(qū)塊鏈交互模式和事務(wù)管理上提取業(yè)界主流區(qū)塊鏈產(chǎn)品核心且必需的公共子集，對區(qū)塊鏈平臺進行多層抽象。數(shù)據(jù)層：跨鏈交互的核心是數(shù)據(jù)在鏈間的流動，數(shù)據(jù)層的抽象就尤為重要。跨鏈涉及的數(shù)據(jù)維度包括區(qū)塊、交易、合約、消息等多個方面。WeCross 以滿足跨鏈基本要求為前提，提煉通用區(qū)塊數(shù)據(jù)結(jié)構(gòu)，將交易、合約和消息等抽象設(shè)計成資

15、源類型，為資源設(shè)計通用的尋址協(xié)議。交互層：不同業(yè)務(wù)場景有不同的跨鏈交互模型，基于抽象數(shù)據(jù)層，WeCross 建設(shè)通用區(qū)塊鏈適配與路由中繼網(wǎng)絡(luò)，結(jié)合標準默克爾證明機制，實現(xiàn)跨鏈交互層抽象設(shè)計。事務(wù)層：基于數(shù)據(jù)結(jié)構(gòu)和交互的抽象層，實現(xiàn)跨鏈事務(wù)效果。目前支持兩類機制：兩階段事務(wù)和哈希時間鎖定事務(wù)。未來將依據(jù)場景需求設(shè)計更多事務(wù)機制。WeCross 抽象體系結(jié)構(gòu)中的任一層都是通用可替換的，無論底層技術(shù)實現(xiàn)如何替換，上層的邏輯都可以通用。WeCross 對區(qū)塊鏈的多層次抽象可以類比 Java ORM（Object Relational Mapping）對數(shù)據(jù)庫的多層次抽象。ORM 技術(shù)作為 Java 訪

16、問數(shù)據(jù)庫的通用“語言”，可以將數(shù)據(jù)庫層完全隱蔽，呈現(xiàn)給開發(fā)的只有 Java 對象。開發(fā)者只需要根據(jù)業(yè)務(wù)邏輯的需要調(diào)用 Java 對象的方法，即可實現(xiàn)對后臺數(shù)據(jù)庫的操作，無需關(guān)注后臺采用什么數(shù)據(jù)庫。相應(yīng)地，WeCross 數(shù)據(jù)結(jié)構(gòu)抽象可以對應(yīng) Java 中對 SQL 和數(shù)據(jù)庫驅(qū)動的抽象如 ODBC 和 JDBC，WeCross 交互抽象類似于 Java 對數(shù)據(jù)庫訪問模型的 ORM 抽象如 MyBatis和 Hibernate，而 WeCross 事務(wù)管理則與 Java 的事務(wù)管理類似，但支持更多事務(wù)模式?？珂溝到y(tǒng)架構(gòu)WeCross 的跨鏈系統(tǒng)架構(gòu)設(shè)計充分考慮跨行業(yè)、機構(gòu)和地域的多區(qū)塊鏈互聯(lián)，無論

17、是新部署的區(qū)塊鏈平臺還是已有的區(qū)塊鏈平臺，都可以基于上一節(jié)中的區(qū)塊鏈體系抽象，在不改動原有區(qū)塊鏈平臺底層的前提下，無縫接入 WeCross 平臺。WeCross 系統(tǒng)架構(gòu)包括以下組件：跨鏈分區(qū)（Zone）指運行著同一類業(yè)務(wù)的區(qū)塊鏈集合。WeCross 可以對這個區(qū)塊鏈集合本身和內(nèi)部的區(qū)塊鏈資源進行命名和尋址。例如，圖中存證業(yè)務(wù)的命名空間為“存證分區(qū)”，結(jié)算業(yè)務(wù)的命名空間為“結(jié)算分區(qū)”。存證分區(qū)里有兩條存證鏈分別是存證鏈A 和存證鏈B，存證鏈 A 鏈上部署一個資產(chǎn)存證資源，產(chǎn)生的費用和相關(guān)的資產(chǎn)可能需要存證。于是，根據(jù)業(yè)務(wù)需要，跨鏈操作會產(chǎn)生分區(qū)和分區(qū)之間，以及分區(qū)內(nèi)部的鏈和鏈之間?？珂溌酚桑≧

18、outer）指用于橋接業(yè)務(wù)系統(tǒng)與區(qū)塊鏈的服務(wù)進程。多個跨鏈路由之間可以相互連接，相互轉(zhuǎn)發(fā)請求。用戶通過向跨鏈路由發(fā)起請求來訪問跨鏈分區(qū)中的資源?？珂溸m配器（Stub）指連接一個區(qū)塊鏈的接口實現(xiàn)，可由跨鏈路由加載。跨鏈路由可以配置多個區(qū)塊鏈適配器，達到連接多條區(qū)塊鏈的效果?？珂溌酚砷g會自動同步區(qū)塊鏈適配器的配置信息，從而幫助用戶尋址位于其他區(qū)塊鏈上的資源?？珂溬Y源（Resource）指區(qū)塊鏈上的智能合約、數(shù)字資產(chǎn)等用戶可訪問的數(shù)據(jù)對象。類似于區(qū)塊鏈適配器的配置信息，跨鏈資源的元信息也在跨鏈路由之間同步。用戶通過統(tǒng)一的接口對跨鏈分區(qū)中的資源進行尋址和調(diào)用。為了滿足未來多樣化的業(yè)務(wù)互聯(lián)需求，針對海量

19、數(shù)據(jù)跨鏈的典型業(yè)務(wù)特征，WeCross 為網(wǎng)絡(luò)交互和部署架構(gòu)設(shè)定了以下關(guān)鍵設(shè)計目標?？绲赜蚧ヂ?lián)：作為多方參與的區(qū)塊鏈應(yīng)用，通常涉及多個服務(wù)機構(gòu)，業(yè)務(wù)部署在多個跨地域的數(shù)據(jù)中心。WeCross 為跨地域場景設(shè)計安全、可靠和高效的網(wǎng)絡(luò)架構(gòu)，基于 TCP長連接、心跳、自動重連和加密通信技術(shù)的網(wǎng)絡(luò)機制來保證大范圍跨地域互聯(lián)的穩(wěn)定性、及時性和安全性。部署架構(gòu)靈活：由于跨鏈需求通常源自成熟的區(qū)塊鏈應(yīng)用項目，跨鏈部署架構(gòu)需要具備兼容現(xiàn)存區(qū)塊鏈實例的能力。WeCross 采用 “非侵入式”設(shè)計，跨鏈路由以獨立進程的方式與區(qū)塊鏈節(jié)點分離部署，無需變更既有的區(qū)塊鏈網(wǎng)絡(luò)架構(gòu)，即可實現(xiàn)靈活的架構(gòu)部署?？珂溌酚砷g使用網(wǎng)

20、絡(luò)傳輸跨鏈消息和區(qū)塊鏈消息，結(jié)合網(wǎng)絡(luò)自動尋路功能，只要跨鏈路由間有直接或間接可觸達的網(wǎng)絡(luò)鏈路，就能完成跨鏈交互?？勺杂啥ㄖ疲含F(xiàn)實業(yè)務(wù)場景中的跨鏈需求千差萬別，接入的區(qū)塊鏈平臺多種多樣，因此定制化可裁剪的跨鏈能力不可或缺。WeCross 的區(qū)塊鏈適配器和跨鏈資源支持自由定制，根據(jù)接入的區(qū)塊鏈類型、系統(tǒng)資源和網(wǎng)絡(luò)情況，選擇不同的區(qū)塊鏈適配器和跨鏈資源。可信交互流程區(qū)塊鏈平臺設(shè)計的基本安全假設(shè)是“每個參與者皆有可能作惡”，在此假設(shè)下通過密碼學(xué)與共識算法等機制構(gòu)建分布式可信環(huán)境。然而此可信環(huán)境往往只在區(qū)塊鏈平臺內(nèi)部生效，無法簡單被另一個區(qū)塊鏈平臺信任，需要引入額外的可信證明信息來實現(xiàn)跨區(qū)塊鏈平臺的可信

21、交互。WeCross 在處理跨鏈交互時除了傳輸區(qū)塊鏈交易信息外，還會額外傳輸區(qū)塊鏈交易的相關(guān)證明數(shù)據(jù)，并使用這些信息進行交易和回執(zhí)（交易執(zhí)行結(jié)果）的存在性證明，以證明鏈上信息的真實與可靠。以上圖所示的跨鏈交互為例，機構(gòu) 1 和機構(gòu) 2 分別部署了區(qū)塊鏈 A 和區(qū)塊鏈 B，現(xiàn)在機構(gòu) 1 的用戶要訪問機構(gòu) 2 的區(qū)塊鏈 B，并要求訪問的結(jié)果真實可信，其跨鏈交互時序如下圖所示。與傳統(tǒng)的區(qū)塊鏈交易處理流程相比，WeCross 跨鏈路由除了傳輸交易和回執(zhí)的信息，還額外傳輸交易和回執(zhí)的默克爾證明，交易的發(fā)送方使用這些證明來進行跨鏈數(shù)據(jù)訪問的可信驗證，使交易的發(fā)送方能確認交易在目標區(qū)塊鏈上真實發(fā)生且獲得結(jié)果

22、，保證交易和回執(zhí)的真實可信。WeCross 遵循跨鏈交互數(shù)據(jù)皆可自證的原則，要求交互響應(yīng)消息同時攜帶數(shù)據(jù)和證明，該規(guī)則普遍適用于各類跨鏈場景，可用于保障整個交易流程的真實可信。第三章 WeCross 核心技術(shù)與優(yōu)勢為了實現(xiàn)跨鏈交互的高效可用、安全可信和便捷治理，WeCross 基于區(qū)塊鏈體系的抽象、跨鏈系統(tǒng)的架構(gòu)和可信交互流程的頂層設(shè)計，提煉四個技術(shù)點，以實現(xiàn)跨鏈的核心功能：通用區(qū)塊鏈接口（UBI，Universal Blockchain Interface）：WeCross 設(shè)計一套通用的區(qū)塊鏈數(shù)據(jù)協(xié)議，抽象提煉主流區(qū)塊鏈共通的核心數(shù)據(jù)結(jié)構(gòu)與資源定義，使多種區(qū)塊鏈平臺可以用統(tǒng)一的數(shù)據(jù)協(xié)議交互

23、，極大程度減小區(qū)塊鏈平臺之間的交互難度。異構(gòu)鏈互聯(lián)協(xié)議（HIP，Heterogeneous Interchain Protocol）：WeCross 設(shè)計主流區(qū)塊鏈平臺通用的網(wǎng)絡(luò)交互協(xié)議及統(tǒng)一的交互模式，通過簡便適配，即可實現(xiàn)異構(gòu)區(qū)塊鏈平臺的連通?？尚攀聞?wù)機制（TTM，Trust Transaction Management）：WeCross 采用密碼學(xué)技術(shù)和分布式算法，保證區(qū)塊鏈平臺之間交互數(shù)據(jù)的真實可信且難以篡改，保證業(yè)務(wù)邏輯的原子事務(wù)性，使得區(qū)塊鏈平臺之間任何關(guān)聯(lián)的兩個交易能夠完全執(zhí)行或完全回滾。多邊跨域治理（MIG，Multilateral Inter-Domain Governanc

24、e）：WeCross設(shè)計一套可擴展、去中心的跨鏈治理架構(gòu)，讓多個區(qū)塊鏈業(yè)務(wù)能夠根據(jù)其特定需求共同搭建一條治理鏈進行跨鏈交互方面的治理。治理鏈承載了權(quán)限控制、事務(wù)管理、準入機制和監(jiān)管介入等治理功能。結(jié)合設(shè)計理念，用戶體驗以及平臺特性等方面的綜合考量，WeCross 具備以下三個主要優(yōu)勢：開源開放：WeCross 秉承開源、開放的原則，與社區(qū)共同維護平臺的迭代升級，群策群力，共建更強大、更好用的跨鏈平臺。開發(fā)友好：WeCross 提供多語言版本的 SDK 供開發(fā)者使用，提供可視化的管理工具，方便用戶開發(fā)、調(diào)試以及運維。安全可信：WeCross 基于加密、準入、隔離以及追溯等多種機制保障跨鏈數(shù)據(jù)的機

25、密性以及系統(tǒng)的安全性。通用區(qū)塊鏈接口各家區(qū)塊鏈平臺有著各自的 SDK、智能合約框架和交互邏輯，開發(fā)者不得不針對性地學(xué)習(xí)每一種區(qū)塊鏈平臺的 API 和調(diào)用邏輯，做定制化開發(fā)。當兩個異構(gòu)平臺存在跨鏈需求時，雙邊業(yè)務(wù)需要重新學(xué)習(xí)對方平臺的 API 和調(diào)用邏輯，這不僅是對開發(fā)者精力和成本的巨大浪費，也是跨鏈落地難的一個重要原因。區(qū)塊鏈平臺雖各有不同，但萬變不離其宗，主流區(qū)塊鏈的底層原理都有其共通之處。經(jīng)過抽象后，大部分區(qū)塊鏈平臺的區(qū)塊鏈邏輯、區(qū)塊數(shù)據(jù)結(jié)構(gòu)和交易數(shù)據(jù)結(jié)構(gòu)等都具有較高的相似性。以 FISCO BCOS 和 Hyperledger Fabric 的交易數(shù)據(jù)結(jié)構(gòu)為例，兩者有各自的 SDK、合約

26、框架等接口規(guī)范。盡管它們之間有一定的差異性，但對于關(guān)鍵數(shù)據(jù)結(jié)構(gòu)和合約調(diào)用接口，兩者之間有很多共同點。FISCO BCOS 和 Hyperledger Fabric 雖然使用不同的智能合約引擎，但智能合約的調(diào)用方式是類似的，都是通過給出智能合約的地址、智能合約的方法名和調(diào)用智能合約的參數(shù)，獲得智能合約方法返回的數(shù)據(jù)。不僅是 FISCO BCOS 和 Hyperledger Fabric，其它主流區(qū)塊鏈平臺的智能合約調(diào)用也基本如此。本著“求同存異”、“聚焦最大公約數(shù)”的基本思路，通用區(qū)塊鏈接口（UBI）對交易、智能合約與資產(chǎn)等數(shù)據(jù)進行抽象包裝，設(shè)計統(tǒng)一的資源范式，對主流區(qū)塊鏈的關(guān)鍵數(shù)據(jù)結(jié)構(gòu)進行提煉

27、，設(shè)計普適跨鏈場景的抽象區(qū)塊數(shù)據(jù)結(jié)構(gòu)，為異構(gòu)區(qū)塊鏈的交互建立數(shù)據(jù)協(xié)議一致的基礎(chǔ)，實現(xiàn)“一次適配，隨處可用”的效果。統(tǒng)一資源范式各家區(qū)塊鏈平臺上的資源多種多樣，有智能合約、資產(chǎn)、信道和數(shù)據(jù)表等，無論這些資源的功能如何多樣，其核心接口主要可以歸納為數(shù)據(jù)、調(diào)用和事件三類固定的接口。為了更好地打通區(qū)塊鏈平臺資源交互，UBI 提出統(tǒng)一資源接口范式，使得用戶在調(diào)用區(qū)塊鏈智能合約、資產(chǎn)、信道或數(shù)據(jù)表時無需關(guān)心具體的智能合約語言和區(qū)塊鏈的底層架構(gòu)，只需傳入通用的參數(shù)，并處理統(tǒng)一定義的返回值即可。統(tǒng)一資源范式包括數(shù)據(jù)、調(diào)用和事件三類接口，如下表所示。統(tǒng)一資源接口的定義如下（偽代碼）：public interfa

28、ce Resource / 獲取數(shù)據(jù)public String getData(String key);/ 設(shè)置數(shù)據(jù)public void setData(String key, String value);/ 調(diào)用智能合約接口public Receipt call(Transaction transaction);/ 向智能合約發(fā)送交易public Receipt sendTransaction(Transaction transaction);/ 注冊事件回調(diào)public void registerEventHandler(EventCallback callback);單個區(qū)塊鏈上的資源

29、可以通過合約地址或名稱來定位和訪問，在跨鏈和多個業(yè)務(wù)互通的復(fù)雜網(wǎng)絡(luò)模型下則需要一個更高層的資源定位協(xié)議。為了讓用戶在復(fù)雜跨鏈分區(qū)下定位和訪問區(qū)塊鏈資源時無需關(guān)心資源位于哪個地域、機構(gòu)或機房，也無需關(guān)心所在區(qū)塊鏈的具體實現(xiàn)，只需提供資源地址和相關(guān)參數(shù)即可實現(xiàn)資源定位和訪問，UBI 使用統(tǒng)一資源尋址協(xié)議，實現(xiàn)自動路由轉(zhuǎn)發(fā)機制，為用戶智能定位所需資源。正如 2.2 “跨鏈系統(tǒng)架構(gòu)”章節(jié)所介紹的跨鏈系統(tǒng)架構(gòu)，WeCross 將跨鏈系統(tǒng)定義為跨鏈分區(qū)、業(yè)務(wù)鏈和業(yè)務(wù)鏈上的資源的組合，以上圖中的支付分區(qū)為例：跨鏈分區(qū)（Zone）：管轄若干具有一定關(guān)聯(lián)性的業(yè)務(wù)鏈，關(guān)聯(lián)性可能包括業(yè)務(wù)模式、地域、領(lǐng)域等。圖中的支

30、付分區(qū)就是一個跨鏈分區(qū)。業(yè)務(wù)鏈（Chain）：業(yè)務(wù)鏈運行在某個跨鏈分區(qū)，而且僅屬于一個跨鏈分區(qū)。圖中的交易鏈、積分鏈和結(jié)算鏈都是支付分區(qū)中的業(yè)務(wù)鏈。區(qū)塊鏈資源（Resource）：指業(yè)務(wù)鏈中的智能合約和資產(chǎn)等對象。如圖中的資產(chǎn)資源是交易鏈的資源，結(jié)算資源是結(jié)算鏈的資源，賬戶資源是積分鏈的資源。跨鏈分區(qū)、業(yè)務(wù)鏈和區(qū)塊鏈資源都有唯一的標識，通過組合三種標識，可以唯一地定位到跨鏈系統(tǒng)中的任一資源的位置，這個尋址的標識稱為跨鏈路徑（iPath，Interchain Path），跨鏈路徑定義為： 跨鏈分區(qū) . 業(yè)務(wù)鏈 . 區(qū)塊鏈資源 以圖中的支付分區(qū)為例：訪問交易鏈的資產(chǎn)資源，跨鏈路徑為：支付分區(qū) .

31、交易鏈 . 資產(chǎn)資源訪問結(jié)算鏈的結(jié)算資源，跨鏈路徑為：支付分區(qū) . 結(jié)算鏈 . 結(jié)算資源訪問積分鏈的賬戶資源，跨鏈路徑為：支付分區(qū) . 積分鏈 . 賬戶資源WeCross 設(shè)計實現(xiàn) HTTP Restful 接口訪問跨鏈路徑，支持以 HTTP URL 的形式訪問跨鏈系統(tǒng)中的資源，URL 格式為： http:/IP:Port/ 跨鏈分區(qū) / 業(yè)務(wù)鏈 / 區(qū)塊鏈資源 / 資源方法 以FISCO BCOS 的智能合約為例，智能合約通過接口讀寫合約的數(shù)據(jù)比如getData 為讀接口， setData 為寫接口，兩者的參數(shù)都可以是合約內(nèi)的變量名，在合約代碼內(nèi)實現(xiàn)讀寫流程；對智能合約的調(diào)用稱為調(diào)用接口，分

32、為 call 和 sendTransaction 兩種，call 接口僅調(diào)用合約讀接口以返回數(shù)據(jù)，不會改變鏈上狀態(tài)，sendTransaction 會往鏈上發(fā)送交易并改變區(qū)塊鏈狀態(tài)；另外還有事件接口，供客戶單接收智能合約的 event 事件。以下用偽代碼來描述資源的獲取和調(diào)用流程：/ 根據(jù)配置初始化 StubStub stub = context.getBean(fisco-bcos);/ 通過 iPath 獲取智能合約資源Resource myResource = stub.getResource(payment.fisco-bcos.HelloWeCross);/ 根據(jù)合約地址、方法名以及

33、參數(shù)列表拼接調(diào)用交易Transaction getTransaction = myResource.newTransaction();getTransaction.setFrom(myAccount); getTransaction.setMethod(get);/ 使用 call 方法，調(diào)用智能合約的 get 函數(shù)Receipt myReceipt = myResource.call(getTransaction);/ 根據(jù)合約地址、方法名以及參數(shù)列表拼接調(diào)用交易Transaction setTransaction = myResource.newTransaction(); setTran

34、saction.setFrom(myAccount); setTransaction.setMethod(set);setTransaction.setArgs(new ObjectHello WeCross!);/ 使用 sendTransaction 方法，向鏈上發(fā)送交易，調(diào)用智能合約的 set 函數(shù)Receipt myReceipt = myResource.sendTransaction(setTransaction);/ 解析返回值Object results = myReceipt.decode();抽象區(qū)塊鏈結(jié)構(gòu)為了滿足異構(gòu)區(qū)塊鏈之間的區(qū)塊數(shù)據(jù)互信的需求，UBI 提出抽象區(qū)塊的概

35、念，由抽象區(qū)塊組成的鏈稱為“抽象鏈”。抽象區(qū)塊里包含業(yè)界主流區(qū)塊鏈共同的數(shù)據(jù)字段，用于驗證區(qū)塊鏈結(jié)構(gòu)的正確性、查詢區(qū)塊鏈當前狀態(tài)和驗證區(qū)塊鏈數(shù)據(jù)等。多個區(qū)塊鏈之間，通過相互同步和獲取抽象鏈的方式，來確認其它區(qū)塊鏈的狀態(tài)，驗證預(yù)期交互數(shù)據(jù)的正確性。以FISCO BCOS 和Hyperledger Fabric 為例，二者的區(qū)塊結(jié)構(gòu)中，區(qū)塊高度、區(qū)塊哈希、上一塊哈希和狀態(tài)數(shù)據(jù)哈希值字段的含義是相同的，不同的是用于驗證的默克爾根字段。抽象區(qū)塊的數(shù)據(jù)字段可以分為兩類，一類是區(qū)塊信息字段，包括區(qū)塊高度、區(qū)塊哈希值和上一塊哈希，這些字段用于驗證區(qū)塊鏈的正確性；另一類是信息驗證字段，包括交易默克爾根、回執(zhí)默

36、克爾根和狀態(tài)默克爾根，分別用于驗證該區(qū)塊相關(guān)的交易、回執(zhí)和狀態(tài)數(shù)據(jù)的存在性和正確性，以證明某個交易是否屬于當前區(qū)塊、某個回執(zhí)是否屬于當前區(qū)塊等。異構(gòu)鏈互聯(lián)模型區(qū)塊鏈交互的核心是接口調(diào)用，盡管各家區(qū)塊鏈平臺的內(nèi)部架構(gòu)、網(wǎng)絡(luò)模型和共識邏輯有很大差異，但這些區(qū)塊鏈平臺的對外接口存在共性，至少都有數(shù)據(jù)讀寫、調(diào)用智能合約和向智能合約發(fā)送交易等接口。以 FISCO BCOS 和 Hyperledger Fabric 為例， 其接口相似性對比如下：異構(gòu)鏈互聯(lián)模型（HIP）通過分析主流區(qū)塊鏈平臺交互方式的共性點，提煉一種通用的區(qū)塊鏈接入范式與跨鏈交互模型，區(qū)塊鏈平臺之間進行少量適配對接，就可以實現(xiàn)異構(gòu)鏈之間的

37、跨鏈交互。通用接入范式HIP 定義一種通用的區(qū)塊鏈接入范式，只需實現(xiàn)兩個核心接口即可接入一條區(qū)塊鏈，這兩個接口分別是獲取“資源”的接口和獲取“信息”的接口。資源源自 3.1.1“統(tǒng)一資源范式”章節(jié)中所述的統(tǒng)一資源定義，信息是區(qū)塊和區(qū)塊高度等區(qū)塊鏈關(guān)鍵信息。基于這種通用范式，不同區(qū)塊鏈平臺可以各自提供一個區(qū)塊鏈適配器（Stub）。區(qū)塊鏈適配器可以基于原有區(qū)塊鏈平臺 SDK 進行封裝，實現(xiàn) HIP 的核心接口，而無需對原有區(qū)塊鏈做滲透修改。任何區(qū)塊鏈只要遵循區(qū)塊鏈接入模型，實現(xiàn)區(qū)塊鏈適配器， 就可以接入 WeCross 平臺。接入方式如 2.2“跨鏈系統(tǒng)架構(gòu)”章節(jié)所述，由跨鏈路由加載區(qū)塊鏈適配器，

38、從而實現(xiàn)接入?yún)^(qū)塊鏈平臺。區(qū)塊鏈適配器的接口聲明如下（偽代碼）：public interface Stub / 獲取 Stub 類型public String getType();/ 獲取 Stub 管理的區(qū)塊鏈的狀態(tài)public ChainState getChainState();/ 獲取 Stub 管理的區(qū)塊鏈的區(qū)塊頭信息public Header getHeader(int blockNumber);/ 獲取 Stub 管理的區(qū)塊鏈上的資源public Resource getResource(Path path) throws Exception；跨鏈交互模型為適配多變的跨鏈業(yè)務(wù)場景，

39、HIP 設(shè)計一套跨鏈交互模型，該模型可以支持單分區(qū)單路由、單分區(qū)多路由以及多分區(qū)多路由等多種場景。單分區(qū)單路由：針對一個機構(gòu)的用戶需要同時訪問多個區(qū)塊鏈的場景，可以在機構(gòu)內(nèi)搭建一個跨鏈路由，并為其配置多個區(qū)塊鏈適配器，連接到多個區(qū)塊鏈。通過給多個區(qū)塊鏈適配器配置不同的 iPath 前綴，用戶可以通過跨鏈路由，任意尋址并訪問網(wǎng)絡(luò)中的資源。如圖所示，用戶 A 可以通過配置了兩個不同區(qū)塊鏈適配器的跨鏈路由，實現(xiàn)對兩條鏈上資源的訪問。單分區(qū)多路由：針對多個機構(gòu)的多個用戶想要交叉訪問對方的區(qū)塊鏈，可以部署多個跨鏈路由，并為其配置各自的區(qū)塊鏈適配器?？珂溌酚芍g通過 P2P 網(wǎng)絡(luò)協(xié)議相連，跨鏈路由之間會自

40、動同步交換各自的區(qū)塊鏈適配器和資源信息。不同機構(gòu)的用戶可以通過調(diào)用本機構(gòu)的跨鏈路由，由本機構(gòu)的跨鏈路由轉(zhuǎn)發(fā)至其它機構(gòu)的跨鏈路由，訪問相應(yīng)資源并按路由返回。如圖所示，用戶甲可以通過跨鏈路由 viaA 和跨鏈路由 viaB 組成的路由網(wǎng)絡(luò)，實現(xiàn)對兩條存證管理鏈上資源的訪問。多分區(qū)多路由：在更為復(fù)雜的業(yè)務(wù)場景中存在多種業(yè)務(wù)相互融合的需求，因此也就存在多個跨鏈分區(qū)互聯(lián)訪問的需求。面對這種需求，HIP 支持跨鏈路由動態(tài)增加與其他跨鏈路由的連接，通過權(quán)限控制保證跨鏈訪問的安全可控，對原有業(yè)務(wù)不做任何滲透修改。如圖所示，通過跨鏈路由將存證分區(qū)和結(jié)算分區(qū)相連，實現(xiàn)原有兩個分區(qū)的用戶能夠訪問對方分區(qū)的資源。從以

41、上三個場景可以看到，跨鏈路由是整個交互模型的核心模塊，是連通多個區(qū)塊鏈的橋梁?？珂溌酚勺鳛楠毩⒌倪M程部署，一個跨鏈路由可以使用多個區(qū)塊鏈適配器模塊去連接多個區(qū)塊鏈，多個跨鏈路由使用 P2P 網(wǎng)絡(luò)互相連通?？珂溌酚蓛?nèi)部采用分層設(shè)計的理念，自底向上分為四個層次：基礎(chǔ)層：跨鏈路由底層最基礎(chǔ)的部分，包括網(wǎng)絡(luò)互聯(lián)模塊、區(qū)塊鏈適配器模塊和抽象鏈存儲模塊。網(wǎng)絡(luò)互聯(lián)模塊負責跨鏈路由間的互聯(lián)，區(qū)塊鏈適配器模塊負責連接具體的區(qū)塊鏈節(jié)點，抽象鏈存儲模塊保存多個區(qū)塊鏈的抽象區(qū)塊頭信息用于驗證交易和回執(zhí)。交互層：處理跨鏈路由的交互邏輯，包括資源同步、資源尋址以及跨鏈證明等模塊。資源同步模塊同步多個其它跨鏈路的資源配置信

42、息，資源尋址模塊幫助用戶在跨鏈分區(qū)中按 iPath 尋址資源，跨鏈證明模塊驗證其它跨鏈路由返回的交易和回執(zhí)數(shù)據(jù)。事務(wù)層：處理和協(xié)調(diào)跨區(qū)塊鏈的事務(wù)邏輯，包括兩階段事務(wù)模塊和哈希時間鎖定等機制。跨鏈路由要在區(qū)塊鏈之間建立連接，為了保證跨鏈路由間能維持高效、可靠和安全的網(wǎng)絡(luò)連接，跨鏈路由設(shè)計如下網(wǎng)絡(luò)機制：網(wǎng)絡(luò)準入：跨鏈路由支持基于CA 認證機制的網(wǎng)絡(luò)準入，支持任意多級的證書結(jié)構(gòu)，保障信息保密性、認證性、完整性、不可抵賴性。所有通訊鏈路使用SSL 加密，加密算法可配置，保證數(shù)據(jù)傳輸?shù)陌踩?。TCP 長連接：跨鏈路由之間維持長連接以保證雙向通信，減少建立連接和斷開連接的開銷?？珂溌酚删W(wǎng)絡(luò)之間使用心跳包來

43、保證可用性，在斷連的時候自動重連。狀態(tài)同步：跨鏈路由之間會自動同步各自區(qū)塊鏈的區(qū)塊高度、共識和網(wǎng)絡(luò)等狀態(tài)。自適應(yīng)路由：跨鏈路由在P2P 網(wǎng)絡(luò)中，會自動搜索和確認與另一個跨鏈路由的可行鏈路，并評估鏈路的響應(yīng)速度、帶寬和可用率，自動選取最佳的鏈路，當一個鏈路失效時，跨鏈路由會選取另一個可用的鏈路，保證跨鏈消息的可用性?？尚攀聞?wù)機制正如第一章關(guān)于 Secure 的設(shè)計理念提到，基于共識機制和密碼學(xué)技術(shù)，區(qū)塊鏈建立了一套內(nèi)部安全機制，但是在面對跨區(qū)塊鏈調(diào)度時會突破區(qū)塊鏈內(nèi)部的安全邊界，需要重新建立安全機制。以基于 PBFT 共識機制的區(qū)塊鏈平臺為例，參與共識的所有區(qū)塊鏈節(jié)點不會直接同步來自其它節(jié)點的狀

44、態(tài)數(shù)據(jù)，而是先下載來自其它節(jié)點的區(qū)塊，驗證區(qū)塊中的 PBFT 共識簽名，然后執(zhí)行區(qū)塊中的所有交易，根據(jù)交易的執(zhí)行結(jié)果來更新狀態(tài)數(shù)據(jù)，保證所有需要上鏈的數(shù)據(jù)都經(jīng)過簽名的校驗和執(zhí)行的驗證。然而，在跨鏈場景中，各自獨立的區(qū)塊鏈網(wǎng)絡(luò)需要相互獲取對方鏈上的數(shù)據(jù)，由于它們并沒有參與對方區(qū)塊鏈的共識流程，如何保證獲得的數(shù)據(jù)可信是一個技術(shù)挑戰(zhàn)點。另一個技術(shù)挑戰(zhàn)點是保證跨鏈交易中各自鏈上交易執(zhí)行的事務(wù)性，例如跨鏈資產(chǎn)交易，讓所有參與交易的區(qū)塊鏈對資產(chǎn)的操作同時成功或者同時失敗。傳統(tǒng)的分布式事務(wù)如多個關(guān)系型數(shù)據(jù)庫的事務(wù)中，多個數(shù)據(jù)庫會選取一個共同可信的中心協(xié)調(diào)者，來協(xié)調(diào)多個數(shù)據(jù)庫的事務(wù)操作。協(xié)調(diào)者向多個參與事務(wù)的

45、數(shù)據(jù)庫發(fā)送操作步驟，并監(jiān)視和管理這些操作的執(zhí)行狀態(tài)，一旦出現(xiàn)異常，中心協(xié)調(diào)者會回滾整個事務(wù)，還原系統(tǒng)狀態(tài)。然而，跨鏈場景中的多個區(qū)塊鏈平臺的地位是對等的，難以選出一個中心化的協(xié)調(diào)者，無法按照傳統(tǒng)的方式實現(xiàn)分布式事務(wù)。WeCross 可信事務(wù)機制（TTM）的目的是解決上述挑戰(zhàn)，提出數(shù)據(jù)互信機制和跨鏈事務(wù)機制，分別解決數(shù)據(jù)可信問題和交易事務(wù)性的問題。數(shù)據(jù)互信機制假設(shè)兩個用戶甲和乙要在兩條不同區(qū)塊鏈上完成資產(chǎn)交換，那么必須要有一種機制來保證兩個用戶都真實擁有所宣稱的資產(chǎn)，否則任何一方的用戶都可以使用偽造的鏈上資產(chǎn)去兌換對方有效的鏈上資產(chǎn)。數(shù)據(jù)互信機制就是要解決這種跨鏈場景下的數(shù)據(jù)可信問題，它基于默克

46、爾證明機制來實現(xiàn)，使得一方在不需要獲取另一方區(qū)塊鏈全量數(shù)據(jù)的情況下，仍然能夠快速證明另一方區(qū)塊鏈上特定數(shù)據(jù)的真實存在性。參與跨鏈的雙方通常沒有條件和權(quán)限去存儲另一方的全量區(qū)塊鏈數(shù)據(jù)，要在不存儲所有區(qū)塊的情況下驗證某個區(qū)塊是否包含了特定的交易，需要借助一種特殊的數(shù)據(jù)結(jié)構(gòu)默克爾樹。默克爾樹的結(jié)構(gòu)如下圖所示，每個非葉子節(jié)點通過其子節(jié)點的哈希值來進行標注，樹的根節(jié)點叫作默克爾根。假設(shè)上圖是區(qū)塊 X 的默克爾樹結(jié)構(gòu)，如果要驗證交易 D 是否在區(qū)塊 X 中，無需獲取整個區(qū)塊 X，只需要提供交易 D，H_AB，H_C 以及默克爾根則可。具體過程如下：根據(jù)交易 D 計算哈希，得到 H_D。根據(jù) H_C 和 H

47、_D 計算哈希，得到 H_CD。根據(jù) H_AB 和 H_CD 計算哈希，得到 H_ABCD。對比H_ABCD 和默克爾根，如果相同，則證明區(qū)塊 X 存在交易D，否則說明不存在。上述的驗證過程稱為默克爾證明，證明信息是指驗證過程中用到的初始哈希值，即 H_ AB 和 H_C。默克爾證明是一種經(jīng)典技術(shù)，用于證明交易存在于區(qū)塊鏈的某個區(qū)塊中，是實現(xiàn)輕客戶端的關(guān)鍵技術(shù)。WeCross 采用默克爾證明做跨鏈互信技術(shù)的基本算法，在功能完備性和用戶體驗方面比傳統(tǒng)輕客戶端前進了一大步，主要表現(xiàn)在以下兩方面：多維度的默克爾證明：WeCross 設(shè)計多維度的默克爾證明，不僅能夠驗證交易存在性，還能夠驗證交易執(zhí)行結(jié)

48、果的正確性，為跨鏈交易可信執(zhí)行以及后續(xù)章節(jié)將講述的事務(wù)機制提供完備的可信驗證。交易存在性驗證是指驗證某一筆交易是否真實存在于某個區(qū)塊，確保跨鏈交易中雙方所聲稱的資產(chǎn)或數(shù)據(jù)是真實存在的。交易執(zhí)行結(jié)果正確性驗證是指驗證跨鏈交易是否已在雙方各自的區(qū)塊鏈上正確執(zhí)行，保證跨鏈交易執(zhí)行結(jié)果的正確性。其中交易存在性驗證需要用到交易默克爾根，交易執(zhí)行結(jié)果正確性驗證需要用到回執(zhí)默克爾根。對用戶完全透明：上述提到的多維度默克爾證明，在 WeCross 中對用戶完全透明，用戶訪問跨鏈資源與訪問鏈內(nèi)資源體驗一致?？珂溌酚山M件的交互層包含一個跨鏈證明模塊，該模塊負責實現(xiàn)默克爾證明機制。用戶發(fā)送跨鏈交易請求，跨鏈路由根據(jù)

49、路由尋址找到相應(yīng)資源所在業(yè)務(wù)鏈，跨鏈路由會向業(yè)務(wù)鏈發(fā)送交易，并且獲得相關(guān)默克爾證明，證明數(shù)據(jù)連同請求結(jié)果一并返回用戶側(cè)的跨鏈路由，由用戶側(cè)的跨鏈路由進行默克爾證明數(shù)據(jù)的驗證。總體流程可見 2.3“可信交互流程”章節(jié)中的時序圖，數(shù)據(jù)可信驗證的全流程由跨鏈路由組件執(zhí)行，用戶無需關(guān)心實現(xiàn)細節(jié)。借助默克爾證明機制，WeCross 能夠有效地驗證跨鏈交易的真實性和跨鏈交易執(zhí)行結(jié)果的真實性，為跨鏈交易的可信執(zhí)行提供了基礎(chǔ)。同時，復(fù)雜的證明過程由跨鏈路由自動實現(xiàn)，對用戶完全透明?？珂準聞?wù)機制同樣以跨鏈資產(chǎn)交換為例，通過數(shù)據(jù)互信機制保證資產(chǎn)和交易的真實有效，對整個交易流程而言仍有不足。假設(shè)在一條鏈上成功完成了

50、資產(chǎn)轉(zhuǎn)移，但是另一條鏈上并未成功執(zhí)行資產(chǎn)轉(zhuǎn)移，就會導(dǎo)致某一方損失資產(chǎn)，使跨鏈資產(chǎn)交換失敗。數(shù)據(jù)互信機制雖然保證了跨鏈交易的可信性，但是為了跨鏈資產(chǎn)交換完全正確執(zhí)行，還需要保證跨鏈交易的事務(wù)性。跨鏈事務(wù)機制保證多個區(qū)塊鏈上的操作要么全部執(zhí)行完畢，要么全部執(zhí)行失敗。傳統(tǒng)分布式系統(tǒng)的事務(wù)技術(shù)有很多，例如兩階段提交和三階段提交等，它們能夠?qū)崿F(xiàn)不同級別的分布式一致性，各有優(yōu)缺點。區(qū)塊鏈早期以數(shù)字資產(chǎn)交換為主要運用，基于區(qū)塊鏈架構(gòu)的特殊性，也有區(qū)塊鏈升級版的事務(wù)技術(shù)，包括哈希鎖定、分布式私鑰控制等，這些技術(shù)主要用于保證跨鏈資產(chǎn)交換場景的事務(wù)性。TTM 的目標是不但能滿足跨鏈數(shù)字資產(chǎn)的交換，還要支持更多復(fù)雜

51、跨鏈場景，所以會逐步集成支持現(xiàn)有主流的事務(wù)技術(shù)，包括兩階段提交協(xié)議、哈希時間鎖定合約等。兩階段提交協(xié)議兩階段提交協(xié)議是一個原子性的提交協(xié)議，旨在保證分布式系統(tǒng)處理事務(wù)時的一致性。兩階段提交協(xié)議具備可靠性強、通用性強、實現(xiàn)簡單等優(yōu)勢，大部分業(yè)務(wù)諸如跨鏈轉(zhuǎn)賬、跨鏈協(xié)同等，都可以使用兩階段提交協(xié)議來實現(xiàn)。兩階段提交協(xié)議將事務(wù)的提交過程分成兩個階段來處理，分別是投票階段和提交階段。為了讓整個事務(wù)能夠正常運行，兩階段提交協(xié)議涉及三個接口，分別是準備（Prepare）、提交（Commit）和回滾（Rollback）。在 3.1.1“統(tǒng)一資源范式”章節(jié)中介紹了統(tǒng)一的資源范式，為資源定義了數(shù)據(jù)獲取、調(diào)用和事件

52、通知的三個核心接口。結(jié)合兩階段提交協(xié)議，WeCross 為需要保證跨鏈事務(wù)性的資源增加三個事務(wù)接口，如下圖所示。在 3.2.2“跨鏈交互模型”章節(jié)中闡述了跨鏈路由的功能設(shè)計，其中事務(wù)層負責實現(xiàn)跨鏈事務(wù)機制。跨鏈路由會擔任兩階段提交協(xié)議中的協(xié)調(diào)者角色，協(xié)調(diào)整個事務(wù)的運行。在準備階段，跨鏈路由會向全體參與事務(wù)的資源發(fā)起準備請求，在所有資源完成準備后，再向全體資源發(fā)送提交請求。準備或提交兩個階段中，如果任一資源返回失敗，跨鏈路由會向全體參與事務(wù)的資源發(fā)起回滾請求，放棄本次事務(wù)，恢復(fù)最初狀態(tài)?？珂溌酚蓞f(xié)調(diào)的事務(wù)機制整體流程如下圖所示。兩階段提交協(xié)議具有諸多優(yōu)勢，傳統(tǒng)數(shù)據(jù)庫和分布式系統(tǒng)大量使用兩階段提交

53、協(xié)議實現(xiàn)事務(wù)機制，因此跨鏈事務(wù)機制也首選兩階段提交協(xié)議。傳統(tǒng)的兩階段提交協(xié)議非常依賴可靠的協(xié)調(diào)者，如果有惡意或異常的協(xié)調(diào)者攔截或阻攔部分事務(wù)請求，就會導(dǎo)致事務(wù)流程的中斷，如果擔任協(xié)調(diào)者的跨鏈路由因為系統(tǒng)或網(wǎng)絡(luò)的原因失效，就會導(dǎo)致單點問題從而使事務(wù)無法繼續(xù)。為了避免上述問題，TTM 支持用戶在多個業(yè)務(wù)區(qū)塊鏈之外可選地搭建一個專門用于協(xié)調(diào)事務(wù)的區(qū)塊鏈，稱為治理鏈。各個機構(gòu)中參與事務(wù)的跨鏈路由通過配置區(qū)塊鏈適配器連接治理鏈，在處理兩階段事務(wù)的過程中，事務(wù)的狀態(tài)都記錄在治理鏈上，這樣惡意的協(xié)調(diào)者就無法輕易地篡改兩階段事務(wù)的狀態(tài)。當負責協(xié)調(diào)事務(wù)的跨鏈路由因為系統(tǒng)或網(wǎng)絡(luò)原因出現(xiàn)異常時，其它跨鏈路由可以從治

54、理鏈得到事務(wù)狀態(tài)，繼續(xù)處理事務(wù)，規(guī)避單點的問題，詳細的實現(xiàn)參見 3.4.1 “權(quán)限事務(wù)管理”。哈希時間鎖定合約哈希時間鎖定合約（HTLC，Hashed Time Lock Contract）是一項進行區(qū)塊鏈網(wǎng)絡(luò)之間資產(chǎn)交換的技術(shù)。在資產(chǎn)交換過程中，為了保證各個區(qū)塊鏈的資產(chǎn)安全，資產(chǎn)轉(zhuǎn)移要么全部完成，要么全部沒有完成，不存在任何中間狀態(tài)。哈希時間鎖定合約基于哈希算法和超時機制，對比兩階段提交，HTLC 并不依賴可信的協(xié)調(diào)者，特別適合區(qū)塊鏈資產(chǎn)交換的場景?；诮y(tǒng)一資源范式，哈希時間鎖定合約為區(qū)塊鏈資源新增三個接口，分別是鎖定（Lock）、解鎖（Unlock）和超時（Timeout）接口。只要正確實

55、現(xiàn)這三個接口，WeCross 跨鏈路由就可以協(xié)調(diào)該區(qū)塊鏈資源，參與到任意基于哈希時間鎖定合約的事務(wù)中。哈希時間鎖定合約的處理流程基于哈希算法和超時機制，假設(shè)有兩個區(qū)塊鏈 A 和 B，試圖交換位于鏈 A 的資產(chǎn) 和位于鏈 B 的資產(chǎn) ，則整個哈希時間鎖定的流程如下：A 首先選取一個秘密隨機數(shù) S，使用特定的哈希算法計算出 S 的哈希值 H，之后 A 將 H 發(fā)給 B，同時 A 和 B 協(xié)商兩個時間點 T0 和 T1，確保 T0 T1。A 基于 H 和 T0 創(chuàng)建資產(chǎn)鎖定智能合約 LockContractA，該智能合約會鎖定資產(chǎn) ，其可以使用 S 來解鎖并將資產(chǎn) 轉(zhuǎn)移給 B，如果在 T0 前仍未解

56、鎖，則會自動撤銷鎖定，且不會發(fā)生任何資產(chǎn)轉(zhuǎn)移。B 基于 H 和 T1 創(chuàng)建資產(chǎn)鎖定智能合約 LockContractB，該智能合約會鎖定資產(chǎn) ，其可以使用 S 來解鎖并將資產(chǎn) 轉(zhuǎn)移給 A，如果在 T1 前仍未解鎖，則會自動撤銷鎖定，且不會發(fā)生任何資產(chǎn)轉(zhuǎn)移。A 使用秘密隨機數(shù) S，調(diào)用 B 上的智能合約 LockContractB，將資產(chǎn) 轉(zhuǎn)移給 A 。經(jīng) 過 上 述 步 驟，B 獲 得 了 秘 密 隨 機 數(shù) S，B 使 用 S 調(diào) 用 A 上 的 智 能 合 約 LockContractA，將資產(chǎn) 轉(zhuǎn)移給 B，資產(chǎn)交換完成。如果 A 或 B 任意一方超時未執(zhí)行操作，則在 T1 時間點后，B

57、資產(chǎn)會撤銷鎖定，T0時間點后，A 資產(chǎn)會撤銷鎖定，還原初始狀態(tài)。T0 和 T1 用于避免 A 或 B 單方延誤交易，所以這其中的交易包 和交易包 都需要設(shè)定時間限制，超出這個時間限制后，相關(guān)資產(chǎn)立即撤銷鎖定，原路返回。整體操作時序流程如下圖所示。兩階段提交協(xié)議和哈希時間鎖定合約各有特點。兩階段提交可以用于滿足一般的事務(wù)處理請求，但是需要依賴可信協(xié)調(diào)者，為了引入多中心可信協(xié)調(diào)者，可能需要額外的治理鏈來配合實現(xiàn)。哈希時間鎖定合約不依賴可信協(xié)調(diào)者，契合區(qū)塊鏈資產(chǎn)交換的場景，但對于資產(chǎn)交換以外的場景，其流程較為復(fù)雜和冗長，沒有兩階段提交通用和有效。多邊跨域治理目前，區(qū)塊鏈面臨的擴展性瓶頸愈發(fā)明顯，現(xiàn)有

58、的一些技術(shù)手段例如多通道、多群組以及多鏈架構(gòu)等僅僅解決區(qū)塊鏈容量的平行擴展問題，但仍缺乏可信的準入、監(jiān)管和治理機制，使得跨鏈應(yīng)用限制在參與方都可信的場景。多邊跨域治理（MIG）是一套完整的區(qū)塊鏈多邊治理方案，支持多個區(qū)塊鏈按照其業(yè)務(wù)需求，以不同的網(wǎng)絡(luò)拓撲來組建跨鏈分區(qū)，并由多個機構(gòu)共同維護治理鏈，實現(xiàn)多個區(qū)塊鏈安全可信地執(zhí)行事務(wù)。MIG 通過協(xié)商和投票的形式進行機構(gòu)準入和區(qū)塊鏈治理，并支持即時有效的監(jiān)管仲裁。治理鏈上部署多種跨鏈治理相關(guān)的智能合約，包括權(quán)限管理合約、事務(wù)管理合約、業(yè)務(wù)監(jiān)管合約、業(yè)務(wù)鏈準入合約和機構(gòu)準入合約等，這些合約分別聚焦于權(quán)限、事務(wù)、監(jiān)管和 準入等功能。治理鏈由業(yè)務(wù)方和監(jiān)管

59、方等相關(guān)機構(gòu)共同搭建，各個機構(gòu)可以通過在各自的跨鏈鏈路由中配置區(qū)塊鏈適配器以接入治理鏈。權(quán)限事務(wù)管理區(qū)塊鏈上的資源可能涉及個人資產(chǎn)、身份數(shù)據(jù)和商業(yè)機密等多種敏感信息，需要可靠的權(quán)限管理和授權(quán)機制來保障區(qū)塊鏈資源的信息安全。通過在治理鏈上部署權(quán)限管理智能合約，能夠?qū)⒖珂湶僮鞯臋?quán)限控制細化到分區(qū)、機構(gòu)、區(qū)塊鏈甚至是資源的具體接口。接入治理鏈的跨鏈路由將實時同步和執(zhí)行來自權(quán)限管理合約的權(quán)限策略，控制和記錄跨鏈操作的資源訪問，實時保障跨鏈業(yè)務(wù)的信息安全。權(quán)限管理合約的邏輯表示例如下：標識號：區(qū)塊鏈用戶或機構(gòu)的標識號，作為表的主鍵，記錄該權(quán)限條目相關(guān)的用戶或機構(gòu)標識。資源路徑：該權(quán)限條目涉及的資源路徑，

60、即 iPath，路徑支持使用通配符。權(quán)限信息：控制該權(quán)限允許訪問的資源接口，參見 3.1.1“統(tǒng)一資源范式”章節(jié)定義的資源接口列表，資源中任一個接口都可以配置獨立的權(quán)限。除了權(quán)限的控制，跨鏈的事務(wù)操作也通過治理鏈調(diào)度。治理鏈部署了事務(wù)管理合約，用于記錄事務(wù)從生成到結(jié)束的完整生命周期。事務(wù)管理合約的邏輯表示例如下：事務(wù)標識號：事務(wù)的唯一標識號，每創(chuàng)建一個新事務(wù)時生成。步驟序號：一個事務(wù)需要多個步驟執(zhí)行，步驟序號為某個事務(wù)已經(jīng)執(zhí)行的步驟的序號。步驟操作：該步驟需要執(zhí)行的操作。步驟狀態(tài)：步驟的當前狀態(tài)。事務(wù)管理合約將事務(wù)的步驟記錄在治理鏈上，需要經(jīng)過所有治理節(jié)點的共識。如有攻擊者試圖攻擊某個事務(wù)，惡