Istanbul-BFT共识算法以及算法中的liveness问题

首先需要声明的是Liveness的问题是搬运github上面的帖子
链接在这里

Title:Istanbul-BFT Consensus Algorithm

  • Abstract and Introduction
  • Istanbul-BFT Consensus Algorithm
    • 术语介绍
    • 共识算法介绍
    • 共识过程展示
    • Round Change Flow
  • Liveness问题介绍
  • 总结

Contents

Abstract and Introduction

Istanbul-BFT是集成在Quorum中的可选算法之一,是一种基于拜占庭容错(Byzantine Fault Tolerance)的共识算法,它的提出是为了进一步保证联盟链(Consortium Chain)共识的安全性。当然Quorum中也提供了Raft共识算法和QuorumChain一种基于合约的投票模型作为共识算法的可选项,这种模块化的共识算法对企业特别的友好,可以根据企业自身需要进行随意切换。最近也在研究Raft共识算法,针对其LeaderElection过程中的一系列问题提出了基于区块链应用场景下的解决方案,希望感兴趣的小伙伴可以与我多多交流。
总结来看,Quorum在工业化应用方面,提供了模块化共识算法的同时,针对公有链(Public Chain)中的数据隐私保护也提出了解决方案,利用Constellation构造的privateTX保护,是一种十分巧妙的隐私保护思路,有兴趣的小伙伴可以自己查阅一下相关材料,原理十分简单。总结来看,Quorum将Ethereum的商业化应用付诸实践,是一个十分不错的开源项目,后续我也会针对这个项目做更多更深的研究和实践。

Istanbul-BFT Consensus Algorithm

术语介绍

  • Validator:提供验证共识的作用
  • Proposer:Proposal的提议者,Proposal中包含了block等信息,也属于Validator,只是功能不同
  • Round:开始于Proposal的提出,结束于block的提交或者进入下一轮(一轮提交没成功)
  • Proposal:提案
  • Sequence:提案的顺序,方便对提案进行排队
  • Backlog:"The storage to keep future consensus messages."应该是对之前共识日志的存储,方便以后的验证过程
  • round state:包含了Pre-Prepare message、Prepare message和Commit message
  • Consensus Proof:可以证明该块的块承诺签名已经通过共识
  • Snapshot:上一个Epoch的Validator投票状态

共识算法介绍

Istanbul-BFT启发于PBFT(其实会发现像修改版的Tendermint),并且针对区块链的应用场景做了一系列的修改。
PROPOSE-> PRE-PREPARE->PREPARE->COMMIT->COMMITED
下图是PBFT图,由于这两种算法十分类似,我们用这个图代替Istanbul-BFT图来说明整个过程。
Istanbul-BFT共识算法以及算法中的liveness问题_第1张图片

N=3F+1(F is Fault Node,N are all Nodes)
PROPOSE:通过round-robin算法选出一个节点作为proposer
PRE-PREPARE:这个阶段主要是由proposer散发PRE-PREPARE message给其它节点。
PREPARE:这个阶段主要是各个接受到PRE-PREPARE message的节点依次向其它节点转发PREPARE message,在接受到2F
+1节点数目的消息后进入COMMIT阶段。这个PREPARE确保了所有的Validator有相同的序号(sequence确保同样的proposal)并且处在相同的轮(round)中。
COMMIT:这个阶段主要是各个Validator节点(包含proposer)向其它节点发送COMMIT message,在接受到2F+1节点数目的消息后进入COMMITED阶段。这个COMMIT主要是通知其它节点自己已经接受了proposer提出的proposal(block),并且将对其进行写入区块链的操作。

Istanbul BFT inherits from the original PBFT by using 3-phase consensus, PRE-PREPARE, PREPARE, and COMMIT. The system can tolerate at most of F faulty nodes in a N validator nodes network, where N = 3F + 1. Before each round, the validators will pick one of them as the proposer, by default, in a round robin fashion. The proposer will then propose a new block proposal and broadcast it along with the PRE-PREPARE message. Upon receiving the PRE-PREPARE message from the proposer, validators enter the state of PRE-PREPARED and then broadcast PREPARE message. This step is to make sure all validators are working on the same sequence and the same round. While receiving 2F + 1 of PREPARE messages, the validator enters the state of PREPARED and then broadcasts COMMIT message. This step is to inform its peers that it accepts the proposed block and is going to insert the block to the chain. Lastly, validators wait for 2F + 1 of COMMIT messages to enter COMMITTED state and then insert the block to the chain.

为什么要有PREPARE和COMMIT过程?
如果你有过类似的困惑,我来解释一下。 PREPARE主要是节点内部的确认,COMMIT主要是让每个节点的确认结果通知到其它节点。这样说是不是就比较好理解这个过程了(题外话,这种通讯方式造成的O(n^2)的复杂度是很不友好的限制了其共识算法的应用,也就是无法处理大规模节点。最新提出的一个算法,paper title is《Enhacing Bitcoin Security and Performance with Strong Consistency via Collective Signing》,将其降为O(n))
相比较起Tendermint共识算法有什么区别?
相比较起Tendermint共识算法,这两种共识算法都是类似于PBFT类型的共识算法,过程也比较类似,但是Istanbul-BFT共识算法缺少了PoLC(Proof of Lock Change)过程,这个过程主要是防止超过1/3的诚实节点被分别锁在两个不同的block中设置的一个变量(具体内容可以参考Tendermint共识算法中的PoLC的实现的Liveness部分),这种情况是极易在不同节点传输延迟的情况下发生的。

共识过程展示

Istanbul-BFT共识算法以及算法中的liveness问题_第2张图片

  • New Round->PRE-PREPARED
    • Proposer打包交易,将交易广播给其它的Validator,然后进入PRE-PREPARED状态。
    • 然后Validator广播PREPARE message消息给其它的Validator节点
  • PRE-PREPARED->PREPARED
    • Validator当收到2F+1个验证的PREPARE messages之后进入PREPARED状态。
    • 然后Validator广播COMMIT message消息给其它的Validator节点
  • PREPARED->COMMITTED
    • Validator收到2F+1个验证的COMMIT messages之后进入COMMITED状态
  • COMMITTED->FINAL COMMITED
    • Validator收到2F+1个提交签名然后将其写入链上。
  • FINAL COMMITED->NEW ROUND
    • Validator重新选取一个新的proposer并且开始一个NEW ROUND

Round Change Flow

  • 导致round change的三个条件:
    • round change计时器到期
    • 无效的PREPREPARE message
    • 区块插入失败

Liveness问题介绍

关于Liveness问题,导致这个问题出现的原因主要是由于节点可能会存在的传输延迟,导致诚实节点会锁在不同的区块上,导致没有足够的1/3的节点可以支持整个共识过程的进行。Tendermint共识算法针对这个问题的解决方案主要是用PoLC(Proof of Lock Change),而Istanbul-BFT并没有解锁过程,所以整个算法的Liveness是可能会存在问题的。目前应该还是没有找到一个特别合适的解决方案,具体可见前面的相关链接。

总结

Istanbul-BFT共识算法其实是做的PBFT共识算法区块链化改造,我这里也有一份详细介绍的PPT,如果大家有兴趣,我可以分享给大家。

你可能感兴趣的:(区块链学习)