Hyperledger Indy：Indy-Plenum，Plenum 拜占庭容错协议

原文地址：https://github.com/hyperledger/indy-plenum/wiki

拜占庭容错 Byzantine Fault Tolerance

---

拜占庭容错是由受拜占庭将军问题影响而产生出来的容错研究的一个子领域，这是一个通用版本的两个将军的问题。

拜占庭将军问题

拜占庭将军问题是一个有关协议（agreement）的问题，最初是由 Marshall Pease，Robert Shostak 和 Leslie Lamport 在1980年提出来的。这个问题是说，一个拜占庭的陆军部队正在准备攻击一个防御强大的城市。每一队陆军部队都是由一位将军来带领的，这位将军驻扎在敌军所在城市的周边。仅仅可以依靠信使来进行信息的交流，将军必须要同意一个常规的进攻计划。然而，一个或者多个将军有可能已经背叛了军队，可能对其他将军去混淆视听。那么问题就是找到一种算法来确保忠诚的将军能够达成一致。如果仅仅使用口头传递消息的话，只有在多于三分之二的将军还是忠诚的条件下才可以解决这个问题，所以一个叛徒可以混淆两个忠诚的将军。如果使用不可伪造的手写消息的话，任意数量的将军和可能的叛徒都可以解决这个问题。在当今的可信赖的电脑系统中，是可以找到能够解决这个拜占庭将军问题的解决方案的。

拜占庭容错（Byzantine Fault Tolerance, BFT）可以通过让忠诚的（非叛徒）将军能够对他们制定的策略达成一致协议的方式来实现。拜占庭容错的目标是能够防御拜占庭错误。

拜占庭错误

拜占庭错误是一个分布式系统在执行一个算法的时候可能会发生的任何形式的错误。它包含了一些通常被认为是 “crash failures” 和 “send and omission failures” 的错误。拜占庭失败大概可以分为以下的几种：

• 在算法中执行另一步的时候失败，也被称为 “crash failure”
• 由任何一种错误原因造成的失败，比如事故（硬件错误），或者恶意攻击（脆弱的网络模式）
• 并没有像算法中指定的那样而是以任何其他的方式执行了某个步骤

Plenum 协议

Plenum 是 RBFT（Redundant Byzantine Fault Tolerance） 的一个实现，是由 Pierre-Louis Aubin，Sonia Ben Mokhtar 和 Vivien Quema 提供的一个共识算法。就像在他们的 白皮书 中描述的那样，已经存在的 BFT 协议使用了一个特殊的被称为 “primary” 的副本（replica），这向其他的副本说明这些请求应该按照什么顺序来执行。这个 primary 可能会带有一种非常精明的恶意并且降低了系统的效率，而且不会被正确的副本所发现。我们的评估显示，RBFT 在没有错误的情况下能够像大多数健壮的协议一样具有同样的表现，当有错误发生的时候，它的最大的表现降格（performance degradation）大概是 3%，也就是说至少能达到现有协议的 78%。

RBFT 实现了一种新的方式，可以让多个协议的实例（instances）同时地运行，一个 Master 实例，和一个或者多个 Backup 实例。所有的实例都会将请求排序，但是只有由 Master 实例排序的请求才会被真正执行。所有的节点会监督 Master 并且将它生成的结果同其他的 Backup 实例生成的结果进行比较。如果 Master 的表现不可以接受，那么它就会被认为是个恶意的实例并且会被替换。

除了使用 RBFT，Plenum 还使用了 RAET（Reliable Asynchronous Event Transport Protocol），在 UDP 之上的一个非常高效，并且可容错的沟通协议。RAET 使用了 Daniel J. Bernstein 的 Curve25519，一个高安全高效率的椭圆曲线（elliptic curve）

Plenum 不同于 RBFT 的地方在于每一次的沟通都会使用 Curve25519 进行数字化的签名，而不是使用消息授权码（Message Authentication Codes）。但是从计算上来说，验证 MAC 授权要比验证数字签名高效的多，通过预估当今的协议应用系统，我们觉得在安全权衡中，使用 MACs 会更高一些。

并且， RBFT 并没有指定投票选举（election）的流程，这个流程是关于如何选出每个协议实例的 primaries 的。我们实现了一个投票的流程来选举出 primary。这个选举的策略是可插拔的，意味着可以很容易地用换用另外一种不同的安全和效率特点的策略。