超级账本中的PBFT算法

Question

能否在不提供任何链接的情况下详细解释PBFT算法？并且它在Hyperledger中的工作原理是什么？因此，一旦交易被发送到区块链：

1. 谁验证该交易？

2. 如何对该交易达成共识？

3. 如何将该交易提交到区块链中？

- Saurabh

Answer 1

"Hyperledger" 是 Linux 基金会下的一个区块链联盟。目前，在 Hyperledger 下至少有 4 种不同的区块链框架实现：

• Fabric（IBM）
• Corda（R3）
• Iroha
• Sawtooth Lake（Intel）

在 Fabric v0.6 中：

所有验证节点之间保持开放连接。您可以将交易提交给其中任何一个节点，该交易将被广播到网络中的其他节点。其中一个节点被选举为“领导者”。当新块即将生成时：

1. 领导者指定应包含在块中的交易候选项，并将此排序后的交易列表广播到网络中的所有其他验证节点。
2. 当每个验证节点接收到排序后的交易列表时，每个验证节点执行以下操作：
   1. 它逐一开始执行排序后的交易。
   2. 一旦所有交易都被执行，它将为新创建的区块计算哈希码（哈希码包括已执行交易的哈希和世界状态的最终哈希）。
   3. 然后它将其答案（生成的哈希码）广播给网络中的其他节点，并开始计算它们的响应。
   4. 如果它看到所有验证节点中有2/3具有相同的哈希码，则将新块提交到其账本的本地副本中。

在Fabric v1.0中：

该版本仍在开发中。在v1中没有“领导者”，独立服务“Orderer”负责块中的交易顺序。该服务是可插拔的，并宣布将有3种不同的选项：

1. Solo - 单个进程负责排序
2. Kafka orderer - 利用Kafka pubsub系统执行排序
3. PBFT - 尚未实现。

在Corda中:

PBFT未被使用。这个实现使用了另一种架构方法。

- Sergey Balashevich

---

以太坊使用“工作量证明”作为共识算法。关于这个概念有很多好的文章：https://en.bitcoin.it/wiki/Proof_of_work - Sergey Balashevich

@SergeyBalashevich 我有疑问。所有这些节点都在网络上，这是指不同服务器上的不同网络位置吗？还是指在同一台虚拟机服务器上？如果所有节点都在同一网络上，那么拥有这么多节点有什么用处呢？ - Sushil

Sergey：Castro-Liskov论文描述PBFT算法是最好的参考资料。 - Kostas

@SergeyBalashevich：我没有其他评论，因为这正是你错了的地方。第2到5步是错误的。我会在周末提交一个回答，描述正在发生的事情。 - Kostas

@Kostas 仍然好奇步骤2-5到底有什么问题，你有时间准备回答了吗？ - Sergey Balashevich

Answer 2

在 Corda 中，共识是由公证人提供的。公证人运营者可以选择使用哪种共识算法，BFT 是其中一种选项。您可以在此处查看 Corda BFT 公证人示例：https://github.com/corda/corda/tree/master/samples/notary-demo。

回答您的问题： (1). 谁验证交易？ 由一个或多个公证人集群验证交易。公证人是具有解决双重支付尝试的唯一目的的节点。 (2). 如何实现交易的共识？ 使用标准的 BFT 算法。公证人集群中的每个节点对其是否认为该交易是双重支付尝试进行投票。最终决定基于多数规则，并且可以容忍集群中高达三分之一的恶意节点。 (3). 如何将交易提交到区块链？ 在 Corda 中，没有中央信息存储库来提交交易。公证人集群只需将已花费状态引用添加到内部数据库表中。它将检查未来的尝试花费状态与该表进行比较，并拒绝花费尝试，如果状态引用已经存储在那里。

- Joel

Answer 3

pbft是由Barbara Liskov和Miguel Castro于1999年提出的共识算法，旨在防止恶意攻击和软件错误导致的故障节点表现出拜占庭（即任意）行为。与之前只能在同步系统上工作的bft算法相比，pBFT被设计为在异步系统中高效运行。

这里是该研究论文的链接。

一种实用的状态机复制算法，它容忍了Byzantine故障。该算法在最多⌊n-1 / 3⌋个副本同时故障的情况下，提供了生存能力和安全性。这意味着客户端最终会收到他们请求的响应，并且这些响应根据线性可组合性是正确的。该算法在像互联网这样的异步系统中工作，并且它包含了使其能够高效执行的重要优化。

该算法大致工作如下：

1. 客户端向主节点发送调用服务操作的请求
2. 主节点将请求广播给备份节点
3. 副本执行请求并向客户端发送回复
4. 客户端等待来自不同副本的1个具有相同结果的回复；这是操作的结果。

与所有状态机复制技术一样，副本需要满足两个要求：

• 它们必须是确定性的
• 它们必须从相同的状态开始。

在满足这两个要求的情况下，该算法通过确保所有非故障副本在请求执行的总顺序上达成一致，从而确保了安全属性。

pbft的局限性：

当分布式网络中节点数量较少时，pbft共识算法才能有效运行。

Hyperledger Fabric：

根据Hyperledger Fabric v1.4，目前使用的共识机制包括SOLO、Kafka和Raft。

Hyperledger Sawtooth：

根据Hyperledger Sawtooth，在此处很好地解释了如何使用pbft：这里

- asing177

Answer 4

以上内容缺少 Hyperledger Sawtooth 的共识算法，以下是它们：

• PoET 时间戳证明（PoET）是一种可选的纳卡莫托风格共识算法，用于 Sawtooth。带有 SGX 的 PoET 具有 BFT。PoET 模拟器具有 CFT。虽然仍可能分叉并出现过时的区块，但不像 PoW 风格算法那样需要大量 CPU。请参见 https://sawtooth.hyperledger.org/docs/core/release s/latest/architecture/poet.html 中的 PoET 规范。
• RAFT 一种共识算法，选举任期内的领导者，Raft 更快，但不是 BFT（Raft 是 CFT）。此外，Raft 不会分叉。 Hyperledger Sawtooth 具有 Unpluggable Consensus 的优点。可以在不重新初始化区块链甚至不重启软件的情况下更改算法。

这里还有其他共识算法：

• PoW 工作量证明。完成工作（基于CPU密集型的Nakamoto共识算法）。通常用于无许可区块链。
• PoS 权益证明。基于最富或最老（权益）的Nakamoto共识算法。
• PBFT 实用拜占庭容错。一种“经典”的共识算法，使用状态机。使用领导者和块选举。PBFT是一个三阶段、网络密集型的算法（n^2个消息），因此不适用于大型网络。

- Dan Anderson