量子链研究院:Tendermint 技术详解

互联网 2019-02-28 10:03:21

区块链系统可以归结为如下图所示的六层架构模型,自下而上分别是数据层、网络层、共识层、激励层、合约层和应用层。部分区块链应用并不完整地包含这六层结构,但是数据层、网络层和共识层可以说是构建所有区块链应用的必要因素。

目前,大部分的区块链应用都是采用整体的设计方法,就是说,这些区块链应用实现成单一的程序,一个程序实现了区块链各层的所有功能,包括P2P连接,交易数据的处理和广播,共识达成,具体的应用功能实现等等。

例如比特币,一整套代码就实现了所有比特币的功能。从软件工程的角度来看,这种非模块化的设计是不合理的,这会使代码复用变得困难,代码的分支管理也变得复杂,同时还限制的区块链应用开发使用的语言。

针对这个问题,Tendermint对区块链的功能模块进行解耦,将共识和P2P部分从具体的区块链应用状态细节中分离出来,以适用各种分布式应用。

Tendermint由两部分组成:区块链共识引擎和通用的应用程序接口。

1. 共识引擎被称为Tendermint Core,用于确保同一个交易在不同机器上记录的顺序相同。

2. 通用的应用程序接口也被称为应用区块链接口(Application Blockchain Interface,ABCI),其作用是使交易可以用任何编程语言进行处理。

Tendermint Core通过ABCI接口与应用层进行交互,应用程序可以用任何语言编写,开发者可以很方便地开发自己的区块链应用。

Tendermint Core

Tendermint Core实现区块链大部分功能,包括:共识算法,RPC,数据库,同步,P2P等等。本节主要介绍Tendermint共识算法。

Tendermint共识算法

Tendermint使用一种基于拜占庭容错(BFT)的共识算法,其工作模式类似于循环投票机制。参与Tendermint共识过程的角色主要有两个:

· Validator(验证者):网络中的节点,可参与共识过程中的投票,不同的验证者在投票过程可能具备不同的投票权重(vote power)。

· Proposer(提议人):Tendermint使用一种确定的非阻塞轮询选择算法从validators中选出proposer,该算法根据validators的投票权重所占比例来选择proposer,投票权重越大的validator被选为proposer的频率越高。

Tendermint区块链是通过基于round(回合)的机制来确定下一个区块。每个round由三个过程组成:propose(提议),prevote(预投票)和precommit(预提交)。

理想情况下,链上的区块生成状态如下:

NewHeight -> (Propose -> Prevote -> Precommit) -> Commit -> NewHeight ->...

其中,NewHeight为区块被全网接受后,区块高度+1。Propose -> Prevote -> Precommit为一个round,这里加括号表示在某一区块高度成功提交一个区块可能需要多个round,也就是说,一个round可能无法成功地提交区块。

区块链处于某一区块高度时,为决定出下一区块,系统会进入如上图所示的共识过程。

第一阶段为propose阶段,在该阶段由系统选出的proposer提议将某一交易区块作为链上的下一区块,并将该提议广播出去。接下来需要进入两个投票阶段:prevote和precommit。在prevote阶段,对于proposer提议的区块,若validator验证为有效区块,那么validator会对其进行prevote;相反,若为无效区块或者validator没有及时收到提议的区块,那么validators的prevote为空(Nil)。

在precommit阶段,若validator收到该区块超过2/3的prevote,那么validator会对区块进行precommit;反之,则precommit为Nil。

上图中有一对夫妇在跳polka(波卡)舞,validator做的事情就像在跳polka舞。当超过2/3的validators对提议的区块进行了prevote,可以称为一个Polka。每次precommit必须由同一round的Polka证明。

在precommit阶段的最后,每个节点需要作出决定。若节点收到了超过2/3的precommit,那么节点进入commit阶段;否则,节点继续进入下一round的propose阶段。

因此,系统处于propose阶段是由两种条件驱动,一种是区块被提交到链上后重新提交新的区块,新的区块高度+1;另一种是区块提交失败后重启round,此时区块高度不变。

此时,我们可以分析在共识过程中为什么成功提交一个区块可能需要多个round,原因有以下几点:

· 选出的proposer不在线;

· proposer提议的区块无效;

· proposer提议的区块没有及时传播出去;

· 提议的区块有效,但在到达Precommit阶段前,validator节点没有及时收到超过2/3的prevote。或者是,prevote超过2/3可以进入下一状态,却出现至少有一个validator投了Nil票或恶意投票;

· 提议的区块有效,并且prevote超过了2/3,但是validator节点没有收到超过2/3的precommit。

每个round开始期间,若validators在一个timeout时间内没有收到提议,validators将通过投票来决定是否跳过当前的proposer。这种对超时的依赖使得Tendermint是一种弱同步协议,而不是一种异步协议。但是,每个round在收到提议之后,就进入完全异步模式,validators只能在取得超过2/3的共识后才能继续往前。

Tendermint共识算法可以容忍1/3以内的节点错误,这个错误包括节点离线和节点作恶。

在拜占庭节点数少于节点总数的1/3时,为了避免出现在同一区块高度不同round分别提交两个不同区块的情况,Tendermint引入了锁机制。Validators会被锁定在其最近precommit的区块上。当收到区块超过2/3的prevote后,validators为该区块进行precommit,validator即锁定在该区块上了。Validators节点每次最多只能锁定一个区块,且只能prevote他们被锁定的区块,这样可以阻止validators在上一round中precommit一个区块,在下一round中又prevote另一个区块,从而避免出现在同一区块高度提交两个不同区块的情况。Validators只有看到更高round(相对于其当前被锁定区块的round数)的polka才能解锁,该polka包括收到超过2/3的prevote或Nil prevote两种类型的polka。

因此,如果拜占庭节点数少于1/3,基于Tendermint的区块链永远不会分叉。

上面说到,大部分的区块链应用都是采用整体的设计方法,就是说,这些区块链应用实现成单一的程序,一个程序实现了区块链各层的所有功能,包括P2P连接,交易数据的处理和广播,共识达成,具体的应用功能实现等等。

例如比特币,一整套代码就实现了所有比特币的功能。从软件工程的角度来看,这种非模块化的设计是不合理的,这会使代码复用变得困难,代码的分支管理也变得复杂,同时还限制的区块链应用开发使用的语言。

针对这个问题,Tendermint对区块链的功能模块进行解耦,将共识和P2P部分从具体的区块链应用状态细节中分离出来,以适用各种分布式应用。

Tendermint由两部分组成:区块链共识引擎和通用的应用程序接口。

1. 共识引擎被称为Tendermint Core,用于确保同一个交易在不同机器上记录的顺序相同。

2. 通用的应用程序接口也被称为应用区块链接口(Application Blockchain Interface,ABCI),其作用是使交易可以用任何编程语言进行处理。

Tendermint Core通过ABCI接口与应用层进行交互,应用程序可以用任何语言编写,开发者可以很方便地开发自己的区块链应用。

ABCI(Application Blockchain Interface)

Tendermint Core通过一个满足ABCI标准的socket协议与应用程序进行交互。

ABCI 包含3 种消息类型:DeliverTx消息,CheckTx消息和commit消息。Tendermint Core将消息发送给应用,应用根据消息进行相应的回复。

DeliverTx 消息是应用的主要工作流程。链上的每笔交易都通过这个消息进行传送。应用基于当前状态、应用协议和交易的加密证书,验证接收到 DeliverTx 消息的每笔交易。然后,验证后的交易会更新应用状态。

CheckTx 消息类似于 DeliverTx,但它仅用于验证交易。Tendermint Core 的内存池首先使用 CheckTx 检验交易的有效性,并且只将有效交易广播给其他节点。

Commit 消息用于通知应用程序计算当前应用状态的加密保证(cryptographic commitment),该加密保证会被放入下一个区块头部。

一个应用可能与多个ABCI socket 连接。Tendermint Core 给应用程序创建了三个 ABCI 连接:一个用于内存池广播时的交易验证,一个用于区块提议时的共识引擎,还有一个用于查询应用状态。

总结

本文主要介绍了Tendermint共识算法和ABCI接口。Tendermint是基于BFT的共识算法,在错误节点不超过1/3的情况下,Tendermint保证安全永远不会被破坏,系统不会在同一区块高度提交冲突的区块。

因此,区块链永远不会分叉。但是每个投票环节都需要得到超过2/3的validators的投票,在现实世界中有很大可能性系统真的会停止运行,这个问题还需要对应的解决方法。

相关资讯Relevent