BuidlerDAO：全面解讀Cosmos跨鏈通信網絡的“中央郵局” IBC

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

作者：貓老大

編排：@Coucou

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

TL；DR

▪ IBC 不僅解決了區塊鏈互操作性問題，而且以信任最小化、安全、可擴展和通用的方式實現了跨區塊鏈進行任意數據傳輸。 「任意數據」包括資產的跨鍊和信息的跨鏈，比如代幣和NFT 資產的轉移，也可以在使用一條區塊鏈的同時管理另一條鏈上的賬戶，還可以從其他鏈上查詢信息，等等。

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

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

▪實現IBC 的信任最小化的核心“輕客戶端”，對於小團隊來說這是一項艱鉅的開發工作。跨鏈安全將允許其他區塊鏈從Cosmos Hub “租用”安全性，而不用建立和維護自己鏈的驗證節點。

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

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

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

目錄

01/引言

02/ IBC是什麼？

03/ IBC 解決了什麼問題？

04/ IBC 是如何工作的？

05/ IBC的安全性如何？

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

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

08/ IBC 可視化工具

09/ 結語

10/ 附錄：開發者資源

11/ 參考資料

引言

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

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

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

隨著多鏈生態的發展，IBC 不僅支持Cosmos 生態區塊鏈的跨鏈通信，也正在與其他區塊鏈生態互聯互通，如Composable Finance 正在將IBC 帶到Polkadot & NEAR，Electron 使用zkProof 將IBC 帶到以太坊等等。

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

IBC 是什麼？

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

Cosmos 生態系統的基礎設施主要有七個團隊為其開發貢獻，其中IBC 協議規範是由Interchain GmbH 團隊領導的。該規範描述了支持IBC 的鏈所需的數據結構和接口，包括IBC 核心協議和基於IBC 的應用程序，並整合為一套跨鏈標準(ICS)。

IBC 解決了什麼問題？

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

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

IBC 是如何工作的？

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

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

兩個區塊鏈之間IBC數據包流，圖源：the-interchain-foundation 

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

傳輸層

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

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

輕客戶端

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

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

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

中繼器

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

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

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

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

連接（Connection）

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

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

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

 Connection State 圖源：interchainacademy

通道（channel）

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

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

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

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

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

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

 Channel Handshake 圖源：interchainacademy

數據包的傳輸流程

在上述內容中，分別介紹了傳輸層的關鍵組件，輕客戶端、中繼器、連接和通道都是如何工作的。那麼，一個將要跨鏈的數據包是如何被傳輸的呢？

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

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

鏈A 中的APP A 調用sendPacket 向鏈B 中的APP B 發送一個數據包，鏈A 的核心IBC a 提交數據包更新自己的狀態，中繼器監測到這個數據包並向鏈B 的核心IBC b發送消息。在這個過程裡，核心IBC a 和核心IBC b 會進行各種驗證，驗證數據包確實由鏈A 發送的，數據包的順序是否正確，數據包的消息證明是否有效，等等。如果核心IBC 驗證成功，這個數據包到達APP B。 APP B 從核心IBC 接收到數據包後，會將其按照預期結構解包，然後走相應的應用邏輯。在處理完數據包之後，同時也會給鏈A 一個回執。

在IBC協議中的數據包結構裡，規定了超時時間戳（TimeoutTimestamp）和超時塊高度（TimeoutHeight），如果數據包到達鏈B 的時間超時了，則該數據包不會被處理。而鏈A 在發送的數據包超時後還沒有收到回執，就會對數據包的狀態做回滾操作，比如，代幣轉移的應用將會取消託管鎖定的代幣等等。

應用層

應用層是與最終用戶交互的地方。它是基於傳輸層構建的各種應用程序，負責處理來自傳輸層通道的數據包。目前用的比較多的IBC 應用是跨鏈代幣轉賬和跨鏈賬戶。

跨鏈代幣轉賬

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

跨鏈代幣轉賬應用邏輯，圖源：interchainacademy 

 IBC token transfer on Mintscan，圖源：interchainacademy

跨鏈賬戶

遵循ICS-27，基於IBC 構建的跨鏈賬戶管理協議。同時啟用了ICS-27 的鏈可以在對方鏈上通過編程創建賬戶，並通過IBC 發送數據包來控制這些賬戶，而不必使用私鑰簽名。跨鏈賬戶允許區塊鏈之間不僅是交換數據，而且可以寫入狀態。跨鏈賬戶包含普通賬戶的所有功能（即質押、發送、投票），它通過IBC 由單獨的鏈管理，即控制鏈（controller chain）。控制鏈上的賬戶具有對主鏈（host chain）上的賬戶的完全控制權。

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

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

跨鏈賬戶，圖源：interchainacademy

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

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

IBC 的安全性如何？

Cosmos 生態主要的七個開發團隊中，Informal Systems Team 主要負責安全性審查。 IBC 協議規範、協議審查和基於模型的測試都是由這個團隊來做的。

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

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

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

故障隔離機制

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

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

眾所周知，Terra 鏈穩定幣Luna 幾乎歸零，在這次危機中，雖然生態中有區塊鏈受到了影響，但多數都是經濟模型上的影響，而安全性方面使用了IBC 協議也經受住了考驗。

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

IBC 如何利用其他非Cosmos 鏈？

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

1. IBC 傳輸層的實現
2. 鏈上的輕客戶端的實現，用於跟踪要連接的交易對手鍊。 （交易對手鍊的輕客戶端在本鏈技術架構下的實現）
3. 基於鏈的共識類型的輕客戶端的實現，將用到交易對手鍊上

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

使用IBC 的應用鏈有哪些？

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

截至Q3，Cosmos 生態系統的TVL，圖源：CosmosATOMDaily Twitter

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

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

Osmosis – Cosmos 上的頂級DEX

鏈接： https://osmosis.zone/

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

在IBC 統計數據中，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 數據，圖源：CosmosATOMDaily Twitter

Kava – Cosmos的首個DeFi平台

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

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

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

 Kava 生態系統TVL，圖源：CosmosATOMDaily Twitter

Secret – Cosmos生態的隱私鏈

鏈接： https://scrt.network/

Secret 網絡是第一個可定制隱私區塊鏈。用戶可以選擇分享什麼，與誰分享，以及如何分享。這保護了用戶，並使開發人員能夠構建更好的Web3。

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

圖源：CosmosATOMDaily Twitter

Juno Network – Cosmos生態的跨鏈智能合約平台

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

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

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

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

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

IBC 可視化工具

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

MapOfZones

Cosmos 網絡瀏覽器。可以直觀的看到Cosmos 生態網絡下各個鏈之間的連接關係和當前的活動信息，包括：IBC 轉賬次數、IBC 交易量、成功率、成交量、交易量等等。

 https://mapofzones.com/home 

 zones/osmosis-1/peers

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

Mintscan

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

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

IOBScan

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

 https://ibc.iobscan.io/home

結語

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

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

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

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

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

附錄：開發者資源

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

Cosmos SDK：構建特定應用區塊鏈的框架

獲取： https://docs.cosmos.network/main

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

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

Cosmos Hub： Cosmos 網絡上第一個互連的公共區塊鏈

獲取： https://hub.cosmos.network/

IBC：用於跨鏈通信的行業標準協議

獲取： 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