本文根據 Ethan Buchman 和 Federico Kunze Kullmer 的推特原文翻譯整理。

IBC 的工作機制

IBC 在 Cosmos 已經試驗啓動。 IBC 是什麼呢？ 就像我們在 Cosmos 中構建的所有內容一樣，IBC 是通用的，可擴展的分層協議。在這種情況下，是用於區塊鏈之間的數據包流傳輸。IBC 共有四層：客戶端，連接，通道，和數據包。

首先我們來說說第一層：客戶端。這些是其他區塊鏈的輕客戶端驗證程序。它們允許一個鏈與另一個擁有相同的輕客戶端相同的安全驗證的鏈去證明抬頭簽名和默克爾證明 （Merkle proofs）。IBC 定義一個通用的客戶端接口。這個客戶端接口可以針對每個不同的區塊鏈共識實施。我們目前有一個 Tendermint 客戶端，但 Polkadot，Celo 等公司客戶端還在開發中。IBC 也定義了一個「單機」客戶端，它允許單個公鑰或多重簽名像通過 IBC 連結的區塊鏈一樣工作。為了使 IBC 能夠正常工作，在一端的客戶必須用另一鏈包含抬頭和驗證人簽名（或等效證明）連續更新。客戶端還會處理不當行為的證據。

第二層是最簡單的一層，即連接層。連接層是兩個不同鏈上的客戶端上的客戶端之間持久的關係。當兩個鏈想要連接時，它們各自為另一個鏈安裝一個客戶端，然後用連接進行握手以表示在版本/ ID 達成協議。

第三層是通道。通道是數據包發送和接收發生的地方。許多通道可以在單個連接（每個通道都有自己的數據包）多路復用。客戶端在單個連接上更新以緩衝上面多個通道。

每個通道的末端都與一個「端口（Port）」有關聯，而且每個端口都應有一個所有者，其形式為 Cosmos-SDK 模塊或相關區塊鏈上的智能合約。因此通道是在不同區塊鏈上兩個模塊或合約之間的一個數據包。IBC 支持有序和無序的通道。它們很大程度與 TCP 和 UDP 相似。在通道上發送的數據包有機會超時和被確認。最後通道可以擴展去支持部分排序和其他通信語義。現在通道只能是「一跳（1-hop）」，這意味著通道兩邊的末端必須在區塊鏈上彼此直接連接。但是 IBC 將會擴展去支持「多重跳（multi-hop）」通道，這將需要一個路由基礎結構在 Cosmos Hub 中支持。

最後一層是數據包。數據包是在通道上發送的東西。數據包攜帶實際的應用程式級別數據而數據包管理者觸發應用程序邏輯。現在唯一完成的數據包類型是同質化通証傳輸，它允許代幣從一個鏈流到另一個鏈。代幣在一個鏈上被鎖定或解鎖，而憑證被鑄造/燒製。但是數據包具有很高的靈活性，並且正在開發更多類型的數據包。 IBC 實際上是一個可擴展的分佈式系統編程環境，其數據包類型及其處理程序是應用程序開發人員的基本 API。

IBC 應用開發

Cosmos 推出一個新協議，並且令其變成非常強大的應用程序開發平台。同質化通証傳輸僅僅只是一個開始。有關 IBC-native 非同質化通証（NFT），鏈間帳戶和跨鏈驗證的工作已經開始。鏈間帳戶允許您通過 IBC 從一個鏈上的另一個帳戶發送一個鏈上的任意交易。 您不必先移動硬幣，也不必擔心其他錢包- Cosmos Hub 上的錢包變得通用。

我們還在研究跨鏈驗證，該驗證再次在 IBC 上作為數據包協議實現。這將會提供「共享安全性」和「分片」的通用形式，使集線器上的驗證者可以選擇加入其他鏈上的驗證。 跨鏈驗證為新鏈的啟動和利用 Cosmos Hub 上已抵押的 ATOM 的安全提供了更簡單的途徑。但跨鏈驗證只是一個 IBC 的擴展，因此我們可以不同特點並進行分片實驗。我們還與 LazyLedger 合作， 研究 IBC 和 optimistic rollup 技術如何互相補充，把最佳的分散式可擴張性帶進區塊鏈的網絡。我們期望看到 IBC 上構建的分佈式系統原語：鎖，信號量，領導者選舉，甚至共識本身，都在多個區塊鏈上運行。IBC 真正開創了區塊鏈可組合性的一種新形式。Agoric 和 Confio 分別在 Javascript 和 WASM 的安全版本中引領了兼容 IBC 的智能合約潮流。敬請期待他們在 IBC 上的一些驚人的新 DeFi 開發！

中繼器（Relayer）

IBC 的最後一部分是中繼器。實際的鏈下流程，負責在鏈之間轉發 txs。Federico Kunze Kullmer 認爲中繼器是區塊鏈互相操作性的核心。

什麽是中繼器和它的流程

中繼器是將包含事務數據的數據包中繼到其他鏈的過程。如果你看過接力賽，IBC 上的接力棒就是數據包，每個短跑運動員都是接力的過程。在之前的文章，我曾提到 IBC 沒有關於整個網絡拓撲的上下文。然而，為了將給定的數據包傳輸到目標鏈，中繼器必須知道存在的連接路徑。

IBC 協議的網絡內容與你在高速公路上開車時所看到的「風景」相同。另一方面， 中繼器可以為你提供鏈上所有路線的“鳥瞰圖”。因為這個原因，中繼可以通過正確的連接路徑發送數據包去包裝代幣，從而防止代幣與其他 IBC 代幣不可替換。這就是接力賽策略，而 IMO 是接力中最重要的那部分。因為它允許你選擇不同的替代方案來轉發數據包。你喜歡使用最便宜的（低收費），最短的（延遲小），還是最安全的路徑？

中繼器工作機制

現在，中繼器通過運行連接的輕客戶端來工作。它使兩個鏈保持更新，以此跟蹤彼此的最新客戶端和共識狀態，從而確認數據包的證明驗證有效。它還通過監聽鏈的事件來轉發數據包。中繼器還允許通過握手來初始化新鏈的連接和鏈狀態中能夠解碼數據包（通道）的獨立部分。中繼器可以為最終用戶提供大量的 UX 抽象，並為網絡中所有互相連結的鏈提供各種 APIs。所有的錢包和交易將會被連接到這些 APIs，而不是連接到每個單獨的鏈。

Ethan Buchman 說到 IBC 得組建在 ICS repo 中被指定為「鏈間標準」或 ICSs。 所以客戶端接口是 ICS02，連接是 ICS03，有序和非有序通道是 ICS07， Polkadot 的 GRANDPA 客戶端是 ICS10，等等。在 TLA+ 中， 我們也有幾乎整個 IBC 協議的正式規範。這有助於我們清楚地理解協議。但是我們也可以使用 Apalache 去從證實規範中自動生成代碼測試。正在使用 Apalache 模型檢查器正式驗證 IBC 的屬性。與此同時，Informal Systems 在 Stargate 發版中的協議和 Go 代碼進行了審核。

IBC 是一個巨大的合作成果，主要是在 Interchain Foundation，Informal Systems，Agoric，iqlusion 之間，並得到 Tendermint， Confio，Jack Zampolin 等人的大量幫助。特別感謝 Christopher Goes 在過去兩年領導這個項目！我們很期待看到其他人將會在 IBC 上構建什麼，以及區塊鏈的互聯網將如何演變。但這僅僅是個開始！