【深度知识】Tendermint共识算法原理和框架流程

辉哥
更新于 2019-06-15 22:15
阅读 5443

# 1. 摘要

Tendermint是跨链Cosmos项目的核心技术。本文主要介绍以下内容：
（1）Tendermint的网络层级框架图
（2）Tendermint模块组成及共识算法原理
（3）Tendermint工作流程

# 2. Tendermint概述

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

![](https://img.learnblockchain.cn/2020/02/01_/490918703.png)

图中可以轻松看出Cosmos就是在Tendermint基础上添加一些插件功能来实现的。

## 2.1 Tendermint的概念

Tendermint的概念总结下有以下几点：
（1）Tendermint是一个能够在不同机器上，安全一致复制应用的软件，其中安全性和一致性也是分布式账本的关键概念。
（2）Tendermint具备拜占庭容错能力，是一种拜占庭容错共识算法。
（3）Tendermint主要有两部分组成：
1）Tendermint Core：区块链共识引擎，负责节点之间数据传输以及拜占庭共识。
2）ABCI：区块链应用程序接口(the Application BlockChain Interface )，也是一个协议，支持任何语言的交易处理实现。
总体来讲，Tendermint可以理解为一个模块化的区块链软件框架，支持开发者个性化定制自己的区块链，而又不需要考虑共识以及网络传输的实现。

## 2.2 Tendermint设计原则

区块链是一个具备确定性的状态机，可以在不信任的节点之间进行状态复制，包括应用的状态和改变状态的交易。从架构的层面上，区块链可以简单分为三个概念层：
（1）网络层（Networking）：负责交易和数据传输和同步。
（2）共识算法（Consensus）：负责不同的验证节点处理完交易后，保证状态的一致，也就是将交易打包到区块中。
（3）应用程序（Application）：交易的真正执行者。

大致框架如下：

![](https://img.learnblockchain.cn/2020/02/01_/630515458.png)

目前大部分的区块链实现都是采用上面的框架，实现成单一的程序，但是这就很容易出现两个问题：
（1）代码复用困难，代码库的分支管理变得复杂。
（2）限制了应用开发的语言。

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

![](https://img.learnblockchain.cn/2020/02/01_/983335884.png)

Tendermint的框架总体来讲分为ABCI Application以及Tendermint Core两部分，两者通过ABCI连接。

# 3. Tendermint核心模块

## 3.1 ABCI Application

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

（1）是一个Socket Server，需支持TSP或GRPC两种方式之一。
（2）能够处理ABCI Message。
所有的ABCI消息类型都是通过protobuf来定义的，具体的消息格式可参考 [https://github.com/tendermint/abci/blob/master/types/types.proto](https://link.zhihu.com/?target=https%3A//github.com/tendermint/abci/blob/master/types/types.proto)
（3） 实现区块链应用接口（ABCI）。
ABCI是Tendermint中定义的一套Application与Tendermint Core之间交互的协议。详细定义如下（版本：0.10.3）：

![](https://img.learnblockchain.cn/2020/02/01_/621765346.png)

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

在Tendermint Core与Application交互的所有消息类型中，有3种主要的消息类型：
**（1）CheckTx消息** 用于验证交易。Tendermint Core中的mempool通过此消息校验交易的合法性，通过之后才会将交易广播给其它节点。
**（2）DeliverTx消息** 是应用的主要工作流程，通过此消息真正执行交易，包括验证交易、更新应用程序的状态。
**（3）Commit消息** 通知应用程序计算当前的事件状态，并存在下一区块头中。

## 3.2 Tendermint Core

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

* **共识算法** ：拜占庭POS算法。
* **P2P** ：采用gossip算法，默认端口是46656。
* **RPC** ：区块链对外接口，默认端口是46657。支持三种访问方式：URI over HTTP、JSONRPC over HTTP、JSONRPC over websockets。详细的RPC接口定义列表可以参考 [https://tendermint.github.io/slate](https://link.zhihu.com/?target=https%3A//tendermint.github.io/slate)
* **其它** ：交易缓存池、消息队列等。

### 3.2.1 共识算法

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

![](https://img.learnblockchain.cn/2020/02/01_/544412565.png)

**协议中有两个角色：**
**（1）验证人：** 协议中的角色或者节点，不同的验证者在投票过程中具备不同的权力（vote power）。
**（2）提议人：** 由验证人轮流产生。
验证人轮流对交易的区块提议并对提议的区块投票。区块被提交到链上，且每个区块就是一个区块高度。但区块也有可能提交失败，这种情况下协议将选择下一个验证人在相同高度上提议一个新块，重新开始投票。

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

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

假设少于三分之一的验证人是拜占庭节点，Tendermint能够保证验证人永远不会在同一高度重复提交区块而造成冲突。为了做到这一点，Tendermint 引入了锁定机制，一旦验证人预投票了一个区块，那么该验证人就会被锁定在这个区块。然后：
（1）该验证人必须在预提交的区块进行预投票。
（2）当前一轮预提议和预投票没成功提交区块时，该验证人就会被解锁，然后进行对新块的下一轮预提交。

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

**（1）相同点：**
1）同属BFT体系。
2）抗1/3拜占庭节点攻击。
3）三阶段提交，第一阶段广播交易（区块），后两阶段广播签名（确认）。
4）两者都需要达到法定人数才能提交块。

**（2）不同点：**
1）Tendermint与PBFT的区别主要是在超过1/3节点为拜占庭节点的情况下。
当拜占庭节点数量在验证者数量的1/3和2/3之间时，PBFT算法无法提供保证，使得攻击者可以将任意结果返回给客户端。而Tendermint共识模型认为必须超过2/3数量的precommit确认才能提交块。举个例子，如果1/2的验证者是拜占庭节点，Tendermint中这些拜占庭节点能够阻止区块的提交，但他们自己也无法提交恶意块。而在PBFT中拜占庭节点却是可以提交块给客户端。
简单的说，就是比特币的网络存在分叉的可能，而Tendermint不会发生这种情况。
2）另一个不同点在于拜占庭节点概念不同，PBFT指的是节点数，而Tendermint代表的是节点的权益数，也就是投票权力。
3）最后一点，PBFT需要预设一组固定的验证人，而Tendermint是通过要求超过2/3法定人数的验证人员批准会员变更，从而支持验证人的动态变化。

**锁机制详解**
举个例子，有四个validator 节点，A,B,C,D, 在某个R轮，在propose阶段，
（1）proposer节点广播出了新块blockX；
（2）A的超时时间内没有收到这个新块，向外广播pre-vote nil，B,C,D都收到了，向外广播pre-vote投给blockX；
（3）现在四个节点进入了pre-commit阶段，A处于红色内圈，B,C,D处于蓝色外圈；
（4）假设A由于自身网络不好，又没有在规定时间内收到超过2/3个对blockX的投票，于是只能发出 pre-commit nil投票消息投给空块
（5）D收到了B和C的pre-vote消息，加上自己的，就超过了2/3了，于是D在本机区块链里commit了blockX
（6）假设此时B和C网络出现问题，收不到D在pre-commit消息，这是B和C只能看到2票投给了blockX，一票投给了空块，全部不足2/3，于是B和C都只能 commit空块，高度不变，进人R+1轮，A也只能看到2票投给了blockX，一票投给了空块，也只能commit空块，高度不变，进人R+1轮；
（7）在R+1轮，由于新换了一个proposer, 提议了新的区块blockY，A,B,C 三个个可能会在达成共识，提交blockY，于是在同样的高度，就有blockX和blockY两个块，产生了分叉？其实，Tendermint加上了锁的机制，具体就是，在第7步，即使proposer出了新块blockY，A,B,C只能被锁定在第6步他们的pre-commit块上，即A在第6步投给了空块，那么在第R+1轮，只能继续投给空块，B在第6步投给了blockX，那么在新一轮，永远只能投给blockX，C也是类似。这样在R+1轮，就会有1票投给空块，两票投给blockX，最终达成共识blockX，A,B,C三人都会commit blockX，与D一致，没有产生冲突。

### 3.2.2 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）校验通过之后，双方的认证就验证成功了。后续的通信就使用共享密钥和随机数进行加密，保护数据的安全。

# 3.3 应用示例

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

> tendermint init

> abci-cli kvstore

> tendermint node

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

![](https://img.learnblockchain.cn/2020/02/01_/503841158.png)

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

# 4. Tendermint工作流程

![](https://img.learnblockchain.cn/2020/02/01_/305790889.png)

**上图简单描述了Tenermint的工作流。大致为：**
（1）client通过RPC接口broadcast_tx_commit提交交易；
（2）mempool调用ABCI接口CheckTx用于校验交易的有效性，比如交易序号、发送者余额等，同时订阅交易执行后的事件并等待监听。
（3）共识从mempool中获取交易开始共识排序，打包区块，确定之后依次调用ABCI相关接口更新当前的事件状态，并触发事件。
（4）最终将交易信息返回client。

# 5. 参考

本文转载自 [《深度解析Tendermint，快速融入Cosmos生态》](https://zhuanlan.zhihu.com/p/38252058) 。

更多Tendermint资料参考：
（1）拜占庭共识Tendermint介绍及简单入门
[https://blog.csdn.net/niyuelin1990/article/details/80537329](https://blog.csdn.net/niyuelin1990/article/details/80537329)
（2）Tendermint 说明文档
[https://tendermint.readthedocs.io/en/master/](https://tendermint.readthedocs.io/en/master/)
（3）Tendermint GIT地址
[https://github.com/tendermint/tendermint](https://github.com/tendermint/tendermint)
（4）深度解析Tendermint，快速融入Cosmos生态[质量高]
[https://zhuanlan.zhihu.com/p/38252058](https://zhuanlan.zhihu.com/p/38252058)
（5）区块链框架 Tendermint 入门教程
[https://hbliu.coding.me/2018/04/02/tendermint-introduction-1/](https://hbliu.coding.me/2018/04/02/tendermint-introduction-1/)
（6）详解Tendermint共识算法
[https://www.odaily.com/post/5134145](https://www.odaily.com/post/5134145)
（7）分布式一致性协议介绍（Paxos、Raft）
[https://www.cnblogs.com/zhang-qc/p/8688258.html](https://www.cnblogs.com/zhang-qc/p/8688258.html)

1. 摘要

Tendermint是跨链Cosmos项目的核心技术。本文主要介绍以下内容：（1）Tendermint的网络层级框架图（2）Tendermint模块组成及共识算法原理（3）Tendermint工作流程

2. Tendermint概述

图中可以轻松看出Cosmos就是在Tendermint基础上添加一些插件功能来实现的。

2.1 Tendermint的概念

Tendermint的概念总结下有以下几点：（1）Tendermint是一个能够在不同机器上，安全一致复制应用的软件，其中安全性和一致性也是分布式账本的关键概念。（2）Tendermint具备拜占庭容错能力，是一种拜占庭容错共识算法。（3）Tendermint主要有两部分组成： 1）Tendermint Core：区块链共识引擎，负责节点之间数据传输以及拜占庭共识。 2）ABCI：区块链应用程序接口(the Application BlockChain Interface )，也是一个协议，支持任何语言的交易处理实现。总体来讲，Tendermint可以理解为一个模块化的区块链软件框架，支持开发者个性化定制自己的区块链，而又不需要考虑共识以及网络传输的实现。

2.2 Tendermint设计原则

区块链是一个具备确定性的状态机，可以在不信任的节点之间进行状态复制，包括应用的状态和改变状态的交易。从架构的层面上，区块链可以简单分为三个概念层：（1）网络层（Networking）：负责交易和数据传输和同步。（2）共识算法（Consensus）：负责不同的验证节点处理完交易后，保证状态的一致，也就是将交易打包到区块中。（3）应用程序（Application）：交易的真正执行者。

大致框架如下：

目前大部分的区块链实现都是采用上面的框架，实现成单一的程序，但是这就很容易出现两个问题：（1）代码复用困难，代码库的分支管理变得复杂。（2）限制了应用开发的语言。

Tendermint的框架总体来讲分为ABCI Application以及Tendermint Core两部分，两者通过ABCI连接。

3. Tendermint核心模块

3.1 ABCI Application

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

（1）是一个Socket Server，需支持TSP或GRPC两种方式之一。（2）能够处理ABCI Message。所有的ABCI消息类型都是通过protobuf来定义的，具体的消息格式可参考 https://github.com/tendermint/abci/blob/master/types/types.proto （3）实现区块链应用接口（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消息 通知应用程序计算当前的事件状态，并存在下一区块头中。

3.2 Tendermint Core

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

共识算法 ：拜占庭POS算法。
P2P ：采用gossip算法，默认端口是46656。
RPC ：区块链对外接口，默认端口是46657。支持三种访问方式：URI over HTTP、JSONRPC over HTTP、JSONRPC over websockets。详细的RPC接口定义列表可以参考 https://tendermint.github.io/slate
其它：交易缓存池、消息队列等。

3.2.1 共识算法

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

协议中有两个角色： （1）验证人： 协议中的角色或者节点，不同的验证者在投票过程中具备不同的权力（vote power）。 （2）提议人： 由验证人轮流产生。验证人轮流对交易的区块提议并对提议的区块投票。区块被提交到链上，且每个区块就是一个区块高度。但区块也有可能提交失败，这种情况下协议将选择下一个验证人在相同高度上提议一个新块，重新开始投票。

假设少于三分之一的验证人是拜占庭节点，Tendermint能够保证验证人永远不会在同一高度重复提交区块而造成冲突。为了做到这一点，Tendermint 引入了锁定机制，一旦验证人预投票了一个区块，那么该验证人就会被锁定在这个区块。然后：（1）该验证人必须在预提交的区块进行预投票。（2）当前一轮预提议和预投票没成功提交区块时，该验证人就会被解锁，然后进行对新块的下一轮预提交。

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

（1）相同点： 1）同属BFT体系。 2）抗1/3拜占庭节点攻击。 3）三阶段提交，第一阶段广播交易（区块），后两阶段广播签名（确认）。 4）两者都需要达到法定人数才能提交块。

（2）不同点： 1）Tendermint与PBFT的区别主要是在超过1/3节点为拜占庭节点的情况下。当拜占庭节点数量在验证者数量的1/3和2/3之间时，PBFT算法无法提供保证，使得攻击者可以将任意结果返回给客户端。而Tendermint共识模型认为必须超过2/3数量的precommit确认才能提交块。举个例子，如果1/2的验证者是拜占庭节点，Tendermint中这些拜占庭节点能够阻止区块的提交，但他们自己也无法提交恶意块。而在PBFT中拜占庭节点却是可以提交块给客户端。简单的说，就是比特币的网络存在分叉的可能，而Tendermint不会发生这种情况。 2）另一个不同点在于拜占庭节点概念不同，PBFT指的是节点数，而Tendermint代表的是节点的权益数，也就是投票权力。 3）最后一点，PBFT需要预设一组固定的验证人，而Tendermint是通过要求超过2/3法定人数的验证人员批准会员变更，从而支持验证人的动态变化。

锁机制详解 举个例子，有四个validator 节点，A,B,C,D, 在某个R轮，在propose阶段，（1）proposer节点广播出了新块blockX；（2）A的超时时间内没有收到这个新块，向外广播pre-vote nil，B,C,D都收到了，向外广播pre-vote投给blockX；（3）现在四个节点进入了pre-commit阶段，A处于红色内圈，B,C,D处于蓝色外圈；（4）假设A由于自身网络不好，又没有在规定时间内收到超过2/3个对blockX的投票，于是只能发出 pre-commit nil投票消息投给空块（5）D收到了B和C的pre-vote消息，加上自己的，就超过了2/3了，于是D在本机区块链里commit了blockX （6）假设此时B和C网络出现问题，收不到D在pre-commit消息，这是B和C只能看到2票投给了blockX，一票投给了空块，全部不足2/3，于是B和C都只能 commit空块，高度不变，进人R+1轮，A也只能看到2票投给了blockX，一票投给了空块，也只能commit空块，高度不变，进人R+1轮；（7）在R+1轮，由于新换了一个proposer, 提议了新的区块blockY，A,B,C 三个个可能会在达成共识，提交blockY，于是在同样的高度，就有blockX和blockY两个块，产生了分叉？其实，Tendermint加上了锁的机制，具体就是，在第7步，即使proposer出了新块blockY，A,B,C只能被锁定在第6步他们的pre-commit块上，即A在第6步投给了空块，那么在第R+1轮，只能继续投给空块，B在第6步投给了blockX，那么在新一轮，永远只能投给blockX，C也是类似。这样在R+1轮，就会有1票投给空块，两票投给blockX，最终达成共识blockX，A,B,C三人都会commit blockX，与D一致，没有产生冲突。

3.2.2 P2P网络

（1）每一个节点都必须生成一对ED25519密钥对作为自己的ID。（2）当两个节点建立起TCP连接时，两者都会生成一个临时的ED25519密钥对，并把临时公钥发给对方。（3）两个节点分别将自己的私钥和对方的临时公钥相乘，得到共享密钥。这个共享密钥对称加密密钥。（4）将两个临时公钥以一定规则进行排序，并将两个临时公钥拼接起来后使用Ripemd160进行哈希处理，后面填充4个0，这样可以得到一个24字节的随机数。（5）得到的随机数作为加密种子，但为了保证相同的随机数不会被相同的私钥使用两次，我们将随机数最后一个bit置为1，这样就得到了两个随机数，同时约定排序更高的公钥使用反转过的随机数来加密自己的消息，而另外一个用于解密对方节点的消息。（6）使用排序的临时公钥拼接起来，并进行SHA256哈希，得到一个挑战码。（7）每个节点都使用自己的私钥对挑战码进行签名，并将自己的公钥和签名发给其它节点校验。（8）校验通过之后，双方的认证就验证成功了。后续的通信就使用共享密钥和随机数进行加密，保护数据的安全。

3.3 应用示例

tendermint init

abci-cli kvstore

tendermint node

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

4. Tendermint工作流程

上图简单描述了Tenermint的工作流。大致为： （1）client通过RPC接口broadcast_tx_commit提交交易；（2）mempool调用ABCI接口CheckTx用于校验交易的有效性，比如交易序号、发送者余额等，同时订阅交易执行后的事件并等待监听。（3）共识从mempool中获取交易开始共识排序，打包区块，确定之后依次调用ABCI相关接口更新当前的事件状态，并触发事件。（4）最终将交易信息返回client。