走进Cosmos之Tendermint

导 读

Cosmos是由Tendermint团队构建的开源社区项目,它的共识算法是基于POS(权益证明)和BFT(拜占庭容错)的共识协议。

Cosmos通过SDK的形式将共识算法和网络模块封装起来,形成一套开箱即用的区块链开发脚手架(Tendermint),本期将为大家带来Cosmos系列文章中Tendermint共识算法的介绍。

Tendermint核心模块

首先我们回顾下,Cosmos中的Tendermint Core核心模块主要包含共识算法和网络模块,由于网络模块采用的是我们熟悉的gossip协议,这里就不再赘述。我们编写的应用层的模块通过ABCI(Application Blockchain Interface)与Tendermint核心模块进行交互,在交互的过程中,由Tendermint完成选举Proposer,BFT三阶段共识以及区块执行的逻辑。

1)ABCI Application

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

走进Cosmos之Tendermint

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

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

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

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

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

· 共识算法:BFT+POS算法;

· P2P:采用Gossip算法;

· RPC:区块链对外提供的API接口;

· 其它:交易缓存池、消息队列等。

2)POS 权益证明协议

接下来介绍Tendermint的POS算法,通过该POS算法可以在验证人集合中选取出下一轮出块的提议人。

走进Cosmos之Tendermint

上图中,假设有A、B、C三个验证人,分别抵押了1、2、3个代币(也就是初始投票权)

1. 第一轮由于C的抵押资产最多,所以C当选第一轮的提议人;

2. 第二轮由于C在上一轮当选过提议人,所以他的 vote_power 变为 pre_votingPower-(stake_a+stake_b) 也就是 3-(1+2)==0,而B的 vote_power 等于pre_votingPower+stake 也就是2+2==4,同理A的 vote_power 等于2,那么这一轮中投票权最大的是B,所以B当选提议人;

3. 第三轮A的 vote_power 为3,B的 vote_power 为2-(2+0)==0,C的 vote_power 为 0+3==3,由于A排名在C的前面,所以A当选提议人;

4. 同理第四轮A的 vote_power 为 -1,B的为2,C的为6,所以C当选提议人;

Tendermint的Pos机制有如下优点和缺点:

优点:Proposer的选择方式是与stake相关的,所以应用层可以实现自己的共识(如:DPOS),在应用层将计算好Validator的权重传递给Tendermint,Tendermint就会按照应用层需要的方式选择Proposer。

缺点:Round-Robin 策略太简单了,容易被坏人预测到下一个Proposer是谁,于是可以提前布局对rProposer发起DDoS攻击或别的攻击。这里Tendermint的解决方法就是验证人节点对外不暴露节点的IP地址。

3)BFT 拜占庭容错协议

Tendermint是一个易于理解的BFT共识协议,协议遵循一个简单的状态机原理:

协议中有两个角色:

验证人:协议中的角色或者节点,不同的验证者在投票过程中具备不同的权力(vote power)。

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

走进Cosmos之Tendermint

从图中可以看到,在propose开始阶段,被选中的proposer会给全网络广播一个proposal。如果proposer锁定在上一轮中的block上,那么proposer在本轮中发起的proposal会是锁定的block,并且在proposal中加上proof-of-lock字段。

在Prevote开始阶段,每个Validator会判断自己是否锁定在上一轮的proposal区块上,如果锁定在之前的proposal区块中,那么在本轮中继续为之前锁定的proposal区块签名并广播prevote投票。否则为当前轮中接收到的proposal区块签名并广播prevote投票。如果由于某些原因当前Validator并没有收到任何proposal区块,那么签名并广播一个空的prevote投票。

在Precommit开始阶段,每个Validator会判断,如果收集到了超过2/3 prevote投票,那么为这个区块签名并广播precommit投票,并且当前Validator会锁定在这个区块上,同时释放之前锁定的区块,一个Validator一次只能锁定在一个区块上。

如果一个Validator收集到超过2/3空区块(nil)的prevote投票,那么释放之前锁定的区块。处于锁定状态的Validator会为锁定的区块收集prevote投票,并把这些投票打成包放入proof-of-lock中,proof-of-lock会在之后的propose阶段用到。如果一个Validator没有收集到超过2/3的prevote投票,那么它不会锁定在任何区块上。

在precommit阶段后期,如果Validator收集到超过2/3的precommit投票,那么Validator进入到commit阶段。否则进入下一轮的propose阶段。

commit阶段分为两个并行的步骤:

· Validator收到了被全网commit的区块,Validator会为这个区块广播一个commit投票。

· Validator需要为被全网络precommit的区块,收集到超过2/3commit投票。

一旦两个条件全部满足了,节点会将commitTime设置到当前时间上,并且会进入NewHeight阶段。在整个共识过程的任何阶段,一旦节点收到超过2/3commit投票,那么它会立刻进入到commit阶段。

上诉过程简单来说,为了成功提交一个区块,必须经过两阶段的投票,称为pre-vote和pre-commit。当超过 2/3 的验证人在同一轮提议中对同一个块进行了pre-commit投票,那么这个区块才会被提交。

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

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

4)BFT VS PBFT

通过上文我们可以看到,Tendermint共识算法和PBFT时非常相似的,可以说是PBFT的变种,那我们来比较一下:

相同点:

· 同属BFT体系,抗1/3拜占庭节点攻击。

· 三阶段提交,第一阶段广播交易,后两阶段广播签名。

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

不同点:

· Tendermint与PBFT的区别主要是在超过1/3节点为拜占庭节点的情况下,当拜占庭节点数量在验证者数量的1/3和2/3之间时,PBFT算法无法提供保证,使得攻击者可以将任意结果返回给客户端。而Tendermint共识模型认为必须超过2/3数量的precommit确认才能提交块。

· 拜占庭节点概念不同,PBFT指的是节点数,而Tendermint代表的是节点的投票权力。

· PBFT需要预设一组固定的验证人,而Tendermint是通过要求超过 Quorum法定人数的验证人员批准会员变更,从而支持验证人的动态变化。

总结

总体来说,Cosmos中Tendermint核心模块中POS和BFT共识算法的实现较为简单,不像Polkadot的混合共识那么复杂,但是也是这个原因,可以成为区块链快速开发的脚手架,帮助越来越多的人了解区块链,热爱上区块链。

作者简介

江哲

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

本文链接:https://www.8btc.com/media/6584910

转载请注明文章出处

转载声明:本文 由CoinON抓取收录,观点仅代表作者本人,不代表CoinON资讯立场,CoinON不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。若以此作为投资依据,请自行承担全部责任。

风险提示:投资有风险,入市需谨慎。本资讯不作为投资理财建议。

走进Cosmos之Tendermint

星期四 2021-01-14 21:36:57

导 读

Cosmos是由Tendermint团队构建的开源社区项目,它的共识算法是基于POS(权益证明)和BFT(拜占庭容错)的共识协议。

Cosmos通过SDK的形式将共识算法和网络模块封装起来,形成一套开箱即用的区块链开发脚手架(Tendermint),本期将为大家带来Cosmos系列文章中Tendermint共识算法的介绍。

Tendermint核心模块

首先我们回顾下,Cosmos中的Tendermint Core核心模块主要包含共识算法和网络模块,由于网络模块采用的是我们熟悉的gossip协议,这里就不再赘述。我们编写的应用层的模块通过ABCI(Application Blockchain Interface)与Tendermint核心模块进行交互,在交互的过程中,由Tendermint完成选举Proposer,BFT三阶段共识以及区块执行的逻辑。

1)ABCI Application

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

走进Cosmos之Tendermint

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

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

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

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

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

· 共识算法:BFT+POS算法;

· P2P:采用Gossip算法;

· RPC:区块链对外提供的API接口;

· 其它:交易缓存池、消息队列等。

2)POS 权益证明协议

接下来介绍Tendermint的POS算法,通过该POS算法可以在验证人集合中选取出下一轮出块的提议人。

走进Cosmos之Tendermint

上图中,假设有A、B、C三个验证人,分别抵押了1、2、3个代币(也就是初始投票权)

1. 第一轮由于C的抵押资产最多,所以C当选第一轮的提议人;

2. 第二轮由于C在上一轮当选过提议人,所以他的 vote_power 变为 pre_votingPower-(stake_a+stake_b) 也就是 3-(1+2)==0,而B的 vote_power 等于pre_votingPower+stake 也就是2+2==4,同理A的 vote_power 等于2,那么这一轮中投票权最大的是B,所以B当选提议人;

3. 第三轮A的 vote_power 为3,B的 vote_power 为2-(2+0)==0,C的 vote_power 为 0+3==3,由于A排名在C的前面,所以A当选提议人;

4. 同理第四轮A的 vote_power 为 -1,B的为2,C的为6,所以C当选提议人;

Tendermint的Pos机制有如下优点和缺点:

优点:Proposer的选择方式是与stake相关的,所以应用层可以实现自己的共识(如:DPOS),在应用层将计算好Validator的权重传递给Tendermint,Tendermint就会按照应用层需要的方式选择Proposer。

缺点:Round-Robin 策略太简单了,容易被坏人预测到下一个Proposer是谁,于是可以提前布局对rProposer发起DDoS攻击或别的攻击。这里Tendermint的解决方法就是验证人节点对外不暴露节点的IP地址。

3)BFT 拜占庭容错协议

Tendermint是一个易于理解的BFT共识协议,协议遵循一个简单的状态机原理:

协议中有两个角色:

验证人:协议中的角色或者节点,不同的验证者在投票过程中具备不同的权力(vote power)。

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

走进Cosmos之Tendermint

从图中可以看到,在propose开始阶段,被选中的proposer会给全网络广播一个proposal。如果proposer锁定在上一轮中的block上,那么proposer在本轮中发起的proposal会是锁定的block,并且在proposal中加上proof-of-lock字段。

在Prevote开始阶段,每个Validator会判断自己是否锁定在上一轮的proposal区块上,如果锁定在之前的proposal区块中,那么在本轮中继续为之前锁定的proposal区块签名并广播prevote投票。否则为当前轮中接收到的proposal区块签名并广播prevote投票。如果由于某些原因当前Validator并没有收到任何proposal区块,那么签名并广播一个空的prevote投票。

在Precommit开始阶段,每个Validator会判断,如果收集到了超过2/3 prevote投票,那么为这个区块签名并广播precommit投票,并且当前Validator会锁定在这个区块上,同时释放之前锁定的区块,一个Validator一次只能锁定在一个区块上。

如果一个Validator收集到超过2/3空区块(nil)的prevote投票,那么释放之前锁定的区块。处于锁定状态的Validator会为锁定的区块收集prevote投票,并把这些投票打成包放入proof-of-lock中,proof-of-lock会在之后的propose阶段用到。如果一个Validator没有收集到超过2/3的prevote投票,那么它不会锁定在任何区块上。

在precommit阶段后期,如果Validator收集到超过2/3的precommit投票,那么Validator进入到commit阶段。否则进入下一轮的propose阶段。

commit阶段分为两个并行的步骤:

· Validator收到了被全网commit的区块,Validator会为这个区块广播一个commit投票。

· Validator需要为被全网络precommit的区块,收集到超过2/3commit投票。

一旦两个条件全部满足了,节点会将commitTime设置到当前时间上,并且会进入NewHeight阶段。在整个共识过程的任何阶段,一旦节点收到超过2/3commit投票,那么它会立刻进入到commit阶段。

上诉过程简单来说,为了成功提交一个区块,必须经过两阶段的投票,称为pre-vote和pre-commit。当超过 2/3 的验证人在同一轮提议中对同一个块进行了pre-commit投票,那么这个区块才会被提交。

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

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

4)BFT VS PBFT

通过上文我们可以看到,Tendermint共识算法和PBFT时非常相似的,可以说是PBFT的变种,那我们来比较一下:

相同点:

· 同属BFT体系,抗1/3拜占庭节点攻击。

· 三阶段提交,第一阶段广播交易,后两阶段广播签名。

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

不同点:

· Tendermint与PBFT的区别主要是在超过1/3节点为拜占庭节点的情况下,当拜占庭节点数量在验证者数量的1/3和2/3之间时,PBFT算法无法提供保证,使得攻击者可以将任意结果返回给客户端。而Tendermint共识模型认为必须超过2/3数量的precommit确认才能提交块。

· 拜占庭节点概念不同,PBFT指的是节点数,而Tendermint代表的是节点的投票权力。

· PBFT需要预设一组固定的验证人,而Tendermint是通过要求超过 Quorum法定人数的验证人员批准会员变更,从而支持验证人的动态变化。

总结

总体来说,Cosmos中Tendermint核心模块中POS和BFT共识算法的实现较为简单,不像Polkadot的混合共识那么复杂,但是也是这个原因,可以成为区块链快速开发的脚手架,帮助越来越多的人了解区块链,热爱上区块链。

作者简介

江哲

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

本文链接:https://www.8btc.com/media/6584910

转载请注明文章出处