由 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 驗證器。

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

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 的原理和優勢

AdaptiveIBC異構鏈跨鏈技術路線的關鍵，在於將 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

免責聲明：本文僅供參考，不得被用作法律、稅務、投資、理財或任何其他建議。