I've read the fabric proposal on consensus architecture with interest, and I have a question about the consensus service. It seems to me that this is effectively a single service that guarantees all peers receive blocks in an order it decides. As such it looks like it would have to be run by a single identified and trusted organization at any given time for a given chain. It doesn't look like the service could be distributed. Is that correct, or have I misunderstood?
This isn't really a programming question: if this is the wrong place to ask this question perhaps someone can let me know please.
UPDATE: The Kafka Orderer is now production-ready:
Solo ordering service (testing): The solo ordering service is intended to be an extremely easy to deploy, non-production ordering service. It consists of a single process which serves all clients, so consensus is not required as there is a single central authority. There is correspondingly no high availability or scalability. This makes solo ideal for development and testing, but not for deployment.
Kafka-based ordering service (production): The Kafka-based ordering service leverages the Kafka pub/sub system to perform the ordering, but wraps this in the familiar ab.proto definition so that the peer orderer client code does not to be written specifically for Kafka. Kafka is currently the preferred choice for production deployments which demand high throughput and high availability, but do not require byzantine fault tolerance.
PBFT ordering service (pending): The PBFT ordering service will use the Hyperledger Fabric PBFT implementation (currently under development) to order messages in a byzantine fault tolerant way.
Consensus service in Hyperledger Fabric is a pluggable module. There is information about 3 announced implementations:
Solo Orderer: The solo orderer is intended to be an extremely easy to deploy, non-production orderer. It consists of a single process which serves all clients, so no `consensus' is required as there is a single central authority. There is correspondingly no high availability or scalability. This makes solo ideal for development and testing, but not deployment. The Solo orderer depends on a backing raw ledger.
Kafka Orderer (pending): The Kafka orderer leverages the Kafka pubsub system to perform the ordering, but wraps this in the familiar ab.proto definition so that the peer orderer client code does not to be written specifically for Kafka. In real world deployments, it would be expected that the Kafka proto service would bound locally in process, as Kafka has its own robust wire protocol. However, for testing or novel deployment scenarios, the Kafka orderer may be deployed as a network service. Kafka is anticipated to be the preferred choice production deployments which demand high throughput and high availability but do not require byzantine fault tolerance. The Kafka orderer does not utilize a backing raw ledger because this is handled by the Kafka brokers.
PBFT Orderer (pending): The PBFT orderer uses the hyperledger fabric PBFT implementation to order messages in a byzantine fault tolerant way. Because the implementation is being developed expressly for the hyperledger fabric, the ab.proto is used for wireline communication to the PBFT orderer. Therefore it is unusual to bind the PBFT orderer into the peer process, though might be desirable for some deployments. The PBFT orderer depends on a backing raw ledger.