【全球速看料】Cosmos-1-理論知識全解析 gumptlu.work/Cosmos-pdf下載教程

資料

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

一、概述與簡介

【資料圖】

1.是什么

Cosmos 是一個獨立并行區塊鏈的去中心化網絡，每個區塊鏈都由 Tendermint 共識這樣的 BFT 共識算法構建。

Cosmos 不是一個產品， 而是建立在一套模塊化、適應性強和可交互工具之上的生態系統。適合于公有鏈或者私有鏈。

三個特點：

**模塊化開發：**Cosmos 通過 Tendermint BFT 和 模塊化的 Cosmos SDK 使區塊鏈易于開發?？珂淐osmos 使區塊鏈能夠通過 IBC 和 Peg-Zones 相互轉移價值， 同時讓它們保留主權。強拓展性：Cosmos 允許區塊鏈應用通過水平和垂直可擴展性解決方案可支持數百萬用戶。

2.區塊鏈層級

2.1. 三層模型

應用程序：負責更新給定的一組交易，即處理交易的狀態，更新狀態。網絡：負責交易和共識相關消息的傳播。共識：使節點能夠就系統的當前狀態達成一致。

2.2. 耦合性

BitCoin

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

Ethereum

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

在應用層實現了EVM虛擬機來處理智能合約，簡化了去中心化應用的開發，但是整體上還是耦合的

缺陷：

可拓展性（scalability）

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

可用性（Usability）

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

主權（Sovereignty）

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

Cosmos

將網絡層和共識層打包成通用引擎用于開發，允許開發人員專注于應用程序開發，而不是復雜的底層協議。

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

進一步對于應用層，Cosmos SDK 是一個通用框架，使用模塊化的思想簡化了在 Tendermint BFT 之上構建安全區塊鏈應用的過程。

通過Tendermint BFT引擎構建的各個區塊鏈Zone可以通過區塊鏈間通信協議（IBC：Inter-Blockchain Communication protocol）實現跨鏈的操作。

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

3.網絡結構

3.1 Zone

Cosmos網絡中各自獨立的區塊鏈，多條Zone與多個Hub組成復雜的Cosmos網絡。

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

3.2 Cosmos Hub

在 Cosmos 網絡中推出的第一個Hub 是 Cosmos Hub。 Cosmos Hub 是一個開放的**權益證明（POS）**的區塊鏈，其原生 staking 代幣為 ATOM，并且交易費用可以用多個 Token 支付。 Cosmos Hub 的推出也標志著 Cosmos 主網上線。

功能職責

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

3.3 light client

網絡中的輕客戶端，新的客戶端需要對當前網絡進行同步：

同步過程

同步當前所有Validator集合

確定網絡最新狀態

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

4.角色

4.1 Validator驗證者

1.概念

應用層的角色，擁有投票權重的節點， 負責出塊與投票。

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

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

Tendermint BFT 只處理區塊鏈網絡和共識，它幫助節點傳播交易和驗證追加交易到區塊鏈。出塊共識與主鏈共識是分開的。

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

2.成為驗證者

數量上的限制

在創世日那天，驗證器的最大數量將被設置為100個，這個數字將以13%的速度增長10年，并穩定在300個驗證器。

途徑

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

替換機制

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

懲罰機制

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

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

如果惡意節點的違規是不易找到證據的，那么可以通過絕大多數投票將其強制超時

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

4.2 No-Validator/delegator

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

5.協議

5.1 IBC

1.概念

inter-blockchain communication protocol區塊鏈間通信協議, 將開發者自由定義的區塊鏈（Zone）連接起來的協議。

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

異構鏈：網絡、共識、應用層結構與實現方式不同

IBC 允許異構鏈之間轉移價值（如 token）和數據，這意味著具有不同應用程序和驗證人集合的區塊鏈是可互操作的。 例如，它允許公有鏈和私有鏈間相互轉移 token。

2.作用

Hub與Zone交流的協議， 用于同步狀態。各個zone不斷提交區塊確認讓Hub能夠同步每個zone的狀態

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

3.包結構

Coin Packet

代幣包，跨鏈時發送的特殊的IBC包，它必須有發送鏈、Hub鏈、接收鏈的確認。

IBCBlockCommitTX

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

其中的交易結構：

SimpleProof是針對驗證區塊Hash的，AppHash則是采用AVL+樹保存應用程序狀態

IBCPacketTx

提供最近區塊的Merkle-proof，證明給定的包確實是發送方應用程序發布的

證明交易的正確性

交易結構:

其中IBCPacket的結構：

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

其中IBCPacketHeader的結構：

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

3.連接過程

類似于區塊鏈上的Tcp/IP協議

發起者不需要確認

更新Hub有關于Zone1的區塊，則在IBCBlockCommitTX上必須包含Zone1的塊hash，這樣IBCBlockCommitTx交易發布在Hub上就使Hub包含了Zone1的塊Hash

發起者需要確認的情況

發送方可以通過將初始包狀態設置為AckPending來要求發送確認。然后，接收鏈有責任通過在應用程序Merkle-Hash中包含一個縮寫的IBCPacket（沒有完整負載的IBCPacket稱為縮寫包）來確認發送

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

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

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

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

? 4.最后，“Hub”必須更新包的狀態，從AckPending到AckReceived。這個新最終確定狀態的證據應返回

到“Zone2”。

確認超時的情況

如果“Hub”沒有從“Zone2”收到350高度內的AckSent狀態，它將自動將狀態設置為Timeout。超時的證據可以在“Zone1”上發回，并且可以返回任何代幣

4.工作流程

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

跟蹤（Tracking）

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

鎖定（Bonding）

當 IBC 轉移被啟動時，ATOM 被鎖定（Bonding）在鏈 A 上。

中繼證明（Proof Relay）

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

驗證（Validation）

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

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

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

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

5.2 ABCI

Application Blockchain Interface區塊鏈應用接口，Tendermint Core使用ABCI與區塊鏈應用聯系, 使得編程區塊鏈應用可使用多種語言

消息類型

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

ABCI是底層（共識層與網絡層）即Tendermint Core與應用層的交互方式

AppendTx消息

區塊鏈中的每個交易都和此消息一起交付，應用程序需要根據事務的當前狀態、應用程序協議和加密憑據驗證使用AppendTx消息接收到的每個交易。然后經過驗證的交易將更新應用程序的狀態，存儲到k-v數據庫或更新UTXO數據庫

結構：

CheckTx消息

類似于AppendTx，但是只用于驗證交易，不改變狀態

? Tendermint Core的內存池首先通過CheckTx檢查交易的有效性，然后只將有效的交易轉發給其他節點

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

Commit消息

Commit消息用于計算對當前應用程序狀態的加密承諾，并將其放入下一個塊頭。

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

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

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

附加的ABCI消息

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

6.共識機制

6.1 Tendermint BFT

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

與PBFT的比較：

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

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

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

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

投票過程

兩個階段

PreVote預投票

PreCommit預確認

投票過程

? 1. 每個Validator可以對當前的區塊進行投票或者投票為空（nil）

? 2. 當對于當前區塊有大于2/3的PreVote時則將其稱之為Polka

? 3. 對于當前區塊有大于2/3的PreCommit則成為區塊的確認

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

timeoutproposal

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

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

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

? 在此期間整個系統的進程是異步的，只有Validator收到了>2/3的確認才會繼續進行

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

首先預提交/確認的區塊必須是Polka狀態的區塊

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

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

保證已經預提交的驗證器不能提供證據來預提交其他內容

7.安全性

7.1 拜占庭機制

確保只有大于三分之一的拜占庭節點才會破壞網絡安全

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

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

7.2 鎖定機制

· 任何一組Validator違反安全或者試圖攻擊網絡都會被協議識別

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

7.3 分叉問責制

當共識失敗，法律系統會進行識別和懲罰，當法律系統不可靠或調用成本過高時，驗證者可能被迫繳納保證金才能

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

8.數據結構

8.1 Merkle樹

1. 簡單樹

· 此Merkle樹用于對塊的交易和應用程序狀態根的頂級元素進行Merkle化。

2.AVL+樹

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

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

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

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

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

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

9.鏈上規章制度

實行一套實現約定好的規章制度為今后的系統問題作出解決 => 防止出現重大問題系統分叉

Cosmos的Validator和delegators可以通過提案的方式修改系統參數、協調升級系統、回滾政策、調整規章制度等

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

10.交易費

1. 個人交易

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

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

· 當交易結束后就會按照對應的費用扣除

2. 系統

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

11.性能

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

取自夏青論文中的對比結果：

12.應用

1.分布式交易所

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

2.橋接其他加密貨幣

1.2.1. 概念

· 橋接的區塊鏈必須同步保持最新的區塊，以此來實現Merkel Proof

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

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

1.2.2. 一般過程

發送代幣到Cosmos Hub

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

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

? 3. 當運行的全節點收到付款后（原鏈是pow機制的話需要足夠多的確認），在bridge-zone中創建相關的賬戶并且有對應的余額

從Cosmos Hub收回代幣到原鏈

? 1.在原鏈上將原鏈代幣轉移到特定的地址

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

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

1.2.3. 連接以太坊

原鏈發送幣到Cosmos

? 1. 發送以太幣到bridge_contract的賬戶上

? 2. bridge_contract會記錄當前bridge_zone上對應的Validator集合，這個集合可能和Hub的Validator相同

? 3. bridge_zone確認后創建對應的賬戶和余額

Cosmos返回幣

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

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

1.2.4. 連接比特幣

原鏈發送幣到Cosmos

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

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

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

Cosmos返回幣

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

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

13.激勵措施

創世紀上atom代幣和驗證器的初始分發將流向Cosmos資金籌集者(75%)、主要捐贈者(5%)、Cosmos網絡基金會

(10%)和ALL IN BITS, Inc(10%)。從創世紀開始，每年1/3的原子總數將獎勵給綁定驗證者和授權者。

黑客漏洞獎勵

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

14.優缺點

優點：拓展性強，通過Hub實現跨鏈支持去中心化的跨鏈，能夠拓展當前主流公鏈；輕客戶端同步當前網絡狀態迅速高效；解決了公鑰認證問題。

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

15.其他

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