1. 跨鏈流程

A鏈上的Alice發送10個ATOM代幣給B鏈上的Bob

step1. Tracking
A鏈上的IBC模塊會不斷的同步B鏈上的區塊頭信息，B鏈上的IBC同理。通過這種方式，雙方能夠實現跟蹤對方區塊鏈上的驗證者集合的變化，本質上來說，就是A鏈、B鏈相互維護了一個對方的輕節點。

step2.Bonding
當使用IBC初始化一筆跨鏈轉賬之后，A鏈上的10個ATOM事實上處于鎖定的狀態。

step3. Proof中繼
一份證明A鏈上已經鎖定10ATOM的“證據”會被路由到B鏈上的IBC模塊。

step4. 驗證
B鏈結合A鏈的輕節點信息，對這份“證據”驗證通過之后，B鏈上會“鑄造”10份ATOM Voucher（抵用券），這些Voucher可以進行后續的流通使用。當然這些Voucher也可以通過同樣的跨鏈方式返回到A鏈，A鏈上的ATOM代幣相應執行解鎖的操作。

2. IBC握手流程

IBC協議實現區塊鏈間跨鏈消息的可信、可靠轉發，并有效進行流量控制、多路復用等功能。
IBC也是如此。

• 借鑒了傳輸層的TCP協議（希望成為區塊鏈領域的“TCP協議”）
• 有連接的、可靠的跨鏈消息傳輸

2.1 三種角色

2.1.1 鏈內客戶端

跨鏈雙方需要在鏈上初始化一個對方鏈的輕客戶端，這個Client實質上是另一個區塊鏈的輕客戶端，而且必須滿足Cosmos規定的一套Client接口。

需要保證在本鏈上能夠驗證來自來源鏈的跨鏈交易是能夠驗證的，否則無法保證在本鏈上執行該交易的有效性和合法性。

• 輕客戶端規定了一套通用的接口，不同類型的區塊鏈通過實現該 Client來達到接入的效果。
• 現階段支持 Tendermint Client和Solo Client，也就是同構鏈之間原生支持跨鏈。
• 不是使用Cosmos構建的區塊鏈想要接入Cosmos Hub進行跨鏈的話，必須通過一個額外的“轉接橋”

2.1.2 Connection和Channel

Connection和Client一起負責跨鏈交易的“合法性”——包括跨鏈交易確實在目的鏈上發生，以及跨鏈交易只提交了一次。

Connection和Channel在跨鏈扮演的角色和能不同， Channel用來保證跨鏈交易的有序性，每筆交易按照 Sequence Number來進行發送。

Connection和Channel的建立過程都如上面所示，只是數據包的名稱和內容會有不同，

• 建立Connection的時候發送的便是 ConnOpenInit請求
• 建立的Channel的時候便是ChanOpenInit 請求，之后的請求依次類推。

2.1.3 無序的Channel

采用了有序的模式。

• 有序Channel和TCP類似

• 無序Channel類似于UDP，無序Channel按照UDP來講的話，在某些不太關注跨鏈消息包順序的場景下也是適用的。

• 考慮到Channel的消息發送能力，允許一條Connection上建立多個Channel，在不同的跨鏈應用場景中，可以使用不同的Channel發送消息，從而隔離不同業務。

2.2 通信原理

2.2.1 握手連接

在輕客戶端的基礎上建立握手連接，握手連接基本上分別為三個部分。Connection和Channel的建立都如下：
● 啟動跨鏈的用戶向鏈A發起OpenInit請求，等待Relayer 接收到該請求。
● Relayer進行路由跨鏈消息包的工作，如果收到 OpenInit的請求，Relayer 會構造一個的OpenTry 的請求發送到鏈B上。
● 鏈B收到OpenTry請求之后，如果同意的話，會對該消息進行確認（生成OpenACK數據包，并按照之前的方式由 Relayer 轉發給鏈A。
● 鏈A通過OpenACK數據包判斷此次握手是否成功，如果成功，對此次握手發送最后的 OpenConfirm 數據包返回鏈B。如果握手失敗，此次連接也就是建立失敗了。

2.2.2 發送跨鏈數據包

完成握手之后，應用層便可以在Channel上發送自己的數據了。Cosmos跨鏈交易的如下圖：

• TimeoutHeight和TimeoutTimestamp 超時機制

  如果某個區塊高度或者某個時間這筆跨鏈交易還沒有完成的話，用戶能夠指定將這筆交易回退（比如是跨鏈轉賬的話，可以防止資金長時間凍結）。

• Data字段
  留給用戶進行自定義，以應對可能的各種復雜的跨鏈場景。

總結

以上是生活随笔為你收集整理的跨链(8)Cosmos之“跨链交互协议IBC”前言的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。