万字雄文详解Cosmos运行原理：从区块链结构到互操作性

来源：以太坊爱好者

原文标题：《科普 | Cosmos 区块链的工作原理，Part-1：比较 Cosmos 与比特币、以太坊》、《科普 | Cosmos 区块链的工作原理，Part-2：如何跨链，为何要跨链 ?》作者：Preethi Kasireddy，区块链真伪验证平台 TruStory 创始人兼首席执行官，曾供职于高盛、a16z、Coinbase翻译及校对：stormpang、IAN LIU、阿剑、安仔、Clint

目录

• Cosmos 是什么？
• 区块链结构简介比特币栈层结构以太坊栈层结构
• 基于比特币与以太坊构建应用程序
• Cosmos 区块链结构Cosmos 共识层Cosmos 网络层Cosmos 应用层
• Hub 和 Zone
• IBC 是如何工作的
• 为什么互操作性如此重要？

密码学货币产业从未停下脚步。

一切都始于 2010 年比特币的问世。比特币刚问世时，所有人都认为它是数字货币的圣杯。曾经被认为不可能的事情现在变成了现实：第一个点对点（peer-to-peer，P2P）支付网络出现了。

即便在今天，对事物的信任仍然是最难以琢磨并且最珍贵的资产。比特币通过创建第一个「免信任型」系统，绕过了这一问题。但这仅仅是一个开始。

从那之后，比特币就成为了催生更广泛密码学创新的催化剂，这些创新也导致了一系列新型去中心化系统与金融基础设施的出现：以太坊（Ethereum）、闪电网络（Lighting Network）、EOS、Tezos、Maker…… 这个名单还在不断延长。

但是有一个项目与众不同：Cosmos。

在区块链领域，Cosmos 是一个「新生儿」。虽然它的理念已经出现有一段时间了，但其开发团队一直在背后慢慢地开发以确保 Cosmos 设计及实现的正确性。这也使得 Cosmos 最近才公开推出。

因此，有很多人看过 Cosmos 项目之后却不理解它也就不足为奇了。简单浏览 Cosmos 相关资料并不会让他们能够直观地了解 Cosmos，反而会让他们有更多疑问：

什么是 Cosmos？Cosmos 的工作原理是什么？与比特币、以太坊相比 Cosmos 有什么不同？Cosmos 的特点是什么？

我已经知道 Cosmos 团队快两年了。老实说，当我第一次听说他们在做什么的时候，我和其他人一样对它的概念一无所知。

但当我更深入地了解 Cosmos 之后，我开始非常欣赏它。我这么说不仅是为了引人注目，是真正地发自内心。

我对 Cosmos 非常着迷，所以我们决定将 TruStory 应用构建为一个 Cosmos 区块链应用。（插播：我将在之后的文章中更详细地阐述我们为什么会做出这个决定）

尽管如此，关于 Cosmos 仍然有很多困惑。所以我决定专门为此写一篇文章。我想让读者对 Cosmos 是什么以及它在区块链世界中的定位有一个更深层次的理解。

你准备好开始了么？理清思绪，带上你的思考帽，系好安全带。我们要开车啦！

Cosmos 是什么？

Cosmos 是这样定义自己的：

「一个由多条独立平行区块链组成的去中心化网络，每条平行区块链均采用 BFT 共识算法（例如：Tendermint 共识）。」

哇，好拗口啊！让我们把这个定义拆分成几个容易理解的部分。

独立平行区块链的去中心化网络

我在这里假设读者已经对区块链非常了解了！不过，我还是快速回顾一下：

简单来说，区块链是一个分布在许多计算机上的数据库，每台计算机上的数据库都保持相同的状态。换句话说，每台计算机上的数据库所包含的数据都完全相同。这些计算机共同组成了所谓的「区块链网络」。

比特币和以太坊都是区块链，而 Cosmos 是由许多这样并行运行的区块链组成的区块链网络。

如果你不能完全理解刚才说的，那么在进一步了解 Cosmos 工作原理之前，你最好再多读一些关于区块链的基础知识。（编者注：中译本见文末超链接《区块链是什么鬼》）

「每条区块链都采用 BFT 共识算法」

BFT 是 「Byzantine Fault-Tolerant （拜占庭容错）」的缩写。一条拜占庭容错的区块链能够在网络中部分节点宕机 以及 / 或者 作恶（即所谓「拜占庭式节点」）的情况下，保证网络依旧具备「安全性」与「活性」等性质。安全性与活性能够确保区块链网络中每个节点维护相同的状态。

插播：如果你想要更深入地了解什么是安全性（Safety）与活性（Liveness），请阅读我的这篇有关分布式共识的文章。（编者注：中译本见文末超链接《分布式共识的工作原理，Part-2》）

因此，一种 「BFT 共识算法」 乃是定义了计算机间通信与协调、使得区块链具有拜占庭容错能力的算法。Cosmos 网络中的所有区块链都采用某种 BFT 共识算法。

比特币和以太坊的共识算法不是典型的 BFT 算法。所以它们不符合 Cosmos 网络中区块链的定义。（值得注意的是，虽然它们不是拜占庭容错的，但仍然可以让比特币和以太坊等区块链加入 Cosmos 网络，仅仅需要一些额外的步骤。如果你觉得费解，不用担心——我们将稍后对此进行更深入的研究。）

插播：如果你还是不清楚什么是 BFT，我在这篇文章中写得蛮清楚了。（编者注：中译本见文末超链接《分布式共识的工作原理，Part-3》）

「Tendermint 共识算法」

Tendermint 是由 Cosmos 开发者提出并构建的一种 BFT 共识算法。Cosmos 网络中的区块链可以使用 Tendermint 共识或任何其他 BFT 共识算法。稍后我们将在本文了解更多关于 Tendermint 的内容。

简单来说，Cosmos 网络是一个由多条并行运行的独立拜占庭容错区块链组成的生态系统。这些区块链是 独立运行的，并且能够与其他区块链进行 互操作。

现在你可能会想，「为什么区块链之间要进行互操作呢？」

好问题！我们很快就会讲到。但首先我们要回顾一下区块链的结构。

区块链结构简介

在深入研究 Cosmos 生态系统中区块链是如何工作和互操作的之前，让我们先回顾一下区块链结构的基础知识。

正如我们前面所讨论的，区块链是一个多机复制数据库，并且在每台计算机上维护相同的数据。这种类型的分布式系统也被称为「复制状态机」。

复制状态机是一种多机复制的确定性状态机，但因为网络中每台计算机都维护着相同的状态，因此在功能上看起来就像一台单机。

听起来很熟悉，对吧？回顾上文区块链的定义，这里的定义仅仅是将「数据库」替换为「状态机」、「数据」替换为「状态」，相信你能明白我的意思。

「确定性」 可以简单地理解为，给定一个确定的输入，状态机将始终产生相同的输出。在区块链系统中，「确定性」意味着如果你从一个给定状态开始执行相同的事务序列，你总是会得到相同的最终状态。

复制状态机从某个状态启动。每笔有效事务都将导致系统状态转变到下一个状态（这与数据库中条目更新相同：如果你更新某个条目，数据库将迁移到包含该更新后数据条目的新状态）。

复制状态机在概念上有三个栈层：

1）应用层

应用层负责定义状态变迁，并在事务发生后更新状态机状态。

2）网络层

网络层负责将在某一个状态机上执行的事务传播到网络中其他所有状态机上。

3）共识层

共识层由算法组成，负责确保在事务执行后每一台状态机都存储相同的状态（即，某一状态机无法伪造不存在的事务）。

3a）抗女巫攻击层

试图在去中心化公网运行的复制状态机还需要第四层（「抗女巫攻击层」），确保任何一台状态机都不能破坏网络。如果没有这一层，状态机可以通过创建许多假身份来篡改状态，从而获得与其投入不成比例的影响或收益（即，发起女巫攻击）。

总之，应用层负责定义状态与管理状态迁移。网络与共识层负责保持每台机器上状态一致（即，确保网络中每个数据库数据一致）。抗女巫攻击层（显然）负责避免女巫攻击。

现在，让我们看看在比特币区块链和以太坊区块链中是如何定义与实现这些栈层的。

比特币栈层结构

1）应用层

比特币的主要应用是 P2P 交易。比特币使用 Script （一种堆栈式非图灵完备的语言）来定义与执行交易。当发送方通过交易发送比特币时，发送方将使用脚本来编码指定谁才能掌控这笔资金。Script 包含一组操作码或者说命令，发送方可以使用这些操作码来指定要花费一笔比特币所需满足的条件。

2）网络层

当发送方向接收方发送比特币时，该转账交易必须被广播到网络中，才能使矿工将其打包进区块中。比特币使用一种「Gossip 协议」来确保每个节点都会将其接收的所有新区块或交易发送至邻居节点（peer）。Gossip 协议是确保消息在全部节点间传播的 P2P 协议。比特币网络中所有节点都会将其新接收的有效交易立即发送给其邻居节点，从而使得待打包交易能够在几秒钟内通过点对点网络传播到大多数节点。

3）共识层

在交易被转播到网络中后，还需要将其添加到区块链中才能完成转账（即让网络中的计算机都来执行这个事务）。验证交易并将其打包到区块中的过程称为「中本聪共识（Nakamoto Consensus）」。中本聪共识的运行原理可以在其他论坛或文章找到。如果你想深入了解，这篇文章是一个很好的入门文章。

3a）抗女巫攻击层

中本聪共识依赖于「工作量证明（Proof-of-Work）」来防止女巫攻击。基本上，产生一个新区块所需的算力使得比特币共识协议自身能够抵抗女巫攻击。由于矿工需要大量的算力来产生下一个区块，使得他们无法在不增加大量算力（与资金）投入的情况下「伪造」多个身份。

以太坊栈层结构

1）应用层

与比特币不同，以太坊的设计初衷是构建一个能够运行去中心化应用的平台。以太坊包含一种高级语言（即，Solidity），使得开发者能够通过编写智能合约定义去中心化应用的具体功能。EVM （以太坊虚拟机，Ethereum Virtual Machine）是以太坊应用层的核心。EVM 使用 EVM 编译器将智能合约代码编译成字节码，用户可以通过交易的形式，将该字节码上传到区块链之后，EVM 就可以执行这些字节码，从而改变去中心化应用的状态（即，更新以太坊节点存储的该智能合约相关状态）。由于以太坊网络中所有节点均运行 EVM，这也保证所有节点的状态一致。

2）网络层

与比特币相似，以太坊也使用 Gossip 协议，使得节点能够与其邻居节点通信。

3）共识层

为了达成共识，以太坊使用了与中本聪共识相似的「Ethash」，但 Ethash 与中本聪共识有一些关键区别。如果你需要了解以太坊共识算法的工作原理，请阅读我之前的一篇文章。（编者注：中译本见文末超链接《以太坊的工作原理》)

3a）抗女巫攻击层

与比特币一样，Ethash 依赖于工作量证明（目前为止，译者注：未来以太坊 2.0 将切换到 PoS 共识机制）来抵御女巫攻击。

基于比特币与以太坊构建应用程序

我希望以上内容让你对区块链结构有了一定了解。当我们讨论 「比特币」 或 「以太坊」时，这些名字指的是相关的所有栈层。因为比特币和以太坊是由这些栈层组成的整体。

你无法将以太坊智能合约与其底层 Ethhash 共识层分开，也因此单独讨论这两个主题都没有意义。比特币也是如此，不使用中本聪共识与工作量证明你就无法进行比特币交易。

另一方面，Cosmos 采用了一种稍微不同的模式：它将应用层与共识层和网络层分开。

因为 Cosmos 的目标是建立一个区块链网络，所以这样设计是有意义的。在这个区块链网络中，每条区块链是独立的，并且有它自己的需要和要求（即，它自己的应用）。在这种情况下，想要提出一种一刀切的、适合所有区块链的应用层，是行不通的。让我们用几个例子来研究一下原因。

比特币局限性的一个例子

假设我们准备构建一个货币应用程序。在这种情况下，像 Bitcoin Scrypt 这种简单的基于堆栈的脚本语言是最佳选择。比特币脚本语言不仅可以很好地实现从一个地址到另一个地址的价值转移，并且非常简单、不是图灵完备的。

因此，它不太容易受到各种类型安全漏洞的影响，而这些安全漏洞可能会严重影响图灵完备的编程语言。这正是我们在处理货币与价值存储时想要的。但是这种简单也有其局限性。

使用 Scrypt 做任何更复杂的事情（例如：去中心化预测市场）都非常困难。比特币脚本语言不仅受其可执行代码复杂性限制，对于开发者来说也十分不友好。更糟糕的是，比特币区块链交易的处理速度很慢（大约每秒 7 笔交易）。因此，直接在比特币区块链上构建需要高交易吞吐量的应用是不现实的。

以太坊局限性的一个例子

与比特币相反，以太坊的 EVM 与智能合约语言（Solidity）是为了支持更灵活的应用程序而设计的。Solidity 是一种图灵完备的编程语言，因此理论上它可以执行任意算法复杂度的代码。

在实际应用中，由于 Solidity 易出错并易受到安全攻击，所以使用 Solidity 开发任意复杂度的程序是相当困难的。这种特性与处理价值转移的应用程序背道而驰，在后者这个场景种，安全性是最重要的。

此外，智能合约也非常难以升级，从而使得迭代开发非常困难。合约一旦部署上链，你所能做的就只有祈祷它能够平稳运行！与比特币一样，以太坊交易处理速率也非常低（大约每秒能够处理 15 笔交易），因此在以太坊区块链上构建需要高交易吞吐量的应用也是不现实的。

Cosmos 的提出就是为了满足这种实际业务需要，尽管它为此做了一些较大的牺牲。接下来我们将深入研究具体的细节。但在那之前，我们还必须理解 Cosmos 中区块链的三个栈层是什么样的。

Cosmos 区块链结构

首先，我们将从共识层开始了解 Cosmos，以便更好地理解在 Cosmos 上开发应用程序与使用比特币或以太坊有何不同。

Cosmos 共识层

Cosmos 网络中区块链使用 Tendermint 共识算法。Tendermint 是一个 2014 年诞生的开源项目，「旨在解决比特币工作量证明（Proof-of-Work, PoW）共识算法的速度、可扩展性与环境问题」。

Tendermint 共识算法是一个 「无视应用层（application-agnostic）的共识引擎」。从本质上讲，这意味着任何区块链都可以使用 Tendermint 共识算法，它是拜占庭容错的，并且使用 PoS 算法来抵御女巫攻击。

又是一大堆术语！我们好好说道说道。

Tendermint 共识是如何运作的？

回顾一下，共识算法的存在是为了保证事务执行后，状态机中保存的状态一致；而 Tendermint 共识算法定义了一种「能让所有节点对下个区块达成共识」的规则。

让我们看看相关因素及规则是如何运作的吧！

验证者

负责达成状态一致的节点称为「验证者」。任何愿意协助整个网络达成共识的参与节点都能成为验证者；作为回报，验证者会获得交易手续费和区块奖励。Tendermint 整合这些验证者的投票结果，确定下一个区块的正确状态。

通过质押对抗女巫攻击

每个验证者的票都有自己的投票权重，投票权重通常是在创世块产生时确定，或是在开始运行后根据应用层开发者所设计的某些逻辑来决定。一般来说，由验证者锁在系统中的代币量（作为质押品）决定投票权重的大小，这种质押物也被称为「保证金」。

Consensus 共识

按照规则，验证者要按轮次（round）对每一个区块达成共识。每一轮都包含三个基本步骤：提议阶段（Propose）、预投票阶段（Prevote）、预提交阶段（Precommit），以及两个后续步骤：提交阶段（Commit）、新高度阶段（NewHeight）。从抽象角度来看，验证者按照以下协议规则共同决定下一高度要使用什么区块：

1. 首先是提议阶段，由指定的验证者提出一个区块——每一轮中的提议者都是从有序的列表中按照投票权重的比例，确定性地选择出来的。
2. 接着进入预投票阶段——每一位验证者广播他们各自的预投票。
3. 当该轮次中某一区块收到超过 2/3 的预投票，我们就称其为 「polka」。一旦出现 「polka」，就进入下一个阶段。
4. 进入预提交阶段，由每一个验证者广播他们的预提交的投票。如果某一特定区块收到超过 2/3 的预投票，就进入提交阶段，这个阶段会将区块加入区块链，并增加区块高度。每当有新的区块加入区块链，所在区块链的区块高度就 +1。如果失败，则要么返回预投票阶段，要么回到预提交阶段。

要注意的是，在任何高度上，都有可能需要一轮以上的投票才能提交一个区块。因为可能出现以下情况：

• 被指定的「提议者」在应该提出区块时掉线
• 提议者所提出的区块违反一些预先定义的规则
• Tendermint 依靠超时机制确保区块链出块不会遇到延宕。如果在超时前，提议区块没有收到超过 2/3 的预投票，则由新的提议者再次进行提出区块流程。

协议细节详见 此处。

总的来说，Tendermint 选择了与比特币的中本聪共识、以太坊 Ethash 不同的路线， 让我们做一些重点对比：

确定性与概率性

与中本聪共识和 Ethash 这类概率性共识不同， Tendermint 是确定共识——这意味着 Tendermint 每个区块都是最终确定的，而不像比特币的区块只是处于「很可能」被确定的状态。

我们回顾一下中本聪共识，区块总是处于「未确定」状态——只有确定某个区块在「最长链」上，才能有把握认为该块正在被最终确定，这也是为什么比特币交易需要等「6 个区块确认」。

而在 Tendermint 中，验证者成功投票及提交后，区块就立即被确认了。

固定验证者 vs. 可变验证者

中本聪共识及 Ethash 允许矿工随时选择加入或退出，并不需要其他矿工提前知晓。相反地，Tendermint 共识要求维护一个事先知晓且固定的验证者集合，验证者身份是靠他们的公钥来辨认的。

领导 vs. 无领导

中本聪共识及 Ethash 没有指定领导者来提议下一个区块（i.e. 任何矿工都有可能挖到下一个区块）。另一方面，Tendermint 选择领导者，或称为提议者，负责提出下一个区块。

明确的 vs. 模糊的超时机制

中本聪共识和 Ethash 没有使用超时机制来确保矿工一定能出块，而 Tendermint 有明确的超时机制保证区块链的出块过程不会遭遇延宕。

100 个验证者 vs. 1000 个验证者

Tendermint 遵循传统的一致性共识算法，每个验证者之间都要进行通信。考虑到通信开销，Tendermint 无法像比特币或以太坊那样可以无限增加验证者。Tendermint 共识安排了 100 个验证者。

因此 Tendermint 的缺点之一就是，它要求事先知晓所有验证者，而且不允许验证者随时加入或退出；这与比特币或以太坊不同。

除此之外，Tendermint 还要求整个系统维持统一时钟；虽然在实践中 Tendermint 已经证明通过整合每个节点的时间戳就能维护统一时钟，但大家都知道同步时间是个非常复杂的理论问题。

Tendermint 的验证者少于比特币，而且要求事先知道验证者集合，因此可能会有人提出 Tendermint 共识协议「不够去中心化」的质疑。

但是，去中心化是见仁见智的。Okay，先不抖机灵，我想说的是去中心化是为了达到某种目标的手段，而不是目标本身；我不喜欢在了解去中心化的目标前就妄下评论。

我认为在许多案例（甚至是大部分情况）下，只要破坏系统的代价够大，并且有针对攻击者的防御及惩罚机制，则 Tendermint 要求固定且事先知晓验证者集合的保守方法是可行的。

如果我们回顾预测市场的例子，我会说去中心化预测市场应用，根本不需要像健全货币或是价值存储应用一样具备这么高级别的去中心化程度，有 10 、20 或 100 个验证者足矣。

以 TruStory 为例，我们使用 Cosmos SDK 构建后端应用逻辑，将应用的状态和逻辑存在区块链上，而前端某种程度上是私有的——Cosmos SDK 允许我们建立用来赏善罚恶的激励系统、透明化展示数据层、允许用户分享网络的所有权及治理权，还可以共同决议未来的事务、踢出恶意使用者，并按照个人喜好针对用户层或基础层设计网络。对于开发者来说，他们也能基于后端区块链逻辑构建自己的开发工具及服务。因此有 10 个或 100 个执行并验证交易的验证者，就能够保障使用者和开发者对于透明性、所有权、责任归属的需求。

如果你能明白 Tendermint 以「选择固定且事先知晓的验证者集合」作为牺牲，所带来的利益，你会对这些原本不可能实现的神奇特性充满赞叹：

安全性及活跃度

Tendermint 的协议保证安全性及活跃度。假设超过 2/3 的验证者投票权重没有掌握在拜占庭验证者手中（也就超过 2/3 验证者是遵守协议的），换句话说少于 1/3 的投票是恶意的 ，则协议就能保证网络的安全性及活跃度（i.e. 验证者永远不会在相同的块高度提出冲突区块，区块链永远会正常出块）。

高性能

Tendermint 共识的出块时间可以低至 1 秒，达到每秒处理数千笔交易的速度，让 Tendermint 更适合需要频繁交易的应用。

即时确认

在区块链世界中，最终确定性（Finality）意味着一旦区块被提交上链，我们就能确定直至该区块之前的整个区块链的状态。

如我们前面提到的，中本聪共识有其概率性，所以没有办法保证最终确定性。你只能基于大多数矿工可能还在该分叉中挖矿的概率，保证你的交易所在的分叉链是共识链。

但是，Tendermint 要求验证者对每个区块进行投票及最终确认。所以我们可以说，在少于 1/3 恶意验证者的情况下，交易能够被「即时确认」——当区块被创建出来，使用者就知道他们的交易已经被确认了。

责任制

Tendermint 使用 PoS 作为抗女巫攻击机制——要求验证者质押代币（i.e. 他们的「保证金」），以确保节点不会通过创建多个虚假账户来欺骗系统。

PoS 比 PoW （PoW 的证明来自矿工解出下个区块哈希所耗费的算力）更节能，但是它固有的「无利害关系」缺陷导致验证者能轻易作弊。

Tendermint 通过罚没保证金来处罚违反协议规则（e.g. 替冲突区块投票，及广播未验明的投票）的验证者，避免发生无利害关系问题。说得更具体点，协议存在「锁定规则」，规范了每个验证者在投票给特定区块时能做的行为。举例来说，一旦验证者预提交投票后，它就被「锁定」在该区块；只有在下一轮中要让一个不同的区块成为 polka 时，该验证者才能解锁并预提交另一个区块。如果违反锁定规则，验证者会被罚没保证金。

更简单的轻客户端

轻客户端比全节点「更轻巧」，因为它们不存储区块链的所有状态，只存储区块头。除非是负责验证和出块的挖矿节点，或验证者节点，不然大部分节点其实不需要存储区块链全状态。

轻客户端下载从创世区块开始到当前区块的区块头，而不去下载和存储整条链。相比于全节点，轻客户端只需要存储少量数据，因为区块头就足以验证某些特定交易的有效性。

最酷的事情在于，基于 Tendermint 的区块链的轻客户端甚至无需同步所有区块头，只要周期性的下载区块头就行。

就像我们前面讨论的，Tendermint 与比特币、以太坊不同，其所有区块都要经过投票及最终确认；因为每个区块都经过最终确认，所以轻客户端只要注意验证者集合的变化——只要知道最新的验证者集合，轻客户端就能下载最新的区块头，并验证这些区块都有大于 2/3 的验证者投票。

Cosmos 网络层

如我们上面所说的，Tendermint 的共识依靠验证者在每一轮进行投票来完成。因此，节点间必须能沟通及传递讯息，确保网络中所有参与者都能看到相同数据。

与比特币和以太坊一样，Tendermint 使用 gossip 协议快速传播最新的区块链状态。

网路中的节点不一定要成为验证者才能在网络共识过程中发挥作用。举例来说，节点可以是轻节点或是全节点，而不是验证者；这类节点也被称为 「非验证者节点」。

验证者及非验证者节点都要肩负传递数据的责任（例如提案数据、区块数据和投票数据），以确保所有节点都能收到系统正在产生的信息和交易。

Cosmos 应用层

目前，我们已经了解 Tendermint 网络层及共识层的核心组成部分；网络层负责网络中所有计算机之间交易的传递，Tendermint 共识算法确保状态机的一致性（即所有节点中的区块链都是一致的）。

但我们传递和验证的到底是什么交易？这里就引出了应用层。

Cosmos 应用层负责：

• 定义和提交需要被记录进区块链的交易
• 在交易通过共识层提交后，持续更新区块链状态

使用 Cosmos SDK 构建应用程序

Cosmos SDK 提供一套构建应用层的框架，就像是区块链界的 Ruby-on-Rails （Ruby-on-Rails 是一种让开发者轻松通过默认设置构建网页端应用的框架），Cosmos SDK 也为开发者提供了一种基于 Tendermint 内核构建安全的区块链应用的框架。

要记住，区块链就是一个在所有节点将状态做相同备份的状态机，而 Cosmos SDK 让你可以构建能在多个节点间进行复制的实际状态机。SDK 让你自定义应用的状态、事务类型，及状态-转变函数所需的功能和工具。

Cosmos 应用如何运行（抽象视角)

Cosmos SDK 提供一种「multistore」机制来定义及维护应用层状态机的状态。Multistore 将应用层的状态划分到不同组件，通过各自的「模块」进行管理。

Cosmos SDK 的强大之处就是它独特的模块化设计，每个模块定义及维护一个状态子集，这些状态子集构成完整的区块链。举例来说：

• 银行模块：允许你在应用中持有代币，及进行代币转账
• 权限模块：允许你创建及管理账户和签名
• 质押与罚没模块：允许你通过编码构建 PoS 共识机制

每个模块都是个小状态机，可以相互聚合生成总体状态机。

应用开发者按照每个模块和修改状态的惯用逻辑来定义子集，除了 Cosmos SDK 提供的模块，开发者还能调用第三方模块。

这种用于构建区块链应用的插件模块非常强大，因为它赋予开发者使用 SDK 或外部模块的灵活性。

应用层如何与共识层交互？

发生在应用层的交易通过区块链应用交互界面（ABCI, Application Blockchain Interface）与 Tendermint 共识及网络层通信。

ABCI 是 Socket 通信协议，连接 Tendermint 核心（共识 + 网络）与应用。它可以兼容任何编程语言，也就是说使用 Cosmos SDK 构建的区块链应用理论上能以任何语言编写，而不仅仅是 Tendermint 底层共识和网路层所用的编程语言。

注意：当前版本的 Cosmos 主要支持 Golang，后续会加入更多语言。

总而言之，Cosmos SDK 允许开发者基于 Tendermint 内核构建去中心化应用，这个应用理论上能用任何语言开发，并通过 ABCI 连接 Tendermint 共识引擎。

将应用层（Cosnos SDK、ABCI）与网路层、共识层（Tendermint 内核）剥离，能让开发者在开发各种类型应用的时候有更大的灵活性，再加上 Cosmos SDK 允许这些应用以任何语言开发（e.g. Golang），让区块链 App 开发过程更像平常的应用开发的样子。

这与在以太坊上开发应用形成鲜明对比，因为后者要求开发者学习新语言 Solidity ，还要克服 Solidity 的诸多限制和缺陷，而且 Golang 比 Solidity 具备更多的开发工具，开发体验好上 10 倍。

除此之外，全部的以太坊 App 都基于单一网络进行操作，这么做的优势是这些 App 能够共享以太坊的标准，以及相应而生的规模效应；缺点是所有这些 App 都共享以太坊共识层，会受到新加入的应用体量大小的影响。 此外，整个网络必须作为一个巨大的单元来管理，会被治理理念和意识形态分歧所束缚，使得扩展难以进行。

Cosmos 区块链应用不会受到这些限制，每个应用都有独立的网络、自己的共识层及治理层。

开发者有很大的自主性来决定它们的共识层权限，还能选择基于代币质押数量推举公开的验证者集合，或是通过预授权设置私密验证者集合。这种自由选择验证者集合的规则，意味着区块链对于自己的链有更大的自主性。

当然，这样的好处伴随某些牺牲：Cosmos 网路中的每个区块链应用都必须导入自己的验证者、社群，及经济体系；无法像以太坊一般，直接蹭用所有验证者、强大的社群，及已有的经济体系。

在这第一篇文章里，我们对比了 Cosmos 网络中的区块链架构与比特币、以太坊的不同。这种架构赋予区块链应用对于自己的链更大的自主性。

在第二部分，我们要深入讨论 Cosmos 中相互独立的区块链如何进行交互；更重要的是回答「为什么区块链需要互相进行交互」。Cosmos 最关建的特性之一是互操作性，即赋能多种区块链之间的交互。为了更好地理解这一特性的运作原理，我们首先需要了解 Cosmos 中用于支撑其互操作性的基础架构：「 Hub 以及 Zone 」。

Hub 和 Zone

Cosmos 网络中的区块链应用了一种中心辐射模型：

位于中心的是 Hub （「中心枢纽」）。Hub 管理着许多被称为 「Zone」 的独立区块链（下文 「 Zone 」 指代区块链），由 Hub 来追踪记录各个 Zone 的状态，而每一个 Zone 有义务不停地把自身产出的新区块反向汇报给 Hub 。类似地，每一个 Zone 也需要同步 Hub 的状态。

但这里有个棘手的问题—— Zone 之间并不直接同步各自的状态，而是通过发向 Hub 的数据包间接通信。要想弄清楚这一流程，我们首先需要调研其背后的支撑机制：跨链通信（IBC）。

IBC 是如何工作的

Hub 与 Zone 直接通信，而 Zone 与 Zone 之间通过 IBC 间接通信。当 Zone 对 Hub 建立起一个 IBC 连接，它可以自动访问其他连接到该 Hub 上的 Zone ，这意味着 Zone 无需与其他 Zone 连接，而仅仅连接到 Hub 上即可。

通过保持各种跨 Zone 代币的固定总额，Hub 可以预防双重支付问题（Double Spend）。这些代币可以通过一种被称为「币包」 的特殊 IBC 数据包而实现 Zone 之间的跨链转移。

当一个 Zone 通过 Hub 收到来自其他 Zone 的代币时，它只需要信任 Hub 以及代币来源的 Zone，而不需要信任网络中所有其它的 Zone 。

让我们看个例子：

假设当前由两条区块链：Zone 1 以及 Zone 2 。现在如果我们想要从 Zone 1 上发送代币到 Zone 2 ，会发生什么呢？

要让数据包从 Zone 1 发送到 Zone 2 ，Zone 1 首先要向 Hub 发送一个指向 Zone 2 的数据包。

紧接着 Hub 向 Zone 2 发送一则证明，表示 Zone 1 向其发布了一个数据包。

在此之后，Zone 2 必须验证关于 Zone 1 的证明是否真实。为此，Zone 2 要利用 Zone 1 存储在 Hub 中的区块头。我们前面提到过 Hub 帮助 Zone 同步记录其它每一个 Zone 的状态，而 Hub 是通过记录其它 Zone 的区块头实现这一功能的。

现在你可能会疑问：为什么 Cosmos 不直接利用 IBC 建立 Zone 与 Zone 之间的连接？为什么需要进行 Hub 和 Zone 的设计？事实上，随着接入到网络中 Zone 的数量上升，以直连方式实现通信会导致链路数量呈平方级上升。以 100 个 Zone 接入到网络中为例，如果各个 Zone 直接都要建立起 IBC 连接，则网络中需要有 4950 条通信链路！如此快速的增长显然会令网络不堪重负。

采用「 Hub 与 Zone 」模型令 Cosmos 能够无视 Zone 的数量而实现跨链通信，并支持网络的不断拓展。

Cosmos 网络的正常运转离不开 IBC ，正是因为它才能让多条承载着不同应用和验证者集的独立区块链（即 Zone ）实现互操作。

创世 「Hub」: Cosmos Hub

如前所述，Hub 是连接不同 Zone 的组件，而 Cosmos Hub 正是 Cosmos 网络中第一个 Hub ，它通过 IBC 连接其它的 Zone 。Cosmos 网络上构建的第一个区块链（或者说 Zone ）会应用该主 Hub 来与网络中其他的 Zone 进行交互。这就意味着 Cosmos Hub 必须具备足够高的安全性（即许多验证者）来保证使用它的 Zone 能安全地进行互操作。

桥接非 Tendermint 共识的区块链

目前为止，我们探讨了基于 Tendermint 共识的区块链（即 Zone ）是如何利用 IBC 和 Hub 进行交互的。然而 Cosmos 并不局限于 Tendermint 共识链的跨链操作。

我将在下文粗略解释 Cosmos 如何兼容其它不同共识算法的区块链。

一般来说，区块链可以分成两种类型：不可逆链和概率链。

不可逆链（Determinmistic chain）指的是每个区块的状态都是确定的（finalized），在未来的任意时刻你都可以从创始块开始复现推演每个区块的状态（例如基于 Tendermint 共识的区块链）；概率链（Probabilistic chain）是指你只能根据区块链网络参与者在不同分叉链上的比例，而以一定概率认为某条链是主链（例如比特币）。Cosmos 中的 Hub 理论上可以接入上述两者，只不过对于概率链的支持在实践中要相对麻烦一些。

这是因为从底层设计来讲，IBC 发挥作用的前提在于区块链的不可逆。如果区块链是概率链，Hub 就不能保证跨 Zone 的代币总额固定。如前所述，Hub 如果想要实现无双重支付的跨 Zone 代币转移，就必须保证在 Zone 与 Zone 之间某一代币的总额是固定的。

Cosoms 试图通过 「Peg Zone」 来实现概率链的互操作性。

Peg Zone 是追踪记录另一条区块链状态的区块链，它要将自己桥接的某条概率链上的状态确定为不可逆的，使得这些状态得以与 IBC 兼容。

还跟得上吗，少年？现在我只剩下最后一个（同时也是最重要的）问题要跟你探讨：区块链究竟为什么需要要互操作性？

为什么互操作性如此重要？

众所周知，区块链是不可逆账本。然而和其他软件一样，随着时间推移，用于构建区块链的软件也需要进行迭代和升级。一蹴而就、无懈可击的软件简直是天方夜谭，所以软件的改动不可避免。「治理」问题就是讨论如何对区块链底层软件的改动进行提案、决议以及应用。

以比特币为例，由比特币基金会、比特币核心开发者、矿工以及用户来发起底层改动的提案，并以协作的方式实现升级。而以太坊则依靠开发者和用户社区的群策群力来做出此类决议。

Cosmos 的做法与上述两者大相径庭。不同于常见的、统摄全网的治理机制，Cosmos 允许每个 Hub 构建自己的治理策略。

任何持币人都可以发起变更提案，由该 Zone 或 Hub 的验证者和持币委托人对提案进行投票。提案的内容包括但不限于对系统预置参数的变更（例如区块 gas 上限）、软件更新，甚至是 hub 在处理窃币、入侵或漏洞时所采取的政策性升级。

同样每个 Zone 也具备各自的治理机制。

举例而言，Cosmos 支持在 Hub 端强制应用不可逆性的同时，每一个 Zone 都可以根据自身需要设置是否不可逆。想要了解更多，可以阅读这篇文章 《 Cosmos 中的 Hub 治理机制流程》。

在我看来这种设计十分强大，同时也被大大低估了。如果非要从本篇博文中提取出什么核心论点的话，也就是下面这一段话了：

Cosmos 在底层设计上不认为能通过有限的规则治理大千世界中形形色色的经济网络，不认为存在特定的一个规则集合让大家都称心如意。这一道理不言自明，看看比特币自运行以来由于哲学和政治分歧引起的众多分叉。另一方面，从以太坊的治理中我们可以看出，持币人无法以规范的形式实现治理或是形成合力拒绝不规范的治理，这对生态的发展起到了副作用，阻碍了以太坊的更新升级。

Cosmos 试图通过独立区块链之间的互操作性解决这一问题，即使并且尤其这些区块链拥有不同的治理政策。因此 Cosmos 最核心的价值属性就是在社会和经济领域的可拓展性。它为其生态之上的用户和开发者提供了无限的自由，以及不加约束的实验潜能。

感谢你陪我讨论了一路 Cosmos （网络）！

难以置信你听我叨叨了这么多，佩服！本文就到此为止了，期待在下一篇文章与你相遇！