BCOS vs EOS 共识算法的区别

本文参考BOS白皮书https://boscore.gitbook.io/docs/essentials/bos-resources/bos-whitepapers

一 基础概念

(1)Byzantine Fault Tolerance

Byzantine Fault Tolerance(拜占庭容错)来自与拜占庭将军问题。该问题可以表述为几位将军从多地共同攻城,已知只有同时全体决定进攻或不进攻才能保证胜利或不损伤,问题在于如何在有叛徒存在的情况下达成一致。

拜占庭容错系统就是用来解决拜占庭将军问题带来的去中心化一致性风险的手段。即在个别分布式节点出现恶意行为的情况下,拜占庭容错系统依然可以正确完成一致性确认。

现有主流底链框架中使用BFT共识机制的包括:

  • Fabric:PBFT(Practical Byzantine Fault Tolerance)
  • EOS:PBFT(pipelined Byzantine Fault Tolerance)
  • BCOS:BFT(batch Byzantine Fault Tolerance)

(2)LIB

LIB:last Irreversible Block,最后一个不能修改的区块将被标注为LIB。

If a block is deemed irreversible, it means that you can trust with 100% confidence that that transaction is final, fully confirmed, and immutable. If the block number of a block is lower than the Last Irreversible Block, that means it is considered final. Commonly abbreviated as LIB.

二共识算法

(1)EOSIO

EOSIO使用一种P(pipelines)BFT算法。每一个块,需要经历Propose、Pre-commit、Commit、Finalise阶段,该交易不可修改的时间大约是3分钟(理论上的最小值是325个块时间,也就是大约162.5秒)。

但是流水线式的验证过程存在效率低的问题。每一个块产生后会广播给其他所有验证节点进行验证,但是每个收到确认信息的节点只能轮流表达自己的意见(即块确认)。最后,经过一轮循环后才可以确认一个块。

(2)BOS

BOS网络使用P(Practical)BFT机制来代替P(Pipelined)BFT,在这样的机制下每一个BP可以立即确认块。

代码层次对EOS的修改:

  1. 保留了原共识中循环出块的机制,同步时钟、出块顺序的强限制依然保留。
  2. 删除了确认环节的部分逻辑以避免和新共识机制在边缘情况下有冲突。
  3. 保留P2P网络的通信机制,确保通信成本可接受
  4. 用批共识代替了单块机制,通过一次性广播多个块,接近实时BFT效果,降低网络负载。

BOS中PBFT的过程可以表述为:

  1. Pre-prepare
    当产生一个区块之后,广播到其他出块节点的过程。
  2. Prepare
    当一个出块节点接收到验证请求并验证成功后,将接收到的信息广播到整个网络。
  3. Commit
    当出块节点接收到足够多的对于某条请求的确认,将该请求发送到全网络
  4. Commit-local
    当出块节点收到针对某块的足够多的Commit信息,会完成块验证过程,即该块
  5. View:当出块节点改变的时候,所有未经许可的信息全部被丢弃,并重新尝试共识程序,直到达成节点共识。
  6. Checkpoint:检查块高度的一致性,用来提供安全证明。当足够多的出块节点具有相同的块高度时,该检查点被认为是可靠的。检查点的生成分为两大类:一类是固定块的生成,另一类是需要提供特殊安全证明的特殊点。

效果:
通过对EOS主网络观测,全局节点之间的网络延时大部分处于1秒以内。根绝BOS现有共识机制推算,区块一致性过程预计可以3秒内完成,即3秒内实现区块链的不可更改。

混淆点

(1)pipeline vs batch

该说法是用来区分块同步的方法。在流水线(pipeline)形式的块同步中,出块节点每次只进行一个块的验证申请。在批处理(batch)形式中,出块节点每次都会发出多个块的验证申请。

(2)DPOS BFT vs PBFT

EOS的发展传承了BM大佬在之前商业尝试中的思路,最初仍采用DPOS来实现。DPOS的核心思想在于不需要浪费算力资源争夺记账权,而是选择依据EOS持有人的投票选出21人担任记账角色。投票中拥有更多EOS的人会有更多的投票权和影响力。

但是DPOS没有考虑网络延迟的因素,比如轮流出块的节点如果分别在不同的国家,网络延迟会过多地影响同步时间。于是BM大佬设计了最新的机制为BFT-BPOS。

最新机制对DPOS主要有三点改进:

  1. 在BFT-DPOS中,引入了拜占庭容错机制,即只需要保证作恶节点不超过1/3即可。这样的机制下,只要有2/3的节点可以认可该区块就能保证全网的一致性;
  2. 按照地理位置指定BP节点出块顺序:中国->日本->美国->加拿大等,保证按照地理位置依次交接出块角色;
  3. 出块节点可以0.5秒产生一个区块,但是为了增加效率的同时考虑时延影响,每个出块节点会连续产生6个区块。区块产生与验证也是同步进行的,在进行出块的同时,也会进行其他块的验证与广播。

BOSCore侧链尝试了另外一种思路来实现速度的提升,
即基于P(practical)BFT机制的批处理方式来改进原有的EOS代码。

PBFT(Practical Byzantine Fault Tolerance),即实用拜占庭容错算法,由Miguel Castro和Barbara Liskov在1999年发表的论文《Practical Byzantine Fault Tolerance and Proactive Recovery》中提出。PBFT算法可以工作在异步环境中,并且通过优化解决了原始拜占庭容错算法效率不高的问题,将算法复杂度由指数级降低到多项式级,使得拜占庭容错算法在实际系统应用中变得可行,目前已得到广泛应用。PBFT算法可以在失效节点不超过总数1/3的情况下同时保证Safety和Liveness。

通过可批处理的BFT算法(即Batch Byzantine Fault Tolerance),目前BOSCore已实现秒级块确认及不可修改。

(3)EOS 的LIB时间到底是多少?

这里参考:https://blog.csdn.net/zhuxiangzhidi/article/details/82927020

对于EOS最新的BFT-DPOS共识机制,每一个出块节点有6秒的出块时间,每个块用时0.5秒,所以每次一个出块节点连续产生12个区块。关于设计的原因,可以参考BM的说法:

6 seconds was chosen based upon the “maximum downtime” if a producer goes off line. This matches Steem & BitShares where a single missed block creates 6 seconds without any confirmation.

通过BM与V神的讨论,DPOS的节点确认被定义为两轮。
所以总确认时间为:
T = 2*(2/3) *21 *12 = 336块时间,而理论上的最小块时间也需要325,所需的最少时间也大概是162.5秒(接近3分钟)。

猜你喜欢

转载自blog.csdn.net/weixin_43347204/article/details/108702799
eos