妥当性を確認するピアは誰ですか？

Question

Glossaryに「ピアと検証していないピアを検証する」という用語の定義はありません。多くの文献がこれらのタイプの同輩に依存しているように、この定義を持つことは重要です。

私の主な質問になる。

ブロックストアをデータストアとして見ると、このデータストアでは、ストアの状態を変更して読み取る機能が公開されることは明らかです。したがって、検証側のピアは、Xが状態より前、Tがトランザクションが適用された状態、Xが結果の状態であるという事実を検証するエンティティであるか？

また、検証ピアは、Tが表すビジネスロジックと、Tを呼び出すために存在するアクセスレベルも検証しますか？

一元化された類推は、SQLエンジンを使用してストアの状態を公開するRDBMSです。このストアは、ビジネスロジック（ルールエンジンなど）とSQLコマンド（INSERT、SELECTなど）を組み合わせて更新できます。私の質問は、SQLコマンドが正常に機能することを確認するためのバリデータですか？または、検証エンジンをルールエンジンにも拡張しますか？

Answer 1

v0.6 of Hyperledger Fabricでは、ピアの検証という用語が使用されていました。彼らは発注者であり、妥当性を確認していない同僚でもあります。

はv1.0のであります

• エンドーサピアは：彼らは、トランザクションを受け取ります。その後、彼らはスマートコントラートとの取引を実行し、結果に署名します。彼らはそれを送信したピアに署名されたトランザクションを送ります。
• コミッターピア：ピアはブロックを取得し（トランザクションを検証します）、元帳にコミットします。
• Orderes：トランザクションをソートしてブロックを生成するノード。

編集（以下追加）：

ピアはエンドーサとコミッタであることができます。また、Endorser Peerは独自のトランザクションを実行できます。

フロー（簡単に）：

• ピアがクライアント要求を取得します。このピア（最初のピア）は、対応する要求をエンドーサピアに送信します。
• Endorser Peersはスマート契約に対して要求を実行します。彼らは応答に署名し、最初のピアにそれを送ります。
• すべての応答の結果が等しく、署名が正しい場合、最初のピアは符号を使用してトランザクションを構築します。発注者に送られます。
• 注文サービスでは、署名が検証されます。オーダーサービスは、ブロックを時系列およびチャネルごとに作成します。彼らはComitter Peersに送られます。
• 各Comitter Peerはブロックの各トランザクションを検証します。 [OK]を選択すると、ブロックが各ローカル元帳に追加されます。