コンセンサス アーキテクチャに関するファブリックの提案を興味深く読みましたが、コンセンサス サービスについて質問があります。これは事実上、すべてのピアが決定した順序でブロックを受信することを保証する単一のサービスであるように思えます。そのため、特定のチェーンの特定の時点で、特定された信頼できる単一の組織によって実行される必要があるように見えます. サービスを配布できなかったようです。それは正しいですか、それとも誤解していますか?
これは実際にはプログラミングの質問ではありません。この質問をするのが間違っている場合は、誰かが私に知らせてください。
更新: Kafka Orderer が本番環境に対応しました:
単独注文サービス (テスト):単独注文サービスは、展開が非常に簡単な非実稼働注文サービスを目的としています。すべてのクライアントにサービスを提供する単一のプロセスで構成されているため、単一の中央機関が存在するため、コンセンサスは必要ありません。したがって、高可用性やスケーラビリティはありません。これにより、ソロは開発とテストには理想的ですが、展開には理想的ではありません。
Kafka ベースの注文サービス (本番): Kafka ベースの注文サービスは、Kafka pub/sub システムを利用して注文を実行しますが、これをおなじみの ab.proto 定義でラップして、ピア注文者のクライアント コードが具体的に記述されないようにします。カフカのために。Kafka は、現在、高スループットと高可用性を必要とするが、ビザンチン フォールト トレランスを必要としない運用展開に適した選択肢です。
PBFT 順序付けサービス (保留中): PBFT 順序付けサービスは、Hyperledger Fabric PBFT 実装 (現在開発中) を使用して、ビザンチン フォールト トレラントな方法でメッセージを順序付けます。
Hyperledger Fabric のコンセンサス サービスは、プラグ可能なモジュールです。発表された 3 つの実装に関する情報があります。
ソロ オーダラー: ソロ オーダラーは、展開が非常に簡単な非生産オーダラーになることを目的としています。すべてのクライアントにサービスを提供する単一のプロセスで構成されているため、単一の中央機関が存在するため、「コンセンサス」は必要ありません。したがって、高可用性やスケーラビリティはありません。これにより、ソロは開発とテストには理想的ですが、展開には理想的ではありません。Solo orderer は、裏付けとなる元帳に依存します。
Kafka Orderer (保留中) : Kafka Orderer は、Kafka pubsub システムを利用して注文を実行しますが、これを使い慣れた ab.proto 定義でラップして、ピア オーダーのクライアント コードが Kafka 用に特別に記述されないようにします。実際の展開では、Kafka には独自の堅牢なワイヤ プロトコルがあるため、Kafka proto サービスが処理中にローカルにバインドされることが予想されます。ただし、テストまたは新規の展開シナリオでは、Kafka orderer をネットワーク サービスとして展開できます。Kafka は、高スループットと高可用性を要求するが、ビザンチン フォールト トレランスを必要としない、推奨される運用環境の展開であると予想されます。これは Kafka ブローカーによって処理されるため、Kafka オーダラーは裏付けとなる生の台帳を使用しません。
PBFT Orderer (保留中) : PBFT Orderer は、ハイパーレジャー ファブリック PBFT 実装を使用して、ビザンチン フォールト トレラントな方法でメッセージを並べ替えます。実装はハイパーレジャー ファブリック専用に開発されているため、ab.proto は PBFT 注文者への有線通信に使用されます。したがって、一部の展開では望ましいかもしれませんが、PBFT オーダラーをピア プロセスにバインドすることは一般的ではありません。PBFT 注文者は、裏付けとなる生の台帳に依存しています。