CoinEx Chain开发团队：详解Tendermint共识协议(一)

Z时代
2024-01-10
分类：技术分享

这是系列文章, 旨在详解Tendermint共识协议, 本篇为第一部分

共识协议的基础知识, 讨论共识协议的安全模型与PBFT协议

详解Tendermint共识协议, 介绍两阶段投票协议以及锁定与解锁机制

Tendermint项目中带权重的提案者轮换选择算法

任何共识协议最终达成的都是多数人的共识(GeneralAgreement)也即常说的少数服从多数(Majority Opinion).区块链系统运行所依赖的共识协议也不例外. 作为分布式系统的区块链系统的一个最基本的目标是维护系统的正确性.

直观来讲, 区块链系统的正确性包含两个方面的含义:不出现二义性并且能处理请求更新自身状态.其中前者对应分布式系统的安全性(Safety)要求,而后者对应分布式系统的可用性(Livenss)要求.分布式系统正确性主要由共识协议维护, 考虑到分布式系统中涉及到多个节点以及网络通信,由于节点和网络通信都可能出现的不稳定性, 给共识协议的设计带来了巨大的挑战.

半同步网络模型与拜占庭容错

为了对所有可能出现的问题进行规律,分布式系统的研究人员通过节点故障模型和网络模型来刻画节点和网络通信中可能出现的各种问题.节点故障模型中的宕机故障(Fail-StopFailure)是指节点本身由于配置错误等原因导致自身停止运行, 从而无法继续参与共识协议的情况.

这类故障除了导致节点自身停止运行之外,不会对分布式系统的其他部分产生副作用. 然而公链一类的分布式系统中,在设计共识协议时除了需要考虑节点的宕机故障之外, 还需要考虑节点主动作恶的情形,这些情况被囊括在拜占庭故障(Byzantine Failure)故障模型中.

拜占庭故障模型包含节点可能出现的所有意外情况,包括被动发生的宕机故障以及节点主动的做出的任意偏离共识协议约定的行为.

为方便叙述, 我们用宕机故障指代被动发生的节点停止运行的情况,用拜占庭故障指代主动发生的节点任意偏离共识协议的情况.

相比节点故障模型可以粗略分为被动和主动两个模型的情况,网络通信的建模相对更为困难. 网络本身就有不稳定性和通信时延的问题,而由于所有的网络通信最终都是由节点完成的.但节点本身又可能出现宕机故障或者拜占庭故障. 所以当一个节点没有收到另一个节点的网络报文时,通常难以界定是由于节点的问题还是由于网络本身的问题导致的.虽然网络通信可能受到来个多个方面的影响, 但是研究人员发现从通信时延出发可以对网络模型进行规范分类, 例如节点宕机会导致从该节点无法发送数据包, 因此对应的通信时延未知, 可以为任意的时长. 基于通信时延的概念可以将网络通信模型归纳划分为以下三类:

同步网络模型: 网络通信存在固定的并且已知的时间上界 $Delta$ .该模型下, 网络中两个节点之间网络通信的时延最大为 $Delta$ ,即使有恶意节点存在, 该恶意节点能够引起的通信时延也不超过 $Delta$ .

异步网络模型: 网络通信存在未知的时延,并且不知道时延的上界,但是消息最终还是能够被成功投递.在该模型下,网络中两个节点之间网络通信时延可以为任意可能的值,也即如果有恶意节点存在,该恶意节点可以任意延长通信时延.

半同步网络模型: 假定存在时间点GlobalStabilizationTime(GST),在GST之前为异步网络模型, 在GST之后为同步网络模型,也即网络通信存在固定且已知的时间上界 $Delta$ .

网络中的恶意节点可以将时间点GST向后任意延长,并且没有GST发生时也不会有任何的通知. 在该模型下, 在时间点 $T$ 时发生的消息被送达的时延为 $Delta + max(T, GST)$ .

同步网络模型是最理想的网络环境,每个经过网络发送的消息都能够在可预期的时间内被接收到,但是这一模型无法反应真实的网络通信情况,因此在真实的网络中, 总会时不时发生网络故障,导致同步网络模型的假设失败.异步网络模型则走向了另一个极端,也无法反应真实的网络情况,并且FLP(Fischer-Lynch-Paterson)定理指出在该模型下,只要有一个节点发生宕机故障,就不存在任何共识协议能够在有限的时间达成共识.相比之下,半同步网络模型可以较好的刻画真实世界的网络通信情况:网络通信通常是同步的,但也可能在短时间内出现问题并随后恢复正常.

这一点相信每个人在自己的上网体验中都有过这种体验,某段时间网页打开很慢, 但通常网页打开的速度都非常快,并且网络恢复正常之后,通常也没有任何通知, 只有自己尝试后才知道网络真的恢复正常了.区块链项目中经常采用的点对点(Peer-to-Peer,P2P)网络通信的实现,也使得一个节点可以从多个网络信道发送和接收信息,想要长时间内一直阻断一个节点的网络信息传播是不现实的. 因此, 本文随后讨论的都默认是在半同步网络模型下进行的.

允许节点动态加入和离开的公链网络,在设计和选用共识协议时,都需要将可能发生的拜占庭故障考虑进来.由此,公链网络的共识协议设计目标是在半同步网络模型下, 可以容忍拜占庭故障的前提下,保证网络的安全性和可用性.分布式系统的研究人员指出为了保证系统的安全性和可用性,共识协议本身需要满足以下三点:

正确性(Validity):诚实节点最终达成共识的值必须是来自诚实节点提议的值

一致性(Agreement):所有的诚实节点都必须就相同的值达成共识

可结束性(Termination):诚实的节点必须最终就某个值达成共识

可以看到正确性和一致性可以保证分布式系统的安全性,也即诚实的节点永远不会就某个随机的值达成共识,并且共识一旦达成所有的诚实节点都同意这个值. 而可结束性则保证了分布式系统的可用性,一个永远无法达成共识的分布式系统是没有任何用处的.

拜占庭将军问题与CAP定理

在半同步网络下, 是否真的可以设计出拜占庭容错并满足正确性,一致性和可结束性的共识协议? 该协议又可以容忍系统中存在多少个拜占庭节点?CAP定理和拜占庭将军问题为这两个问题提供了答案,成为指导拜占庭容错的共识协议设计的基本准则.

Lamport, Shostak和Pease在1982年将分布式系统中的共识机制设计问题抽象为: 拜占庭将军问题.该问题可以表述为,多位将军各自率领军队参与战争并且军队驻扎在不同的地方.为了取得战争的胜利,将军们必须制定统一的行动计划. 然而由于驻扎地相聚较远,将军们只能通过通信兵进行相互通信,也即将军们无法同时出现在统一个场合当面达成共识.更不幸的是,将军当中有叛徒,而叛变的将军希望通过发送错误的信息来破坏忠诚的将军们的统一行动,而通信兵本身无法将消息送到目的地.

此处假设每个通信兵都能够证明自己带来的是某个将军的信息,在真是的BFT共识协议中,每个节点都有自己的公私钥来相互建立加密通信信道,保证网络通信中自己的消息不会被篡改,消息接收方也可以据此验证消息的发送方.正如前面已经提到过的, 任何共识协议最终达成的都是多数人的共识,在将军们互相通信以达成进攻还是撤退的过程中,一个将军同样根据其收集到的信息中多数意见作出自己的决策.

Lamport等人对该问题的研究表明,节点中只要有1/3及以上的叛徒,将军们就无法达成统一的决策. 以下图为例,假设有3个将军,并且只有1个叛徒.在左侧的图中, 假设将军C是判断,而A和B则是忠诚的.如果A想要发动攻击,分别向B和C传递想要仅供的指令,而叛徒C则向B传递消息称A发送给自己的消息是撤退, 则B拿到来自A和B的消息之后, 无法做出自己的决定.

因为B并不知道谁是叛徒,并且根据收到的信息也无法支撑B做出决定.而如果A是叛徒, 则可以向B和C发送不同的消息,此时C向B如实的报告了自己收到的信息, 此时B同样看到了互相矛盾的信息且无法做任何决定.在两种情形中,B收到的信息是一致的, 也无从分辨A和C之中到底谁是叛徒. 因此可以看到, 在下图展示的两种情形中, 诚实的将军B无法做出抉择.

根据这一结论, 推而广之, 可知当总共有 $n$ 个将军并且其中至多有 $f$ 个叛徒时, 如果 $n leq 3f$ , 则此时将军们无法达成一致的共识, 而当 $n > 3f$ 时, 则可以达成一致的共识.根据这一结论,可知当拜占庭故障的节点数 $f$ 超过系统中总节点数 $n$ 的1/3时 $f ge n/3$ ,不存在任何共识协议可以在全部诚实节点中达成共识. 只有 $f < n/3$ 时, 才有可能达成共识, 因此不失一般性, 后续的共识协议讨论都默认 $n ge 3f + 1$ .

Lamport等人对拜占庭将军问题的结论为拜占庭容错协议的设计在拜占庭故障的容忍度方面画出了可能与不可能的分界线. 在可能范畴里, 共识协议的设计最终可以达到怎样的效果, 是否可以完全保证分布式系统的安全性和可用性? Brewer在2000年提出的CAP定理提供了答案. CAP定理指出, 一个分布式系统需要下面三个基本的属性, 但是任意分布式系统, 最多只能同时满足三个属性中的两个.

一致性(Consistency): 任意节点相应请求时要么提供最新的状态信息, 要么不提供任何状态信息

可用性(Availability): 系统中任意的节点都要能够持续进行读写操作

网络分区容忍(Partition Tolerance): 系统可以容忍网络在两个节点之间丢失任意多个消息仍然能够正常运转

分布式系统的最终目的是对外提供类似于一致的服务, 因此一致性属性要求系统中的两个节点不能提供相互矛盾的状态信息, 也不能提供已经过期的信息, 这可以保证分布式系统的安全性目标. 可用性的属性则保证系统可以持续更新自身状态, 可以保证分布式系统的可用性目标. 网络分区容忍属性则与网络通信时延相关, 在半同步网络模型下可以认为是在GST时间之前的状态, 此时网络处于异步状态, 网络通信延时有未知的时延, 通信的节点间可能无法收到对方的信息, 此时认为网络处于分区状态. 网络分区容忍属性则要求分布式系统及时在面对网络分区时依然能够正常运转对外提供功能.

CAP定理的证明可以通过以下图示完成, 其中图中的曲线代表网络分区, 每个网络中均有四个节点,用数字1, 2, 3, 4进行区分, 该分布式系统存储颜色信息, 最开始所有节点储存的状态信息均为蓝色.

网络分区容忍与可用性意味着丧失一致性: 最左侧图中当节点1收到新的请求时而改变状态为红色, 节点1的状态转换信息传递给节点3, 节点3也更新状态信息为红色. 但是节点3和节点4由于网络分区没有接收到相应的信息, 状态信息仍为蓝色. 此时如果通过节点2查询状态信息, 节点2返回的蓝色并不是系统的最新状态, 从而丧失了一致性.

网络分区容忍与一致性意味着丧失可用性: 中间的图中, 所有节点初始状态信息均为蓝色. 当节点1和节点3更新状态信息为红色之后, 节点2和节点4由于网络分区仍保持过时的状态信息蓝色. 同样通过节点2查询状态信息时, 由于节点2需要遵循一致性所以在返回状态信息之前需要先通过询问其他节点来确定自己的状态是最新状态, 但是由于网络分区的存在, 节点2无法从节点1和节点3接收到任何信息, 此时节点2会无法确定自己的状态是最新的状态, 因此选择不返回任何信息, 由此系统丧失了可用性.

一致性与可用性意味着丧失了网络分区容忍特性: 最右侧图中, 系统初始不存在网络分区, 状态更新与查询都可以顺利进行. 但是一旦发生网络分区情况, 则退化为前面两种情况之一, 因此证明了任意分布式系统在同一时间无法同时保证三种属性都成立.

CAP定理的发现似乎宣告了前述的共识协议的目标是无法达成的. 但是从上面的证明中细心的读者可以发现, 证明中所涉及到的都是极端情况, 比如网络分区导致信息完全无法传输的情况, 在现实世界中很少碰到, 尤其是当采用P2P网络通信时. 而第2种情形时, 现实系统也很少会跟节点2一样不返回任何信息, 通常的做法是在查询别的节点等待适当的时间之后, 不论是否真的拿到了别的节点的请求信息, 都返回自己认为的最新状态. 因此虽然CAP定理指出了任何分布式系统无法同时满足三种属性, 但是这并不是非黑即白的二元选择, 作为共识协议的设计者, 可以根据分布式系统的需求在三种属性之间做权衡做选择. 然而由于分布式系统中总会涉及到通信延时, 因此任何分布式系统的实际都要在保证某种程度的网络分区容忍的前提下, 在可用性和一致性方面做出选择. 具体来说则是在前述的第2种情形, 节点2是返回某些可能过时的值还是直接不返回任何值. 返回可能过时的值, 可能违背了一致性属性, 但是保证了可用性, 而不返回任何值, 则丧失了系统的可用性, 却保证了系统的一致性. 后续将要介绍的Tendermint共识协议可以认为在这种权衡中选择了一致性, 也即在某些情况下会丧失可用性.

中本聪的天才之处也正是在CAP定理约束的前提下, 在不可靠网络环境中, 通过组合PoW机制, 中本聪共识协议与经济激励措施以及适当的参数配置, 从而在大规模的分布式网络中达成可靠的拜占庭共识. 关于Bitcoin的机制设计是否真正解决了拜占庭将军问题, 在学术界一直有争议. Garay, Kiayias和 Leonardos在论文The Bitcoin Backbone Protocol: Analysis and Applications 中详细分析了Bitcoin中的机制设计与拜占庭共识问题之间的联系, 简单来说中本聪共识是一种概率性的拜占庭容错的共识协议, 依赖于网络通信环境, 恶意节点的算力占比等条件. 当网络通信环境良好, 恶意节点的算力占比不超过1/2时, 中本聪共识能够在分布式环境中可靠的解决拜占庭共识问题. 然而当网络通信环境变差时, 恶意节点的算力占比即使不超过1/2时, 也会导致中本聪共识无法就拜占庭共识问题达成可靠的结论. 值得注意的是, 网络环境质量是相对于Bitcoin的出块间隔来说的, Bitcoin选择的10分钟的出块间隔可以保证在绝大多数情况下系统的网络通信环境都是良好的, 因为就Bitcoin网络的实际运营经验, 一个区块在分布式网络中的广播时间通常小于1秒钟. 另一方面, 经济激励的设置又可以激励大多数的节点主动遵从协议约定的行为. 由此, 可以认为在当前的Bitcoin网络参数配置以及机制设计下, 在当前世界的网络环境这一特定的场景下, Bitcoin中的机制设计可靠的解决了拜占庭共识问题.

PBFT协议简介

半同步网络中的拜占庭容错的共识协议设计并不容易, 第一个实际可使用的拜占庭容错的共识协议是在1999年由Castro和Liskov设计的实用拜占庭容错协议(Practical Byzantine Fault Tolerance, PBFT). PBFT是首个多项式复杂度的拜占庭容错的共识协议, 对于包含 $n$ 个节点的分布式系统, 其通信复杂度为 $O(n^2)$ . Castro和Liskov在论文中报告, 通过使用PBFT协议将中心化的文件系统改造为分布式的文件系统之后, 整体的性能损失仅有3%. 本小节简要介绍PBFT协议, 为后续深入详解Tendermint协议以及理解Tendermint协议的改进之处做铺垫.

包含 $n=3f+1$ 的节点的PBFT协议可以容忍最多 $f$ 个拜占庭节点, PBFT原始论文中要求 $n$ 个节点之间存在全连接, 也即 $n$ 个节点中任意两个节点都相互建立网络连接. 所有的节点通过网络通信共同维护系统状态. Bitcoin网络中允许任意节点在任意时刻参与通过算力挖矿参与或退出共识过程, 而PFBT协议需要在协议开始之前确定所有参与的节点, 节点的加入与退出由管理员负责管理. PBFT协议中所有的节点被分为两类, 主节点和从节点. 任意时刻主节点仅有一个, 所有的节点轮流做主节点. 所有节点都在一个被称为视图(View)的轮换过程中运行, 每个视图中都会重新选择主节点. PBFT中的主节点选择算法非常简单, 所有节点按照编号轮流成为主节点. 在每个视图中, 所有节点尝试就系统状态达成共识. 值得提及的是, PBFT协议中每个节点都有自己的数字签名密钥对, 所有发送的消息(包括客户端的请求消息)都需要进行签名操作, 以保证消息在网络传播中的完整性以及消息本身的可追溯性(可以根据签名值判断一个消息是由谁发送的).

下图中展示了PBFT共识协议的基本流程. 假设当前试图的主节点为节点0.客户端C向主节点0发起请求, 主节点收到请求之后将请求广播给所有从节点, 所有从节点均处理客户端C的请求并向客户端返回结果. 客户端从不同的节点(根据签名值判断)收到 $f+1$ 个相同的结果之后, 即可将该结果作为整个操作的最终结果. 因为系统中最多有 $f$ 个拜占庭节点, 这就意味着客户端收到的 $f+1$ 结果中至少有一个来自诚实的节点, 而共识协议的安全性保证了所有诚实节点会就相同的状态达成共识, 所以来自1个诚实节点的反馈就足以确认相应的请求已经被系统处理.

为了保证所有诚实节点的状态同步, PBFT协议对每个节点有两个约束条件, 一是所有的节点必须从相同的状态开始, 二是所有节点的状态转移必须是确定性的, 也即给定相同的状态和请求, 操作执行之后的结果必须是相同的. 在这两个条件的约束下, 只要整个系统对所有的交易的处理顺序达成一致, 就可以保证在所有诚实节点的状态是一致的. 这也是PBFT协议的主要目的: 在所有的节点之间就交易的顺序的达成共识, 从而保证整个分布式系统的安全性. 可用性方面, PBFT共识协议依赖超时机制发现共识过程中的异常, 并及时启动视图转换协议(View Change)来再次尝试达成共识.

上图展示了一个简化的PBFT协议的工作流程. 其中C为客户端, 0, 1, 2, 3分别代表4个节点, 其中0为当前视图主节点, 1, 2, 3为从节点, 并且节点3为故障节点. 正常情况下, PBFT共识协议通过三阶段协议在节点之间就交易顺序达成共识, 这三个阶段分别为: 预准备(Pre-Prepare), 准备(Prepare)以及提交(Commit):

预准备节点主节点负责对接收到的客户端请求分配序号, 并向从节点广播<PRE-PREPARE, v, n, d, sig>消息, 消息中包含客户端请求的哈希值d, 当前视图序号v, 主节点为该请求分配的序号n, 以及主节点的签名信息sig. PBFT协议的方案设计将请求传输与请求排序过程做了分离, 请求传输此处不讨论. 收到消息的从节点, 检查消息合法后就接受该消息并进入准备阶段. 这一步的消息查了检查基本的签名, 哈希值, 当前视图之外, 最重要的检查是判断主节点是否在当前视图给不同的客户端请求消息赋予过相同的序号.

在准备阶段, 从节点向所有节点(包括自己)广播消息<PREPARE, v, n, d, sig>, 表示自己认同在当前视图v下给哈希值为d的客户端请求分配序号n, 并有自己的签名sig做证明. 收到消息的节点会检查签名正确性, 视图序号的匹配性等, 并接受合法的消息. 当节点收到的关于一个客户端请求的PRE-PREPARE消息(来自主节点)和来自2f个从节点的PREPARE均相互匹配时, 意味着在当前视图中系统就该客户端请求的序号达成了一致. 因为这意味着当前视图中有2f+1个节点认同该请求序号的分配, 由于其中至多包含f个来自恶意节点的信息, 这就意味着至少有f+1个诚实节点认同了该请求序号的分配. 当存在f个恶意节点时, 城市节点共有2f+1个, 则f+1就是诚实节点中的大多数, 也就是之前提过的多数人的共识.

当节点(包括主节点和从节点)收到一个客户端请求的PRE-PREPARE消息和2f个PREPARE消息之后, 就全网广播消息<COMMIT, v, n, d, sig> 并进入提交阶段. 该消息用来表明该节点已经观察到全网已经就该客户端请求消息的序号分配达成共识. 当节点收到2f+1个COMMIT消息之后, 意味着至少有f+1个诚实节点, 也即诚实节点中的大多数都观察到了全网已经就该客户端请求消息的序号分配达成了共识. 此时节点可以处理该客户端请求并向客户端返回执行结果.

粗略来讲, 预准备阶段由主节点为所有新的客户端请求指定序号, 在准备阶段所有节点就本视图内的客户端请求序号达成共识, 而提交阶段则用来保证在不同视图之间客户端请求序号的一致性. 另外PBFT协议本身的设计并不依赖请求消息按照分配的序号顺序一次提交, 而允许请求消息的乱序提交, 这样可以提高共识协议的执行效率, 但是最终执行时, 消息还是按照共识协议分配的序号顺序执行以分布式系统的一致性.

在PBFT协议的三阶段协议执行过程中, 节点本身除了维持分布式系统本身的状态信息之外, 也需要日志记录其所收到的各类共识信息. 日志的逐渐累积会耗费可观的系统资源, 因此PBFT协议中还额外定义了检查点(Checkpoints)来帮助节点进行垃圾回收(Garbage Collection). 可以根据请求序号每100或者1000个序号设置一个检查点, 当执行完检查点处的客户端请求之后, 节点全网广播<CHEKPOINT, n, d, sig>消息, 表示节点在执行完序号为n的客户端请求之后, 系统状态的哈希值为d, 并且通过自己签名sig做保证. 当接收到2f+1个相互匹配的CHECKPOINT消息之后(其中1个可以来自于自己)就意味着全网中诚实节点的大多数中就执行完序号为n的客户端请求之后的系统状态达成了共识, 则可以清空所有序号小于n的客户端请求的相关日志记录. 节点需要保存这2f+1个CHECKPOINT消息作为此时状态合法的证明, 对应的检查点则被成为稳定检查点(Stable Checkpoint).

PBFT协议的三阶段协议可以保证客户端请求处理顺序的一致性, 而检查点机制的设置一方面在帮助节点进行垃圾回收之外, 也进一步确保了分布式系统状态的一致性, 这些可以保证前面提到的分布式系统的安全性. 分布式系统的另一个目标可用性又是如何保证的? 在半同步网络模型下, 通常会引入超时机制. 而超时的时间窗口的设置, 则网络环境的延时 $Delta$ 有关. 半同步网络模型中, 在GST之后假设网络时延 $Delta$ 有已知的上界, 在具体的系统实现中, 则通常会根据系统部署的网络情况设定一个初始值, 在发生超时事件时, 除了触发相应的处理流程之外, 也会进入额外的机制重新调整等待时间, 例如可以通过类似于TCP的指数退避一类的算法调整发生超时事件后的等待时间.

在PBFT协议中为了保证系统的可用性, 也引入了超时机制. 另外由于主节点本身可能发生拜占庭故障, PBFT协议也需要确保这种情况下系统的安全性和可用性. 当主节点出现拜占庭故障时, 例如从节点在设定的等待时间内没有收到来自主节点的PRE-PREPARE消息或者主节点发送的PRE-PREPARE消息被判定非法时, 从节点可以向全网广播<VIEW-CHANGE, v+1, n, C, P, sig>, 表示节点请求切换到序号为v+1的新视图. n表示节点本地的最新的稳定检查点对应的请求序号, C则是前述的用来的证明该稳定检查点的2f+1个合法的CHECKPOINT消息. 在最新的稳定检查点之后和发起VIEWCHANGE消息之前, 在上一个视图中, 可能系统已经就部分请求消息的序号达成了共识, 为了保证这些请求序号在视图切换时的一致性, VIEWCHANGE消息需要将这部分信息传递至新视图中, 这也是该消息中P字段的含义, P中包含了所有该节点处收集到的请求序号大于n的客户端请求消息以及该序号已经在节点中达成共识的证明: 关于该请求的合法的PRE-PREPARE消息以及2f个匹配的PREPARE消息. 当视图v+1中的主节点收集到2f+1个VIEWCHANGE消息时就可以广播发送NEW-VIEW消息将整个系统带入到新的视图当中. 为了结合PBFT协议的三阶段协议保证系统的安全性, NEW-VIEW的信息的构造规则十分复杂, 此处不再详细介绍, 感兴趣的读者可以参考PBFT的原始论文.

可以看到VIEWCHANGE中包含了大量的信息, 例如C中包含2f+1个签名信息, P中包含了若干个签名集合, 每个集合均有2f+1个签名信息. 又因为至少有2f+1个节点需要发送VIEWCHANGE消息才能促使系统进入下一个新视图, 由此可以看到在构造VIEWCHANGE和NEW-VIEW的信息的复杂逻辑之外, 视图转换协议的通信复杂度为 $O(n^2)$ , 这一复杂度也限制了PBFT协议只能支持较少的节点, 而当有100个节点时, PBFT由于复杂度太高通常无法实际部署. 值得注意的是, 有的资料里面将PBFT协议的 $O(n^2)$ 的通信复杂度完全归结于 $n$ 个节点之间的全连接, 这是不恰当的. 通过将全连接的网络拓扑结构改为目前区块链项目中常用的基于分布式哈希表的P2P网络拓扑结构, 可以显著由于全连接引入的通信复杂度较高的问题. 但是在视图转换过程中的通信复杂度的改进较为困难. 近几年有研究人员提议通过采用聚合签名的技术来降低这一步的通信量.利用聚合签名技术, 可以将2f+1个签名信息压缩成一个签名信息, 从而降低降低视图转换过程的通信量.

*本文由CoinEx Chain开发团队成员longcpp撰写。CoinEx Chain是全球首条基于Tendermint共识协议和Cosmos SDK开发的DEX专用公链，借助IBC来实现DEX公链、智能合约链、隐私链三条链合一的方式去解决可扩展性（Scalability）、去中心化（Decentralization）、安全性（security）区块链不可能三角的问题，能够高性能的支持数字资产的交易以及基于智能合约的Defi应用。

以上是 CoinEx Chain开发团队：详解Tendermint共识协议(一) 的全部内容，来源链接： utcz.com/a/26366.html