TBFT开源引擎

1. 概述

Tendermint是一个开源的完整的区块链实现，可以用于公链或联盟链，其官方定位是面向开发者的区块链共识引擎。tendermint引以为傲的是其共识算法 —— 世界上第一个可以应用于公链的拜占庭容错算法。tendermint曾于2016年国际区块链周获得最具创新奖，并在Hyperledger的雨燕（Burrow） 等诸多产品中被采纳为共识引擎。由于避免了POW机制，tendermint可以实现很高的交易吞吐量。根据官方的说法，在理想的应用数据结构支持下，可以达到42000交易/秒。 在现实环境中，部署在全球的100个节点进行共识沟通，实际可以达到1000交易/秒。

Tendermint同时是拜占庭容错的（Byzantine Fault Tolerance），因此对于3f+1个 验证节点组成的区块链，即使有f个节点出现拜占庭错误，也可以保证全局正确共识的达成。同时在极端环境下，tendermint在交易安全与停机风险之间选择了安全，因此当超过f个验证节点发生 故障时，系统将停止工作。什么是拜占庭错误? 简单的说就是任何错误：既包括节点宕机、也包括恶意节点的欺骗和攻击。

说到BFT类共识算法，自然会想到PBFT共识算法。Tendermint共识算法和PBFT最大的不同点就是Tendermint没有PBFT的View Change阶段。Tendermint很巧妙的把超时的情况跟普通情况融合成了统一的形式，都是 propose->prevote->precommit 三阶段，只是超时的时候通过投空票从而使进入新的轮次来切换主节点。而PBFT是有一个单独的view change过程来触发primary轮换。因此相比PBFT，tendermint共识算法更加高效和灵活。

TBFT引擎采用的共识算法，即TBFP共识算法就是基于tendermin算法，为了更好的适应区块链环境，我们在其基础上进行了很多优化和改进，实现了名为TBFT的共识算法，它生于tendermint，优于tendermint。

2. TBFT开源引擎

站在区块链定制化角度来看，tendermint其实已经非常优秀。tendermint作最大的特点是其差异化的定位： 尽管包含了区块链的完整实现，但它却是以SDK的形式将这些核心功能提供出来，供开发者 方便地定制自己的专有区块链。tendermint的SDK中包含了构造一个区块链节点旳绝大部分组件，例如加密算法、共识算法、 区块链存储、RPC接口、P2P通信等等，开发人员只需要根据其应用开发接口 （Application Blockchain Communication Interface）的要求实现自己 的应用即可。ABCI是开发语言无关的，开发人员可以使用自己喜欢的任何语言来开发基于tendermint的 专用区块链。

虽然tendermint已经非常优秀，但是它仍然有很多局限性以及不足之处。tendermint的抽象性不足够，用户需要做非常多的操作才能适配到自己的环境，很多开发者想自己定义的模块，由于tendermint没有抽象出来，开发者不能够自定义，比如说通信网络、区块链存储、加密算法等等。因此为了弥补tendermint的这些不足，我们设计开发了TBFT开源引擎。

TBFT开源引擎就是使用TBFT共识算法作为核心的开源引擎架构，它的目标是允许开发者轻松创建自己定义的基于TBFT共识算法的区块链。TBFT引擎只专注于共识本身，不关心共识之外的其他实现，如网络通信、验签、共识内容、持久化等。开发者可以实现引擎对外提供的接口，启动自定义的节点，从而能够快速搭建一条基于TBFT共识算法实现的区块链。

TBFT共识算法已经是一个成熟且完善的共识算法，在长安链项目中，TBFT共识算法作为其核心的共识算法之一，已经稳定运行了很久，结合开源社区使用情况，解决了很多实际遇到的问题并且会继续优化和更新，这也是tendermint不具备的优势，因此TBFT开源引擎也是长安链社区对外贡献的一部分。

TBFT开源引擎包括两个主要的内容：共识引擎和通用应用接口。 共识引擎就是TBFT共识算法，保证所有的机器达成相同的共识操作从而确保安全性和活性。 应用接口，则是对外暴露一系列需要开发者实现的接口，从而达到自定义区块链的目的。在后面的章节，我们会对TBFT引擎的这两个内容进行详细的介绍。

3. TBFT VS Tendermint

TBFT与原生Tendermint的区别主要包括两个方面，第一是共识算法本身的优化，第二则是从开源角度来讲，TBFT具有更优越的开源性：

共识算法上来看，TBFT在Tendermint共识算法上改进点：

1）增加同步节点状态时的传票机制，在弱网络下的稳定性更强；

2）优化proposal提案广播机制，采用斐波那契数列发送方式，降低消息广播量；

3）节点重启时采用round快速同步模式，使得该节点可尽快与其他节点对齐；

4）将共识核心流程与辅助流程分离，提供一致性引擎辅助消息广播；

5）优化WAL写入模型，降低写入次数和内容，提供整体处理性能；

6）二阶段协议增强，支持随机函数类交易剔除操作；

7）优化超时处理机制，支持节点间动态调整超时时间，提高共识效率；

8）异步并行的消息处理模型，提高消息处理并行度，降低共识时间；

9）增加超前票的缓存机制，当节点状态达到时，可直接使用，无需等待；

在独立开源角度来看，TBFT具有如下的优势：

1）TBFT更加纯粹，它面向的对象是一个批次，这个批次可以是交易集合，也可以是其他的信息，TBFT实现本身是不关心共识内容的；

2）TBFT接口更清晰、独立。用户可以根据自己的业务场景，自定义签名、验证规则，网络消息处理、WAL存储等多种信息，TBFT提供的是一个更加独立的框架；

3）TBFT依赖库小，并且提供了基本的Demo模型，用户可根据Demo模型实现自己的区块链，而不需要太复杂的编码操作；

4. TBFT共识算法

1.TBFT算法三阶段提交

TBFT引擎，既TBFT共识算法是一种拜占庭容错共识算法，也是最多容忍不超过1/3的恶意节点。协议遵循一个简单的状态机，通过消息事件推动状态的改变。TBFT共识主要有一下几个阶段：NewHeight、NewRound、Propose、Prevote、Precommit、Commit。作为一个BFT类的共识算法。TBFT对应的三阶段分别是Propose，Prevote，Precommit三个阶段：

在上面这个三阶段图例中，第一阶段是主节点创建proposal并且广播给其他从节点的过程，第一阶段所有的节点会开启一个定时器，如果在这个超时时间内没有收到提案(主节点来看就是没有在超时时间内创建提案，从节点来看就是在超时时间内没有收到主节点的提案)，那么节点就会投一个空票。节点在一阶段收到了proposal或者一阶段超时，就会基于这个proposal生成prevote预投票，或者投空prevote票从而进入第二阶段。第二阶段就是节点收集一阶段生成的prevote预投票，在这个阶段中，每个节点需要收集到2/3+1张针对同一个proposal的prevote预投票(prevote可能是空投票，一阶段超时生成的是空prevote投票)，在这个收集过程中，如果收集到了2/3+1个任意的投票(任意的意思是可能存在针对不同proposal的投票或者空投票)就会开启第二阶段定时器。第二阶段收集到了足够的prevote投票或者第二阶段超时，会生成precommit预提交投票进入第三阶段。第三阶段就是收集第二阶段生成的预提交投票，和二阶段一样，第三阶段也是需要收集2/3+1张针对同一个proposal的precommit预提交投票，如果收集到了2/3+1个任意的预提交投票，会开启第三阶段定时器。第三阶段收集到了足够的precommit预提交投票，或者第三阶段超时则会进入到提交阶段。以上就是TBFT共识算法的三阶段核心流程，除了经典的三阶段，在三阶段前后TBFT还有其他的步骤和阶段进行对三阶段提交的补充。

2.TBFT算法流程

在TBFT共识中，我们需要的proposal，是从应用层接口获取到的batchMsg来创建的。关于batchMsg的概念我们在后面的应用接口章节会详细描述，在这儿我们先把它认为一个需要TBFT共识算法共识的内容，站在常见的区块链角度可以理解为是一个块的概念。TBFT共识算法是根据batchMsg来创建proposal的。在上面说到TBFT共识算法有六个阶段，除了三阶段之外，还有NewHeight、NewRound、Commit三个阶段。下面详细说明这六个阶段TBFT共识算法的实现。

1.NewHeight阶段

NewHeight阶段属于特殊阶段，是一个新高度共识的开始阶段，这个阶段表示上一个高度的batchMsg已经被commit了，开启下一个高度的共识。

2.NewRound阶段

NewHeight阶段之后，会进入到NewRound阶段，这时候是从round 0开始进行共识流程。TBFT达成一个batchMsg的共识可能需要多个round，因为在上文我们描述三阶段的时候提及到了如果是超时就有可能投空票，因此在一个round的共识过程中，TBFT可能在commit提交阶段的时候，没有收到2/3+1个基于同一个proposal的precommit预提交投票，因此在这个round我们没有达成基于这个proposal的共识。如果在一个round没有达成有效batchMsg投票一致的话，共识不会提交batchMsg，而是会round+1进入继续到NewRound阶段。NewRound阶段之后我们就会进入到Propose阶段，这个阶段就开始熟悉的BFT三阶段了。

3.Propose阶段

到了这个阶段，主节点就开始根据batchMsg生成提案了，主节点的选取规则是根据高度和round以及共识节点列表来计算出主节点。生成proposal之后，直接点会把proposal发送给其他从节点，然后共识进入到prevote阶段。从节点收到proposal后，验证proposal和batchMsg之后，也会进入到prevote阶段。Propose阶段所有的节点还会开启一个一阶段定时器，如果在这个时间之内，如果没有收到proposal(主节点可能是没有收到batchMsg，从节点可能是没有收到proposal)，则会超时进入到prevote阶段。

4.Prevote阶段

在Prevote开始阶段，节点会根据收到的proposal进行构造prevote投票，并将prevote投票广播给其他节点。如果由于某些原因当前节点并没有收到任何proposal，那么会签名并广播一个空的prevote投票。prevote阶段会不停的收取来自其他节点的prevote投票，如果收到了2/3+1的任何prevote投票(包括自己的prevote投票)，prevote阶段还会开启二阶段定时器，如果在这个时间内，没有收到2/3+1的同一个proposal的prevote投票，则会超时进入precommit阶段。（注：必须是收到2/3+1的任意prevote投票才开启定时器。）如果收到了2/3+1的基于同一个proposal的prevote投票(2/3+1的空prevote投票也是一样)就会进入到precommit阶段。

5.PreCommit阶段

Prevote阶段超时或者收到2/3+1的prevote投票的时候，就进入到Precommit阶段，如果此时节点收到+2/3的Prevote的投票，则会生成并且广播一条Precommit投票。和Prevote阶段一样，如果收到了2/3+1的任何precommit投票(包括自己的precommit投票)，precommit阶段还会开启第三阶段定时器(注：必须是收到2/3+1的任意precommit投票才开启定时器）。如果在这个时间内，没有收到2/3+1的同一个proposal的precommit投票，则会超时进入Commit阶段。如果收集到了2/3+1的同一个proposal的precommit投票，则会立即进入到Commit阶段。

6.Commit阶段

Commit阶段是共识流程的最后阶段了，如果收到了针对本轮次的2/3+1个precommit投票，并且之前也收到了对应这个precommit集的proposal，则会commit这个proposal中的batchMsg，然后进入NewHeight 阶段, 开启新的height；而如果没有收集到这个2/3+1的针对这个proposal的precommit投票集或者没有收到proposal，则进入NewRound 阶段, 开启新的一轮共识。