原文：《Buidler DAO 一文讀懂IBC：Cosmos 跨鏈通信協(xié)議》

編排：@Coucou

注：文章僅代表作者個人觀點，不構(gòu)成任何投資建議。

TL；DR

? IBC 不僅解決了區(qū)塊鏈互操作性問題，而且以信任最小化、安全、可擴展和通用的方式實現(xiàn)了跨區(qū)塊鏈進行任意數(shù)據(jù)傳輸?！溉我鈹?shù)據(jù)」包括資產(chǎn)的跨鏈和信息的跨鏈，比如代幣和 NFT 資產(chǎn)的轉(zhuǎn)移，也可以在使用一條區(qū)塊鏈的同時管理另一條鏈上的賬戶，還可以從其他鏈上查詢信息，等等。

? IBC 協(xié)議的獨特之處是它采用分層設計，傳輸層和應用層來實現(xiàn)整個工作流程。傳輸層(TAO：transport layer) 提供必要的基礎設施來建立安全連接和驗證區(qū)塊鏈之間的數(shù)據(jù)包。應用層（application layer）建立在傳輸層之上，它定義了數(shù)據(jù)包應該如何被發(fā)送鏈打包、以及如何被接收鏈解包。

? IBC 的安全性是基于 IBC 輕客戶端，不需要額外的信任第三方。使用基于源鏈的輕客戶端也意味著其安全性與其區(qū)塊鏈底層的安全性假設基本一致。

?實現(xiàn) IBC 的信任最小化的核心“輕客戶端”，對于小團隊來說這是一項艱巨的開發(fā)工作?？珂湴踩珜⒃试S其他區(qū)塊鏈從 Cosmos Hub “租用”安全性，而不用建立和維護自己鏈的驗證節(jié)點。

?雖然 IBC 源自 Cosmos，但是它也可以用于其他鏈（未基于 Cosmos SDK 構(gòu)建），甚至與 Tendermint 完全不同的共識也可以。只是這需要基于鏈的共識類型和區(qū)塊鏈框架，開發(fā) IBC 所需要的不同的組件。

? IBC 可視化工具：MapOfZones 更直觀的展示了鏈與鏈互連通道；Mintscan 更詳細的展示了中繼器的相關(guān)信息；IOBScan 更便捷的可以通過交易哈希進行搜索。

全文 9638字，預計閱讀時間 24 分鐘

目錄

01/引言

02/ IBC是什么？

03/ IBC 解決了什么問題？

04/ IBC 是如何工作的？

05/ IBC的安全性如何？

06/ IBC如何用于其他非Cosmos鏈？

07/ 使用IBC的應用鏈有哪些？

08/ IBC 可視化工具

09/ 結(jié)語

10/ 附錄：開發(fā)者資源

11/ 參考資料

引言

互聯(lián)網(wǎng)促進了世界上不同地區(qū)不同類型計算機之間的相互通信，TCP/IP 的簡單性和靈活性使它成為了標準 Internet 通信協(xié)議，被用于計算機、服務器、手機，甚至是小型物聯(lián)網(wǎng)設備。Cosmos 被譽為“區(qū)塊鏈互聯(lián)網(wǎng)”，IBC 就是區(qū)塊鏈互聯(lián)網(wǎng)中的 “TCP/IP” 協(xié)議。它提供了一種無需許可的方式在區(qū)塊鏈之間中繼數(shù)據(jù)包，實現(xiàn)區(qū)塊鏈之間的相互通信。

圖源：https://www.youtube.com/watch?v=yR4ORIQICYs

IBC 自推出以來已經(jīng) 18 個月，它已成為安全、可互操作、跨鏈通信的標準。截至目前，IBC 已在超過 48 條活躍鏈中實現(xiàn)了超過 4300 萬次跨鏈轉(zhuǎn)賬，擁有三百多萬用戶。

隨著多鏈生態(tài)的發(fā)展，IBC 不僅支持 Cosmos 生態(tài)區(qū)塊鏈的跨鏈通信，也正在與其他區(qū)塊鏈生態(tài)互聯(lián)互通，如 Composable Finance 正在將 IBC 帶到Polkadot & NEAR，Electron 使用 zkProof 將 IBC 帶到以太坊等等。

本文將對 IBC 跨鏈通信協(xié)議進行詳細解讀，包括工作原理、關(guān)鍵應用、可視化工具以及安全性討論。

IBC 是什么？

IBC（Inter-Blockchain Communication）是一種通用的互操作性協(xié)議，它支持兩個不同的區(qū)塊鏈互相通信，而無需信任中間的任何人。IBC 不僅可以用于基于 Cosmos SDK 開發(fā)的區(qū)塊鏈，也可以用于其他區(qū)塊鏈，如以太坊、Polkadot 等。

Cosmos 生態(tài)系統(tǒng)的基礎設施主要有七個團隊為其開發(fā)貢獻，其中 IBC 協(xié)議規(guī)范是由 Interchain GmbH 團隊領導的。該規(guī)范描述了支持 IBC 的鏈所需的數(shù)據(jù)結(jié)構(gòu)和接口，包括 IBC 核心協(xié)議和基于 IBC 的應用程序，并整合為一套跨鏈標準(ICS)。

IBC 解決了什么問題？

一句話概括，IBC 解決了“跨鏈通信”的問題?；ヂ?lián)網(wǎng)使信息可以在世界各地輕松流動。同樣，不同區(qū)塊鏈之間的信息也需要跨多個平臺的自由訪問。當用戶想要使用區(qū)塊鏈 A 的穩(wěn)定幣，通過區(qū)塊鏈 B 的去中心化交易所(DEX) 的流動性池 (LP) 產(chǎn)生收益。這就需要鏈之間的互操作性來實現(xiàn)。

IBC 不僅解決了互操作性問題，而且以信任最小化、安全、可擴展和通用的方式實現(xiàn)了跨區(qū)塊鏈進行任意數(shù)據(jù)傳輸?！溉我鈹?shù)據(jù)」包括資產(chǎn)的跨鏈和信息的跨鏈，比如代幣和NFT資產(chǎn)的轉(zhuǎn)移，也可以在使用一條區(qū)塊鏈的同時管理另一條鏈上的賬戶，還可以從其他鏈上查詢信息，等等。

IBC 是如何工作的？

IBC 協(xié)議的獨特之處是它采用分層設計，傳輸層和應用層來實現(xiàn)整個工作流程。傳輸層(TAO：transport layer) 提供必要的基礎設施來建立安全連接和驗證區(qū)塊鏈之間的數(shù)據(jù)包。應用層（application layer）建立在傳輸層之上，它定義了數(shù)據(jù)包應該如何被發(fā)送鏈打包、以及如何被接收鏈解包。

一個容易理解的類比： IBC 的工作原理類似郵件傳遞系統(tǒng)。當你通過郵政服務向某人發(fā)送一封信，這個郵政服務會把裝有信件的信封存入收件人的郵箱。然后收件人打開信封并閱讀你的信。IBC 的傳輸層可以被認為是郵政服務。郵政服務根本不關(guān)心信的內(nèi)容是什么。它只執(zhí)行從 A 點收取信封并發(fā)送到 B 點的動作。信封本身可以看作是從一條鏈發(fā)送到另一條鏈的 IBC 數(shù)據(jù)包。在這個信封上，你寫了收件人的地址，這相當于 IBC 的數(shù)據(jù)包里包含發(fā)件人和收件人信息。最后，收件人（應用程序）收到信（數(shù)據(jù)包）打開它并閱讀其中的內(nèi)容。

兩個區(qū)塊鏈之間IBC數(shù)據(jù)包流，圖源：the-interchain-foundation

IBC 各組件間工作流程，圖源：the-interchain-foundation

傳輸層

需要跨鏈的消息被打包在數(shù)據(jù)包（packet）中，傳輸層負責傳輸、驗證和排序這些數(shù)據(jù)包。在傳輸層，不關(guān)心數(shù)據(jù)包里面是什么，也不關(guān)心接收鏈怎么解碼這個數(shù)據(jù)包。從傳輸層的角度來看，數(shù)據(jù)包中的信息只是隨機字節(jié)。

傳輸層的關(guān)鍵組件是輕客戶端、中繼器、連接和通道。

輕客戶端

負責驗證數(shù)據(jù)包中的消息證明。輕客戶端是運行完整節(jié)點的輕量級替代方案。與完整節(jié)點不同，它不存儲所有區(qū)塊數(shù)據(jù)也不執(zhí)行交易。相反，他們只驗證區(qū)塊頭。IBC 輕客戶端實際上是某個區(qū)塊鏈中的一種驗證算法，用于跟蹤另一個區(qū)塊鏈的狀態(tài)變化（時間戳、根哈希、下一個驗證節(jié)點集哈希），這節(jié)省了空間并提高了處理共識狀態(tài)更新的效率。

也就是說，使用 IBC 交互的兩條獨立區(qū)塊鏈 A 和 B 具有彼此交易對手鏈的輕客戶端。比如，鏈 A 上有個鏈 B 的輕客戶端，當鏈 A 想與鏈 B 通信某個消息 X 的時候，它會將包含消息X的區(qū)塊的塊頭和消息證明的數(shù)據(jù)包發(fā)送給鏈 B。然后鏈 B 使用接收到的數(shù)據(jù)包進行加密驗證以確定鏈 A 執(zhí)行了消息 X。反之亦然。

IBC 安全模型是基于輕客戶端的而不是鏈。也就是說，IBC 協(xié)議并不關(guān)心鏈的信息，只要 IBC 輕客戶端保持著有效的共識更新可以對 Merkle 證明進行驗證就可以。這類似 IP 地址和 DNS，其中 IP 地址是 IBC 的 clientID，而 DNS 是 chainID。

中繼器

在 IBC 中，區(qū)塊鏈彼此間不會通過網(wǎng)絡直接互相傳遞消息，而是依賴中繼器進行通信。中繼器是鏈下進程，負責監(jiān)視運行 IBC 協(xié)議的每條鏈的狀態(tài)，并將更新的數(shù)據(jù)包中繼給交易對手鏈。如上一段的例子，當 A 向 B 發(fā)送消息 X，A 會在其狀態(tài)機中提交或存儲包含消息 X 的數(shù)據(jù)包的哈希值。當中繼器看到 A 在狀態(tài)機中提交了一條打算發(fā)送給 B 的消息 X 時，他們只需要拿起這條消息 X 并將其傳遞給 B。

中繼器負責來回發(fā)送數(shù)據(jù)包，不能修改數(shù)據(jù)包，也不對數(shù)據(jù)包進行任何驗證，因此不需要被信任。在建立連接和通道握手的時候，也需要使用中繼器。當連接的某一端的鏈試圖分叉或者其他惡意行為，中繼器也可以提交不當行為作為證據(jù)。

依賴中繼器通信存在一個缺陷：想象一下，如果每一對區(qū)塊鏈之間都運行中繼器，這將是非常復雜的，也及其浪費資源。所以 Cosmos Hub 為此而生，作為區(qū)塊鏈之間傳輸數(shù)據(jù)的樞紐。只需要在區(qū)塊鏈和 Cosmos Hub 之間運行一個中繼器，這個區(qū)塊鏈就可以與其他已經(jīng)連接到 Cosmos Hub 的區(qū)塊鏈彼此之間傳輸數(shù)據(jù)。

目前，鏈下中繼器的運營方式短期內(nèi)是可行的，但長期是不可持續(xù)的。對此，IBC 在跨鏈標準 ICS-29 中，提出了鏈上中繼激勵方法，包括三種不同的方式，費用中間件、費用補助、預算模塊。目的是希望為中繼者提供一個可持續(xù)的收入模式。

連接（Connection）

負責連接兩個不同鏈上的輕客戶端，通過四次握手驗證其各自交易對手的客戶端是否是正確的。簡單理解就是，在輕客戶端驗證數(shù)據(jù)包之前，連接先要對“輕客戶端”這個驗證者的身份進行驗證。這四次握手的所有操作都是由中繼器來觸發(fā)，并且在每次握手更新連接狀態(tài)之前，會先更新兩個鏈上彼此的輕客戶端的狀態(tài)，以保證其共識狀態(tài)是最新的。概述過程如下：

• 握手1 – OpenInit，從鏈A 發(fā)起的此握手將其連接狀態(tài)更新為 INIT
• 握手 2 – OpenTry，鏈B根據(jù)在其輕客戶端中鏈A的信息（算法和共識狀態(tài)的最后快照，包含最新高度的根哈希以及下一個驗證節(jié)點哈希），驗證鏈 A 的身份。同時還驗證交易對手鏈A是否擁有鏈 B 的身份信息。均驗證通過后，從鏈B發(fā)起這個握手將其連接狀態(tài)更新為 TRY
• 握手 3 – OpenAck，鏈 A 在其輕客戶端中驗證鏈B的身份，同時驗證鏈 B 上是否擁有鏈A的正確身份信息。都驗證通過后，從鏈A發(fā)起的此握手將其連接狀態(tài)更新為 OPEN
• 握手4 – OpenConfirm，鏈B 確認自我識別和交易對手識別都成功，將其連接狀態(tài)從 TRY 更新為 OPEN 握手結(jié)束，成功建立IBC 連接

從上述四次握手的描述可以看到，鏈A和鏈B互有其對手鏈的輕客戶端，在建立連接的過程中，各自驗證自己鏈的對手信息和對手鏈的自己的信息，來防止有惡意的冒充，驗證彼此互為彼此。

Connection State 圖源：interchainacademy

通道（channel）

IBC 中應用程序之間的通信是通過通道進行的，是在這些不同鏈上的應用程序模塊之間傳輸數(shù)據(jù)包的管道。一個連接可以有任意數(shù)量的關(guān)聯(lián)通道。但是，每個通道僅與一個連接 ID（ConnectionID）相關(guān)聯(lián)，這個 ConnectionID 用于識別輕客戶端，通道還有一個端口ID（PortID），用于識別連接通道的應用程序。

鏈上的應用程序模塊負責如何解碼和處理數(shù)據(jù)包數(shù)據(jù)。通道傳輸?shù)臄?shù)據(jù)包可以是有序的（ORDERED），由接收模塊按照發(fā)送的順序進行處理；也可以是無序的（UNORDERED），按照它們到達的順序進行處理。要強調(diào)的是，在大多數(shù)的應用中發(fā)送數(shù)據(jù)包時并不關(guān)心順序，所以可以以任何順序發(fā)送數(shù)據(jù)包以及任何順序接收它們。這尤其對于代幣轉(zhuǎn)移來說非常重要。因為如果一個數(shù)據(jù)包超時，就無法繼續(xù)再按順序接收它們，有序通道就會關(guān)閉。而且對于區(qū)塊鏈之間的通信來說，大多數(shù)時候都是異步的，很難保障其按發(fā)送的順序收到數(shù)據(jù)包。

與建立連接的方式類似，通道也是通過四次握手建立的，其中每一步都由中繼器發(fā)起。建立通道的握手過程如下：

• 握手 1 – ChanOpenInit，將鏈 A 設置為 INIT 狀態(tài)。此過程中，應用程序通過回調(diào)可能自定義一系列檢查，如端口是否正確、通道是否按預期順序、應用程序的版本是否一致，等等
• 握手2 – ChanOpenTry，鏈 B 若驗證鏈 A 狀態(tài)為 INIT，則將鏈 B 設置為 TRY 狀態(tài)
• 握手3 – ChanOpenAck，鏈 A 若驗證鏈 B 狀態(tài)為 TRY，則將鏈 A 設置為 OPEN 狀態(tài)
• 握手4 – ChanOpenConfirm，鏈 B 若驗證鏈 A 狀態(tài)為 OPEN，則將鏈B 設置為 OPEN 狀態(tài)

當鏈 A、鏈 B 的通道狀態(tài)都為 OPEN 時，通道建立成功。在每次握手中，都需要檢查應用程序版本一致性。因為數(shù)據(jù)包是由應用程序來解析的，如果應用程序版本不同，可能會導致解析數(shù)據(jù)包失敗。

注意，雖然握手流程相似，但連接（Connection）連接的是兩個區(qū)塊鏈。而通道（channel）連接的是兩個模塊。

Channel Handshake 圖源：interchainacademy

數(shù)據(jù)包的傳輸流程

在上述內(nèi)容中，分別介紹了傳輸層的關(guān)鍵組件，輕客戶端、中繼器、連接和通道都是如何工作的。那么，一個將要跨鏈的數(shù)據(jù)包是如何被傳輸?shù)哪兀?/p>

Packet Flow 圖源：https://ibcprotocol.org/

如上圖所示，有兩個數(shù)據(jù)包流程的示例，第一個是成功的數(shù)據(jù)包流程，第二個是超時情況下的流程。詳解如下：

鏈 A 中的 APP A 調(diào)用 sendPacket 向鏈 B 中的APP B 發(fā)送一個數(shù)據(jù)包，鏈 A 的核心 IBC a 提交數(shù)據(jù)包更新自己的狀態(tài)，中繼器監(jiān)測到這個數(shù)據(jù)包并向鏈 B 的核心 IBC b 發(fā)送消息。在這個過程里，核心 IBC a 和核心 IBC b 會進行各種驗證，驗證數(shù)據(jù)包確實由鏈 A 發(fā)送的，數(shù)據(jù)包的順序是否正確，數(shù)據(jù)包的消息證明是否有效，等等。如果核心 IBC 驗證成功，這個數(shù)據(jù)包到達 APP B。APP B 從核心 IBC 接收到數(shù)據(jù)包后，會將其按照預期結(jié)構(gòu)解包，然后走相應的應用邏輯。在處理完數(shù)據(jù)包之后，同時也會給鏈 A 一個回執(zhí)。

在IBC協(xié)議中的數(shù)據(jù)包結(jié)構(gòu)里，規(guī)定了超時時間戳（TimeoutTimestamp）和超時塊高度（TimeoutHeight），如果數(shù)據(jù)包到達鏈 B 的時間超時了，則該數(shù)據(jù)包不會被處理。而鏈 A 在發(fā)送的數(shù)據(jù)包超時后還沒有收到回執(zhí)，就會對數(shù)據(jù)包的狀態(tài)做回滾操作，比如，代幣轉(zhuǎn)移的應用將會取消托管鎖定的代幣等等。

應用層

應用層是與最終用戶交互的地方。它是基于傳輸層構(gòu)建的各種應用程序，負責處理來自傳輸層通道的數(shù)據(jù)包。目前用的比較多的 IBC 應用是跨鏈代幣轉(zhuǎn)賬和跨鏈賬戶。

跨鏈代幣轉(zhuǎn)賬

用戶可以跨支持 IBC 的鏈發(fā)送代幣，遵循跨鏈標準 20（ICS-20）。ICS-20（Interchain Standards -20）指定了數(shù)據(jù)包的結(jié)構(gòu)以及接收鏈如何解碼它們。通過在源鏈上托管代幣實現(xiàn)，托管證明和代幣元數(shù)據(jù)被中繼到目標鏈，由存儲在目標鏈上的輕客戶端驗證托管證明。如果驗證通過，將為目標鏈上的代幣生成憑證，并將確認發(fā)送回源鏈。還有一種情況是代幣從目標鏈轉(zhuǎn)移回源鏈，先由目標鏈銷毀代幣，然后源鏈釋放托管的代幣。

跨鏈代幣轉(zhuǎn)賬應用邏輯，圖源：interchainacademy

IBC token transfer on Mintscan，圖源：interchainacademy

跨鏈賬戶

遵循 ICS-27，基于 IBC 構(gòu)建的跨鏈賬戶管理協(xié)議。同時啟用了 ICS-27 的鏈可以在對方鏈上通過編程創(chuàng)建賬戶，并通過 IBC 發(fā)送數(shù)據(jù)包來控制這些賬戶，而不必使用私鑰簽名。跨鏈賬戶允許區(qū)塊鏈之間不僅是交換數(shù)據(jù)，而且可以寫入狀態(tài)?？珂溬~戶包含普通賬戶的所有功能（即質(zhì)押、發(fā)送、投票），它通過 IBC 由單獨的鏈管理，即控制鏈（controller chain）。控制鏈上的賬戶具有對主鏈（host chain）上的賬戶的完全控制權(quán)。

進一步解釋，為什么跨鏈賬戶不用密鑰簽名也可以實現(xiàn)普通賬戶的所有功能？簡單來說，通過控制鏈向主鏈發(fā)送帶有“編程指令”的 IBC 數(shù)據(jù)包，以編程的方式控制主鏈中的賬戶。

跨鏈賬戶還有一個特點是，它提升了跨鏈交互的體驗，它使用戶可以保持在同一界面上，而無感實現(xiàn)跨鏈的交互。

跨鏈賬戶，圖源：interchainacademy

除了上述的跨鏈代幣轉(zhuǎn)移和跨鏈賬戶之外，IBC 還有：

• 跨鏈安全（Interchain Security）:在 Cosmos 2.0 大會上被重點提出并升級。它使區(qū)塊鏈能夠從另一條鏈（如Cosmos Hub）租用安全，而不需要建立自己的驗證節(jié)點，只需要付出一點租用的費用就行。
• 費用中間件：遵循 ICS-29，用于激勵數(shù)據(jù)包中繼者。
• 跨鏈 NFT 傳輸：ICS-721，是一個應用層協(xié)議，可以允許基于 IBC 連接的區(qū)塊鏈（包括同構(gòu)鏈和異構(gòu)鏈）之間實現(xiàn)跨鏈 NFT 互操作。

 

IBC 的安全性如何？

Cosmos 生態(tài)主要的七個開發(fā)團隊中，Informal Systems Team 主要負責安全性審查。IBC 協(xié)議規(guī)范、協(xié)議審查和基于模型的測試都是由這個團隊來做的。

IBC 安全性的設計圍繞兩個主要原則

相信鏈（共識）而不是橋（第三方）

IBC 中數(shù)據(jù)包的驗證是由輕客戶端完成的。因此，IBC 的安全性取決于輕客戶端的安全性。也就是說在使用 IBC 在鏈間進行交互不需要額外的信任第三方，也是所謂“信任最小化”。使用基于源鏈的輕客戶端也意味著其安全性與其區(qū)塊鏈底層的安全性假設基本一致。

故障隔離機制

可以限制在這些鏈受到惡意行為影響時所造成的任何損害。

在 Tendermint 中，需要鏈的快速確定性（即交易被快速打包且無法撤銷或更改），也是 IBC 的先決條件，因此原則上不應發(fā)生分叉的情況。如果在使用 IBC 跨鏈通信中的一個鏈出現(xiàn)惡意行為，中繼器可以提交不當行為證明，另一條鏈上的輕客戶端會被凍結(jié)。在攻擊被消除后，可以通過治理建議解凍輕客戶端，從而收回資金。

眾所周知，Terra 鏈穩(wěn)定幣 Luna 幾乎歸零，在這次危機中，雖然生態(tài)中有區(qū)塊鏈受到了影響，但多數(shù)都是經(jīng)濟模型上的影響，而安全性方面使用了 IBC 協(xié)議也經(jīng)受住了考驗。

與跨鏈橋相比，IBC 的信任最小化使安全性更高。但是也有其缺陷，實現(xiàn) IBC 的信任最小化的核心“輕客戶端”，對于小團隊來說這是一項艱巨的開發(fā)工作。在 Cosmos2.0 白皮書中提到了“跨鏈安全”或許可以解決這一難題。跨鏈安全將允許其他區(qū)塊鏈從 Cosmos Hub “租用”安全性，而不用建立和維護自己鏈的驗證節(jié)點?？梢岳斫鉃?，Cosmos Hub是供應商鏈，其他應用鏈是消費者鏈，供應商鏈為消費者鏈生成區(qū)塊，而消費者鏈向供應商鏈及其驗證者發(fā)放區(qū)塊獎勵。對于小團隊來說，使用跨鏈安全可以減少早期承擔過多的技術(shù)負擔，又同時可以保障其區(qū)塊鏈的安全性。

IBC 如何利用其他非 Cosmos 鏈？

雖然 IBC 源自 Cosmos，但是它也可以用于其他鏈（未基于 Cosmos SDK 構(gòu)建），甚至與 Tendermint 完全不同的共識也可以。但是這需要基于鏈的共識類型和區(qū)塊鏈框架，開發(fā) IBC 所需要的不同的組件，比如：

1. IBC 傳輸層的實現(xiàn)
2. 鏈上的輕客戶端的實現(xiàn)，用于跟蹤要連接的交易對手鏈。（交易對手鏈的輕客戶端在本鏈技術(shù)架構(gòu)下的實現(xiàn)）
3. 基于鏈的共識類型的輕客戶端的實現(xiàn)，將用到交易對手鏈上

如前所述，開發(fā)這些組件不是一件簡單的事情。在跨鏈基金會（ICF）的支持下，正有一些開發(fā)團隊，將 IBC 用于 Bitcoin、以太坊、Polkadot 等。

使用 IBC 的應用鏈有哪些？

自 2021 年 4 月 Cosmos 推出區(qū)塊鏈跨鏈通信協(xié)議（IBC）以來，Cosmos 區(qū)塊鏈互聯(lián)網(wǎng)正在快速發(fā)展。從 IOBScan 上的數(shù)據(jù)來看，截止到目前，通過 IBC 連接的應用區(qū)塊鏈已達 53 條，活躍鏈 48 條，已經(jīng)發(fā)生了 920 萬筆 IBC 交易。IBC 的成功實施吸引了更多用戶加入 Cosmos，這使得整個生態(tài)系統(tǒng)都跟著受益。

截至Q3，Cosmos 生態(tài)系統(tǒng)的TVL，圖源：CosmosATOMDaily Twitter

Kava 以 2.912 億美元的 TVL 排名第一，Osmosis，TVL 為 2.09 億美元。排名第二，Thorchain 以 1.0585 億美元排名第三

深入了解使用 IBC 的應用鏈，可以掌握未來對 Cosmos 生態(tài)投資的主動性。以下簡單介紹使用 IBC 的 Cosmos 生態(tài)項目，數(shù)據(jù)均來自“Cosmos Ecosystem – Q3 2022 Quarterly Report”。

Osmosis – Cosmos 上的頂級 DEX

鏈接：https://osmosis.zone/

Osmosis 的 TVL 為 2.09 億美元，在 Cosmos 生態(tài)系統(tǒng)中排名第二。Osmosis 始終提供高流動性的流動池，是 Cosmos 生態(tài)首選。

在 IBC 統(tǒng)計數(shù)據(jù)中，Osmosis 一直是排名第一的，在第三季度，30 天 IBC 的交易額每個月都在增長。9 月，Osmosis 的 IBC 總交易額為 4.6873 億美元，目前有 46 個 peers 和 174 個channels。此外，Osmosis 擁有 62,027 名 IBC 月活躍用戶，占整體 MAU 的 45.4%。

Osmosis 流動性最高的頂級流動池，圖源：CosmosATOMDaily Twitter

2022 年 9 月Osmosis IBC 數(shù)據(jù)，圖源：CosmosATOMDaily Twitter

Kava – Cosmos的首個DeFi平臺

鏈接：https://www.kava.io/

Kava Network 是一個 Layer1 區(qū)塊鏈，其提出的“co-chain“的架構(gòu)可以支持以太坊 EVM 和 Cosmos 的跨鏈流動。其致力于為產(chǎn)品應用和開發(fā)者們提供無門檻的永久性金融服務基礎設施。同時，其團隊打造的 Kava DApp 是 Cosmos 上首個 DeFi 平臺，類似 MakerDAO，提供主流數(shù)字資產(chǎn)抵押貸款及穩(wěn)定幣的跨鏈去中心化金融服務。

目前，Kava 的 TVL 為2.912億美元，在 Cosmos 生態(tài)系統(tǒng)中排名第一，超過了 Near Protocol。此外，SushiSwap 和 Curve 都已經(jīng)宣布部署到 Kava。

Kava 生態(tài)系統(tǒng)TVL，圖源：CosmosATOMDaily Twitter

Secret – Cosmos生態(tài)的隱私鏈

鏈接：https://scrt.network/

Secret 網(wǎng)絡是第一個可定制隱私區(qū)塊鏈。用戶可以選擇分享什么，與誰分享，以及如何分享。這保護了用戶，并使開發(fā)人員能夠構(gòu)建更好的 Web3。

Secret 目前正在使用 CosmWasm 0.10 版，隨著 Shockwave Delta 主網(wǎng)升級將升級到 CosmWasm1.0 版。借助 CosmWasm1.0，Secret 智能合約可以在 IBC 協(xié)議的幫助下在多個鏈上運行。

圖源：CosmosATOMDaily Twitter

Juno Network – Cosmos生態(tài)的跨鏈智能合約平臺

鏈接：https://www.junonetwork.io/

Juno 是 Cosmos 官方團隊開發(fā)的，一個可互操作的智能合約網(wǎng)絡，可部署 DApp。與以太坊 EVM 使用Solidity智能合約不同，基于Juno 的智能合約是使用CosmWasm的。

很多人吐槽 Juno，如果要做 DAPP 可以去以太坊何必來 Juno 呢？其實，Juno 可能更多的是 Cosmos 官方團隊用于生態(tài)發(fā)展的實踐產(chǎn)品，就像在 Osmosis 之前，Cosmos 官方團隊開發(fā)了Gravity DEX，被Osmosis后來者居上后就關(guān)閉了。而且由于 Cosmos SDK 模塊開發(fā)比較容易上手，選擇 Juno 上構(gòu)建 DApp 也可以享受到 Cosmos 生態(tài)的助力，很多小型 DApp 產(chǎn)品選擇 Juno 很有優(yōu)勢。

Juno Network 的 dApp 和工具，圖源：CosmosATOMDaily Twitter

Cosmos 生態(tài)是一個區(qū)塊鏈互聯(lián)網(wǎng)，而 IBC 擔負著“跨鏈通信”的職責，這類似Web2互聯(lián)網(wǎng)中的“TCP/IP”。Osmosis（DEX）、KAVA（DEFI）、Secret（隱私）、Juno（智能合約DApp），都是一個個獨立的區(qū)塊鏈，他們的發(fā)展方向各有不同，但是他們都使用了 IBC，加強了彼此的互操作性可組合性，使得生態(tài)中的用戶不斷增加，彼此受益。

IBC 可視化工具

推薦三個 IBC 網(wǎng)絡的可視化工具，可以查看 IBC 網(wǎng)絡中的鏈（hub&zone）、連接、通道、交易的信息，也可以幫助選擇中繼器。

MapOfZones

Cosmos 網(wǎng)絡瀏覽器。可以直觀的看到 Cosmos 生態(tài)網(wǎng)絡下各個鏈之間的連接關(guān)系和當前的活動信息，包括：IBC 轉(zhuǎn)賬次數(shù)、IBC 交易量、成功率、成交量、交易量等等。

https://mapofzones.com/home

zones/osmosis-1/peers

如上圖所示，MapOfZones 還可以展示鏈與鏈之間的連接列表。同時還可以看到所選鏈與其它鏈之間的通道信息。

Mintscan

也是 Cosmos 網(wǎng)絡瀏覽器。Mintscan 的特點是除了基本 Cosmos 生態(tài)網(wǎng)絡鏈與鏈之間的關(guān)系和 IBC 信息的展示之外，還可以在詳細頁面中看到連接、發(fā)送/接收交易、中繼器交易歷史和中繼器交易量的信息，其對中繼器的信息展示的非常詳細。

https://www.mintscan.io/osmosis/relayers/channel-0

IOBScan

與前兩個類似，也是 Cosmos 網(wǎng)絡瀏覽器。IOBScan 的一個特點是，可以通過交易哈希進行搜索。

https://ibc.iobscan.io/home

結(jié)語

未來是多鏈共存的，這幾乎已經(jīng)成為加密圈內(nèi)的共識。但未必是跨鏈的，這是當下還存在疑慮的。當可以將所有應用程序都放在一個通用鏈上時，為什么還要有多個區(qū)塊鏈呢？畢竟，在一條鏈上擁有多個應用程序使它們更容易通信和共享數(shù)據(jù)。

其原因有兩方面，一方面是資源競爭，區(qū)塊鏈上的區(qū)塊空間是有限的，應用程序在同一個區(qū)塊鏈上自然免不了要彼此競爭。另一方面是專業(yè)化。應用程序存在于通用鏈上必須適應通用鏈的功能，如果想要開發(fā)獨特的功能或許會受限于通用鏈的底層設施。而為某一類應用類型而定制的區(qū)塊鏈可以更好的優(yōu)化性能、安全、主權(quán)等等。所以，既然應用區(qū)塊鏈的發(fā)展是必然的，那么應用鏈與通用鏈之間、應用鏈與應用鏈之間，跨鏈通信、跨鏈組合也是必然的。只是當下，區(qū)塊鏈基礎設施還不完善，各項技術(shù)還處于發(fā)展中，所以很難說在跨鏈技術(shù)方面，哪一種是最佳的。

在 IBC 之前，跨鏈通信主要由跨鏈橋來實現(xiàn)。然而，在過去這半年由于一系列的黑客攻擊，這些跨鏈橋在過去幾個月中飽受爭議。與第三方跨鏈橋相比，IBC 提供了一個信任最小化的通信環(huán)境，通過使用輕客戶端加密驗證交易對手鏈的共識狀態(tài)。這使 IBC 跨鏈通信的安全性與每個區(qū)塊鏈底層的安全性基本一致。但是 IBC 的這種設計理念，以確保網(wǎng)絡安全性作為第一目標，當然會犧牲一部分的可擴展性和成本。輕客戶端的開發(fā)難度、部署成本，在一定程度上限制了 IBC 的可接入的鏈數(shù)量。當然，在跨鏈基金會（ICF）的支持下，已經(jīng)有一些開發(fā)團隊將 IBC 擴展到 Cosmos 以外的生態(tài)系統(tǒng)，相信這將進一步推進 IBC 協(xié)議的應用。

對于 Cosmos 生態(tài)來說，IBC 推動了其快速發(fā)展，成功的實現(xiàn)了 Cosmos “區(qū)塊鏈互聯(lián)網(wǎng)”的第一步“跨鏈互連”。隨著 Cosmos 2.0 的升級，如跨鏈安全、跨鏈調(diào)度、跨鏈分配，以及 ATOM 新的經(jīng)濟模型，這一系列組件環(huán)環(huán)相扣，使共享安全的落地成為可能。有了共享安全，應用鏈不需要自己實現(xiàn)共識機制、維護驗證節(jié)點，應用鏈可以更專注于與用戶交互的體驗和功能。同時，也將進一步的降低 Cosmos 應用開發(fā)難度，可以讓小團隊非常容易地創(chuàng)建新項目，對開發(fā)人員的友好一定會助力生態(tài)的繁榮。

由于時間和精力所限，本文只是簡單的介紹了 IBC 的實現(xiàn)原理和一些基本面信息。未來希望可以帶來更多 Cosmos 的內(nèi)容。

附錄：開發(fā)者資源

Cosmos SDK 的模塊化特性使開發(fā)人員不必關(guān)心一些抽象層，例如輕客戶端、連接、證明驗證等。對于應用開發(fā)人員來說，最相關(guān)的需求和功能是通道和端口。如下，一些開發(fā)者資源：

Cosmos SDK：構(gòu)建特定應用區(qū)塊鏈的框架

獲?。?/strong>https://docs.cosmos.network/main

Tendermint 核心：區(qū)塊鏈共識引擎及應用接口

獲取：https://docs.tendermint.com/

Cosmos Hub：Cosmos 網(wǎng)絡上第一個互連的公共區(qū)塊鏈

獲?。?/strong>https://hub.cosmos.network/

IBC：用于跨鏈通信的行業(yè)標準協(xié)議

獲?。?/strong>https://ibc.cosmos.network/main/ibc/overview.html

參考資料

[1] ELI5: What is IBC?

https://medium.com/the-interchain-foundation/eli5-what-is-ibc-a212f518715f

[2] Moving Relayer Incentives On-Chain: Fee Middleware, Fee Grant and Budget Modules

https://medium.com/the-interchain-foundation/moving-relayer-incentives-on-chain-fee-middleware-fee-grant-and-budget-modules-a956523d22ec

[3]Relaying The Message: A Deep Dive Into IBC Relayer Operations

https://medium.com/the-interchain-foundation/relaying-the-message-a-deep-dive-into-ibc-relayer-operations-6ff763a2a22f

[4] IBC: A Core Primitive for Interchain Native Products

https://medium.com/the-interchain-foundation/ibc-a-core-primitive-for-interchain-native-products-38d73519cd66

[5] IBC Beyond Light Clients: Solo Machine

https://medium.com/the-interchain-foundation/ibc-beyond-light-clients-solo-machine-fb55ba0b0234

[6] Cross-chain security models, compared

https://0xpostman.medium.com/part-2-cross-chain-security-models-compared-c4f91107cad4

[7] How Seven Teams Collaborated To Deliver The Biggest Software Upgrade In The Cosmos Universe

https://blog.cosmos.network/how-seven-teams-collaborated-to-deliver-the-biggest-software-upgrade-in-the-cosmos-universe-2288f4f9afe8

[8] Cosmos Ecosystem – Q3 2022 Quarterly Report

https://twitter.com/CosmosATOMDaily/status/1578069873078534144

[9] IBC Applications

https://ibcprotocol.org/applications/

[10] How IBC Works: Light Clients, Connections & Channels

https://www.youtube.com/watch?v=Z60PPZDz4Gc