摘要：被譽為區(qū)塊鏈的互聯網，旨在解決區(qū)塊鏈可互操作性和可擴展性問題。摘要本文給出了互聯鏈通信協議的技術規(guī)范，這個協議在年月白皮書中有過首次描述。使用消息傳遞范式，并允許參與鏈保持獨立。

Cosmos被譽為“區(qū)塊鏈的互聯網”，旨在解決區(qū)塊鏈可互操作性和可擴展性問題。其區(qū)塊鏈間通訊協議可以實現區(qū)塊鏈的互聯，支持不同區(qū)塊鏈之間的資產轉移。隨著區(qū)塊鏈協同操作的需求越發(fā)強烈， Cosmos作為跨鏈技術的佼佼者，值得我們關注和學習。

摘要
本文給出了Cosmos IBC（互聯鏈通信）協議的技術規(guī)范，這個協議在2016年6月Cosmos白皮書中有過首次描述[1]。其它一些技術也可以在一個原子操作中涵蓋兩個鏈，比如“哈希時間鎖定合同”[2]，不過很多（此類技術）都僅限于保證兩個交易同時成功或失敗。IBC則創(chuàng)建了完整的雙向“側鏈”，真正地允許跨鏈傳遞價值，并充分利用Tendermint的即時最終性來實現代幣的快速傳遞。

IBC使用消息傳遞范式，并允許參與鏈保持獨立。每個鏈都維護一個局部的部分順序，而消息則用于跟蹤所有跨鏈的因果關系。一旦兩個鏈之間注冊了信任關系，就可以安全地將數據包從一個鏈發(fā)送到另一個鏈上，代表從一個鏈上的一個賬戶轉移代幣到另一個鏈上的賬戶。該協議也可擴展到代幣轉移之外（的其它功能） – 盡管為其他應用類型設計安全的通信邏輯還待深入研究。該協議對鏈之間傳輸數據包時的阻塞時間或網絡延遲不做假設，因此在異構環(huán)境中具有很強的魯棒性。

本文闡述了Cosmos IBC協議的要求和結構，目標是提供足夠的細節(jié)來充分理解和分析協議的安全性。

以下是《Cosmos互聯鏈通信技術規(guī)范》譯文的前半部分。

一 、簡介

Cosmos IBC是圍繞Cosmos網絡和Tendermint共識引擎而設計的，從根本上依賴于Tendermint的即時最終性屬性（意味著永遠不會創(chuàng)建分叉）。Cosmos網絡將由Cosmos樞紐和多個獨立的分區(qū)組成，這些分區(qū)都通過IBC與樞紐進行通信。Cosmos樞紐還可以通過在它們之間中繼IBC消息來橋接不同的分區(qū)。

我們從一個簡單情形的具體例子入手，它可用于為后續(xù)的抽象解釋提供一個形式框架。在此之后，將解釋這個例子中使用的消息傳遞語義。接下來就是安全證明和數據包傳輸所依賴的技術基礎。

在此之后，將討論更高級的消息類型，例如超時和路由（以使更大的網絡在相當長時間內能高效運作），還要對協議處理所有可能情況的能力予以充分考慮。

除了為IBC協議提供理論理解和參考文檔之外，本文還旨在為協議的安全基礎提出令人信服的論據。本文是對正在進行的Cosmos項目的一個報告，隨著來自實踐的數據不斷更新理論，我們也將持續(xù)調整它的內容。

二、 示例場景

為了使討論不那么抽象，這里用例子說明一個具體情形是如何工作的。Alice想從她在Cosmos分區(qū)X上的賬戶發(fā)送30個wink幣（示例代幣名稱）給Cosmos樞紐上的Bob。假設分區(qū)X已經跟樞紐建立了一個IBC連接，Alice將在分區(qū)X上創(chuàng)建一個交易來發(fā)起傳輸。分區(qū)X會將那些代幣凍結在某個托管賬戶，然后創(chuàng)建一個IBC數據包請求樞紐在Bob的賬戶中創(chuàng)建相應數量的代幣。本質上，分區(qū)X上的驗證節(jié)點集合會保證銷毀這些代幣以換取在樞紐上重鑄它們。

一個獨立的中繼進程（任何人都可運行的客戶端軟件）可以從分區(qū)X提取那個IBC數據包的證明并將其發(fā)布到樞紐。樞紐將驗證區(qū)塊頭，Merkle證明和順序號來確保這是一個從分區(qū)X來的有效的IBC數據包。這下我們面臨兩個選擇：要么分區(qū)X在樞紐上有足夠信用來鑄這30個wink幣從而數據包被接受，要么信用不夠而數據包被拒絕。如果數據包被接受，樞紐就在Bob的賬戶中鑄30個新鮮的wink幣，并將數據包連同成功記錄存在它的傳入隊列中；如果數據包被拒絕，則不會創(chuàng)建代幣，且隊列中會存入一個失敗記錄。

我說的“信用”指的是什么？我們不希望每個連接到樞紐的鏈都能在樞紐上隨意創(chuàng)建任意數量的任意代幣，否則所有經濟保證很快就變得毫無意義。樞紐必須使用它自己的邏輯來驗證它是否足夠信任分區(qū)X并接受那30個wink幣。如果分區(qū)X是wink幣的本源（X的原生代幣），那么在發(fā)送wink幣到樞紐這件事上，它將得到樞紐的極大信任。如果樞紐之前已經向分區(qū)X發(fā)送過500個wink幣，那么它必須記住這個信息并允許分區(qū)X將（不超過）那500個wink幣發(fā)送回樞紐，從而實現代幣的自由流動。這個邏輯可以為代幣傳輸提供安全性，其它應用則需要在不完全信任網絡中所有分區(qū)的情況下，運用它們自己的邏輯來維護全局約束條件。

在樞紐成功或不成功地執(zhí)行了那個交易之后，我們希望將交易的收據（連同證明）傳回到分區(qū)X以完成這個循環(huán)。此收據只是另一種類型的IBC數據包，其執(zhí)行方式與發(fā)送一樣。唯一區(qū)別是，在發(fā)起分區(qū)處理收據絕不能產生錯誤。（根據收據內容）如果交易是成功的，則分區(qū)X將銷毀托管的30個wink幣，代幣在分區(qū)間轉移成功；如果交易因任何原因被拒絕，那么托管代幣就會釋放回Alice的賬戶 – 就像什么都沒有發(fā)生過一樣。

這意味著，在收到響應（成功或失敗）之前，誰也不能碰分區(qū)X上的托管代幣。除非我們有證據證明該數據包被接收鏈拒絕，已經發(fā)出的代幣不會被釋放。沒有代幣會被無端創(chuàng)建或銷毀，也不可能執(zhí)行雙花，代幣不會莫名消失在跨鏈操作中。發(fā)送方只需要等待兩個數據包的轉發(fā)和執(zhí)行（很多情況下是十來秒鐘）。對處理硬分叉分區(qū)（如ETH/ETC或BTC/BCH）的考慮會在下面的高級章節(jié)討論。

三、 消息傳遞語義

在試圖擴展區(qū)塊鏈時，必須找到一種不違反任何安全保證的可行方法，來增加并行寫的數量。防止雙花需要為任何給定賬戶提供嚴格的串行訪問（讀和寫），但是我們需要一些安全的方法來允許多個交易同時執(zhí)行，而又不給惡意利用競態(tài)條件提供可能性。

通過IBC協議，我們尋求避免一個問題，那就是允許多個獨立節(jié)點將交易應用到相同的狀態(tài)空間。如果你不想丟失任何數據（比如：強最終一致性），這個問題即便不考慮拜占庭角色也是困難的，在面對惡意行動人尋求利用任何不一致為自身牟利的情況下，則變得極其困難。安全地將不同的部分排序協調成一致的全局排序的最嚴謹方法是CRDTs（無沖突數據復制類型），它保證一組固定交易的所有可選的部分排序都將收斂到相同結果。CRDTs確實很有趣，但由于其固有特性，不允許在區(qū)塊鏈用例中強制執(zhí)行約束條件（例如，賬戶余額永遠不能為負數）。

這個問題的另一個解決方案是使用分片，每個分片都只能訪問狀態(tài)空間的一部分。這可以增加吞吐量，但也會使任何涉及多個分片的交易極難正確執(zhí)行。觸及多個分片并需要一致視圖的查詢可以通過使用快照來執(zhí)行，但是在高度分布的環(huán)境中這可能很困難。如果您想在兩個分片上安全地、原子地查詢和修改數據，就需要類似鎖和三階段提交的機制，這在許多數據庫中都使用過。但是，如果您想要保證順序并在通信層引入同步和定時假設，這就是一個阻塞操作，這使得它不適合分布式(多)區(qū)塊鏈的場景。

我們通過定義“分區(qū)”而走了一條不同的路。每個分區(qū)都是一個獨立的區(qū)塊鏈，有自己的應用邏輯，自己的交易和數據存儲。分區(qū)應該沿使用界線分開，因此絕大多數交易只影響一個分區(qū)，但我們可以保證任何跨鏈交易擁有安全和非阻塞的語義。每個分區(qū)都是一個完整的獨立系統(tǒng)，它們使用消息傳遞進行通信。它們能夠保證本地分區(qū)中的交易正確排序和執(zhí)行，同時允許其它分區(qū)里的交易并行執(zhí)行。唯一需要全局排序的東西是系統(tǒng)之間發(fā)送的消息。

分布式系統(tǒng)中的消息傳遞是一個已經被深入研究的領域，也是許多其它系統(tǒng)的搭建基礎。我們能夠對異步消息進行建模，且對信道不做時序假設。這樣的結果是，我們允許每個分區(qū)以自己的速度行動，不被任何其它分區(qū)阻塞，卻能夠以當時網絡允許的最快速度通信。

使用消息傳遞作為原語的另一個好處是，接收方能夠對傳入的消息應用自己的安全檢查。僅僅因為一個我們了解的分區(qū)發(fā)送了一條消息給某個特定帳戶添加50個以太幣，并不意味著我們必須增加余額。我們可以在接收消息時添加我們自己的業(yè)務邏輯，以決定我們是否想拒絕該消息，以及我們想如何處理它（如果我們接受它）。在一個共享狀態(tài)的場景中，很難甚至不可能做到這一點。消息傳遞允許每個分區(qū)確保其安全性和自治性，同時允許不同的系統(tǒng)作為一個整體協同工作。這可以看作是微服務體系架構的一個類比，但是跨越了組織邊界。

為了在一個可證明的異步消息傳遞原語上構建有用的算法，我們需要定義一些更高階的結構在所有系統(tǒng)間共享，從而允許我們和一些更容易的保證打交道。

3.1 可靠消息隊列

我們在這里引入的第一個原語是可靠的消息隊列（以下簡稱隊列），這是異步消息傳遞的典型構造，它使我們能夠確保因果排序并避免阻塞。

這個隊列在每個區(qū)塊鏈的Merkle數據存儲中以多個鍵值對的形式永續(xù)保存。每個隊列有一個獨特的前綴，鍵是通過把一個代表其順序號的8字節(jié)大端模式整數追加在這個前綴后面生成的。注意這個編碼方式為我們提供了一個與鍵的順序號相一致的鍵的字典序，這讓我們能快速找到最新的數據包，也能證明在某個給定順序位的數據包內容（或沒有數據包） -- 假設像在我們的IAVL+ Merkle樹[3]里那樣訪問范圍證明。

新增的任何一個數據包的順序號只能比當前最高數據包的順序號大1。為了使證明更容易，我們會將順序號也存在數據包本身（鍵值對的值）里面。一旦一個數據包被寫入，它就是不可變的（除了在清理期間刪除，這在后面會解釋）。這使得接收分區(qū)可以接受位于源分區(qū)高度H的數據包Z的證明，而接收分區(qū)處理交易時盡可放心數據包在源分區(qū)里仍然以相同狀態(tài)存在（異步性的要求）。區(qū)塊鏈應用邏輯必須為所有隊列保證這些約束條件，以確保消息層的正常運行。

假設我們的IBC隊列的前綴是0xCAFE，我們可以看到多個數據包是如何存在Merkle樹中的，而它們的順序號又是如何追加（生成鍵）的，這樣我們就可以輕松地為某個給定數據包的存在（或不存在）提供一個Merkle證明。下面圖示了構建順序號為2的數據包的Merkle證明的路徑，用橙色高亮顯示。

本節(jié)的其余部分將定義可通過此隊列發(fā)送的基本消息類型。

3.2 注冊鏈（需經許可）

在兩個鏈之間建立起連接之前，我們需要先讓它們彼此注冊。這一點尤為重要，因為所有輕客戶端證明都需要一個對驗證消息頭至關重要的信任種子，當有未經共識算法批準的惡意分支存在時，它能讓我們確認那條真的鏈。

為了在A和B之間形成連接，我們必須在B上注冊A，也要在A上注冊B。這些過程是對稱的，所以在這里我們只描述如何在A上注冊B。在注冊時，A為B添加一個可信的消息頭和驗證節(jié)點集合，保存在它的安全數據存儲中。這用于驗證來自B的所有未來的消息頭，以及驗證節(jié)點集合的變更。A還要創(chuàng)建兩個具有不同名稱（前綴）的隊列。

ibc::out – 存放所有以B為目的地的傳出數據包

ibc::in – 存放所有來自B的傳入數據包連同它們的執(zhí)行結果

注意，注冊鏈應該是一個需要獲得許可的操作，且執(zhí)行時要有人工驗證。這將產生一個信任聲明，即這個消息頭和驗證節(jié)點集合代表了對應鏈的正確狀態(tài)，它們不屬于試圖鏡像這條鏈的某些影子鏈。不像PoW的最長鏈勝出算法，對權益證明而言信任必須在某個時點被明確授予。

而且，注冊過程還必須定義好我們用來驗證Merkle證明的算法（這些證明存在于隊列中的IBC數據包里）。缺省設置是來自我們的IAVL樹的Merkle證明格式，但是其他Merkle化的數據存儲，比如Patricia Trie，也可以得到支持。這個算法必須在注冊時設置一次，并且必須被參與鏈所支持。隊列的整個生命周期都會基于可信的消息頭，一致地使用該算法驗證每個數據包或收據。

3.3 驗證節(jié)點變更

任何生產鏈的驗證節(jié)點集合都會隨著時間推移而發(fā)展變化。當我們注冊一個新鏈時，會針對一個特定的驗證節(jié)點集合做一個信任聲明 (更具體而言，我們的信任綁定的是這樣一個條件：消息頭擁有超過一定閾值數量的與給定公鑰集相匹配的數字簽名)。當我們信任的這組公鑰變化時，我們需要一個消息來把這個變更通知給其它鏈。由于驗證節(jié)點變更對共識算法至關重要，所以我們用一個標準格式把它存儲在Tendermint的區(qū)塊頭內。

我們定義一個特殊的更新數據包，它包含一個Tendermint區(qū)塊頭和新的驗證節(jié)點集合，我們可以將它發(fā)送給接收鏈。接收鏈可以核實驗證節(jié)點集合變更的有效性，并使用它來驗證所有未來的數據包。

3.4 發(fā)送數據包

發(fā)送一個IBC數據包涉及區(qū)塊鏈應用邏輯調用IBC模塊，告訴它需要發(fā)送的數據包以及目標鏈的標識。如果目標鏈已經注冊好，IBC模塊只需計算下一個順序號并將其添加到傳出隊列out queue。順序號與特定連接相關并由發(fā)送鏈生成，它們必須是單調遞增和連續(xù)的。

數據包被寫入Merkle化的數據存儲，這樣它就嵌入了和區(qū)塊頭相關聯的證明當中。這些代表了數據包的鍵值對證明接下來就會被傳送給其它鏈。

區(qū)塊鏈應用程序必須對誰可以寫一個隊列的鍵空間做出限制，不是隨便哪個智能合約都可以在那里寫交易數據，只有當區(qū)塊鏈邏輯判定數據包有效，且與數據包類型相關的全局約束條件得到滿足（比如：上面例子中的托管代幣被凍結），才會生成（并寫入）數據包。

3.5 中繼數據包

為了讓數據包到達目標鏈，我們依靠一個或多個中繼進程把鏈A上的傳出證明out proof發(fā)布到鏈B的傳入隊列in queue中。由于這里只需要輕客戶端證明，中繼進程不需要是驗證節(jié)點，甚至都不需要是全節(jié)點。實際上，如果每個發(fā)起創(chuàng)建IBC數據包的用戶也負責將它中繼到接收鏈，那就太理想了。唯一的限制是，中繼進程必須能夠在目標鏈上支付適當的費用。

為了系統(tǒng)自舉，鏈開發(fā)人員可以提供一個有足夠資金的特殊賬號給中繼進程，為所有數據包支付費用，直到用戶在兩個鏈上都有代幣。不過，使用IBC的人應該自己負責支付這些費用。注意，更新消息頭是一種代價高昂的交易（大約100個數字簽名校驗），而為一個已知消息頭發(fā)布證明則要便宜得多（大約20個哈希計算）。因此，為了優(yōu)化，許多數據包可以捆綁在一起在同一區(qū)塊高度發(fā)送，即使它們是在不同的區(qū)塊高度創(chuàng)建的，這樣可以通過增加一點延遲來節(jié)省計算成本。

系統(tǒng)必須允許多個中繼進程安全地并行運行，拒絕掉任何重復的消息發(fā)布。但更理想的是能在起初就防止他們嘗試重復發(fā)布，因為這會浪費帶寬和鏈上的計算時間。

3.6 收據

當一個IBC數據包發(fā)布到另一個鏈上并被認為是有效的（即，數據包的證明跟源鏈的已知消息頭相匹配），則不管執(zhí)行是否成功，我們都必須將它存儲在傳入隊列in queue里，這樣就有證據表明它已經被處理過。相關交易應該發(fā)送到合適的智能合約加以驗證和執(zhí)行，然后返回標準的ABCI結果（成功或錯誤）；收到的數據包連同處理結果被寫進傳入隊列。

另一個中繼進程可以獲得這個數據包已經在鏈B上處理過的證明，把它作為收據發(fā)布到鏈A。此收據將由鏈A處理，觸發(fā)進一步的應用邏輯，以及對隊列的清理（參見高級部分）。將請求從A中繼到B的那個進程可以將響應從B中繼回A，但也可以使用一個不同的進程來做這件事。

作者：Ethan Frey, frey@tendermint.com
譯者：奚海峰 Haifeng Xi
校對：曹恒 Harriet Cao
本文首發(fā)于萬云Wancloud微信號，未經授權不允許轉載。

。