详解Tendermint共识算法
Posted 跨链技术践行者
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了详解Tendermint共识算法相关的知识,希望对你有一定的参考价值。
Tendermint算法核心流程是什么?Tendermint隐含了什么锁机制?
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地址。
以上是关于详解Tendermint共识算法的主要内容,如果未能解决你的问题,请参考以下文章