深度剖析区块链跨链技术Cosmos(上&下篇)

区块链的公链项目越来越多，每个项目都是一个孤立的网络体系，因此区块链项目之间的互联互通能力也是技术发展的大方向。这其中Cosmos项目是其中的优秀代表。本文作者从Cosmos核心技术Tendermint开始，深度剖析Cosmos项目，让大家对跨链技术将一个比较深入的了解。

 

导读

 

2017 年以来，区块链项目出现了井喷式地上升，然而在喜人增长态势的背后，人们也注意到大部分项目都缺乏与其它区块链项目互连互通的能力而成为孤立的网络体系。因此，跨链技术也逐渐进入了大家的视野，本文将为大家解读一个跨链项目 Cosmos，看看它是如何做到让不同区块链的价值网络实现互通的。通过对该项目的解读，让大家对跨链项目有个初步的了解。同时受限于篇幅，我们会分为上下两篇，上篇带大家先了解 Cosmos 的核心技术 Tendermint，下篇会着重介绍 Cosmos。

 

Tendermint 概述

 

提到区块链，大家想必已然不陌生了，不过更多人想到的可能会是众所周知的 Bitcoin 和 Ethereum。的确，两者分别是区块链技术的起源和发展的代表，也是大家广泛传播和深入研究的对象。但是随着 Bitcoin 的不断推进，比特币工作量证明共识机制在速度和扩展性上的不足也逐步展现出来。

 

Cosmos 的开发团队 Tendermint 其实早在 2014 年就开始意识到了其不足，并持续专注于寻求不依赖挖矿等高电力消耗的共识机制，提供快速的交易处理能力，它们的目标是为全世界所有的区块链提供速度、安全和可扩展性。目前，Tendermint 加入了微软 Azure 区块链即服务平台，也成为了以太坊区块链联盟成员之一，同时 Tendermint 也是跨链技术 Cosmos 的核心技术。两者大致的关系如下：

 

 

图中可以轻松看出 Cosmos 就是在 Tendermint 基础上添加一些插件功能来实现的，上篇暂不对 Cosmos 做过多阐述，先来认识一下 Tendermint。

 

Tendermint 是什么

 

首先让我们来看看官方定义：

 

Tendermint is software for securely and consistently replicating an application on many machines. By securely, we mean that Tendermint works even if up to 1/3 of machines fail in arbitrary ways. By consistently, we mean that every non-faulty machine sees the same transaction log and computes the same state. Secure and consistent replication is a fundamental problem in distributed systems; it plays a critical role in the fault tolerance of a broad range of applications, from currencies, to elections, to infrastructure orchestration, and beyond.

 

Tendermint consists of two chief technical components: a blockchain consensus engine and a generic application interface. The consensus engine, called Tendermint Core, ensures that the same transactions are recorded on every machine in the same order. The application interface, called the Application BlockChain Interface (ABCI), enables the transactions to be processed in any programming language. Unlike other blockchain and consensus solutions, which come pre-packaged with built in state machines (like a fancy key-value store, or a quirky scripting language), developers can use Tendermint for BFT state machine replication of applications written in whatever programming language and development environment is right for them.

 

上面的定义有点长，总结下有以下几点：

 

1.Tendermint 是一个能够在不同机器上，安全一致复制应用的软件，其中安全性和一致性也是分布式账本的关键概念。

 

2.Tendermint 具备拜占庭容错能力，是一种拜占庭容错共识算法。

 

3.Tendermint 主要有两部分组成：

 

• Tendermint Core：区块链共识引擎，负责节点之间数据传输以及拜占庭共识。

• ABCI：区块链应用程序接口，也是一个协议，支持任何语言的交易处理实现。

 

总体来讲，Tendermint 可以理解为一个模块化的区块链软件框架，支持开发者个性化定制自己的区块链，而又不需要考虑共识以及网络传输的实现。

 

Tendermint 设计原则

 

先简单说说区块链的概念，区块链是一个具备确定性的状态机，可以在不信任的节点之间进行状态复制，包括应用的状态和改变状态的交易。从架构的层面上，区块链可以简单分为三个概念层：

 

• 网络层（Networking）：负责交易和数据传输和同步。

• 共识算法（Consensus）：负责不同的验证节点处理完交易后，保证状态的一致，也就是将交易打包到区块中。

• 应用程序（Application）：交易的真正执行者。

 

大致框架如下：

 

 

目前大部分的区块链实现都是采用上面的框架，实现成单一的程序，但是这就很容易出现两个问题：

 

1.代码复用困难，代码库的分支管理变得复杂。

 

2.限制了应用开发的语言。

 

如何去规避这两个问题呢？Tendermint 设计了自己的一套框架，其设计原则是易使用，易理解，高性能，适用于各种分布式应用。它的创新之处在于，将区块链应用（状态）与底层共识进行了分离，将共识引擎和 P2P 网络层封装组成 Tendermint Core。同时提供 ABCI 接口与应用层进行交互，应用逻辑可以用任何语言编写，应用做的事情实际上就是状态机控制。基于这种架构，应用的开发者可以方便地实现自己的区块链。

 

 

Tendermint 的框架总体来讲分为 ABCI Application 以及 Tendermint Core 两部分，两者通过 ABCI 连接。下面会对这两部分依次展开介绍。

 

• Tendermint核心模块

 

ABCI Application

 

开发者定制开发的区块链应用，开发语言不受限制，可以使用任何语言进行开发，但是必须实现为一个 ABCI Server，即需要满足以下几点：

 

1.是一个 Socket Server，需支持 TSP 或 GRPC 两种方式之一。

 

2.能够处理 ABCI Message。所有的 ABCI 消息类型都是通过 protobuf 来定义的，具体的消息格式可 3.参考https://github.com/tendermint/abci/blob/master/types/types.proto

 

实现区块链应用接口（ABCI）。ABCI 是 Tendermint 中定义的一套 Application 与 Tendermint Core 之间交互的协议。详细定义如下（版本：0.10.3）：

 

 

ABCI 接口可以分为三类：信息查询、交易校验以及共识相关处理。而 Tendermint Core 作为 ABCI Client 在启动时，会与 ABCI Server 建立三个连接，分别用于这三类接口消息的处理。

 

在 Tendermint Core 与 Application 交互的所有消息类型中，有 3 种主要的消息类型：

 

1.CheckTx 消息用于验证交易。Tendermint Core 中的 mempool 通过此消息校验交易的合法性，通过之后才会将交易广播给其它节点。

 

2.DeliverTx 消息是应用的主要工作流程，通过此消息真正执行交易，包括验证交易、更新应用程序的状态。

 

3.Commit 消息通知应用程序计算当前的世界状态，并存在下一区块头中。

 

Tendermint Core

 

Tendermint 共识引擎，包含区块链需要大部分功能实现，主要有：

 

• 共识算法：拜占庭POS算法。

• P2P：采用gossip算法，默认端口是46656。

• RPC：区块链对外接口，默认端口是46657。支持三种访问方式：URI over HTTP、JSONRPC over HTTP、JSONRPC over websockets。详细的RPC接口定义列表可以参考https://tendermint.github.io/slate

• 其它：交易缓存池、消息队列等。

 

共识算法

 

Tendermint 是一个易于理解的 BFT 共识协议。协议遵循一个简单的状态机，如下：

 

 

协议中有两个角色：

 

• 验证人：协议中的角色或者节点，不同的验证者在投票过程中具备不同的权力（vote power）。

• 提议人：由验证人轮流产生。

 

验证人轮流对交易的区块提议并对提议的区块投票。区块被提交到链上，且每个区块就是一个区块高度。但区块也有可能提交失败，这种情况下协议将选择下一个验证人在相同高度上提议一个新块，重新开始投票。

 

从图中可以看到，成功提交一个区块，必须经过两阶段的投票，称为 pre-vote 和 pre-commit。当超过 2/3 的验证人在同一轮提议中对同一个块进行了 pre-commit 投票，那么这个区块才会被提交。

 

由于离线或者网络延迟等原因，可能造成提议人提议区块失败。这种情况在 Tendermint 中也是允许的，因为验证人会在进入下一轮提议之前等待一定时间，用于接收提议人提议的区块。

 

假设少于三分之一的验证人是拜占庭节点，Tendermint 能够保证验证人永远不会在同一高度重复提交区块而造成冲突。为了做到这一点，Tendermint 引入了锁定机制，一旦验证人预投票了一个区块，那么该验证人就会被锁定在这个区块。然后：

 

1.该验证人必须在预提交的区块进行预投票。

 

2.当前一轮预提议和预投票没成功提交区块时，该验证人就会被解锁，然后进行对新块的下一轮预提交。

 

可以看到，Tendermint 共识算法和 PBFT 时非常相似的，可以说是 PBFT 的变种，那我们来比较一下：

 

相同点：

 

1.同属 BFT 体系。

 

2.抗 1/3 拜占庭节点攻击。

 

3.三阶段提交，第一阶段广播交易（区块），后两阶段广播签名（确认）。

 

4.两者都需要达到法定人数才能提交块。

 

不同点：

 

1.Tendermint 与 PBFT 的区别主要是在超过 1/3 节点为拜占庭节点的情况下。当拜占庭节点数量在验证者数量的 1/3 和 2/3 之间时，PBFT 算法无法提供保证，使得攻击者可以将任意结果返回给客户端。而 Tendermint 共识模型认为必须超过 2/3 数量的 precommit 确认才能提交块。举个例子，如果 1/2 的验证者是拜占庭节点，Tendermint 中这些拜占庭节点能够阻止区块的提交，但他们自己也无法提交恶意块。而在 PBFT 中拜占庭节点却是可以提交块给客户端。

 

3.另一个不同点在于拜占庭节点概念不同，PBFT 指的是节点数，而 Tendermint 代表的是节点的权益数，也就是投票权力。

 

3.最后一点，PBFT 需要预设一组固定的验证人，而 Tendermint 是通过要求超过 2/3 法定人数的验证人员批准会员变更，从而支持验证人的动态变化。

 

P2P网络

Tendermint的P2P网络协议借鉴了比特币的对等发现协议，更准确地说，Tendermint是采用了BTCD的P2P地址簿（Address Book）机制。当连接建立后，新节点将自身的Address信息（包含IP、Port、ID等）发送给相邻节点，相邻节点接收到信息后加入到自己的地址薄，再将此条Address信息，转播给它的相邻节点。

 

此外为了保证节点之间数据传输的安全性，Tendermint 采用了基于 Station-to-Station 协议的认证加密方案，此协议是一种密钥协商方案，基于经典的 DH 算法，并提供相互密钥和实体认证。大致的流程如下：

 

1.每一个节点都必须生成一对 ED25519 密钥对作为自己的 ID。

 

2.当两个节点建立起 TCP 连接时，两者都会生成一个临时的 ED25519 密钥对，并把临时公钥发给对方。

 

3.两个节点分别将自己的私钥和对方的临时公钥相乘，得到共享密钥。这个共享密钥对称加密密钥。

 

4.将两个临时公钥以一定规则进行排序，并将两个临时公钥拼接起来后使用 Ripemd160 进行哈希处理，后面填充 4 个 0，这样可以得到一个 24 字节的随机数。

 

5.得到的随机数作为加密种子，但为了保证相同的随机数不会被相同的私钥使用两次，我们将随机数最后一个 bit 置为 1，这样就得到了两个随机数，同时约定排序更高的公钥使用反转过的随机数来加密自己的消息，而另外一个用于解密对方节点的消息。

 

6.使用排序的临时公钥拼接起来，并进行 SHA256 哈希，得到一个挑战码。

 

7.每个节点都使用自己的私钥对挑战码进行签名，并将自己的公钥和签名发给其它节点校验。

 

8.校验通过之后，双方的认证就验证成功了。后续的通信就使用共享密钥和随机数进行加密，保护数据的安全。

 

应用示例

Tendermint官方项目里内置了ABCI Application的两个简单实现counter以及kvstore。这个两个Demo逻辑非常简单，运行起来也非常简单，以kvstore为例，只需要下面三条简单的指令就可以轻松的跑起来：

tendermint init

abci-cli kvstore

tendermint node

 

复杂一点，假设想使用 Tendermint 实现一套类似 Ethereum 的应用，最终应该是这样：

 

 

由 Tendermint Core 负责交易和区块的共享以及共识处理，开发者只需将 go-ethereum 和 ABCI Server 集成一个 ABCI 应用。Ethermint 项目就是 Tendermint 团队开发的一个类似应用，大家可以参考，遗憾的是目前 Ethermint 目前只支持低版本的 abci 和 go-ethereum。

 

Tendermint 工作流

 

 

上图简单描述了 Tenermint 的工作流。大致为：

 

1.client 通过 RPC 接口 broadcast_tx_commit 提交交易；

 

2.mempool 调用 ABCI 接口 CheckTx 用于校验交易的有效性，比如交易序号、发送者余额等，同时订阅交易执行后的事件并等待监听。

 

3.共识从 mempool 中获取交易开始共识排序，打包区块，确定之后依次调用 ABCI 相关接口更新当前的世界状态，并触发事件。

 

4.最终将交易信息返回 client。

 

总结

 

本文从概念、设计原则以及架构等方面对 Tendermint 做了详细的介绍，让大家可以直观了解到 Tendermint 的设计思想和实现原理。了解 Tendermint 之后，方便大家：

 

1.可以快速开发出自己的区块链应用而无需关注共识和 P2P 网络。

 

2.能够很好的兼容到 Cosmos 跨链生态中，因为 Tendermint 是 Cosmos 的核心技术。

 

3.开发支持任何编程语言的区块链。

 

本文转载自美图技术公众号。

 

原文链接：https://mp.weixin.qq.com/s/5Eej8usYtdKLCXdgCRiVmA

 

跨链技术背景

随着区块链技术的火热，越来越多的企业和开发人员加入到区块链的浪潮中，市面上也出现了许多不同类型的链，应用在金融、健康医疗、供应链、资产管理和溯源等领域。然而大部分链上应用（加密货币或者智能合约）都无法跨越当前链的边界，不能与其他链协同合作实现价值的流通从而限制了区块链的发挥空间。如何能让不同类型的链协同合作实现价值的流通成了探索的方向，这也是跨链技术的起因。跨链技术是打开链与链之间互通的钥匙，能很好地解决价值孤岛的问题，建立价值网络的桥梁。

目前主流的跨链技术包括：

1. 公证人机制（Notary schemes）
2. 侧链 / 中继（Side chains/relays）
3. 哈希锁定（Hash-locking）
4. 分布式私钥控制（Distributed private key control）

而本文所要介绍的主角 Cosmos 就是中继技术的一个典型案例，接下来将逐步为大家揭开 Cosmos 的面纱。

Cosmos 概述

Cosmos 是 Tendermint 团队推出的一个支持跨链交互的异构网络，它最终的目标是创建一个区块链互联网，允许大量自主且易开发的区块链互相扩展和交互。基于 Tendermint 开发，采用的 Tendermint 共识算法，是一个类似实用拜占庭容错共识引擎，具有高性能、一致性、具备拜占庭容错等特点。关于 Tendermint 的详细介绍可以参考本文上篇：深度剖析区块链跨链技术 Cosmos(上篇)。

Cosmos 网络由许多独立的并行区块链组成，网络中第一个区块链是 Cosmos Hub，其他的并行链称为 Zone，通过跨链协议（IBC）与 Hub 进行跨链操作。

目前 Cosmos
Hub 已经经过了多个版本的迭代，MVP 版本也趋于完成，同时测试网络也在前不久更新到 gaia-7001，但主网的上线时间团队还未给出，所以对 Cosmos 感兴趣的朋友还需要一些耐心。

Cosmos 架构

从 Github 上可以看出 Cosmos 主要的代码是 cosmos-sdk，它包含 Cosmos
Hub 的程序代码，同时也是一个区块链开发框架，为其他区块链开发者提供一些通用的功能模块，比如：共识，P2P 网络，IBC，账户，治理，认证等。大致框架如下：

不难看出 cosmos-sdk 其实就是一个 ABCI 应用。主要有：

• baseapp：定义了一个基本 ABCI 应用的模版，与 Tendermint 通信。开发者也可以根据自己的需求重写。
• 应用程序：包括 gaia、basecoin、democoin。其中 gaia 就是 hub 主程序，basecoin 以及 democoin 是提供的两个示例应用。
• plugins：cosmos-sdk 的基本单元，每个 plugin 都是 baseapp 的功能扩展，包含各自的消息和交易处理逻辑。目前 SDK 已经集成了一些重要的 plugin：
• staking：POS 相关的实现，包括：绑定，解绑，通货膨胀，费用等操作。
• ibc：跨链协议 IBC 的实现，也是 Cosmos 支持跨链的主要插件。
• governance：治理相关的实现，如提议、投票等。
• auth：定义了一个标准的多资产账户结构（BaseAccount），开发者可以直接嵌入自己的账户体系中。
• bank：定义资产的转移。

因此基于 cosmos-sdk 框架，利用其插件功能，可以非常快速的开发出属于自己应用的区块链，同时也可以很方便的加入 Cosmos 生态网络，支持不同链之间的互操作，在插件的设计上和 EOS 也有异曲同工之妙。

那么如何使用这些插件功能呢？可以参考 cosmos-sdk 提供的示例应用，以 basecoin 为例，只需要几步：

1. 创建自己的 ABCI 应用，可以嵌入 baseapp，也可以重载 baseapp。
2. 定义自己的账户体系，可以嵌入 BaseAccount。
3. 选择所需要的插件，注册到消息路由。

**

**

Cosmos 跨链

Tendermint 团队在 15 年就开始考虑跨链技术，跨链也是 Cosmos 网络最重要的一个特性。一般来说，实现跨链需要做到：

• 共识算法需要具备及时最终性，也就是说在出块之后，需要能够快速确认为不可逆（固定不变）。
• 交易确认需要高效独立的证明方法，目前的做法都是基于 Merkle 证明。

基于 cosmos-sdk 的区块链使用了 Tendermint 共识算法就非常容易能够做到。除此之外，Cosmos 的区块链间通信协议（IBC）将不同区块链连接起来，达到价值转移的目的。

IBC 协议

IBC 协议是针对 Cosmos 网络设计的，依赖其及时最终性的特点，用于 Hub 与 Zone 之间消息传递。IBC 协议中设计了两个消息：

• IBCBlockCommitTx：发送方所在区块链的最新的区块信息。
• IBCPacketTx：跨链交易本身的信息，及其在发送方链中被打包的区块信息。

但有了消息的传递，接收链如何校验信任消息呢？

在 IBC 协议设计里，两个链建立连接之前需要进行彼此注册，有两个作用：

1. 保存对方链验证者集合以及 Merkle 证明的算法，这样接收链才能确保消息的正确性和来源的可靠性。
2. 为对方链创建两个可靠队列，一个队列存放所有对方链的消息（outgoing），一个队列存放来自对方链的消息（incoming）。

我们以 chain1 中用户 User A 转 100mycoin 给 test-hub 用户 User B 为例看看 IBC 整个的工作流程如下（基于目前 IBC 实现代码）：

整个工作流程可以分为三个阶段：

1. User A 向 chain1 提交跨链交易，chain1 执行该交易，并将交易存入 outgoing 队列。
2. relayer 从 chain1 中对应 test-hub 的 outgoing 消息队列取出跨链交易，提交到 test-hub。
3. test-hub 执行交易，放入 incoming 消息队列。

大家可以看到，整个流程比较简单，而且涉及的消息只有 IBCPacket。目前 Cosmos 跨链实现并没有全部完成，只是完成了一个简单的交易处理流程。

PegZone

基于 cosmos-sdk 开发的区块链能够轻松满足实时最终性，然而现存的 Bitcoin 和 Ethereum 这类使用 POW 共识的区块链并不具备此特点，只能属于概率最终性，无法防止区块链的回滚。对于这类链，团队采用 PegZone 方案来解决。

PegZone 本身其实是一条代理链，实时跟踪原始链的状态，通过设定一个安全阀值，等待原始链区块增长数达到安全阀值时就认为原始链的状态达到了伪实时最终性（回滚概率小），这点和轻客户端钱包验证是相同的原理，例如比特币安全阀值通常设置为 6，以太坊安全阀值可以设置为 20 或者 100。而 PegZone 本身具备实时最终性，就可以通过 IBC 与 Hub 相连，从而实现跨链。

接下来还是用例子来说明下，以 Ethereum 为例来看，有兴趣的朋友可参考 Github 上的 cosmos/Peggy 项目。示意图如下：

上图我们可以看出 PegZone 可以分为 5 个部分：

• Smart Contract：资产托管的角色，保管以太坊中的代币和 Cosmos 中的代币。主要提供了 lock、unlock、mint、burn 四个方法。
• Witness：是一个以太坊全节点，监听以太坊合约的 event，并等待 100 个区块产生后，封装 WitnessTx 提交到 PegZone 中来证明在以太坊内状态更改。
• PegZone：PegZone 是基于 Tendermint 的区块链，负责维护用户的账户信息，允许用户之间资产的转移，并提供交易查询。
• Signer：使用 secp256k1 对交易进行签名，以便签名能够高效的被智能合约验证，对应于智能合约的校验者公钥集合。
• Relayer： 中继器负责交易转发。将所有 Signer 签名后的 SignTx 转发到 smart contract 中。

现状

跨链是 Cosmos 的重要特性，但在从目前的代码实现上感觉有些遗憾：

• IBC 协议目前只完成了基本消息的传递功能，并没有安全校验、注册机制以及一些异常的处理。
• PegZone 机制处于暂停状态，机制设计上团队也称处于实验性质。
• 对于没有基于 cosmos-sdk 开发，但符合实时最终性的链无法使用 IBC，无法做到异构链的兼容。它们可能使用不同的：
• 签名算法
• 序列化方法
• Merkle 证明的方式

总结

通过上下两篇文章，从架构，核心技术——Tendermint、跨链、源码以及现状等方面对 Cosmos 进行了详细介绍。整体来讲，Cosmos 更偏向于一个区块链开发框架，让开发者可以只需要专注于自身业务而不需要考虑区块链底层技术实现，所以在架构设计上采用了灵巧的插件设计，开发者可以按需使用。

Cosmos 跨链协议部分从代码上看，完成度还不太高，有些遗憾。并且设计上跨链交易都需要通过 Cosmos
Hub，这样会过于依赖 Hub，对 Hub 本身的承载压力是个考验，目前其他的一些跨链实现方案也都需要依赖自身的一条链，都会存在这个问题。笔者觉得跨链未来会发展成标准化协议，就像 TCP 之于互联网，而不是依赖某条具体链，通过定义标准化的模块，通过路由将跨链交易转到目标链，目标链完成对原始链的校验后，确认交易合法性，并执行交易。设想示意图如下：

转载来源：https://mp.weixin.qq.com/s/5Eej8usYtdKLCXdgCRiVmA