NEO共识机制图解

共识机制

术语说明

• 权益证实 PoS ：一种利用网络协商一致来处理容错的算法。
• 工做量证实 PoW ：一种利用计算能力来处理容错的算法。
• 拜占庭错误 BF： 一个节点保持功能，但以不诚实甚至是恶意的方式来工做。
• dBFT（一种改进的拜占庭容错算法） dBFT ：NEO
  区块链中的共识算法，该算法经过多个共识节点的协商来达成共识，有良好的可用性和最终性。
• 视图 V ：在 dBFT 算法中，一次共识从开始到结束所使用的数据集合，称为视图。

规则

在 NEO 的共识算法中，共识节点由 NEO 持有人投票选出，并对区块链中交易的有效性进行验证。过去这些节点被称做“记帐人”，如今他们被称做”共识节点”。

• 共识节点：此节点参与共识行为。 在共识行为中, 共识节点轮流担任如下两个角色：
• 议长 （一人） ：议长 负责向系统发送一个新的区块的提案。
• 议员 （多人） ：议员 负责对议长的提案进行投票，大于等于2/3的议员投票时，提案经过。

介绍

众多区块链共识算法的根本区别是他们如何保障对系统中的故障节点、恶意节点的容错能力。

传统的 PoW 方法能够提供这种容错能力，只要网络的大多数算力是诚实的。

然而，因为这种模式依赖于大量的计算，这种机制可能会很是低效且不环保（算力消耗能源，须要硬件）。 这些依赖就是 PoW 方法的限制所在，最主要的就是扩展的成本。

NEO实现了一种委托的拜占庭容错共识算法，它借鉴了一些 PoS 的特色（NEO持有人须要对共识节点进行投票） 利用最小的资源来保障网络免受拜占庭故障的影响，同时也弥补了 PoS 的一些问题。该解决方案解决了与当前块链实现相关的性能和可扩展性问题，而不会对容错产生重大影响。

理论

拜占庭位于现在的土耳其的伊斯坦布尔，是东罗马帝国的首都。因为当时拜占庭罗马帝国国土辽阔，为了防护目的，所以每一个军队都分隔很远，将军与将军之间只能靠信差传消息。 在战争的时候，拜占庭军队内全部将军和副官必需达成一致的共识，决定是否有赢的机会才去攻打敌人的阵营。可是，在军队内有可能存有叛徒和敌军的间谍，左右将军们的决定又扰乱总体军队的秩序。在进行共识时，结果并不表明大多数人的意见。这时候，在已知有成员谋反的状况下，其他忠诚的将军在不受叛徒的影响下如何达成一致的协议，拜占庭问题就此造成。

为了描述 DBFT 的工做原理，咱们将本节重点放在第 5 部分中的证实 66.66％ 的共识率的正确性。请记住，不诚实的节点不须要主动恶意，由于它根本不多是按预期运做。

为了讨论，咱们将描述一些情景。 在这些简单的例子中，咱们假设每一个节点沿着从 议长 发送过来的消息发送。 此技工也用于DBFT，对系统相当重要。 咱们将仅描述功能系统与功能失效系统之间的区别。 有关更详细的说明，请参阅参考资料。

诚实的议长

图 1： 一个 n = 3 的例子中存在一个不诚实的 议员。

在图 1 中，咱们有一个诚实的 议员 (50%)。两个 议员 从 议长 那里收到相同的消息，然而，因为其中一个 议员 不是诚实的，诚实的议员只能肯定有不诚实的节点，但没法识别它是 议长 仍是 议员。所以 议员 必须弃票，改变视图。

图 2： 一个 n =4 的例子中存在一个不诚实的 议员。

在图 2 中，咱们有两个诚实的 议员 (66%)。全部的 议员 从 议长 那里收到相同的消息，而后向其它 议员 发送消息和本身的验证结果。根据两位诚实 议员 的共识，咱们能够肯定 议长 或者右边的 议员 在系统中是不诚实的。

不诚实的议长

图 3： 一个 n = 3 的例子中存在一个不诚实的 议长。

在图 3 中，不诚实的是 议长，这和图 1 中描述的案例有一样的结论。议员 没法肯定哪一个节点是不诚实的。

图 4： 一个 n = 4 的例子中存在一个不诚实的 议长。

在图 4 所示的例子中，中间的节点和右边的节点接收的区块不可验证， 因为他们占到多数（66%），致使更换视图选举新议长。在这个例子中，若是诚实的议长向三名议员中的两名发送了诚实的数据，那么它将被验证而不须要改变视图。

实际实施

DBFT 在 NEO 中的实际实现使用迭代共识方法来保证达成共识。算法的性能取决于系统中诚实节点的分数。图5描绘了做为不诚实节点的函数的指望迭代。

请注意，图5没有低于66.66%的共识节点诚信。在这个临界点和33.33%的共识节点诚信之间，有一个无人地带，那里没法达成共识。低于33.33%的共识节点诚信，不诚实的节点（假设它们达成共识）可以本身达成共识，并成为系统中新的真理点。

图5: DBFT算法的 Monto-Carlo 模拟，描绘了达成共识所需的迭代。 {100 个节点；100,000 个模拟区块随机选择诚实节点}

定义

在算法中有以下定义：

• t：分配给区块生成的时间总量，以秒为单位。

  当前时间： t = 15 秒
  这个值能够用来粗略估计单个视图迭代的持续时间，由于共识活动和通讯事件相对于这个时间常数是快速的。

• n： 有效的共识节点数量。
• f：系统中故障共识节点的最小阈值。

  f = (n - 1) / 3

• h : 在共识活动期间的当前块高度。
• i : 共识节点索引。
• v : 共识节点视图。该视图包含节点在一轮共识中收到的汇总信息。 这包括全部议员发起的投票（prepareResponse 或
  ChangeView）。
• k : 视图 v 的索引。共识活动可能须要多轮。在共识失败时，k值增长，新一轮的共识开始。
• p : 选为议长的共识节点索引。这个索引的计算机制在共识节点间轮流，以防止单个节点成为系统内的指令器。

  p = (h - k) mod (n)

• s: 安全共识的阈值。 低于这个阈值，表示网络故障。

  s = ((n - 1) - f)

要求

在NEO中，共识容错有三项主要要求：

• s 议员必须就一项交易达成共识，而后区块才能够实施。
• 不诚实的共识节点不能说服故障交易的诚实共识节点。
• 至少s Congressmen 处于同一状态 (h,k) ，开始达成共识。

算法

该算法工做原理以下：

1.共识节点使用发送者的签名向全网广播一个交易。

图 6:一个 共识节点 收到交易并在系统中广播

2.共识节点将交易数据记录到本地存储器中。

3.共识活动的第一个视图 v 被初始化。

4.议长肯定。

图 7: 议长 肯定且设置好视图

等待 t 秒。 ​

5.议长广播提案 <prepareRequest, h, k, p, bloc, [block]sigp>

图 8:议长 提出区块提案，由众议员审阅。

6.议员收到提案并验证：

• 数据格式与系统规则是否一致?
• 交易是否已经在链上?
• 合同脚本是否正确执行?

  交易是否只包含一笔开支（即交易是否避免了双重开支的状况？)

• 若是是有效的提案广播: <prepareResponse, h, k, i, [block]sigi>
• 若是是无效的提案广播: <ChangeView, h,k,i,k+1> ​ ‘

图 9:议员 审阅区块提案并响应

7.在收到 s 数量的 'prepareResponse' 广播后，众议员达成共识并发布一个区块。

8.议员签名该区块

图 10: 达成共识，获批议员签名区块，并将其绑定到链上。

9.当一个共识节点收到一个完整区块时，当前的视图数据被清除，并开始新一轮的共识。

k = 0

NOTE
若是 ( ) 秒后在同一视图没有达成共识：

• ​共识节点进行广播：<ChangeView, h,k,i,k+1>
• 一旦共识节点接收到至少 s 个表示相同视图改变的广播，就会增长视图 v， 并引起新一轮的共识。

​

引用

• A Byzantine Fault Tolerance Algorithm for Blockchain
• Practical Byzantine Fault Tolerance
• The Byzantine Generals Problem