原作者：灵魂机器
Tendermint 是 Tendermint公司开源的的一个项目，是一个pBFT算法的变体，Tendermint和pBFT的关系类似于Raft和Paxos的关系，Tendermint是pBFT的简化版。
算法核心流程
Tendermint 核心算法流程如下图所示：
Tendermint算法先随机选出一些节点作为Validators(怎么选择验证节点？见后面的“如何选择验证节点”)，然后选择其中一个validator作为proposer节点。Proposer节点开始监听并收集全网的所有交易，几分钟后，组装一个新块，并向全网广播，这个就是 proposal block。全网所有validator节点收到这个 proposal block后，开始读取这个block里的所有交易，一一进行验证，如果没有问题，就发出一条 pre-vote 投票消息，表示同意这个block，投一个肯定票，如果发现block里有非法交易，则投一个反对票，这些投票消息会被广播到所有validator节点，所以每个validator节点既会发出一个投票消息，又会收集别人的投票消息，当发现收集到的同意投票数量超过 2/3时，就发出一个pre-commit 投票信息，这是第二阶段的投票了，这是每个节点也在监听并收集pre-commit的投票消息。当一个validator节点收集到的 pre-commit 同意票数超过2/3时，说明这个block 是得到了大多数人统同意的，可以放心把这个block写入本地的区块链，追加到末尾，即完成commit。同时区块高度增一，proposer节点索引也增1，进入下一轮(round), 开始提议新快。
上述描述的是90%时候的正常流程，即蓝色箭头表示的那个大循环。接下来说一下内圈那个红色箭头表示的小循环。大部分情况下，一个块只需要一轮就可以完成确认，达成共识，但是有时候网络状态不好，经常发生超时，这时候就会进入内圈红色流程了。由于每一轮(round)只有一个proposer有权力出块，如果这个proposer挂了或者网络不好超时了，怎么办？不可能大家永远等待这个proposer啊，算法显然不会设计的这么蠢，存在一个明显的单点故障（single point of failure）。在proposer节点propose阶段，所有validator节点会启动一个定时器，设置超时时间为T（这个T的值是根据网络情况动态计算出来的），如果在这个时间内还没有收到proposer节点发来的新块，就认为这个proposer节点挂了，所有validator节点不会继续等下去，会立刻在本机生成一个特殊结构的空块，假装这个空块是从Proposer节点那里收到的，这样，无论如何，在时间T内，都会收到一个proposal区块，要么是一个正常块要么是一个空块。然后接着对这个块进行pre-vote投票和pre-commit投票。如果proposer挂了，绝大部分validator看到的都是一个空块，因此空块会获得多数投票，进入commit阶段。commit空块的时候，不会真的往区块链写入一个空块，而是什么都不写，区块高度不自增，保持不变，这样相当于什么也没有干，这一轮(round)是在空转。这一轮转完了，下一轮开始的时候会换下一个validator当proposer，这样当前那个挂掉的proposer，就不会卡主整个网络。
网络通信复杂度
Tendermint 的网络通信复杂度为 O(n2)，因为在两个投票阶段，每个validator节点都需要收集超过2/3个投票消息，网络发送的数据包数量是n2，因此网络同心复杂度是O(n2)。在Proposal阶段，新块只需要被所有validator收到，网络通信复杂度是O(n)。总的来说，是O(n2)。 网络通信复杂度为 O(n2)，注定了Tendermint的节点数不会太多，太多的话网络通信这一块会成为瓶颈，因此Tendermint 适用于私有连和联盟链，论文第17页也指明了这一点： Tendermint is that solution, optimized for consortia, or inter-organizational logic 不过如果配合良好的分片Sharding机制，还是可以用于公有链的。这是后话了。
网络假设
Tendermint对网络的要求是，需要网络是半同步的。Tendermint在Propose阶段，有一个超时机制，但是这个超时时间不是一个常量，是动态变化的，因此在这个阶段，要求网络是半同步的。在pre-vote阶段和pre-commit两个投票阶段，对网络没有要求的，即网络是异步的。因此，Tendermint对网络要求是半同步的。
由于在pre-vote和pre-commit的投票阶段，网络是异步的，如果没有收集到超过2/3的投票数，所有validator节点会无限期等待下去，因此，整个系统会卡住。Tendermint在Liveness方面有所妥协，换取了更强的Finality。
举个例子，如果在某一轮中proposer节点广播出了一个新块blockX，某个validator A节点没有按时收到新块，那么该A就会在本机构造一个空块，当做是从proposer收到的，发出一个pre-vote nil投票消息然后进入pre-vote循环，并启动一个超时定时器，这时进入了红色内圈循环，A开始监听网络并收集投票信息，
如果在规定时间内，收集到的投票数，无论是投给空块的还是blockX的，加起来，没有超过2/3，则无限等待，直到投票总数超过2/3
收集到了超过2/3的投票总数后，如果投给空块的票数超过2/3，则发出pre-vote nil投给空块，依旧留在红色内圈；如果投给blockX的票数超过2/3，则发出pre-vote投给blockX，切换到蓝色外圈；如果空块和blockX各自的票数，都没有超过2/3，那么发出pre-vote nil 消息投票给空块，进入pre-commit阶段，依旧在红色内圈。
一旦A发出了pre-commit nil的投票消息，A还是留在红色内圈循环，pre-commit流程与上面类似。总而言之，红色内圈的流程，需要假设网络是半同步的。
Finality和Liveness
Tendermint的Finality是Deterministic 的，而比特币的Finality是Probabilistic，Tendermint比比特币具有更强的Finality。
但是在Liveness方面，例如在网络发生分裂的时候，Tendermint理论上有可能卡住，任何新交易都无法写入，而比特币可以分裂成两个分叉，各自独立工作，新的交易可以继续进行。
锁机制
在上面的图中，其实还隐含有一个锁机制，没有在图中表现出来。举个例子，有四个validator 节点，A,B,C,D, 在某个R轮，
在propose阶段，proposer节点广播出了新块blockX
A的超时时间内没有收到这个新块，向外广播pre-vote nil，B,C,D都收到了，向外广播pre-vote投给blockX
现在四个节点进入了pre-commit阶段，A处于红色内圈，B,C,D处于蓝色外圈
假设A由于自身网络不好，又没有在规定时间内收到超过2/3个对blockX的投票，于是只能发出 pre-commit nil投票消息投给空块
D收到了B和C的pre-vote消息，加上自己的，就超过了2/3了，于是D在本机区块链里commit了blockX
B和C网络出现问题，收不到D在pre-commit消息，这是B和C只能看到2票投给了blockX，一票投给了空块，全部不足2/3，于是B和C都只能 commit空块，高度不变，进人R+1轮，A也只能看到2票投给了blockX，一票投给了空块，也只能commit空块，高度不变，进人R+1轮
在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一致，没有产生冲突。
Tendermint与pBFT比较
Tendermint和pBFT看起来非常类似，例如：
都属于BFT类型的算法，最多容忍不超过1/3的恶意节点
都是三阶段提交，Tendermint的propose->pre-vote->pre-commit三个阶段，跟pBFT的三个阶段，pre-prepare, prepare, commit 三阶段是一一对应的
都在超时的时候，换掉proposer/primary
不够Tendermint相对于pBFT有两处简化。
Tendermint没有pBFT那种View Change阶段，Tendermint很巧妙的把超时的情况，跟普通情况融合成了统一的形式，都是 propose->pre-vote->pre-commit 三阶段，只是超时的时候新块是一个特殊的空块。切换proposer是通过提交commit空块来触发的，而pBFT是有一个单独的view change过程来触发primary轮换。
除了消除View Change这一点，Tendermint还在另一个地方有所简化，Tendermint的所有信息都存储在blockchain里。因为pBFT是1999年提出来的，那时候还没有blockchain这个东西(blockchain是2009年比特币出现之后才有的)，因此 pBFT的所有节点虽有有一致的数据，但数据是分散存放的。pBFT的每个节点的数据包括:
The state of each replica includes the state of the service, a message log containing messages the replica has accepted, and an integer denoting the replica’s current view.
Blockchain就是一个分布式数据库，好比在MySQL这类DBMS数据库没出现之前，人们都是把数据写入文件然后存在硬盘上，发明出各种奇怪的文件格式和组织方式。有了MySQL后，管理数据就方便多了。同理，Tendermint 把数据全部存入blockchain, pBFT没有blockchain这样一个分布式数据库，所有全节点需要自己在硬盘上管理数据，比如为了压缩消息日志，丢弃老的消息，节省硬盘空间，引入了checkpoint的概念，光是数据管理这一块就多了很多繁琐的步骤。
Tendermint和pBFT关系类似于Raft和Paxos的关系，Tendermint是pBFT的简化版，是针对blockchain这个场景下的简化版pBFT 。
如何选择验证节点
首先，在创始区块里，可以静态设置一组validator节点 其次，当链启动后，可以发送 ValidatorUpdate消息，更新validator列表。见 Validator Updates
这个地方文档里没有讲太多，看起来还是比较原始的，没有 Algorand 那种密码抽签类似的随机抽样算法。不过这个地方应该是可以随时拓展的。
如何轮流换 Proposer
选出来了一组validator节点后，全网所有validator节点都会存一份，比如放在一个循环数组里。
一般一个区块大部分情况下只需要一轮(round)就能产生，网络不好的时候可能要多轮才能出一个块。无论如何，每一轮都会有一个新的validator作为proposer, 轮换规则就是很简单的依次递增，第一轮，会选择数组中第0个validator作为proposer, 第二轮选择第1个validator,一次类推，到达最后一个后，重置为0，这样无限循环。
然后开始共识算法，第0轮回选择位置为0的validator 作为proposer节点，第1轮选择位置为1的validator, 第2轮选择位置为2的validator作为proposer, 到达最后一个后在重置为0，无限循环。
这种round-robin 策略，能有效的略过超时的proposer节点。如果一个proposer节点挂了或者所在网络很差，大部分节点都不能按时收到一个新快，于是超时后每个验证节点会在本机构造出一个空块，并广播投票消息出去，经过pre-vote和pre-commit两轮投票之后，最后commit一个空块，等价于什么不做，高度不变，开始新一轮。由于每开始新一轮，都会按顺序换成下一个proposer，这样就自然跳过了挂掉的proposer节点，算法能自动进行下去。
Round-robin 策略太简单了，容易被坏人预测到下一个validator是谁，于是可以提前布局，对validator发起DDoS攻击或别的攻击，怎么办呢？Tendermint的解决方法就是，把validator节点，全部放在 Sentry Node后面，对外不暴露IP地址。
π-calculus形式化证明
待续 TODO
参考资料
Tendermint: Byzantine Fault Tolerance in the Age of Blockchains
Tendermint: Consensus without mining
