3

我感兴趣地阅读了关于共识架构的结构提案，并且我有一个关于共识服务的问题。在我看来，这实际上是一个单一的服务，它保证所有对等点都按照它决定的顺序接收块。因此，对于给定的链，它看起来必须在任何给定时间由一个已识别且受信任的组织运行。看起来该服务无法分发。这是正确的，还是我误解了？

这不是一个真正的编程问题：如果这是问这个问题的错误地方，也许有人可以让我知道。

4

1 回答 1

8

更新： Kafka Orderer 现在可以生产了：

单独订购服务（测试）：单独订购服务旨在成为一种极其易于部署的非生产订购服务。它由一个服务于所有客户的单一流程组成，因此不需要达成共识，因为只有一个中央机构。相应地没有高可用性或可伸缩性。这使得 solo 非常适合开发和测试，但不适用于部署。

基于 Kafka 的排序服务（生产）：基于 Kafka 的排序服务利用 Kafka pub/sub 系统来执行排序，但将其包装在熟悉的 ab.proto 定义中，因此无需专门编写 peer orderer 客户端代码对于卡夫卡。Kafka 目前是要求高吞吐量和高可用性但不需要拜占庭容错的生产部署的首选。

PBFT 排序服务（待定）： PBFT 排序服务将使用 Hyperledger Fabric PBFT 实现（目前正在开发中）以拜占庭容错的方式对消息进行排序。

Hyperledger Fabric 中的共识服务是一个可插拔模块。有关于3 个已宣布的实现的信息：

单独订购者：单独订购者旨在成为一个非常易于部署的非生产订购者。它由一个服务于所有客户的单一流程组成，因此不需要“共识”，因为只有一个中央机构。相应地没有高可用性或可伸缩性。这使得 solo 非常适合开发和测试，但不是部署。Solo orderer 依赖于支持的原始分类帐。

Kafka Orderer（待定）：Kafka orderer 利用 Kafka pubsub 系统来执行 ordering，但是将其包装在熟悉的 ab.proto 定义中，这样 peer orderer 客户端代码就不会专门​​为 Kafka 编写。在现实世界的部署中，预计 Kafka 原型服务将在本地绑定，因为 Kafka 有自己强大的有线协议。但是，对于测试或新颖的部署场景，Kafka orderer 可以部署为网络服务。预计 Kafka 将成为需要高吞吐量和高可用性但不需要拜占庭容错的首选生产部署。Kafka 订购者不使用支持原始分类帐，因为这是由 Kafka 代理处理的。

PBFT Orderer (pending)：PBFT orderer 使用超级账本结构 PBFT 实现以拜占庭容错方式对消息进行排序。因为该实现是专门为超级账本结构开发的，所以 ab.proto 用于与 PBFT 订购者的有线通信。因此，将 PBFT 排序者绑定到对等进程是不常见的，尽管对于某些部署可能是可取的。PBFT 订购者依赖于支持的原始分类帐。

  • 对于 Solo 订购者（现在可用），“必须由单个已识别且受信任的组织运行”的声明是正确的。
  • Kafka orderer（开发中）——应该可以以分布式方式部署。
  • PBFT Orderer - 没有找到关于这个实现的信息。
于 2016-12-19T15:42:36.910 回答