走进Cosmos之入门

导读

跨链作为近两年来区块链技术一个炙手可热的方向，吸引了许多人的目光。

从技术层面看，Cosmos无疑可以与Polkadot并称“跨链双雄”，两者的技术路线并无明显的优劣之分，只是开发理念各有千秋。

Cosmos最初是由Tendermint团队构建的开源社区项目，它将自己定义为“一个由多条独立平行区块链组成的去中心化网络”，和Polkadot一样，也由中继技术实现。

Cosmos到底是如何解决跨链过程中遇到的各项问题的，本文通过对其架构和跨链交易流程的解读，带我们进一步了解Cosmos。

什么是Cosmos

Cosmos作为跨链双雄之一，定位为一个可扩展、易用、互操作的区块链互联网。

首先介绍Cosmos的三个重要组成部分

Hub：本质上是一条中继链，由官方进行维护，被当作跨链消息的信任中心；

Zone：参与到Cosmos网络中的应用链，允许不同类型的区块链加入进来；

IBC（Inter-Blockchain Communication Protocol）：链间通信协议。

他们三者的关系我们从上面的简图中看到，位于中心的是Hub。

Hub管理着许多被称为“Zone”的应用链，在Ｃosmos网络中，由Hub来追踪记录各个Zone的状态，而每一个Zone有义务不停地把自身产出的新区块反向汇报给Hub。

Hub与Zone直接通信，而Zone与Zone之间通过IBC（跨链协议）间接通信。

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

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

为什么Cosmos不直接利用IBC建立Zone与Zone之间的连接？

事实上，随着接入到网络中Zone的数量上升，以直连方式实现通信会导致链路数量呈平方级上升，如此快速的增长显然会令网络不堪重负。

Cosmos架构

Cosmos作为一个多链互操作的跨链平台，支持不同种类应用链接入到Cosmos的网络，如图所示：

一般来说，应用链可以分成两种类型：概率链和确定性链。

概率链（Probabilistic chain）是指只能根据区块链网络参与者在不同分叉链上的比例，而以一定概率认为某条链是主链（例如比特币和以太坊）。一般来说比特币通过6个区块以上来达到确认，而以太坊通过15个区块以上来达到确认。

确定性链（Determinmistic chain）指的是每个区块的状态都是确定的（finalized），在未来的任意时刻你都可以从创始块开始复现推演每个区块的状态（例如基于 Tendermint和BFT共识的区块链）。

Cosmos中的Hub理论上可以接入上述两者，只不过对于概率链的支持在实践中要相对麻烦一些。这是因为从底层设计来讲，IBC跨链通信协议发挥作用的前提在于区块链的不可逆。

所以Cosoms试图通过“Peg Zone”桥接链来实现概率链的互操作性。Peg Zone 是追踪记录另一条区块链状态的区块链，它要将自己桥接的某条概率链上的状态确定为不可逆的，使得这些状态得以与IBC兼容。

其中这里的ABCI是应用层的区块链如何与共识层交互的接口，共识层和网络层是由CosmosSDK底层实现，只需实现相关的ABCI接口即可自行搭建一条链。

ABCI接口和CosmosSDK会在接下来的Cosmos系列中会详细介绍。

交易流程

接下来介绍Cosmos的交易流程，Cosmos的交易分为普通交易和跨链交易，普通交易通过应用链内的共识上链，跨链交易通过IBC跨链协议进行交易。

▲ 普通交易
Cosmos的普通交易和以太坊类似，也是一个帐户模型，有着From，To和Amount关键字段。

普通交易Msg：

type MsgSend struct {FromAddress github_com_cosmos_cosmos_sdk_types.AccAddressToAddress   github_com_cosmos_cosmos_sdk_types.AccAddressAmount      github_com_cosmos_cosmos_sdk_types.Coins
}

交易流程

接下来介绍一笔普通交易的流程，例如Alice转给Bob 100atom代币。

Tendermint收到该笔交易，调用BaseApp的CheckTx校验该笔交易的有效性；
Tendermint出块，调用BaseApp的BeginBlock，检查区块的高度、Gas消耗情况和节点投票情况；
Tendermint调用BaseApp的DeliverTx，执行区块中的交易；
减少Alice 100atom，增加Bob 100atom，存储Alice和Bob的账本。
区块内交易全部执行完成后，Tendermint调用BaseApp的EndBlock收尾，包含执行完成后的事件和相关的验证者集合等等；
Tendermint调用BaseApp的Commit，IavlStore构建Merkle Tree；
通过返回的MerkleTree Root生成区块哈希，进行一下轮出块。

▲ 跨链交易

交易结构

IBC协议中包含了三个主要的交易类型：

MsgPacket：定义了IBC协议的跨链交易数据包，包含跨链交易、目的链的超时高度和时间戳（Port和Channel会在下一期的IBC协议中介绍）。

/ IBC 数据包
type MsgPacket struct {Packet      Proof       commitmentexported.Proof ProofHeight uint64                  Signer      sdk.AccAddress
}// 数据包定义了一种通过IBC跨不同链传输数据的类型
type Packet struct {// 跨链交易数据Data []byte  // number对应于发送和接收的顺序，必须按序发送和接收Sequence           uint64    // 标识来源链上的端口SourcePort         string // 标识来源链上的通道SourceChannel      string   // 标识目的链上的端口DestinationPort    string // 标识目的链上的通道DestinationChannel string // 标记数据包超时的区块高度TimeoutHeight      uint64    // 数据包超时的区块时间戳TimeoutTimestamp   uint64
}

MsgAcknowledgement：定义IBC协议的响应数据包，包含跨链交易执行成功或者失败的状态。

/ IBC响应数据包
type MsgAcknowledgement struct {Packet          Acknowledgement []byte               Proof           commitmentexported.Proof ProofHeight     uint64           Signer          sdk.AccAddress
}

MsgTimeout：定义IBC协议的超时数据包，包含下一个接收包的序列号。

// IBC超时数据包
type MsgTimeout struct {Packet          NextSequenceRecv uint64   Proof            commitmentexported.Proof ProofHeight      uint64                  Signer           sdk.AccAddress
}

当应用链双方在Hub注册后，彼此发现就可以通过路由进行跨链交易。

IBC跨链流程

我们通过一个例子来介绍IBC的跨链交易，ChainA和ChainB都是基于CosmosSDK搭建的应用链，Relayer作为一个链下中继负责轮询和路由IBC的数据包，这里的大致流程如下所示：

ChainA -> relayer -> hub -> relayer -> ChainB

为了更加清晰的描述ChainA的跨链交易是如何到达ChainB的，relayer和hub之间只是负责路由，这里简化了relayer到hub之间的过程。

ChainA的Alice转给ChainB的Bob 100atom

ChainA的Tendermint收到该笔交易，调用BaseApp的BeginBlock，检查区块的高度、Gas消耗情况和节点投票情况；
执行区块中的交易，减少Alice 100atom，增加托管账户Escrow 100atom，存储Alice和Escrow的账本（如果不是原生代币，则销毁Alice 100代币）。
构建跨链交易MsgPackage数据包，根据DestinationChannel和DestinationPort定位Outgoing队列，将MsgPackage存入该队列；
区块内交易全部执行完成后，Tendermint调用BaseApp的EndBlock收尾，包含执行完成后的事件等等，再调用BaseApp的Commit，调用IavlStore持久化等操作；
IavlStore通过当前所有的Iavl Tree Root构建Merkle Tree；
ChainA的Tendermint通过Tree root生成区块哈希；
ChainA的Tendermint准备进行下一轮出块；
中继器Relayer轮询ChainA的Out队列，发现Outgoing队列存在MsgPackag；
中继器Relayer解析MsgPackage数据包来源和目的；如果发现ChainB的区块高度大于超时高度，移除ChainA的MsgPackage，向ChainA的inComming队列发送MsgTimeout数据包；
中继器Relayer向ChainB的Incomming队列发送包含MsgPackage数据包，ChainB随后解析MsgPackage，验证MsgPackage的有效性；
托管账户Escrow mint 100atom，然后向Bob发送100 atom；
ChainB构建MsgAcknowledgement数据包，中继器Relayer轮询ChainB的Incomming队列，将其放入ChainB的Outgoing队列；
ChainA收到ChainB的MsgAcknowledgement或者MsgTimeout数据包，如果MsgAcknowledgement包含执行失败的状态或者存在MsgTimeout数据包，则根据数据包内的信息进行向托管账户赎回对应的金额。

跨链难题

▲ Relayer 作恶问题

场景描述：Relayer是链下的一个传递跨链消息的组件，任何人可以启动Relayer来传递消息。

方案：所有验证在链上进行，Ｒelayer只做消息传递。

效果：可多个Ｒelayer同时工作，跨链消息的有效性和有序性的保证和Ｒelayer无关，至少一个不作恶Ｒelayer即可工作

▲ 跨链存在性证明
我们可以看到，在每个IBC数据包的结构中都包含：

struct {Proof       commitmentexported.Proof ProofHeight uint64                  Signer      sdk.AccAddress
}

其中ProofHeight是对应的区块高度，Proof是Merkle Proof，Signer是发送者的地址，跨链双方维护对方的轻节点，提供类似SPV证明的机制。

▲ 跨链交易事务
IBC跨链协议中定义了两种关于包含状态的跨链交易数据包：

MsgAcknowledgement：定义IBC协议的响应数据包，包含跨链交易执行成功或者失败的状态。

// MsgAcknowledgement receives incoming IBC acknowledgement
type MsgAcknowledgement struct {Packet          Acknowledgement []byte               Proof           commitmentexported.Proof ProofHeight     uint64           Signer          sdk.AccAddress
}

MsgTimeout：定义IBC协议的超时数据包，包含下一个接收包的序列号。

// MsgTimeout receives timed-out packet
type MsgTimeout struct {Packet          NextSequenceRecv uint64   Proof            commitmentexported.Proof ProofHeight      uint64                  Signer           sdk.AccAddress
}

来源链通过MsgAcknowledgement数据包，可以判断跨链交易是否执行成功，如果执行失败来源链做出相对的回滚。

来源链通过MsgTimeout数据包，可以判断一个跨链交易的数据包是否超时，如果超时来源链做出相对的回滚。

结论

总体来说，Cosmos作为与Polkadot齐名的跨链双雄之一，在架构设计和IBC跨链协议上有许多值得我们学习借鉴的地方。

接下来的Cosmos系列文中会详细介绍IBC协议和Tendermint共识详解，敬请期待！

作者简介
江哲
来自数据网格实验室BitXHub团队
主要负责区块链账本互操作技术相关研究工作