詳解 Adaptive IBC 異構鏈跨鏈技術路線

作者：MiX

由 Cosmos 提出的 IBC 協議，採用鏈上原生輕客戶端/ light client 來驗證跨鏈消息，即跨鏈雙方都在自己的鏈上維護一個原生的、對側鏈的輕客戶端，從而最大限度地確保跨鏈數據的安全。

Cosmos SDK 為所有基於 tendermint 共識的區塊鏈提供了 tendermint 輕客戶端實現，所以 Cosmos 鏈之間的跨鏈體驗絲滑，但非 tendermint 共識的區塊鏈，也就是所謂的「異構鏈」，因為沒有對應輕客戶端的工程實現，所以 IBC 擴展到異構鏈的旅程舉步維艱。

2023年12月17日，章魚網絡開發的第二個異構鏈 IBC ------ NEAR-IBC 正式投入使用，從立項開發、到第三方審計直至正式上線，整個過程不足一年，這背後的功臣就是章魚網絡團隊提出的 Adaptive IBC 異構鏈跨鏈技術路線：通過對 IBC 技術架構的創新，彌補了 IBC 協議在異構鏈跨鏈的缺陷，極大地拓展了 IBC 協議的適應性：

1. 各種不同的共識機制的區塊鏈都可以採用 Adaptive IBC 技術路線，比如 Ethereum、NEAR Protocol 和 Polkadot 等等。
2. 極大降低了跨鏈成本，解決了 IBC 協議延伸到異構鏈最大的问题。
3. 可以適應各類驗證技術的進步，比如 ZK 技術一旦成熟，可以很方便的將代理客戶端升級為 ZK 驗證器。

Adaptive IBC 技術演進里程碑詳見文末附錄

|IBC 協議的基本原理及其優勢

Cosmos 團隊提出的 IBC（Inter-Blockchain Communication）協議是一個完全開源、通用的區塊鏈跨鏈互操作協議。

跨鏈技術方案的關鍵，在於其「互操作能力」和「安全性」。IBC 協議的「分層架構」和「開源策略」，讓 IBC 可以支持功能豐富、無需信任的跨鏈互操作，成為當之無愧的跨鏈協議的黃金標準。

1、分層架構：

IBC 將跨鏈拆分為「應用層/ Application」和「通訊層/ Channel」，其簡潔性和靈活性堪稱區塊鏈的 TCP/IP 協議，就如 IBC 官網自述：IBC 從構建互聯網的底層協議 TCP/IP 汲取了靈感。
圖1：IBC 是區塊鏈的 TCP/IP 協議

• 應用層是面向最終用戶的跨鏈互操作接口：包括 token 轉賬、鏈間賬戶和鏈間查詢等多個獨立的應用協議，這些應用協議具備可組合性，隨著應用協議的增加，跨鏈能力可以指數級的提高。
• 通訊層定義了數據跨鏈發送於接收，包括傳輸、驗證和排序，且傳輸數據內容是不可見。這其中，在源鏈的狀態機內的輕客戶端，是通訊層的關鍵，也成為了 IBC 的精髓所在。

圖2：IBC 技術架構

鏈 A 在自己的狀態機內有一個代表鏈 B 的輕客戶端，鏈 B 也有一個鏈 A 的輕客戶端，輕客戶端通過驗證區塊頭和 Merkle 證明來跟蹤對方區塊鏈的共識數據，從而驗證跨鏈交互的合法性。

跨鏈雙方之間有一個 Relayer，負責監視兩側區塊鏈產生的 Event，一旦收到 IBC Event 就會把它轉換為實際的 IBC message，傳遞到對面的鏈上。

簡單說，就是 IBC 協議首先建立兩個區塊鏈之間的安全通道，然後傳遞數據包/ Data Packets，輕客戶端驗證對方區塊鏈的共識信息，保證轉移的一致性和安全性。 所以，只要通訊層建立起來，整個 IBC 的跨鏈就是安全的。

2、技術開源

任何人都可以使用 IBC 協議，並且為其做出貢獻，IBC 協議內沒有抽佣或者隱藏費用。

跨鏈橋之所以安全問題頻發，說到底是因為用單一團隊的安全能力無法對抗整個黑客群體。只有使用共同的跨鏈開放協議，以開源的方式，借助開放社區共同的力量來持續迭代升級，才能讓整個行業的跨鏈安全能力持續進化。 Louis Founder of Octopus Network

圖3：IBC 跨鏈數據
數據來源：mapofzones.com

截至2024年1月15日，IBC 協議已經在107個區塊鏈上啟動，過去30天總交易量 $40+ 億，安全跨鏈交互800+萬次。當然，目前絕大多數跨鏈發生在 Cosmos SDK 區塊鏈之間。

與此同時，許多團隊正在努力將 IBC 協議延伸到其他生態系統，希望可以通過 IBC 實現與異構鏈的跨鏈交互，包括以太坊、波卡、NEAR Protocol Avalanche、Solana 和 Celestia rollups。

|IBC 擴展到異構鏈的難點

IBC 協議的架構基於輕客戶端，所以無需引入第三方的驗證服務，實現了無信任/ Trustless 跨鏈。尤其是在 Cosmos 鏈之間取得了安全性、成本和速度的極佳平衡，但是在延伸到異構鏈時，很多團隊都是肉眼可見的進展緩慢。

IBC 和 Tendermint 共識機制都是 Cosmos 團隊提出，所以 Cosmos SDK 從設計之初就對輕客戶端做了非常好的支持。

如果要在 Cosmos 鏈和非 Cosmos 鏈之間實現 IBC 協議，就需要在 Cosmos 鏈上實現對側的非 Cosmos 鏈的輕客戶端，並且在非 Cosmos 鏈上實現 tendermint 輕客戶端。因為異構鏈共識機制的不同，在實現過程中需要做大量 兼容性 工作，並引入相應的技術風險。

這也就讓異構鏈 IBC 在實現過程中面臨很多技術挑戰：

第一，異構鏈對 跨鏈 消息的驗證，成本高且會有計算資源限制/gas Limitation：

IBC 驗證跨鏈消息需要先驗證區塊頭，驗證區塊頭通常要驗證幾十上百個簽名，在鏈上用智能合約做這些計算成本非常高。另一方面，無論是以太坊、NEAR 乃至其他區塊鏈，都会對智能合約的可用計算量進行限制和規範。這就讓 IBC 在做驗證時容易遇到驗證簽名 gas 不夠的問題。

最近出現的零知識證明跨鏈，把很多簽名轉換成一個 ZK 證明，驗證 ZK 證明等效於驗證區塊頭的所有簽名，從而節省驗證成本。

第二，鏈上資產管理/ On-chain Asset Management 機制不同

Cosmos SDK 可以通過協議對鏈上資產進行註冊和操作，但在智能合約區塊鏈上不行，Fungible Token 數據都是由單獨的智能合約管理。

第三，虛擬機的沙盒限制/Sandbox Limitation

當前的智能合約區塊鏈都基於虛擬機，這種封閉可控的環境訪問宿主鏈的能力有限，比如智能合約就無法獲取鏈上共識狀態，又比如 NEAR 是異步鏈，共識狀態變化可能出現在智能合約調用的多個塊，更為複雜。

第四，鏈上存儲/ On Chain Storage 數據的規則不一樣

IBC 協議需要有較嚴格的存儲鍵值規則/Path Rule，再去鏈上獲取基於規則生成的存儲鍵值對應的密碼學的證明/Proof。

以上難點乃至更多的差異，開發團隊都要做額外的工程處理，勢必會極大地增加複雜度和 Bug 風險。

|Adaptive IBC 的原理和優勢

Adaptive IBC 異構鏈 跨鏈 技術路線的關鍵，在於將 IBC 協議的分層架構進行了創新，進一步拆分出「驗證層」，即引入「驗證代理/ Verification Proxy」部署在代理鏈（ ICP ）上，這樣跨鏈雙方只需要驗證「驗證代理」產生的 Proof，無需直接驗證對方鏈的區塊頭和全部簽名。

圖4：基於 Adaptive IBC 的 NEAR-IBC 架構

以 NEAR-IBC 為例：在代理鏈/ Proxy Chain 上部署了 Cosmos 和 NEAR 的驗證代理，維護對應鏈的共識，然後在跨鏈雙方再部署一個對方共識機制的代理客戶端，替換 IBC 原來的輕客戶端。

以 Cosmos 向 NEAR 跨鏈為例，當 Cosmos 向 NEAR 傳遞消息時，代理鏈上的 Cosmos 驗證代理/ Tendermint Verification Proxy 會驗證跨鏈消息，對它進行簽名生成一個 Proof，然後 NEAR 這一邊的 Cosmos 代理客戶端/ Tendermint Proxy Client 只需要驗證這個 Proof，就可以完成跨鏈的驗證。

圖5：跨鏈技術的安全性與拓展性

在安全性方面，雖然引入的驗證代理屬於外部驗證/ External Verification 方案，理論上安全性是略低於原生輕客戶端驗證的，但值得注意的是，相較原生輕客戶端驗證，總體安全性並沒有顯著降低。

因為 Adaptive IBC 建議將驗證代理部署在公鏈上，例如 NEAR-IBC 就是部署在公鏈 ICP 上，所以這種方式既保證了去中心化和公開可驗證，也保證了驗證代理和整個跨鏈系統的安全性。 5：跨鏈安全的兩種視角

只要跨鏈雙方有一條鏈的攻擊成本/ Attacking Cost 低於公鏈ICP ，驗證代理的引入就不會因為信任集合/ Trust Set擴大而損害安全性。 相比多簽或者其他各種外部驗證的跨鏈橋，安全等級都高得多。

由此可見，Adaptive IBC 的驗證代理架弥補了 IBC 協議在異構鏈跨鏈場景下的缺陷，並且從三個方面，極大地拓展了 IBC 協議的適應性：

1. 極大地降低跨鏈成本： 從驗證對方鏈區塊頭的幾十個上百個的全部簽名，變成只對驗證代理的1個簽名進行驗證，解決了 IBC 異構鏈跨鏈的最大痛點，即「驗證成本高且會有計算資源限制」的問題。

2. 可兼容各種共識機制： 驗證代理架構對跨鏈雙方不存在依賴關係，可以被各種不同共識機制的區塊鏈採用，比如 Ethereum、NEAR Protocol 和 Polkadot 等等，是名副其實的異構鏈跨鏈技術方案。

3. 可適應驗證技術發展： Adaptive IBC 從通訊層中，進一步拆分了「驗證層」並演化出驗證代理方案。分層架構的優勢之一就是降低整個系統互相之間的依賴，所以 Adaptive IBC 可以適應各類驗證技術的進步。

• Cosmos 如果能支持聚合簽名，或者 NEAR 支持了 ED25519 簽名的 Precompile，將大幅降低 NEAR Protocol 上直接驗證的成本，就可以把代理客戶端再次升級成真正可用的輕客戶端

• ZK 跨鏈技術一旦成熟，就可以把驗證代理換成ZK證明器，把代理客戶端升級為 ZK 驗證器。只需要通過社區治理進行投票，即可無縫切換進行升級，不影響應用層的使用和技術演進。

Adaptive IBC 是站在巨人的肩膀上，進一步發揚「分層架構」的優勢，設計了應用層、通訊層和驗證層的三層架構，讓驗證層可以單獨地去演進，不但能夠適應更多的區塊鏈的共識機制，而且可以隨著驗證技術的發展而擁抱可用的最好技術，** 适应未来逐步进化。**

|附錄

1、2020年，章魚網絡前身 Cdot 團隊獲得 Interchain 基金的 grant，開發 Substrate-IBC，即 ICS10。 2、2022年，Substrate-IBC 開發完成，成為全世界第一個在非 Cosmos 區塊鏈上實現 IBC 的團隊。 3、2022年10月，提出 Adaptive IBC 異構鏈跨鏈技術路線，並且啟動 NEAR-IBC 的開發。 4、2023年10月， NEAR-IBC 開發完成，並且由第三方安全團隊 Blocksec 完成審計。 5、2023年12月，Cosmos SDK 區塊鏈 Ottochain 採用 $NEAR Rstaking 共享安全服務，正式啟動運行。NEAR-IBC 作為其中的關鍵技術，驗證了 Adaptive IBC 異構鏈跨鏈技術路線的可行性和科學性。 6、2024年第一季度，隱私協議 Secret Network 將使用基於 Adaptive IBC 的NEAR-IBC，實現與 NEAR Protocol 之間的資產跨鏈。隨後，Octopus Network 將會與 Secret Network 繼續探索消息跨鏈技術，讓 NEAR 的智能合約可以直接調用 Secret Network 的隱私計算能力。 7、2024年，計劃啟動基於 Adaptive IBC 的 ETH-IBC 開發，目標是在以太坊和其他支持 IBC 的區塊鏈之間，成為第一個為用戶提供可負擔得起的 IBC 跨鏈體驗的團隊。

|參考資料

《The IBC Protocol 2023 Year in Review》Mary McGilvray
《Adaptive IBC ：異構鏈互操作性的顛覆者》Louis
《NEAR-IBC 介紹｜如何使用智能合約實現 IBC 協議》楊鎮
《NEAR will be a Cosmos zone SOON》Louis