Ric*_*h N 3 consensus hyperledger hyperledger-fabric
我已经阅读了有关共识架构的结构提案,我对共识服务有疑问.在我看来,这实际上是一种单一服务,可以保证所有对等体按照它所决定的顺序接收块.因此,在任何给定时间,对于给定的链,它看起来必须由单个已识别且受信任的组织运行.它看起来不像服务可以分发.这是正确的,还是我误解了？
这不是一个真正的编程问题:如果这是一个错误的地方提出这个问题,也许有人可以让我知道.
更新: Kafka Orderer现已投入生产:
独立订购服务(测试):独立订购服务旨在成为一种非常易于部署的非生产订购服务.它由一个为所有客户提供服务的流程组成,因此不需要达成共识,因为只有一个中央机构.相应地没有高可用性或可伸缩性.这使得solo非常适合开发和测试,但不适合部署.
基于Kafka的订购服务(生产):基于Kafka的订购服务利用Kafka发布/订阅系统来执行订购,但是将其包含在熟悉的ab.proto定义中,以便不会专门编写对等订购者客户端代码为卡夫卡.Kafka目前是生产部署的首选,它需要高吞吐量和高可用性,但不需要拜占庭容错.
PBFT订购服务(待定): PBFT订购服务将使用Hyperledger Fabric PBFT实施(目前正在开发中)以拜占庭容错方式订购消息.
Hyperledger Fabric中的共识服务是一个可插拔模块.有信息约3日公布实施:
Solo Orderer:独奏订购者旨在成为一个非常容易部署的非生产订货人.它由一个为所有客户提供服务的流程组成,因此没有"共识",因为只有一个中央机构.相应地没有高可用性或可伸缩性.这使得solo非常适合开发和测试,但不适合部署.Solo orderer取决于后备原始分类帐.
Kafka Orderer(待定):Kafka orderer利用Kafka pubsub系统执行排序,但将其包含在熟悉的ab.proto定义中,以便对等订购者客户端代码不会专门为Kafka编写.在现实世界的部署中,由于Kafka拥有自己强大的线路协议,因此可以预期Kafka原型服务将在本地绑定.但是,对于测试或新颖的部署方案,Kafka订购者可以部署为网络服务.预计Kafka将是首选的生产部署,需要高吞吐量和高可用性,但不需要拜占庭容错.Kafka订货人不使用支持原始分类账,因为这是由Kafka经纪人处理的.
PBFT Orderer(待定):PBFT订购者使用超级分层结构PBFT实现以拜占庭容错方式对消息进行排序.由于正在为超级分层结构明确开发实现,因此ab.proto用于与PBFT订购者的有线通信.因此,将PBFT订购者绑定到对等进程中是不常见的,尽管对于某些部署可能是合乎需要的.PBFT订货人依赖于支持原始分类帐.