私はfabric proposal on consensus architectureを読んで興味を持っており、コンセンサスサービスについて質問があります。これは事実上、すべてのピアがブロックを受け取った順番に受け取ることを保証する単一サービスです。このように、特定のチェーンのための特定の時点で、単一の識別され信頼された組織によって実行される必要があるように見えます。サービスを配布できるようには見えません。それは正しいのですか、私は誤解しましたか？Hyperledger Fabric Consensus Serviceを配布できますか？
これは実際にプログラミングの質問ではありません。これが間違った場所であれば、誰かが私に教えてください。
UPDATE：
ソロ注文サービス（テスト）：ソロ注文サービスを展開することが非常に容易であることを意図している、非生産順序カフカ発注者は現在、生産準備ができています サービス。すべてのクライアントにサービスを提供する単一のプロセスで構成されているため、単一の中央権限があるため、 コンセンサスは必要ありません。 これに対応して、高可用性やスケーラビリティはありません。この は、開発とテストに理想的ですが、展開には適していません。
カフカベース注文サービス（製造）：カフカベース注文サービスは 順序付けを実行するカフカパブ/サブシステムを利用するが、ピア発注 ように馴染みab.proto定義でこれをラップクライアントコードは具体的には カフカのために書かれていません。現在のところ、高スループットと高可用性を要求する生産のためには、カフカが好ましい選択ですが、 では、byzantineのフォールトトレランスは必要ありません。
PBFT注文サービス（保留）： PBFT注文サービスは、ビザンチンフォルトトレラントな方法でメッセージを注文する（現在 開発中）HyperledgerファブリックPBFT実装を使用します。 Hyperledgerファブリックで
コンセンサスサービスは、プラグイン可能なモジュールです。
ソロ発注者： ソロ発注者は、展開が非常に簡単で、非生産発注者であることを意図しているinformation約3発表された実装があります。これはすべてのクライアントに を提供する単一のプロセスで構成されているため、単一の セントラルオーソリティが存在するため、「コンセンサス」は必要ありません。これに対応して高可用性もなく、 のスケーラビリティもありません。これにより、ソロは開発とテストに理想的ですが、 は展開されません。ソロ発注者は、元の元帳に依存します。
カフカ発注（係属中）： カフカ発注が発注を行うためカフカとのpubsubシステムを活用するが、ピア・発注・クライアント・コードが具体的に書き込まれない ように馴染みab.proto定義でこれをラップ カフカ。現実の展開では、カフカは独自の 堅牢なワイヤプロトコルを持っているため、Kafka プロトサービスはローカルで処理されることが期待されます。ただし、テストまたは新規導入の場合は、カフカ発注者をネットワークサービスとして展開することができます。 カフカは、高スループットと高可用性が要求されるが、 のバイザントフォールトトレランスを必要としない、好ましい選択の生産配備であることが予想されている（ ）。カフカ発注者は、 バッキング元帳を使用していません。これは、カフカブローカーによって処理されるためです。
PBFT発注者（保留）： はPBFT発注は、ビザンチンフォルトトレラントな方法でメッセージを注文するhyperledgerファブリックPBFT実装を使用しています。 実装は、ハイパーボーダー ファブリック用に明示的に開発されているため、ab.protoはPBFT 発注者への有線通信に使用されます。したがって、PBFT発注者を ピアプロセスにバインドすることは珍しいことですが、一部の展開では望ましいかもしれません。発注者PBFT は、元の元帳に依存します。
（現在利用可能）ソロ発注については