資料

點擊查看大圖，瀏覽器不支持在線閱讀pdf可以點此下載 Download PDF.

一、概述與簡介

【資料圖】

1.是什么

Cosmos 是一個獨立并行區(qū)塊鏈的去中心化網(wǎng)絡(luò)，每個區(qū)塊鏈都由 Tendermint 共識這樣的 BFT 共識算法構(gòu)建。

Cosmos 不是一個產(chǎn)品， 而是建立在一套模塊化、適應(yīng)性強和可交互工具之上的生態(tài)系統(tǒng)。適合于公有鏈或者私有鏈。

三個特點：

**模塊化開發(fā)：**Cosmos 通過 Tendermint BFT 和 模塊化的 Cosmos SDK 使區(qū)塊鏈易于開發(fā)?？珂淐osmos 使區(qū)塊鏈能夠通過 IBC 和 Peg-Zones 相互轉(zhuǎn)移價值， 同時讓它們保留主權(quán)。強拓展性：Cosmos 允許區(qū)塊鏈應(yīng)用通過水平和垂直可擴展性解決方案可支持?jǐn)?shù)百萬用戶。

2.區(qū)塊鏈層級

2.1. 三層模型

應(yīng)用程序：負(fù)責(zé)更新給定的一組交易，即處理交易的狀態(tài)，更新狀態(tài)。網(wǎng)絡(luò)：負(fù)責(zé)交易和共識相關(guān)消息的傳播。共識：使節(jié)點能夠就系統(tǒng)的當(dāng)前狀態(tài)達(dá)成一致。

2.2. 耦合性

BitCoin

比特幣系統(tǒng)三層耦合在一起，比特幣腳本語言只支持交易處理，沒有虛擬機的支持無法實現(xiàn)智能合約

Ethereum

以太坊構(gòu)建了一個人們可以部署任何類型應(yīng)用的區(qū)塊鏈。 以太坊通過將應(yīng)用層轉(zhuǎn)換為稱為以太坊虛擬機(EVM)的虛擬機來實現(xiàn)這一點。該虛擬機能夠處理稱為智能合約的程序，任何開發(fā)人員都可以以***無許可***的方式部署到以太坊區(qū)塊鏈。 這種新的方法允許成千上萬的開發(fā)人員開始構(gòu)建去中心化應(yīng)用（DApps）。

在應(yīng)用層實現(xiàn)了EVM虛擬機來處理智能合約，簡化了去中心化應(yīng)用的開發(fā)，但是整體上還是耦合的

缺陷：

可拓展性（scalability）

所有的DApp都在Ethereum一條鏈上運行，采用PoW的以太坊效率很低，建立在以太坊之上的去中心化應(yīng)用程序被每秒15交易數(shù)的共享速率所抑制。

可用性（Usability）

合約編程語言有限制，開發(fā)人員編程有較低的靈活性，不能實現(xiàn)代碼的自動執(zhí)行，以太坊智能合約的執(zhí)行需要有外部賬號的觸發(fā)動作。

主權(quán)（Sovereignty）

每個應(yīng)用程序在主權(quán)方面都受到限制，因為它們都共享相同的基礎(chǔ)環(huán)境。應(yīng)用程序出現(xiàn)問題（例如智能合約出現(xiàn)漏洞The DAO事件）需要以太坊平臺的改變才能解決，而以太坊平臺是多個應(yīng)用程序的共享平臺。

Cosmos

將網(wǎng)絡(luò)層和共識層打包成通用引擎用于開發(fā)，允許開發(fā)人員專注于應(yīng)用程序開發(fā)，而不是復(fù)雜的底層協(xié)議。

Tendermint BFT 引擎通過使用 ABCI（Application Blockchain Interface） 套接字（socket）協(xié)議連接到應(yīng)用程序。 這個協(xié)議可以用任何編程語言進行封裝，開發(fā)者可以選擇適合他們適合的語言。

進一步對于應(yīng)用層，Cosmos SDK 是一個通用框架，使用模塊化的思想簡化了在 Tendermint BFT 之上構(gòu)建安全區(qū)塊鏈應(yīng)用的過程。

通過Tendermint BFT引擎構(gòu)建的各個區(qū)塊鏈Zone可以通過區(qū)塊鏈間通信協(xié)議（IBC：Inter-Blockchain Communication protocol）實現(xiàn)跨鏈的操作。

個人看法：Cosmos并非完全解耦，共識層與網(wǎng)絡(luò)層打包成為一個通用引擎便利于開發(fā)者***為各種應(yīng)用程序創(chuàng)建獨享的鏈***這樣每個應(yīng)用的主權(quán)就是完整的，同時在應(yīng)用層上通過cosmos sdk來模塊化開發(fā)從而減少重復(fù)性開發(fā)，IBC解決跨鏈互通問題。但是Cosmos的共識機制是不能替代的（為了保證通用性），比較于Fabric或其他主流的聯(lián)盟鏈框架，F(xiàn)abric在共識層上實現(xiàn)了可拔插的共識協(xié)議，共識層解耦度更高

3.網(wǎng)絡(luò)結(jié)構(gòu)

3.1 Zone

Cosmos網(wǎng)絡(luò)中各自獨立的區(qū)塊鏈，多條Zone與多個Hub組成復(fù)雜的Cosmos網(wǎng)絡(luò)。

每一個Zone都依賴于Tendermint Core也就是Tendermint BFT引擎。

3.2 Cosmos Hub

在 Cosmos 網(wǎng)絡(luò)中推出的第一個Hub 是 Cosmos Hub。 Cosmos Hub 是一個開放的**權(quán)益證明（POS）**的區(qū)塊鏈，其原生 staking 代幣為 ATOM，并且交易費用可以用多個 Token 支付。 Cosmos Hub 的推出也標(biāo)志著 Cosmos 主網(wǎng)上線。

功能職責(zé)

能夠與其他的Zone進行拓展所有的Zone之間的代幣交換都需要經(jīng)過Hub, Hub記錄代幣種類以及記錄各個Zone中代幣的總額記錄Cosmos Hub區(qū)塊鏈承載的是多資產(chǎn)分布式賬本，其中代幣可以由個體用戶或空間本身持有。這些代幣能夠通過特殊的 IBC 包裹，即"代幣包"（coin packet）從一個Zone轉(zhuǎn)移到另一個Zone。Cosmos Hub可看作不同區(qū)塊鏈之間交易的樞紐,使全網(wǎng)的代幣總量保持恒定.負(fù)責(zé)流通Atom代幣，是hub唯一的可質(zhì)押代幣?？捎糜谄唾M來避免垃圾交易，額外的Atom和汽油費獎勵給Validator與代理人當(dāng)有超過三分之一的Validator投票停止系統(tǒng)或者有超過三分之一的Validator審查到惡意行為證據(jù)時，Hub必須通過硬分叉reorg-proposal恢復(fù)

3.3 light client

網(wǎng)絡(luò)中的輕客戶端，新的客戶端需要對當(dāng)前網(wǎng)絡(luò)進行同步：

同步過程

同步當(dāng)前所有Validator集合

確定網(wǎng)絡(luò)最新狀態(tài)

通過驗證最新區(qū)塊結(jié)果的絕大多數(shù)（>2/3）投票結(jié)果，輕型客戶端可以定期與驗證器設(shè)置的更改保持同步，以避免遠(yuǎn)程攻擊，與以太坊類似，Tendermint允許應(yīng)用程序在每個塊中嵌入一個全局Merkle根Hash，根據(jù)應(yīng)用程序的性質(zhì)，允許對賬戶余額、合同中存儲的價值或是否存在未使用的交易輸出等事項進行容易驗證的狀態(tài)查詢。

4.角色

4.1 Validator驗證者

1.概念

應(yīng)用層的角色，擁有投票權(quán)重的節(jié)點， 負(fù)責(zé)出塊與投票。

每個區(qū)塊鏈都由一組驗證者維護，他們的工作是同意下一個區(qū)塊提交給區(qū)塊鏈。

如何選取Validator是由開發(fā)者自由決定的，每個驗證器的投票權(quán)重也是，如果采用持有的Token來選擇，那么就是區(qū)塊鏈就是權(quán)益證明POS（Proof-of-Stake）。如果只能是經(jīng)過授權(quán)或許可才能成為驗證者那么就是許可鏈或者私有鏈。

Tendermint BFT 只處理區(qū)塊鏈網(wǎng)絡(luò)和共識，它幫助節(jié)點傳播交易和驗證追加交易到區(qū)塊鏈。出塊共識與主鏈共識是分開的。

Tendermint采用確定性輪詢機制的實用拜占庭容錯協(xié)議。在出塊選舉階段，不采用工作量證明來實現(xiàn)而是采用規(guī)定節(jié)點在主賬戶存入保證金（Atom）才能實現(xiàn)投票（成為驗證者），投票權(quán)重與保證金數(shù)量（Atom）成正比。每輪輪詢機制選出的出塊者為Leader或proposer

2.成為驗證者

數(shù)量上的限制

在創(chuàng)世日那天，驗證器的最大數(shù)量將被設(shè)置為100個，這個數(shù)字將以13%的速度增長10年，并穩(wěn)定在300個驗證器。

途徑

持有Atom可以通過簽名和提交BondTx事務(wù)成為Validator，任何人任何時間只要持有Atom那么就可以抵押自己的Atom成為驗證者,除非驗證者的數(shù)量為當(dāng)前最大，則觸發(fā)替換機制。

替換機制

如果當(dāng)前驗證器集合數(shù)量已經(jīng)是最大，那么想要成為新的驗證器就需要比當(dāng)前集合中的最小驗證器的質(zhì)押大（有效的質(zhì)押Atom包括別人委托的質(zhì)押Atom），被替換的驗證者變成不活動的，進入unbonding狀態(tài)。

懲罰機制

如果Validator違反了規(guī)定那么就會受到處罰，例如在同一區(qū)塊中雙重簽名或者違反prevote-the-lock（Tendermint的共識協(xié)議）中的規(guī)定

如果是因為斷電或故障那么會損失ValidatorTimeoutPenalty(默認(rèn)1%)的股份。

如果惡意節(jié)點的違規(guī)是不易找到證據(jù)的，那么可以通過絕大多數(shù)投票將其強制超時

處一般為削減Atom和代幣股份

4.2 No-Validator/delegator

可以將自己的權(quán)益委托給Validator進行使用，從而獲得部分占額的出塊利息以及出塊獎勵，但是這個代理過程需要自己承擔(dān)風(fēng)險，并且自己需要支付一定的傭金給Validator，這可以由系統(tǒng)來決定。

5.協(xié)議

5.1 IBC

1.概念

inter-blockchain communication protocol區(qū)塊鏈間通信協(xié)議, 將開發(fā)者自由定義的區(qū)塊鏈（Zone）連接起來的協(xié)議。

IBC 利用 Tendermint 共識的“強一致性”（其他的具有“強一致性”共識引擎也可以），以允許異構(gòu)鏈之間相互轉(zhuǎn)移價值（如 token）或數(shù)據(jù)。

異構(gòu)鏈：網(wǎng)絡(luò)、共識、應(yīng)用層結(jié)構(gòu)與實現(xiàn)方式不同

IBC 允許異構(gòu)鏈之間轉(zhuǎn)移價值（如 token）和數(shù)據(jù)，這意味著具有不同應(yīng)用程序和驗證人集合的區(qū)塊鏈?zhǔn)强苫ゲ僮鞯摹?例如，它允許公有鏈和私有鏈間相互轉(zhuǎn)移 token。

2.作用

Hub與Zone交流的協(xié)議， 用于同步狀態(tài)。各個zone不斷提交區(qū)塊確認(rèn)讓Hub能夠同步每個zone的狀態(tài)

每個zone與Hub保持同步，同一個Hub的zone之間沒有直接的同步，但是可以通過Hub間接實現(xiàn)同步

3.包結(jié)構(gòu)

Coin Packet

代幣包，跨鏈時發(fā)送的特殊的IBC包，它必須有發(fā)送鏈、Hub鏈、接收鏈的確認(rèn)。

IBCBlockCommitTX

用于提供可證明的最近的區(qū)塊Hash，證明區(qū)塊正確性與存在性。

其中的交易結(jié)構(gòu)：

SimpleProof是針對驗證區(qū)塊Hash的，AppHash則是采用AVL+樹保存應(yīng)用程序狀態(tài)

IBCPacketTx

提供最近區(qū)塊的Merkle-proof，證明給定的包確實是發(fā)送方應(yīng)用程序發(fā)布的

證明交易的正確性

交易結(jié)構(gòu):

其中IBCPacket的結(jié)構(gòu)：

Payload或PayloadHash中必須有一個存在。IBCPacket的Hash是頭和負(fù)載這兩個項的簡單Merkle根。沒有完整負(fù)載的IBCPacket稱為縮寫包。

其中IBCPacketHeader的結(jié)構(gòu)：

在整個協(xié)議傳遞過程中SrcChainID 和 DstChain始終不會改變，當(dāng)“Zone1”想通過“Hub”向“Zone2”發(fā)送數(shù)據(jù)包時，無論Merkle化的數(shù)據(jù)包是在“Zone1”、“Hub”還是“Zone2”上, IBCPacket數(shù)據(jù)都是相同的。唯一可變的字段是跟蹤交付的狀態(tài)。

3.連接過程

類似于區(qū)塊鏈上的Tcp/IP協(xié)議

發(fā)起者不需要確認(rèn)

更新Hub有關(guān)于Zone1的區(qū)塊，則在IBCBlockCommitTX上必須包含Zone1的塊hash，這樣IBCBlockCommitTx交易發(fā)布在Hub上就使Hub包含了Zone1的塊Hash

發(fā)起者需要確認(rèn)的情況

發(fā)送方可以通過將初始包狀態(tài)設(shè)置為AckPending來要求發(fā)送確認(rèn)。然后，接收鏈有責(zé)任通過在應(yīng)用程序Merkle-Hash中包含一個縮寫的IBCPacket（沒有完整負(fù)載的IBCPacket稱為縮寫包）來確認(rèn)發(fā)送

? 1. 首先，在“Hub”上發(fā)布IBCBlockCommit和IBCPacketTx，這證明了“Zone1”上存在IBCPacket

? 2. 接下來，在“Zone2”上發(fā)布IBCBlockCommit和IBCPacketTx，這證明了“Hub”上存在IBCPacket。

? 3. 接下來，“Zone2”必須在它的app-hash中包含一個縮寫包，該包顯示AckSent的新狀態(tài)。

IBCBlockCommit和IBCPacketTx被發(fā)回“Hub”上，這證明了“Zone2”上存在一個縮寫的IBCPacket。

? 4.最后，“Hub”必須更新包的狀態(tài)，從AckPending到AckReceived。這個新最終確定狀態(tài)的證據(jù)應(yīng)返回

到“Zone2”。

確認(rèn)超時的情況

如果“Hub”沒有從“Zone2”收到350高度內(nèi)的AckSent狀態(tài)，它將自動將狀態(tài)設(shè)置為Timeout。超時的證據(jù)可以在“Zone1”上發(fā)回，并且可以返回任何代幣

4.工作流程

IBC 背后的原理相當(dāng)簡單。 我們以鏈 A 上的一個帳戶想要發(fā)送 10 個 Token（假設(shè)是 ATOM）到鏈 B 為例介紹。

跟蹤（Tracking）

鏈 B 會不間斷地接收鏈 A 的報頭，反之亦然。 這允許每個鏈跟蹤其他鏈的驗證者集合。 從本質(zhì)上講，每個鏈運行一個其他鏈的輕客戶端。

鎖定（Bonding）

當(dāng) IBC 轉(zhuǎn)移被啟動時，ATOM 被鎖定（Bonding）在鏈 A 上。

中繼證明（Proof Relay）

然后，需要一個從鏈 A 轉(zhuǎn)移到鏈 B 的 10 個 ATOM 被鎖定的證明。

驗證（Validation）

鏈 B 上針對鏈 A 的區(qū)塊頭的證明進行驗證，如果有效，則在鏈 B 上創(chuàng)建 10 個 ATOM 憑證（ATOM-vouchers）。

注意， 在鏈 B 上創(chuàng)建的 ATOM 不是真正的 ATOM,因為 ATOM 僅存在于鏈 A 上。它們是鏈 A 中 ATOM 在 鏈 B 上的表示形式，同時還證明了這些 ATOM 被凍結(jié)在鏈 A 上。

當(dāng)他們回到其原始鏈時， 也使用類似的機制來解鎖 ATOM。

個人理解：IBC的包傳遞過程的核心就是傳遞Merkle證明，以此來證明資金的鎖定情況

5.2 ABCI

Application Blockchain Interface區(qū)塊鏈應(yīng)用接口，Tendermint Core使用ABCI與區(qū)塊鏈應(yīng)用聯(lián)系, 使得編程區(qū)塊鏈應(yīng)用可使用多種語言

消息類型

有三種，從核心core發(fā)向應(yīng)用程序，應(yīng)用程序作出對應(yīng)的響應(yīng)，ABCI請求/響應(yīng)是簡單的Protobuf消息

ABCI是底層（共識層與網(wǎng)絡(luò)層）即Tendermint Core與應(yīng)用層的交互方式

AppendTx消息

區(qū)塊鏈中的每個交易都和此消息一起交付，應(yīng)用程序需要根據(jù)事務(wù)的當(dāng)前狀態(tài)、應(yīng)用程序協(xié)議和加密憑據(jù)驗證使用AppendTx消息接收到的每個交易。然后經(jīng)過驗證的交易將更新應(yīng)用程序的狀態(tài)，存儲到k-v數(shù)據(jù)庫或更新UTXO數(shù)據(jù)庫

結(jié)構(gòu)：

CheckTx消息

類似于AppendTx，但是只用于驗證交易，不改變狀態(tài)

? Tendermint Core的內(nèi)存池首先通過CheckTx檢查交易的有效性，然后只將有效的交易轉(zhuǎn)發(fā)給其他節(jié)點

? 應(yīng)用程序可以檢查事務(wù)中不斷遞增的nonce，如果nonce舊，則在CheckTx時返回錯誤。

Commit消息

Commit消息用于計算對當(dāng)前應(yīng)用程序狀態(tài)的加密承諾，并將其放入下一個塊頭。

? 有一些方便的屬性。更新狀態(tài)的不一致會顯示為區(qū)塊鏈分叉，它會捕獲所有類型的編程錯誤

? 簡化了安全輕量級客戶機的開發(fā)，因為可以通過對塊哈希進行檢查來驗證Merkle -hash證明，并且塊哈希

由法定數(shù)量的驗證器(通過投票)簽名。

附加的ABCI消息

允許應(yīng)用程序跟蹤和更改驗證器集，并讓應(yīng)用程序接收塊信息，如高度和提交投票。

6.共識機制

6.1 Tendermint BFT

部分同步的BFT共識算法，衍生于DLS共識算法

與PBFT的比較：

Tendermint區(qū)塊按順序提交（只有第N提交了>N的塊才能后續(xù)提交）這就避免了與PBFT的視圖更改相關(guān)的復(fù)雜性和溝通開銷

TBFT將一些交易打包成塊同時采用Merkle哈希應(yīng)用程序的狀態(tài)，這比PBFT以檢查點的方式周期性的摘要能夠更快的確認(rèn)交易和提高通信速度

采用類似于LibSwift的方式將區(qū)塊進行部分劃分提高通信能力

在弱點多點通信中也可以正常工作

投票過程

兩個階段

PreVote預(yù)投票

PreCommit預(yù)確認(rèn)

投票過程

? 1. 每個Validator可以對當(dāng)前的區(qū)塊進行投票或者投票為空（nil）

? 2. 當(dāng)對于當(dāng)前區(qū)塊有大于2/3的PreVote時則將其稱之為Polka

? 3. 對于當(dāng)前區(qū)塊有大于2/3的PreCommit則成為區(qū)塊的確認(rèn)

? 如果本輪對于單一的區(qū)塊有大于2/3的投票為空則進入下一輪

timeoutproposal

? 每一輪都需要對當(dāng)前的leader進行檢測，并且需要防止始終達(dá)成nil不提交塊的共識

? 所以每個Validator在PreVote之前都會等待一個隨機的時間=>timeoutproposal

? 并且timeoutproposal隨著每輪投票的增加而增加

? 在此期間整個系統(tǒng)的進程是異步的，只有Validator收到了>2/3的確認(rèn)才會繼續(xù)進行

同一高度只提交一個區(qū)塊（保證強一致性）

首先預(yù)提交/確認(rèn)的區(qū)塊必須是Polka狀態(tài)的區(qū)塊

如果Validator已經(jīng)在R_1輪預(yù)提交了一個塊，我們說他們被鎖定在那個塊上，并且用于在R_2輪驗證新的預(yù)提交的Polka必須來自R_1 < R_polka <= R_2

驗證器必須提議并且預(yù)先投票它們鎖定的塊

保證已經(jīng)預(yù)提交的驗證器不能提供證據(jù)來預(yù)提交其他內(nèi)容

7.安全性

7.1 拜占庭機制

確保只有大于三分之一的拜占庭節(jié)點才會破壞網(wǎng)絡(luò)安全

· PBFT的安全保障（已證明）

· 如果Hub有三分之一以上機器宕機或者為惡意節(jié)點那么可以通過硬分叉恢復(fù)

7.2 鎖定機制

· 任何一組Validator違反安全或者試圖攻擊網(wǎng)絡(luò)都會被協(xié)議識別

· 例如投票給沖突區(qū)塊，廣播不公正投票等

7.3 分叉問責(zé)制

當(dāng)共識失敗，法律系統(tǒng)會進行識別和懲罰，當(dāng)法律系統(tǒng)不可靠或調(diào)用成本過高時，驗證者可能被迫繳納保證金才能

參與，而當(dāng)檢測到惡意行為時，這些保證金可能會被撤銷或削減。

8.數(shù)據(jù)結(jié)構(gòu)

8.1 Merkle樹

1. 簡單樹

· 此Merkle樹用于對塊的交易和應(yīng)用程序狀態(tài)根的頂級元素進行Merkle化。

2.AVL+樹

· AVL+樹類似于以太坊的Patricia tries

· 作為平衡二叉樹，梅克爾證明平均較短。

· 使用AVL算法的一種變體來平衡樹，所有操作都是O(log(n))。

· 在AVL樹中，任意節(jié)點的兩個子樹的高度相差最多為1。每當(dāng)更新時違反了這個條件，就會通過創(chuàng)建O(log(n))個新節(jié)點來重新平衡樹，這些新節(jié)點指向舊樹中未修改的節(jié)點。

· 原始AVL內(nèi)部節(jié)點也可以持有鍵值對，與原始的AVL算法不同的是，AVL+算法采用的是所有的值保留在葉子節(jié)點上，而只使用分支節(jié)點存儲鍵 => 搜索快速，驗證快速

· 鍵在插入IAVL+樹之前不需要取Hash，因此這提供了鍵空間中更快的有序迭代，這可能有利于某些應(yīng)用程序。

9.鏈上規(guī)章制度

實行一套實現(xiàn)約定好的規(guī)章制度為今后的系統(tǒng)問題作出解決 => 防止出現(xiàn)重大問題系統(tǒng)分叉

Cosmos的Validator和delegators可以通過提案的方式修改系統(tǒng)參數(shù)、協(xié)調(diào)升級系統(tǒng)、回滾政策、調(diào)整規(guī)章制度等

來快速改善系統(tǒng)bug，每個zone也可以制定自己的政策

10.交易費

1. 個人交易

· 每一個Hub Validator都可以接受任意的代幣組合來支付交易的汽油費

· 并且由自己來主觀決定匯率是多少

· 當(dāng)交易結(jié)束后就會按照對應(yīng)的費用扣除

2. 系統(tǒng)

· 系統(tǒng)收取的所有交易費的百分之二用戶儲備，作為系統(tǒng)安全性和價值的依據(jù)，這些資金也可以根據(jù)治理系統(tǒng)的決策進行分配。

11.性能

惡劣條件下每秒數(shù)千交易，提交延遲大約在1~2秒

取自夏青論文中的對比結(jié)果：

12.應(yīng)用

1.分布式交易所

Cosmos DEX, 也就是去中心化的交易所，實現(xiàn)跨虛擬代幣系統(tǒng)的交易,交易雙方不需要同時在線,交易者可以提交限價指令，進行交易。在Cosmos中，Hub的職責(zé)就是一個分布式跨鏈交易所.

2.橋接其他加密貨幣

1.2.1. 概念

· 橋接的區(qū)塊鏈必須同步保持最新的區(qū)塊，以此來實現(xiàn)Merkel Proof

· Cosmos需要和加入的其他虛擬貨幣保持同步

· 橋接Zone的方式簡單并且不用知道其他鏈的共識模式

1.2.2. 一般過程

發(fā)送代幣到Cosmos Hub

? 1. bridge-zone運行一個Tendermint-core的區(qū)塊鏈并且生成一個特殊的橋接應(yīng)用，同時在原鏈（原加密貨幣鏈）上運行一個全節(jié)點

? 2. 當(dāng)原鏈有新區(qū)塊出現(xiàn)時，bridge-zone的所有的Validator通過簽名和分享他們各自的本地視圖來實現(xiàn)對當(dāng)前提交區(qū)塊正確性的判定一致結(jié)果

? 3. 當(dāng)運行的全節(jié)點收到付款后（原鏈?zhǔn)莗ow機制的話需要足夠多的確認(rèn)），在bridge-zone中創(chuàng)建相關(guān)的賬戶并且有對應(yīng)的余額

從Cosmos Hub收回代幣到原鏈

? 1.在原鏈上將原鏈代幣轉(zhuǎn)移到特定的地址

? 2. IBC包能夠證明在bridge_zone上發(fā)生了代幣銷毀交易（幣由zone轉(zhuǎn)向Hub）

? 3. 原鏈上確認(rèn)bridge_zone被銷毀后（以太坊就是發(fā)布交易到合約）就可以允許原鏈代幣被撤回

1.2.3. 連接以太坊

原鏈發(fā)送幣到Cosmos

? 1. 發(fā)送以太幣到bridge_contract的賬戶上

? 2. bridge_contract會記錄當(dāng)前bridge_zone上對應(yīng)的Validator集合，這個集合可能和Hub的Validator相同

? 3. bridge_zone確認(rèn)后創(chuàng)建對應(yīng)的賬戶和余額

Cosmos返回幣

? 通過向以太坊特定的取款地址交易銷毀

? 證明交易發(fā)生在bridge-zone的IBC包發(fā)布到以太坊的橋接合同上，從而允許以太坊被撤回。

1.2.4. 連接比特幣

原鏈發(fā)送幣到Cosmos

? 1. 類似于以太坊但是沒有合約

? 2. 將UTXO使用P2SH的多重簽名進行控制

? 3.由于P2SH的限制，一般與Hub的Validator集合不同

Cosmos返回幣

? 因為P2SH的多重簽名的簽名人集合會發(fā)生變化，所以一旦變換就需要遷移UTXO到新的UTXO，以此來適應(yīng)簽名人集合的改變

? 一種方法是壓縮和解壓縮UTXO的集合，以此來降低頻繁改變UTXO所帶來的UTXO集合的過大

13.激勵措施

創(chuàng)世紀(jì)上atom代幣和驗證器的初始分發(fā)將流向Cosmos資金籌集者(75%)、主要捐贈者(5%)、Cosmos網(wǎng)絡(luò)基金會

(10%)和ALL IN BITS, Inc(10%)。從創(chuàng)世紀(jì)開始，每年1/3的原子總數(shù)將獎勵給綁定驗證者和授權(quán)者。

黑客漏洞獎勵

為了鼓勵和盡早的發(fā)現(xiàn)漏洞，Cosmos鼓勵黑客可以通過ReportHackTx交易向系統(tǒng)發(fā)布漏洞，如果無誤的話則每個人會拿出5%的atom獎勵給黑客地址

14.優(yōu)缺點

優(yōu)點：拓展性強，通過Hub實現(xiàn)跨鏈支持去中心化的跨鏈，能夠拓展當(dāng)前主流公鏈；輕客戶端同步當(dāng)前網(wǎng)絡(luò)狀態(tài)迅速高效；解決了公鑰認(rèn)證問題。

缺點：對接比特幣/以太坊等已有鏈的跨鏈資產(chǎn)返回還未設(shè)計完全；沒有合約引擎無法部署和使用合約（但是可以用組件實現(xiàn)：ETHERMINT）；法律監(jiān)管、pos、規(guī)章制度是否是中心化的隱患

15.其他

Cosmos與波卡的區(qū)別：https://xiaozhuanlan.com/topic/0567839241