走进Cosmos之入门

导 读

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

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

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

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

什么是Cosmos

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

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

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

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

IBC(Inter-Blockchain Communication Protocol):链间通信协议。

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

Hub管理着许多被称为“Zone”的应用链,在Cosmos网络中,由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.AccAddress ToAddress github_com_cosmos_cosmos_sdk_types.AccAddress Amount github_com_cosmos_cosmos_sdk_types.Coins }

交易流程

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

1. Tendermint收到该笔交易,调用BaseApp的CheckTx校验该笔交易的有效性;

2. Tendermint出块,调用BaseApp的BeginBlock,检查区块的高度、Gas消耗情况和节点投票情况;

3. Tendermint调用BaseApp的DeliverTx,执行区块中的交易;

4. 减少Alice 100atom,增加Bob 100atom,存储Alice和Bob的账本。

5. 区块内交易全部执行完成后,Tendermint调用BaseApp的EndBlock收尾,包含执行完成后的事件和相关的验证者集合等等;

6. Tendermint调用BaseApp的Commit,IavlStore构建Merkle Tree;

7. 通过返回的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

1. ChainA的Tendermint收到该笔交易,调用BaseApp的BeginBlock,检查区块的高度、Gas消耗情况和节点投票情况;

2. 执行区块中的交易,减少Alice 100atom,增加托管账户Escrow 100atom,存储Alice和Escrow的账本(如果不是原生代币,则销毁Alice 100代币)。

3. 构建跨链交易MsgPackage数据包,根据DestinationChannel和DestinationPort定位Outgoing队列,将MsgPackage存入该队列;

4. 区块内交易全部执行完成后,Tendermint调用BaseApp的EndBlock收尾,包含执行完成后的事件等等, 再调用BaseApp的Commit,调用IavlStore持久化等操作;

5. IavlStore通过当前所有的Iavl Tree Root构建Merkle Tree;

6. ChainA的Tendermint通过Tree root生成区块哈希;

7. ChainA的Tendermint准备进行下一轮出块;

8. 中继器Relayer轮询ChainA的Out队列,发现Outgoing队列存在MsgPackag;

9. 中继器Relayer解析MsgPackage数据包来源和目的;如果发现ChainB的区块高度大于超时高度,移除ChainA的MsgPackage,向ChainA的inComming队列发送MsgTimeout数据包;

10. 中继器Relayer向ChainB的Incomming队列发送包含MsgPackage数据包,ChainB随后解析MsgPackage,验证MsgPackage的有效性;

11. 托管账户Escrow mint 100atom,然后向Bob发送100 atom;

12. ChainB构建MsgAcknowledgement数据包,中继器Relayer轮询ChainB的Incomming队列,将其放入ChainB的Outgoing队列;

13. ChainA收到ChainB的MsgAcknowledgement或者MsgTimeout数据包,如果MsgAcknowledgement包含执行失败的状态或者存在MsgTimeout数据包,则根据数据包内的信息进行向托管账户赎回对应的金额。

跨链难题

▲ Relayer 作恶问题

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

方案:所有验证在链上进行,Relayer只做消息传递。

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

▲ 跨链存在性证明

我们可以看到,在每个IBC数据包的结构中都包含:

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

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

▲ 跨链交易事务

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

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

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

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

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

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

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

结论

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

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

作者简介

江哲

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

写评论,请先登录