EOS出块和共识

EOS生产区块：解析插件producer_plugin

Controller：EOS区块链核心控制器

原创| 源码解析 股权证明的交易(TaPos) 的作用

谈谈EOS的出块时间，不可逆时间，BFT

原创| 源码解析 producer_plugin 之区块的生产流程

共识机制

EOSIO采用的是基于流水线的拜占庭容错机制 (Pipelined Byzantine Fault Tolerance)，对于一个Block需要经过Propose、Pre-Commit、Commit、Finalize [1] 几个步骤，最后不可更改的块范围由Last Irreversible Block (LIB) 标明；一笔交易基本上需要约3分钟 (理论最低为325个出块时间，即162.5秒) 才能进入LIB，虽然相比BTC、ETH等其他数字通证的交易可靠时间有很大提高，但是对于很多应用场景来说还是有很大限制。比如支付场景，由于不能立即确定该笔交易最后是否成功，需要等待一段的时间才可完成商品的交易，这就增加了很多限制。

造成交易需要较长确认时间的原因是在DPOS BFT共识算法中，所有块同步后的确认信息都只有轮到该节点出块的时候才会被广播出去。举个例子来说，在BP1出块(所出块为BLKn)，BP1～BP21轮流出块的情况下，BP2～BP21会陆续收到并验证BLKn，但所有BP只能等到自己出块的时候才能发出对BLKn的确认信息。

在分析过EOSIO共识算法的问题以后，为了缩短一笔交易变成不可更改状态的时间，BOS将采用PBFT (Practical Byzantine Fault Tolerance[2]) 来替代Pipelined BFT，让BP之间实时地对当前正在生产的区块进行确认，能够使整个系统最终达到接近实时的共识速度。

BOS的共识算法是在 PBFT 理论基础上，结合EOSIO代码进行的改进，在保证实现拜占庭容错的前提下，会进行以下部分的改动：

保留Pipelined BFT的BP 轮流出块的机制，并且和EOS一样对同步时钟和出块顺序进行强约束

移除Pipelined BFT共识部分的逻辑，即去掉原本出块时的implicit confirm 和 (explict) confirm 部分，避免在极端情况下与PBFT的共识结果产生冲突

共识的通讯机制使用现有p2p网络进行，将会使用PBFT机制广播prepare和commit信息，并保证通信成本在可接受范围内。

采用批量共识替换PBFT中对每个块进行共识的要求，通过一次广播多个块的相关信息，以此来逼近实时BFT的理想状态并减轻网络负载。

BOS PBFT中状态描述如下：

pre-prepare，指出块节点出块以后，广播给网络里的所有其他中继节点。可以类比为EOSIO中BP出块并广播至全网。

prepare，指中继节点收到请求后向全网广播将要对此请求进行执行。可类比为EOSIO中所有节点收到块并验证成功后广播已收到的信息。

commit，指中继节点收到足够多的对同一请求的prepare消息，向全网广播执行此请求。可以类比为EOSIO中节点收到足够多对同一个块的prepare消息，提出proposed lib消息

committed-local，指中继节点收到足够多对同一请求的commit消息，完成了验证工作。 可以类比为EOSIO中的LIB提升。

view change，指出块节点因为各种原因失去其他节点的信任，整个系统更改出块节点的过程。由于EOSIO采用了Pipelined BFT的算法，所有BP是通过投票的方式提前确定的，在一轮出块中整个系统的出块顺序是完全不变的。当网络情况良好并且出块节点没有发生改变的时候可以认为不存在view change状态。当引入PBFT后，为了避免分叉导致共识不前进的情况，加入view change机制，抛弃所有未达成共识的块进行replay，不断重试直到继续共识。

checkpoint，指在某一个块高度记录共识证据，以此来提供安全性证明。当足够多的中继节点的checkpoint相同时，这个checkpoint被认为是stable的。checkpoint的生成包括两大类：一类是固定k个块生成，另一类是特殊的需要提供安全性证明的点，例如出块BP排名发生变更的块。

通过对现有EOS主网进行的观察来看，全球节点之间的网络延迟大部分都在1s以内，按照BOS PBFT的共识机制在绝大多数场景下可以做到3s (pre-prepare, prepare, commit) 不可更改。将一笔交易的可信时间从分钟级缩短成秒级将会让很多应用场景可以在BOS链上面进行实现。