本文作者：BitXHub
我們和跨鏈技術的緣分從一個客戶需求開始：
在養老金行業的區塊鏈應用中我們遇到了一個跨鏈的需求，一個客戶使用趣鏈聯盟鏈構建了一個養老金鍊，同時另一方客戶則使用Fabric構建了另一個區塊鏈服務，他們所做的業務分別位於養老金業務流程中的兩個不同階段，參與的機構和使用者也不盡相同，為了從底層開始打通這兩個區塊鏈，讓養老金的業務之間無縫互補並行更大規模的業務，同時促進兩者的業務互補達到共贏的目的，我們開始了跨鏈的探索之旅。
大概在一年前我們整理過《關於跨鏈技術的思考》，分析發現市場上的跨鏈平臺都無法滿足異構聯盟鏈的跨鏈需求，因此也就自然地開始了自研跨鏈平臺。
這一次我們就使用者最關心的10個關於跨鏈平臺的問題，來向大家傳遞BitXHub這款產品背後的設計思路，希望大家瞭解了架構的設計理念之後能夠更好的使用BitXHub，也能更好的參與到跨鏈平臺的演進之中。
1.跨鏈的本質是什麼？
自從區塊鏈這個行業興起之後，不同時期，不同的組織機構針對不同的應用場景開發出了種類繁多的區塊鏈平臺，例如Ethereum，趣鏈區塊鏈，Hyperledger Fabric等等。這些區塊鏈平臺的共識演算法、智慧合約執行引擎、密碼體系等機制設計上的不同導致了這些鏈之間的很難通訊，資料很難互認，導致了區塊鏈特別是異構的區塊鏈之間的跨鏈難題。
跨鏈難題的存在主要有兩個原因：一是早期區塊鏈設計自身就沒有跨鏈的模組，也就是類似電腦不帶網絡卡，二是現代某些區塊鏈支援跨鏈但是隻是支援特定協議的區塊鏈跨鏈如Polkadot，Cosmos，它們對支援他們協議的同構平行鏈支援完善，但是對異構鏈支援不夠。
結合區塊鏈的應用模式，我們認為跨鏈需要解決的本質問題就是跨鏈交易的捕獲、驗證和路由問題。也就是跨鏈服務應該能夠將跨鏈訊息從一個區塊鏈傳遞到另外一個區塊鏈，同時能夠讓目的區塊鏈正確驗證跨鏈訊息的合法性並執行相應的跨鏈動作。
2.為什麼是“閘道器+中繼”？
我們先來回顧一下常見的跨鏈方式：1）雜湊鎖定，安全性高但是場景有限；2）公證人機制：實現簡單但是存在中心化作惡風險；3）中繼鏈的機制，具備分散式治理的安全性，目前僅有公鏈的實現且對異構鏈支援不夠友好。
如下圖所示，結合現有的跨鏈解決方案和跨鏈的本質問題，我們設計了一種更加通用的鏈間通用傳輸協議IBTP，並配合閘道器+中繼鏈的架構模式實現異構區塊鏈跨鏈互動，閘道器解決跨鏈交易的獲取和提交問題，中繼鏈結合IBTP解決跨鏈交易的驗證和路由問題。
對這個方案有人可能會疑惑，難道不能只有閘道器嗎？目前在國內外也看到另一種類似的方案，就是不用中繼鏈，直接使用類似的閘道器進行點對點的跨鏈通訊，這種簡化的方式在可信的環境下尚可應用，但是談到跨鏈服務的多方治理，規則透明，資料的高可用層面遠不及採用中繼鏈的方式安全。
那既然這樣能不能閘道器的功能和中繼鏈合併呢？合併當然可以，但是會帶來額外的維護成本，引入閘道器首先我們將鏈和鏈之間多對多的關係降低到一對多的問題，其次是功能解耦，我們從架構圖中可以看到閘道器主要是負責和具體的應用鏈對接，每個應用鏈的互動模式不同，如果閘道器服務做到中繼鏈中去，那麼中繼鏈中新增加一個應用鏈，我們的中繼鏈就得去對接和系統級別升級，而使用閘道器去對接應用鏈可以保持中繼鏈的核心功能解耦。
因此“閘道器+中繼”的架構模式既能夠保證整個平臺的靈活性又能夠提供較高的安全性。
3.典型的跨鏈流程是什麼？
我們設計的跨鏈服務儘量減少業務人員對跨鏈底層的感知，讓跨鏈呼叫和普通跨合約呼叫保持一致。執行跨鏈呼叫之前需要執行一些準備工作，包括應用鏈註冊，驗證規則註冊以及跨鏈雙方的業務鏈上依據我們的跨鏈合約撰寫規則(https://github.com/meshplus/bitxhub/wiki/跨鏈合約編寫文件) 設定好相應的跨鏈合約，接下來使用SDK呼叫業務鏈的具體合約方法，這和呼叫普通的跨鏈服務沒有什麼區別，最簡跨鏈呼叫流程如下：
SDK呼叫具體的業務鏈A的合約方法；
合約方法被執行，丟擲跨鏈事件T1；
業務鏈A的跨鏈閘道器監聽到T1, 將其轉換成IBTP結構，提交到中繼鏈BitXHub上；
BitXHub依據相關規則對T1進行驗證以及路由；
業務鏈B的跨鏈閘道器接受到T1並根據IBTP結構進行解析，轉換成業務鏈B可識別的交易Tb；
B的跨鏈閘道器將Tb提交到業務鏈B上進行執行。
4.怎麼保證跨鏈資料的真實性？
如何驗證跨鏈資料的安全性以及有效性是跨鏈服務中需要主要解決的問題，在BitXHub的設計中，結合IBTP中的Proof和對應的驗證策略保障，這樣既可以對異構鏈支援的靈活性，同時可以保障跨鏈資料的可信驗證。
如下圖所示，對所有的跨鏈交易IBTP需要其提供相關的真實性證明內容序列化到Proof欄位裡，然後該IBTP訊息被傳遞到中繼鏈時，中繼鏈使用註冊的該Proof的驗證規則對IBTP進行驗證。
舉個例子，我們知道Fabric是基於背書策略進行交易的確認的，跨鏈交易可以將相應的背書結果封裝到Proof裡面，最後BitXHub的驗證引擎依據Fabric之前註冊進來的背書驗證規則對Proof內容進行驗證，從而保障相應跨鏈交易的真實性。
只要Proof和規則對的上，所有異構的區塊鏈理論上都能夠透過該模型驗證跨鏈資料的安全性。
5.跨鏈交易安全嗎？隱私該怎麼辦？
很多朋友一看到我們的跨鏈有個中繼鏈就非常擔心跨鏈交易的安全性問題，其實在設計之初我們就考慮到了這個問題。參考上面問題4中的IBTP的結構圖，可以看到傳遞到中繼鏈的跨鏈交易核心資料是儲存在Payload裡面的。那麼保護也就是正對該Payload的保護，針對跨鏈針對的跨使用環境的不同設計三種級別的資料的隱私保護手段：
透過特殊序列化規則對跨鏈資料進行序列化，這種適合較安全互信的環境；
透過中繼鏈兩個跨鏈閘道器使用DH協商加密秘鑰，對跨鏈核心欄位Payload進行加密；
採用隱私交易的方式，跨鏈交易完整Payload僅在指定的中繼節點上儲存，其他節點上相關欄位僅儲存Payload的雜湊值。
6.應用鏈需要改造嗎？工作量大嗎？
如果鏈平臺級別可改造那麼100%可以解決跨鏈的問題，然而我們不可能要求所有的業務鏈進行系統層級的改造，這既不科學也不經濟。我們一開始就是秉持著易接入性的原則進行架構設計的。BitXHub中主要透過跨鏈閘道器來幫助應用鏈代理跨鏈系統之間的網路通訊、交易格式轉換，使用中繼鏈輔助跨鏈交易的驗證。
針對跨鏈閘道器的設計，我們採用外掛的機制，將閘道器的核心功能和與具體應用鏈對接的功能進行解耦，對於新的應用鏈僅需按照跨鏈閘道器的規則實現好與其對接的部分即可。
7.如何保障跨鏈交易的事務性？
在BitXHub的跨鏈系統中，整個跨鏈交易主要會在發起跨鏈的應用鏈A、中繼鏈以及目的應用鏈B之間存在互動，他們之間的交易原子性和分散式事務所面臨事務的問題類似。
傳統分散式事務經典的實現模式是二階段提交和三階段提交，這兩種實現方式複雜但是能夠保障事務的實時一致性。這種實現需要有中心化的資源管理器，不適用這種分散式的跨鏈服務。在我們的採用中繼鏈的跨鏈方案中，中繼鏈儲存了所有的跨鏈交易內容，依據中繼鏈的特性我們採用了最終一致性的跨鏈事務機制，藉助中繼鏈的跨鏈事件表構建事務補償機制。這種方式能夠儘可能提高系統執行效率，同時保障跨鏈的安全性。
8.跨鏈效率怎麼樣？
從跨鏈平臺的架構來看，單條跨鏈交易的時間分為應用鏈A的發起交易確認時間+中繼鏈的驗證時間以及應用鏈B的確認時間，這裡我們設計上可控的是中繼鏈的時間最佳化，針對跨鏈交易的特殊性我們做了效率上的一系列最佳化方式：
採用高效能的規則驗證引擎，基於WASM構建驗證引擎；
對於不同鏈之間以及不同合約之間的跨鏈交易的簽名驗證、規則執行等透過並行處理；
由於跨鏈交易的特殊性，跨鏈交易的儲存也採用檔案形式儲存，加快儲存效率；
企業版提供趣鏈自研高效能RBFT和NoxBFT共識演算法，可達數萬級別的TPS。
9.IBTP和IBC的區別是什麼？
IBTP目前在BitXHub專案中主要指代一種跨鏈資料格式，通用的鏈間傳輸格式。IBTP以一種最簡潔的方式定義了跨鏈訊息的必要元素，包括用於路由的來源和目的鏈ID，用於控制交易順序的索引資訊，跨鏈合約呼叫的編碼資訊，用於驗證的交易證明資訊以及協議的版本。IBTP格式遮蔽了具體應用鏈之間的差異，同時支撐跨鏈交易的轉換、驗證、路由、呼叫核心機制。
IBC是Cosmos專案提出的一整套跨鏈傳輸協議，包括了跨鏈訊息通訊中的資料中繼，資料隱私合規，可用性，流控，認證等等一些列的規定。BitXHub在設計之初採用了更加簡潔的IBTP的主要原因在於當時IBC還不夠完善，IBC最初僅對資金類跨鏈服務進行了細化和實現，不符合聯盟鏈對合約跨鏈的業務需求。
我們認為關於具體通訊協議的爭論其實是無意義的，當前跨鏈技術最重要的是解決問題是能不能work的問題。我們也相信未來鏈間通用的跨鏈協議一定會慢慢趨同，甚至會和網路通訊協議一樣最終形成共識。到那個時候跨鏈協議本身就不再重要，更加重要的是如何提供一個更加安全、高效、穩定的跨鏈服務，這也是BitXHub致力於努力的方向。
10.跨鏈未來在哪裡？
我們預測隨著跨鏈需求的越來越成熟，跨鏈相應的標準也會逐步完善和穩定，最終區塊鏈之間會形成類似TCP/IP的跨鏈協議。我們也無需進行無謂的跨鏈協議之爭，最終市場認可的應該還是怎麼樣的跨鏈實現更適合相應的跨鏈場景。大膽預測一下，未來的跨鏈產品應該如同今日的路由器，對於不同的場景可以選擇不同的跨鏈服務進行連線。例如在公網的場景下和在區域網的場景下我們選擇的網路路由器裝置的安全性、效能等各個方面會有不同的側重點。跨鏈服務也類似。但是有一點可以確認，隨著區塊鏈業務的不斷豐富，在整個區塊鏈行業中一定會形成萬鏈互聯的可信互鏈網形態。
