hyperledger-fabric ドキュメント 公式ドキュメント

• ##はじめに
  Hyperledger Fabric は、高度なセキュリティ、回復力、柔軟性、およびスケーラビリティを提供するモジュラー アーキテクチャを備えた分散型台帳ソリューションのプラットフォームです。さまざまなコンポーネントのプラグ可能な実装をサポートし、複雑な経済エコシステムに適応するように設計されています。
  • ### 非公開で許可済み
  • ###チャネル
    一部の参加者は競合他社である可能性があり、たとえば、一部の参加者のみに提供し、他の参加者には提供しない特別価格など、すべての取引をすべての参加者に知られたくない場合があります。2 人の参加者がチャネルを形成する場合、その 2 人の参加者のみがチャネルの台帳のコピーを持ち、他の参加者は持ちません。
• ##ブロックチェーン
  • ### 分散台帳
    • #### ブロックチェーン台帳は、多くのネットワーク参加者間で複製され、各参加者が台帳を維持するために協力しているため、しばしば分散化されていると説明されます。
    • #### は変更できません。証明システムとして使用できます。
  • ###スマート コントラクト: 台帳への制御されたアクセスを提供する
    チェーン コードで記述され、アプリケーションが台帳と対話する必要がある場合、ブロックチェーン外のアプリケーションによって呼び出されます。ほとんどの場合、チェーンコードは台帳のデータベース、ワールド ステート (クエリなど) とのみ対話し、トランザクション ログとは対話しません。
  • ###コンセンサス: ネットワーク全体で元帳の同期を維持するプロセス
    • #### トランザクションは、ネットワーク内の参加者のセットが異なる場合でも、発生した順序で台帳に書き込まれる必要があります。これを行うには、トランザクションの順序を確立する必要があり、台帳に誤って (または悪意を持って) 挿入された違法なトランザクションを拒否する方法が必要です。たとえば、PBFT (Practical Byzantine Fault Tolerance) は、破損が発生した場合でも、ファイル コピーが複数のコピー間で一貫性を維持するためのメカニズムを提供できます。または、ビットコインでは、マイニングと呼ばれるプロセスをソートします。このプロセスでは、競合するコンピューターが競合して、すべてのプロセスがその後構築される順序を定義する暗号パズルを解決します。
    • #### ブロック内のトランザクションの順序と結果が明示的なポリシー基準チェックを満たしている場合、最終的に合意に達します。これらのチェックとバランスは、トランザクションのライフサイクル中に発生し、承認ポリシーを使用して、トランザクション クラスとシステム チェーンコードを承認する必要がある特定のメンバーを指定し、これらのポリシーが確実に適用および維持されるようにします。コミットする前に、ノードはこれらのシステムチェーンコードを使用して、十分な承認が存在し、適切なエンティティからのものであることを確認します。さらに、トランザクションを含むブロックが元帳に追加される前に、バージョン管理チェックが行われ、その間に元帳の現在の状態が合意されます。この最終チェックは、データの整合性を損なう可能性のある二重支出操作やその他の脅威を防ぎ、非静的変数に対して関数を実行できるようにします。
    • #### 行われる多数の承認、検証、およびバージョン チェックに加えて、トランザクション フローのあらゆる方向で進行中の認証が行われます。アクセス制御リストはネットワーク レベルで実装され (チャネルへのサービスの順序付け)、ペイロードは、トランザクションの提案がさまざまなアーキテクチャ コンポーネントを通過するときに、繰り返し署名、確認、および検証されます。要約すると、コンセンサスは一連のトランザクションの合意された注文に限定されるものではなく、提案から承認に至るまでのトランザクションの進行中の検証の副産物である包括的な機能です。
  • ### 共有台帳
    • ####WorldState
      worldstate コンポーネントは、特定の時点での台帳の状態を表します。台帳のデータベースです
    • #### トランザクション ログ
      ワールド ステートで現在の値を生成したすべてのトランザクションを記録します。これは、ワールド ステートの更新履歴です。台帳には、世界の状態データベースとトランザクション ログの履歴が含まれます。トランザクション ログはプラグ可能である必要はありません。ブロックチェーンネットワークが利用する台帳データベースの前後の値のみを記録します。
    • ####機能 キー
      ベースのルックアップ、範囲クエリ、複合キー クエリを使用した台帳のクエリと更新 - Rich Query Language を使用した読み取り専用クエリ (状態データベースとして CouchDB を使用している場合) - 読み取り専用履歴クエリ (チェーンコードによって読み取られたキー/値のバージョンを含むトランザクション (読み取りセット) およびチェーンコードによって書き込まれたキー/値 (書き込みセット) を含むトランザクション - 各エンドーサーの署名を含むトランザクション順序付けサービスに送信される - ブロックに順番にパッケージ化され、順序付けサービスからチャネル上のノードに「配布」されます - ノードは承認ポリシーに従ってトランザクションを検証し、ポリシーを適用します - ブロックを追加する前に、バージョンチェックが実行されますチェーンコードの実行後に読み取られたアセットの状態が変更されていないことを確認します - トランザクションが検証されてコミットされると、変更できません - チャネルの台帳には、ポリシー、アクセス制御リスト、およびその他の関連情報を定義する構成ブロックが含まれています - チャネルには以下が含まれますメンバーシップ サービス プロバイダー さまざまな認証局からの暗号化マテリアルの導出を可能にするプログラムの例
  • ### ブロックチェーンネットワーク
  • アプリケーションに台帳およびスマート コントラクト (チェーンコード) サービスを提供する技術インフラストラクチャ

    

    • R4 は、ネットワークのイニシエーターとして割り当てられ、ネットワークの初期バージョンを設定する権限を持っています。R4 は、ネットワーク内でビジネス トランザクションを実行しません。**R1 と R2 には、R2 と R3 と同様に、ネットワーク全体でプライベート通信が必要です。
    • 組織 R1 には、チャネル C1 でビジネス トランザクションを実行できるクライアント アプリケーションがあります。**組織 R2 には、チャネル C1 と C2 で同様の作業を行うクライアント アプリケーションがあります。組織 R3 はチャネル C2 でこれを行うことができます。
    • ノード P1 は、C1 の台帳 L1 のコピーを保持します。ノード P2 は、C1 の台帳 L1 と C2 の台帳 L2 のコピーを保持します。ノード P3 は、C2 の台帳 L2 のコピーを保持します。
    • このネットワークは、ネットワーク構成 NC4 で指定されたルールに従って管理され、ネットワーク全体が組織 R1 と R4 によって管理されます。チャネル C1 は、組織 R1 および R2 によって管理されるチャネル構成 CC1 で指定されたルールに従って管理されます。チャネル C2 はチャネル構成 CC2 で指定されたルールに従って管理され、このチャネルは組織 R2 および R3 によって管理されます
    • このネットワーク N のネットワーク管理者ノードとして機能し、システム チャネルを使用する順序付けサービス O4 があります。順序付けサービスは、アプリケーション チャネル C1 および C2 もサポートして、トランザクションを順序付け、ブロックに追加し、分散します。すべての組織には、優先 CA があります。
  • ### ネットワークの作成

    • 

      
      この例のネットワーク N では、注文サービス O4 は、ネットワーク構成 NC4 に従って構成された単一のノードで構成されています。ネットワーク レベルでは、証明機関 CA4 を使用して、組織 R4 の管理者とネットワーク ノードに ID 情報を割り当てます。*
      認証局: CA4、マネージャーおよびネットワーク ノードに証明書を発行するために使用されます
      CA4 は、組織の R4 のコンポーネントを識別するために使用できる X.509 証明書を配布するため、ネットワークで重要な役割を果たします。CA によって発行された証明書は、組織がトランザクションの結果を承認していることを示すために、トランザクションの署名を提供するためにも使用できます。承認は、トランザクションが受け入れられ、元帳に記録されるための前提条件です。
      な
    • ネットワーク管理者を追加できます

      

      
      オーダラー O4 は R4 のインフラストラクチャ上で実行されますが、R1 がアクセスできる場合は管理者特権を共有できます。つまり、R1 または R4 は、ネットワーク構成 NC4 を更新して、R2 がネットワーク メンテナンスでいくつかの機能を実行できるようにすることができます。このように、R4 は順序付けサービスを実行しますが、R1 にも完全な管理者権限があり、R2 には新しいフェデレーションを作成する権限が制限されています。通常、注文サービスはマルチノードであり、異なる組織の異なるノードで構成することもできます。たとえば、R4 で O4 を実行し、組織 R1 の別のオーダラーである O2 に接続する場合があります。このように、マルチノード、マルチ組織の管理構造があります。
    • 連合を定義する

      

      
      ネットワーク管理者は、組織 R1 と R2 で構成される 2 つのメンバーを持つフェデレーション X1 を定義します。このフェデレーションの定義は、ネットワーク構成 NC4 に保存され、その後のネットワークの開発で使用されます。CA1 と CA2 は、これら 2 つの組織に対応する認証局です。*
      NC4 の構成方法により、R1 と R4 のみが新しいフェデレーションを作成できます。このアイコンは、R1 と R2 をフェデレーション組織として定義する新しいフェデレーション X1 を示しています。また、R2 からユーザーを識別するために CA2 も追加されていることがわかります。フェデレーションには任意の数の組織を含めることができることに注意してください。ここでは、最も単純な構成として 2 つの組織のみを含めます。
      フェデレーションは、相互に取引できる必要性を共有するネットワーク内の組織のサブセットを定義することがわかります。この場合、R1 と R2 が取引できるようになります。これは、共通の目標を共有する組織のグループにとって理にかなっています。
    • フェデレーション用のチャネルを作成する

      

      • R1 と R2 にはコンフェデレーション X1 によって作成されたチャネル C1 を使用します。このチャネルは、チャネル構成 CC1 によって管理され、ネットワーク構成から完全に独立しています。CC1 は、C1 に対して同等の権利を持つ R1 と R2 によって管理されます。R4 は CC1 で何の権利も持っていません。
      • C1 はネットワーク N の一部ですが、このネットワークとは大きく異なります。また、このチャネルは R1 と R2 の間のトランザクションの処理専用であるため、組織 R3 と R4 はこのチャネルに含まれていないことに注意してください。前のステップでは、R4 が R1 にアクセス許可を割り当てて新しいフェデレーションを作成する方法を確認しました。R4 では、R1 がチャネルを作成することもできます。この図では、組織 R1 と R4 がチャネル C1 を作成します。繰り返しになりますが、チャネルには任意の数の組織を含めることができますが、ここまでは、最も単純な構成である 2 つしか含めていません。
      • cc1 はチャネル ルールです。cc1 に追加されたユーザーのみが c1 チャネルと対話できます。
      • チャネルが作成されると、チャネル構成で指定された組織のみがチャネルを制御できます。NC4 を変更しても、CC1 には影響しません。たとえば、コンソーシアム定義 X1 が変更された場合、チャネル C1 のメンバーには影響しません。
    • ノードと台帳

      

      
      ピア ノード P1 がチャネル C1 に参加します。物理的には、P1 は台帳 L1 のコピーを保存します。P1 と O4 は、チャネル C1 を通信に使用できます。な
      • ピア ノードは、ブロックチェーン台帳のコピーを格納するネットワーク コンポーネントです.
        P1 の構成の重要な部分は、P1 を組織 R1 に関連付ける CA1 によって発行された X.509 ID 情報です. P1 が起動すると、シーケンス O4 を使用してチャネル C1 に参加できます。O4 がこの参加要求を受信すると、チャネル構成 CC1 を使用して、このチャネルでの P1 のアクセス許可を決定します。たとえば、CC1 は、P1 がレジャー L1 に対して情報を読み書きできるかどうかを決定します。
    • アプリケーションとスマート コントラクトのチェーンコード

      

      
      スマート コントラクト S5 は P1 にインストールされます。組織 R1 のクライアント アプリケーション A1 は、S5 を使用して、ピア ノード P1 を介して台帳にアクセスできます。A1、P1、および O4 はすべてチャネル C1 に参加しており、このチャネルが提供する通信機能をすべて使用できます。
      • この例では、クライアント アプリケーション A1 は組織 R1 に関連付けられており、Fabric ブロックチェーン ネットワークの外部にありますが、チャネル C1 を介してネットワークに接続できます。
      • クライアント アプリケーション A1 は、スマート コントラクト S5 を通じて台帳 L1 を取得する必要があります。
      • スマート コントラクトはトランザクションを管理するものと考えてください。チェーンコードは、スマート コントラクトをパッケージ化してデプロイする方法を管理します。
      • チェーン コードを定義する チェーン
        コードは、組織のピア ノードにインストールされます. 組織は、インストールされたスマート コントラクトを使用して元帳にクエリを実行し、トランザクションを承認する前に、チェーン コードの定義を承認する必要があります.
      • 承認ポリシー
      • スマートコントラクトを呼び出す
    • 完全なネットワーク

      

      
      このネットワークは、新組織 R2 のインフラストラクチャを追加することによって、より大きくなりました。具体的には、R2 は、元帳 L1 のコピーを格納する Peer ノード P2 とチェーンコード S5 を追加します。R2 は、R1 と同じチェーンコード定義を承認しました。P2 は、クライアント アプリケーション A2 を持つチャネル C1 にも参加します。A2 と P2 は、CA2 によって発行された証明書を使用して、A2 と P2 を識別します。これらはすべて、A1 と A2 がピア ノード P1 または P2 を使用して C1 で S5 を呼び出すことができることを示しています。
    • ピア ノード タイプ
      • タイプ
        • *コミットノード*。チャネル内の各ピア ノードは送信ノードです。それらは生成されたブロックを受け取り、これらのブロックが検証された後、台帳のピア ノードのコピーに追加で送信されます。
        • *承認ノード*。スマート コントラクトがインストールされているすべてのピア ノードは、承認ノードとして機能することができます。ただし、真の承認ノードになるには、ノードのスマート コントラクトをクライアント アプリケーションで使用して、署名付きトランザクション応答を生成する必要があります。
      • 役割
        • マスターノード: 組織がチャネルに複数のピアノードを持っている場合、マスターノードがあり、組織内のソートノードから他の引き出しノードにトランザクションを分配する責任があります。
          • 静的に選択されたマスター ノード: 0 個以上のノードをマスター ノードとして構成できます
          • 動的に選択されたマスター ノード: ノードがマスター ノードとして選択されます. マスター ノードに障害が発生した場合、残りのノードはマスター ノードを再選択します.
        • アンカー ノード: 組織間のコミュニケーション
      • チャネルは 1 つだけあり、このチャネル コンポーネントとやり取りする論理台帳は 1 つだけです。ピアノード P1 と P2 は台帳 L1 の同じコピーを持っています
    • ソーティング サービス
      アプリケーションから承認されたトランザクションを収集し、これらのトランザクションをブロックにソートし、これらのブロックをチャネル内の各ピア ノードに配布するコンポーネント。このようなコミット ノードごとに、トランザクションが有効か無効かに関係なく記録され、元帳のローカル コピーが更新されます。
    • 分散トランザクション分散: 複数の注文ポイント
    • ポリシーを変更する
    • ネットワークが完全に形成されました

      

      
      この図では、Fabric ブロックチェーン ネットワークに 2 つのアプリケーション チャネルと 1 つの並べ替えチャネルが含まれていることがわかります。組織 R1 と R4 はシーケンス レーンを担当し、R1 と R2 は青のアプリケーション レーンを担当し、R2 と R3 は赤のアプリケーション レーンを担当します。クライアント アプリケーション A1 は組織 R1 の要素であり、CA1 はその認証局です。組織 R2 のノード P2 は、青色の通信機能と赤色のアプリケーション チャネルを使用できます。各アプリケーション チャネルには独自のチャネル構成 (ここでは CC1 と CC2) があります。システムチャネルのチャネル構成は、ネットワーク構成 NC4 の一部です。
  • ID: すべての参加者 (ネットワークの内外でサービスを使用できるアクティブな要素) は、X.509 デジタル証明書* にカプセル化されたデジタル ID を持っています。これにより、リソースに対する正確な権限と、情報へのブロックチェーン ネットワーク アクセスにおける参加者の所有権が決定されます。 .
    • 本体
    • ID は検証可能であり、信頼できる機関からのものである必要があります。メンバーシップ サービス プロバイダー (メンバーシップ サービス プロバイダー、MSP) は、Fabric の信頼できる機関です。MSP は、組織の有効なアイデンティティを管理するルールを定義するコンポーネントです。Fabric のデフォルトの MSP 実装では、X.509 証明書を ID として使用し、従来の公開鍵基盤 (PKI) 階層化モデルを使用します (PKI については後で詳しく説明します)。
  • PKI と MSP は同じように連携します。PKI は ID のリストを提供し、MSP はネットワークに参加している特定の組織のメンバーを示します。
    • PKI は、さまざまな種類の検証可能な ID を割り当てるカード プロバイダーのようなものであり、ネットワーク内で安全な通信を提供する一連のインターネット テクノロジです。

      

      
      公開鍵基盤 (PKI) の要素。PKI は、さまざまな関係者 (サービスのユーザー、サービス プロバイダーなど) にデジタル証明書を発行し、それらを使用して環境と交換されるメッセージで自分自身を認証する認証局で構成されます。CA の証明書失効リスト (CRL) は、有効ではなくなった証明書への参照を構成します。証明書の失効は、さまざまな理由で発生する可能性があります。たとえば、証明書に関連付けられた暗号化されたプライベート マテリアルが公開されたために、証明書が取り消される場合があります。
      • X.509 などのデジタル証明書
      • 公開鍵と秘密鍵
        • 従来の認証メカニズムはデジタル署名に依存しています
        • 技術的には、デジタル署名メカニズムでは、各当事者が暗号化された接続に対して 2 つの鍵を保持する必要があります。広く利用可能な公開鍵と認証のアンカーとして機能する秘密鍵、およびメッセージにデジタル署名を生成するために使用される秘密鍵です。 . デジタル署名されたメッセージの受信者は、意図した送信者の公開鍵の下で追加の署名が有効であることを確認することにより、受信したメッセージの発信元と完全性を検証できます。
      • 認証局 CA
        • ルート CA、中間 CA、信頼チェーン
          CA ルート CA と中間 CA の 2 つの形態があります。ルート CA (Symantec、Geotrust など) は何億もの証明書をインターネット ユーザーに安全に発行する必要があるため、このプロセスをいわゆる中間 CA に分散すると便利です。これらの中間 CA には、ルート CA または他の中間 CA によって発行された証明書があり、チェーン内の任意の CA によって発行された証明書に対して「信頼チェーン」を確立できます。ルート CA までさかのぼることができるため、セキュリティを提供しながら CA の機能を拡張できるだけでなく (証明書を使用する組織が信頼して中間 CA を使用できるようになります)、ルート CA の公開も制限されます。侵害された場合、信頼チェーン全体が侵害されます。一方、中間 CA が侵害された場合、露出ははるかに小さくなります。
        • Fabric CA: Fabric は、ブロックチェーン ネットワークで CA を作成できる組み込みの CA コンポーネントを提供します。
      • 証明書失効リスト
        CRL を使用して、証明書がまだ有効かどうかを確認します。偽装者が無効なデジタル証明書を検証者に渡そうとした場合、最初に発行 CA の CRL をチェックして、無効としてリストされていないことを確認できます。
    • MSP は、ストアが受け入れたカード プロバイダーのリストに似ており、どの ID がストアの支払いネットワークの信頼できるメンバー (参加者) であるかを判断します。MSP は、検証可能な ID をブロックチェーン ネットワークのメンバーに変えます。

      

      
      ID はクレジット カードのようなもので、支払能力を証明するために使用されます。MSP は、受け入れられるクレジット カードのリストに似ています。
    • MSP ドメイン
      • 参加者ノード (ローカル MSP) でローカルに
        • ユーザーがチャネルのメンバー (チェーンコード トランザクションなど) として、またはシステム内の特定の役割の所有者 (構成トランザクションの組織管理者など) としてトランザクションで自分自身を確認できるクライアントとノードに対して定義されます。 .
        • すべてのノードはローカル MSP を定義する必要があります。ローカル MSP は、そのレベルで誰が管理権限または参加権限を持っているかを定義するため、組織、組織の管理者、ノードの管理者、およびノー​​ド自体がすべて同じ信頼のルートを持つ必要があります。
        • 参加者を検証するために使用されるソートノード、ノードもあります。
      • チャネル構成 (チャネル MSP): チャネル レベルで管理および参加権限を定義します。

        

        
        チャネル構成のフラグメント。json ファイルには、2 つの組織の MSP が含まれています。
        • チャネル MSP は、チャネル レベルで誰が権限を持つかを決定します。チャネル MSP はチャネル メンバーを定義し、チャネル MSP もチャネル内の各ノードのファイル システムでインスタンス化され、コンセンサスによって同期が維持されます。
        • ローカル MSP は、適用先のノードまたはユーザーのファイルシステムでのみ定義されます
        • 各ノードには、ローカル ファイル システムに各チャネル MSP のコピーがあり、ネットワーク内でローカル MSP とチャネル MSP がどのように共存しているかを示します。
        • 証明書の OU フィールドは、ID が属するビジネス ユニットを指定します。
          • 証明書でのロールと OU の表現方法:
          • node ou
            上記の例では、MSP には 4 つのノード OU ロールがあります: クライアント、ピア、管理者、発行申請者
          • 注: チャネル MSP の場合、参加者が管理者の役割を持っているからといって、特定のリソースを管理できるわけではありません。特定の ID がシステムを管理する実際の能力は、システムのリソースを管理するためのポリシーによって決まります。
          • コンソーシアム内のさまざまな組織は、ou を使用して互いを区別できます。ただし、この場合、異なる組織は信頼のチェーンに同じルート CA と中間 CA を使用し、各組織のメンバーを識別するために OU フィールドを割り当てる必要があります。これにより、すべての組織が同じ CA または信頼チェーンを持っている場合、システムは意図したよりも集中化されます。
        • ローカル MSP フォルダーには、次のサブフォルダーが含まれています。
          • config.yaml: 「ノード OU」ノードをアクティブ化し、受け入れ可能なロールを定義することにより、Fabric で ID 分類機能を構成します
          • cacerts: このフォルダーには、この MSP によって表される組織によって信頼されたルート cas の自己署名 X.509 証明書のリストが含まれています。この MSP フォルダーには、少なくとも 1 つのルート CA 証明書が必要です。これは、信頼のチェーンを形成するために、それぞれの組織のメンバーと見なされるために他のすべての証明書を派生させる必要がある CA を識別するため、最も重要なフォルダーです。
          • Intermediatecerts: このフォルダーには、この組織によって信頼されている中間 CA の X.509 証明書のリストが含まれています。各証明書は、MSP 内のルート CA のいずれか、または最終的に信頼されたルート CA に戻る一連の CA を発行する中間 CA によって署名される必要があります。中間 CA は、組織の下位区分を表すために使用できます。
            • 中間 CA なしで機能するネットワークを持つことも可能であることに注意してください。その場合、このフォルダーは空になります。
            • ルート CA フォルダーと同様に、このフォルダーは、組織のメンバーと見なされるために証明書を発行する必要がある CA を定義します。
          • admincerts (Fabric v1.4.3 以降では非推奨): このフォルダーには、この組織の管理者ロールを持つ参加者を定義する ID のリストが含まれています。通常、1 つ以上の X.509 証明書が必要です。ユーザーが CA に登録するときに、admin ロールを使用してノード管理者を指定することをお勧めします。この ID は、signcert のノード OU ロール値によって管理者として識別されます。管理者の役割を利用するには、設定で「ID 分類」機能を有効にする必要があることに注意してください。「node ou」を Enable: true に設定することによって
          • keystore: (private Key): このフォルダーは、ピアまたはオーダー ノードのローカル MSP (またはクライアントのローカル MSP) 用に定義され、ノードの秘密キーが含まれています。この鍵はデータの署名に使用されます
            • チャネル MSP は署名機能ではなく、認証機能のみを提供することを目的としているため、チャネル MSP 構成にはこのフォルダーは含まれません。
            • キー管理に HSM (ハードウェア セキュリティ モジュール) を使用する場合、秘密キーは HSM によって生成され、HSM に格納されるため、このフォルダーは空です。
          • signcert: ノードの CA によって発行された証明書が含まれています, これを使用して、この証明書のコピーを持っている人によって検証される署名を生成することができます. このフォルダーはローカル MSP に必要であり、公開鍵が含まれている必要があります.
            • このフォルダへのアクセスは、ピアの管理責任を持つユーザーに制限する必要があります。
            • チャネル MSP の構成にはこのフォルダーは含まれません。チャネル MSP は認証機能のみを提供することを目的としており、署名機能は提供しないためです。
          • tlscacerts: このフォルダーには、TLS を使用したノード間の安全な通信のために組織によって信頼されているルート CA の自己署名 X.509 証明書のリストが含まれています。MSP TLS メッセージには、ネットワーク内のノードが含まれます
          • tlsintermediatecacerts: このフォルダーには、TLS を使用したノード間の安全な通信のために、MSP によって表される組織によって信頼された中間 CA 証明書のリストが含まれています。
          • operationscerts: このフォルダーには、Fabric Operations Service API との通信に必要な証明書が含まれています。
        • チャネル MSP には、さらに次のものが含まれます。
          • 取り消された証明書: 加害者の ID が取り消された場合、その ID に関する識別情報 (ID 自体ではなく) がこのフォルダーに保持されます。x.509 ベースの ID の場合、これらの ID は Subject Key Identifier (SKI) と Authority Access Identifier (AKI) と呼ばれる文字列のペアであり、証明書が失効していないことを確認するために証明書が使用されるたびにチェックされます。
  • ストラテジー：

    

    • システム チャネル構成: すべてのネットワークは、注文サービス システム チャネルから始まります。ネットワーク内に順序付けサービスの順序付けシステム チャネルが少なくとも 1 つ存在する必要があります。これが最初に作成されるチャネルです。チャネルには、誰が注文サービス (注文サービス組織) のメンバーであり、ネットワークで取引を行っているか (連合組織) も含まれています。順序付けシステムのチャネル構成ブロックのポリシーは、順序付けサービスによって使用されるコンセンサスを管理し、新しいブロックの作成方法を定義します。システム チャネルは、新しいチャネルを作成できるコンソーシアムのメンバーも管理します。
    • アプリケーション チャネルの構成: アプリケーション チャネルは、フェデレーション内の組織間のプライベート通信メカニズムを提供するために使用されます。アプリケーション チャネルのポリシーは、チャネルにメンバーを追加および削除する機能を管理します。また、アプリケーション チャネルは、Fabric チェーンコード ライフサイクルを使用してチェーンコードを定義し、チャネルにコミットする前に、どの組織の同意が必要かを管理します。システム チャネルが最初に作成されると、デフォルトで、注文システム チャネルのすべての注文サービス パラメータが継承されます。同時に、これらのパラメーター (それらを管理するポリシーを含む) はチャネルごとにカスタマイズできます。
    • アクセス制御リスト (ACL)
    • ポリシーの範囲
    • スマート コントラクト承認ポリシー
    • 更新戦略
    • ファブリックでポリシーを作成する方法
      • 署名戦略: 並べ替えと複数の論理関係をサポート
      • ImplicitMeta ポリシー: 階層的に構築されたポリシー ツリーに基づくチャネル構成で有効
        • 暗黙的なメタポリシーは、署名ポリシーによって最終的に定義された深い構成ツリーの結果を集約します。それらは、チャネル構成の現在の組織に基づいて暗黙的に構築されているため隠されています。また、それらの評価は特定の MSP 仕様に依存せず、構成ツリー内の他のサブポリシーに依存しているため、メタ情報です。
        • 開閉の原則に従う
        • さらなる粒度と制御のための NodeOU
      • 署名ポリシーの使用例
      • Implimeta の使用例
      • ライフサイクル
  • ノード: 台帳とチェーンコードを維持する

    

    
    冗長性は、単一障害点を回避するため、ファブリック ネットワークで意図的に提供されます。
    • 
      ブロックチェーン ネットワークはピア ノードで構成され、各ノードは元帳とスマート コントラクトのコピーを保持します。この例では、ネットワーク N はノード P1、P2、および P3 で構成されており、それぞれが独自の分散台帳 L1 を維持しています。P1、P2、および P3 は、同じチェーンコード S1 を使用して、分散型台帳のコピーにアクセスします。複数の台帳とチェーンコードを維持できます
    • アプリケーションとピア ノード: アプリケーションが台帳とチェーン コードにアクセスする必要がある場合、常にピア ノードに接続する必要があります. ピア ノードに接続することにより、アプリケーションはチェーン コードを実行して台帳を照会または更新できます. 台帳をクエリした結果、すぐに
      ピア ノードとソート ノードが返され、台帳が各ピア ノードに最新の台帳を持つことが保証されます。この例では、アプリケーション A が P1 に接続し、チェーンコード S1 を呼び出して台帳 L1 をクエリまたは更新します。P1 は、チェーンコード S1 を呼び出して提案応答を生成します。これには、クエリ結果または台帳更新の提案が含まれます。アプリケーション A は提案に対する応答を受け取り、クエリの場合、フローはここで終了します。更新の場合、アプリケーション A はすべての応答からトランザクションを作成し、注文者 O1 に注文のために送信します。O1 はネットワーク内のトランザクションを収集してブロックにパッケージ化し、これらのブロックを P1 を含むすべてのピア ノードに配布します。P1 は、レジャー L1 にコミットする前にトランザクションを検証します。L1 が更新されると、P1 はイベントを生成し、プロセスの終了をマークするために A によって受信されます。
      • 独立したピア ノードは現在台帳を更新できません。これは、他のピア ノードが最初に変更に同意する (つまり、コンセンサスに達する) 必要があり、ピア ノードが提案された更新をアプリケーションに返し、ピア ノードが更新されるためです。他のノードの以前のプロトコルに基づいて、この更新を適用します
    • ピア ノードとチャネル
      チャネルは、ブロックチェーン ネットワーク内の特定のピア ノードとアプリケーションが相互に対話できるようにします。この例では、アプリケーション A は、チャネル C を使用してピア ノード P1 および P2 と直接通信できます。チャネルは、アプリケーションとピア ノード間の通信のパスと考えることができます。(オーダラーはこの図には示されていませんが、稼働中のネットワークに存在する必要があります。)
    • ピアノードと組織: ここには集中化されたリソースはありません. これらの組織がノードを提供しない場合, ネットワーク N は存在しません. 組織がリソースを提供しない限り, そのようなネットワークは形成されません. そうでない場合, このネットワークは形成されません.存在の意味
    • ピア ノードと ID: ネットワーク内の各ピア ノードには、それが属する組織の管理者によってデジタル証明書が割り当てられます.
      ピア ノードがチャネルに接続すると、そのデジタル証明書はチャネル MSP を通じてその組織を識別します. この例では、P1 と P2 は CA1 によって発行された ID を持っています。チャネル C は、そのチャネル構成のポリシーを通じて、ORG1.MSP を使用して CA1 からの ID を Org1 に関連付ける必要があることを決定します。同様に、P3 と P4 は ORG2.MSP によって Org2 の一部として認識されます。
    • ピアとオーダラー: 台帳を更新するアプリケーションは、3 段階のプロセスに導入されます。
      • 最初のフェーズでは、アプリケーションは承認ノードのサブセットと連携します。各ノードは提案された台帳の更新をアプリケーションに承認しますが、提案された更新を台帳のコピーには適用しません。
      • 第 2 段階では、これらの散在するエンドースメントがまとめられ、トランザクションとしてブロックにパッケージ化されます。
      • 最終段階では、これらのブロックが各ピア ノードに配布され、ピア ノードの元帳のコピーに適用される前に各トランザクションが検証されます。
      • フェーズ 1: 提案: アプリケーションはトランザクションの提案を生成し、承認のために一連の必要なノードに送信します。各エンドースメント ノードは、トランザクション提案を独立して使用してチェーン コードを実行し、トランザクション提案に対する応答を生成します。応答結果はアプリケーションに返されます。トランザクション提案は、ピア ノードによって独立して実行されます。ピア ノードは
        承認のために提案応答を返します。この例では、アプリケーション A1 がトランザクション T1 と提案 P を生成し、アプリケーションはトランザクションと提案をピア ノード P1 とピア ノード P2 にチャネル C で送信します。P1 は、トランザクション T1 とプロポーザル P を使用してチェーンコード S1 を実行します。これにより、トランザクション T1 に対する応答 R1 が生成され、エンドースメント E1 が提供されます。P2 はトランザクション T1 プロポーザル P を使用してチェーンコード S1 を実行します。これにより、トランザクション T1 に対する応答 R2 が生成され、エンドースメント E2 が提供されます。アプリケーション A1 は、トランザクション T1 に対して、E1 および E2 と呼ばれる 2 つの保証応答を受け取ります。
        • アプリケーションは、エンドースメント ポリシーに従って更新するピア ノードを選択します。ピア ノードは、提案の応答に独自のデジタル署名を追加することでエンドースメントを提供し、その秘密鍵を使用してロード全体の署名を提供します。この承認は、組織のピアが特定の応答を生成したことを証明するために使用されます。
        • アプリケーションは、更新された提案応答を要求できます。チェーンコードが非決定論的であり、個々のピアがトランザクションの結果が非決定論的であることを認識できないことが原因である可能性は低いですが、非常に深刻です。非決定論的問題が発見されるまで、トランザクション応答をまとめて収集する必要があります。比較のために
      • フェーズ 2: トランザクションをブロックに分類してパッケージ化する
      • 第 3 段階: 検証と送信
        順序付けノードの 2 番目の役割は、ブロックをピア ノードに配布することです。この例では、順序付けノード O1 がブロック B2 をピア ノード P1 とピア ノード P2 に分散しました。ピア P1 はブロック B2 を処理し、P1 の台帳 L1 に追加される新しいブロックを生成します。一方、ピア P2 はブロック B2 を処理し、P2 の台帳 L1 に追加される新しいブロックを生成します。このプロセスが完了すると、台帳 L1 はピア ノード P1 および P2 に対して一貫して更新され、トランザクションが処理されたことを接続アプリケーションに通知する場合もあります。
        な
        • チェーンコードは最初のフェーズでのみ実行されます - 機密性は保証されますが、出力はすべてのノードで共有されます
      • 注文ノードとコンセンサス: トランザクション処理プロセス全体はコンセンサスと呼ばれます
  • 元帳: オブジェクト プロパティの現在の値と、それらの現在の値を生成したトランザクションの履歴の両方を含む、ビジネス オブジェクトに関する重要な事実情報を格納します。
    • 元帳、事実および状態:
      • 元帳：
        • 世界の状態は、台帳の状態のセットの現在の値を格納するデータベースです。ワールド ステートを通じて、プログラムは現在の値を計算するためにトランザクション ログ全体を走査することなく、台帳の状態の現在の値に直接アクセスできます。デフォルトでは、台帳の状態はキーと値のペアで表され、作成、更新、および削除できるため、世界の状態は頻繁に変化する可能性があります。
        • ブロックチェーンは、世界の現在の状態に寄与したすべての変更を記録するトランザクション ログです。世界の現在の状態に貢献したすべての変化を理解するのに役立つ歴史を改ざんすることはできません。

          

          
          元帳 L はブロックチェーン B と世界の状態 W で構成され、世界の状態 W はブロックチェーン B によって決定されます。世界の状態 W はブロックチェーン B に由来するとも言えます。
      • 世界の状態: 関連する承認組織によって署名されたトランザクションのみが、世界の状態を更新し、リアルタイムで変更できます。

        

        
        台帳の世界の状態は、2 つの状態で構成されます。最初の状態は、key=CAR1 および value=Audi です。2 番目の状態には、より複雑な値があります: key=CAR2 および value={model:BMW, color=red, owner=Jane}。両方の状態バージョンは 0 です。
      • ブロックチェーン: リンクされたブロックのコレクションのシリアル化されたログ。各ブロックには一連のトランザクションが含まれ、各トランザクションは世界の状態に関するクエリまたは更新操作を表します。各ブロックのヘッダーには、ブロックのトランザクションのハッシュと、前のブロックのヘッダーのハッシュが含まれています。ノートブック上のすべてのトランザクションは順序付けされ、暗号的にリンクされています。このハッシングとリンクにより、台帳データは非常に安全になります。

        

        
        ブロックチェーン B には、B0、B1、B2、B3 の 4 つのブロックが含まれます。B0 はブロックチェーンの最初のブロックで、ジェネシス ブロックとも呼ばれます。
        上の図では、ブロック B2 にブロック データ D2 があり、これには B2 のすべてのトランザクション (T5、T6、T7) が含まれていることがわかります。
      • ブロック
        • ブロックヘッダー

          

          
          ブロックヘッダ詳細：ブロックＢ２のブロックヘッダＨ２は、ブロック番号２、現ブロックデータＤ２のハッシュ値ＣＨ２、前ブロックヘッダＨ１のハッシュ値を含む。
        • ブロック番号：番号は0（初期ブロック）から始まり、ブロックチェーンに新しいブロックが追加されるたびに番号の番号が1ずつ増えていきます。
        • 現在のブロックのハッシュ: 現在のブロックに含まれるすべてのトランザクションのハッシュ。
        • 前のブロック ヘッダーのハッシュ: ブロックチェーン内の前のブロック ヘッダーのハッシュ。
        • ブロック データ セクションには、トランザクションの順序付きリストが含まれます。ブロック データは、順序付けサービスがブロックを作成するときに書き込まれます。
        • ブロック メタデータ セクションには、ブロックが書き込まれた時間、ブロック作成者の証明書、公開鍵、および署名が含まれます。ブロックの送信者は、各トランザクションに有効または無効フラグも追加しますが、この情報はブロックと同時に生成されるため、ハッシュには含まれません。
      • トランザクション: トランザクションは、世界の状態の更新を記録し、ブロック内のブロック データに格納されます。

        

        
        トランザクションＴ４は、ブロックＢ１のブロックデータＤ１に位置し、トランザクションヘッダＨ４、トランザクション署名Ｓ４、トランザクション提案Ｐ４、トランザクション応答Ｒ４、および一連のエンドースメントＥ４を含む。
        • ヘッダーは H4 で示され、関連するチェーンコードの名前やバージョンなど、トランザクションに関するいくつかの重要なメタデータを記録します。
        • S4 で示される署名セクションには、クライアント アプリケーションによって作成された暗号署名が含まれます。このフィールドは、トランザクションの署名の生成にアプリケーションの秘密鍵が必要なため、トランザクションの詳細が改ざんされていないことを確認するために使用されます。
        • P4 で示される提案部分は、アプリケーションがスマート コントラクトに提供する入力パラメーターをエンコードする役割を担い、スマート コントラクトは提案台帳の更新を生成します。スマート コントラクトが実行されている場合、この提案は、現在の世界の状態と共に新しい台帳の世界の状態を決定する一連の入力パラメーターを提供します。
        • 応答の一部は R4 で示され、世界の状態の前後の値を読み取り/書き込みセット (RW-set) の形式で記録します。トランザクション応答はスマート コントラクトの出力であり、トランザクションの検証が成功すると、トランザクションが台帳に適用され、それによって世界の状態が更新されます。
        • 承認 E4 に示されているように、これは一連の署名済みトランザクション応答を指し、これらの署名は承認ポリシーで指定された関連組織からのものであり、これらの組織の数は承認ポリシーの要件を満たす必要があります。
      • 世界状態データベース オプション: LevelDB および CouchDB を含む - プラグ可能
        • LevelDB は世界状態データベースのデフォルトのオプションであり、元帳の状態が単純なキーと値のペアである場合は、LevelDB を使用するのが非常に適切です。LevelDB データベースはピア ノードと同じ場所にあり、ピア ノードと同じオペレーティング システム プロセスに組み込まれています。
        • CouchDB: 台帳の状態構造は JSON ドキュメントであり、ビジネス トランザクションに関連するデータ型は通常非常に豊富であり、CouchDB はこれらのデータ型のさまざまな形式のクエリと更新をサポートできます。実装に関しては、CouchDB は別のオペレーティング システム プロセスで実行されますが、ノードと CouchDB インスタンスの間には 1 対 1 の関係があります。スマート コントラクトは、上記のいずれも見ることができません。
      • レジャーfabcarの例

        

        
        台帳 L には世界の状態 W とブロックチェーン B が含まれています。その中で、W には 4 つの状態が含まれており、各状態のキーは、CAR0、CAR1、CAR2、および CAR3 です。B には 2 つのブロック 0 と 1 が含まれます。ブロック 1 には、T1、T2、T3、T4 の 4 つのトランザクションが含まれています。
      • 名前空間
        • 各チェーンコードには、他のすべてのチェーンコードのワールド状態とは別の独自のワールド状態があります。世界の状態は名前空間に存在するため、同じチェーンコードに存在するスマート コントラクトのみが特定の名前空間にアクセスできます。
      • チャネル: 各チャネルには完全に独立した台帳があります
  • 仕分けサービス
    • Orderer とチャネルの構成: Orderer は、チャネルの作成を許可されている組織 (フェデレーション) のリストも維持します。テーブル自体は「発注者システム チャネル」(「発注者システム チャネル」とも呼ばれます) の構成に保持されます。このリストとそれが存在するチャネルは、発注者管理者のみが編集できます。
    • 注文ノードと ID (MSP): 注文ノードは組織に属し、組織ごとに個別の認証局 (CA) を使用します. どの CA が自己定義されているかについて
    • 注文ノードとトランザクション フロー
      • フェーズ 1: 提案
      • フェーズ 2: トランザクションをブロックに並べてパックする

        

        
        発注者の最初の役割は、提案用の台帳の更新をパッケージ化することです。この例では、アプリケーション A1 はトランザクション T1 を注文者 O1 に送信し、E1 と E2 によって裏書きされます。同時に、アプリケーション A2 は、E1 によって承認されたトランザクション T2 を注文者 O1 に送信します。O1 は、アプリケーション A1 からのトランザクション T1 とアプリケーション A2 からのトランザクション T2、およびネットワーク内の他のアプリケーションからのトランザクションをブロック B2 にパックします。B2 では、トランザクションの順序が T1、T2、T3、T4、T6、T5 であることがわかりますが、これは、これらのトランザクションが注文者に到着した順序ではない可能性があります。(この例では、orderer が 1 つだけの非常に単純な順序付けサービス構成を示しています。)
        • ブロック内のトランザクションの数は、ブロックの目的のサイズと、最大間隔時間に関連するチャネル構成パラメーター (正確には、BatchSize および BatchTimeout パラメーター) によって異なります。
        • 注文サービスによって生成されたブロックは最終的なものであり、Hyperledger Fabric の最終性は、レジャー フォークがないことを意味します。つまり、検証済みのトランザクションが書き換えられたり削除されたりすることはありません。
        • 注文ノードはソートのみで、トランザクションは発生しません
      • フェーズ 3: 検証と送信: すべてのピア ノードを順序付けノードに接続する必要はありません。ピア ノードは、ゴシップ プロトコルを使用してブロックを他のノードに関連付けることができます。

        

        
        順序付けノードの 2 つ目の役割は、ブロックをピア ノードに配布することです。この例では、オーダラー O1 がブロック B2 をノード P1 と P2 に配布します。ノード P1 はブロック B2 を処理し、新しいブロックを P1 の台帳 L1 に追加します。同時に、ノード P2 はブロック B2 を処理し、それによって P2 の元帳 L1 に新しいブロックを追加します。このプロセスが完了すると、ノード P1 と P2 の台帳 L1 が一貫して更新され、各ノードは接続されたアプリケーションにトランザクションが処理されたことを通知できます。
        • ノードの承認は承認ポリシーと一致し、トランザクションが最初に承認されたときに実行されている可能性がある最近コミットされた他のトランザクションによって無効にされません。無効なトランザクションは発注者によって作成されたブロックに残りますが、ノードはそれらを無効としてマークし、台帳の状態を更新しません。
      • 仕分けサービスの実装
        • Raft (推奨): v1.4.1 の新機能として、Raft は[etcd](https://coreos.com/etcd/) のRaft プロトコルに基づくクラッシュ フォールト トレラント (CFT) ソート サービスです。Raft は「リーダーフォロワー」モデルに従います。このモデルでは、各チャネルでリーダーノードが選出され、その決定はフォロワーによって複製されます。Raft 順序付けサービスは、Kafka ベースの順序付けサービスよりもセットアップと管理が容易であり、その設計により、さまざまな組織がノードを分散順序付けサービスに提供できるようになります。
          • クラッシュ耐性: システムは、リーダー ノードを含むノードの損失を許容できます (「クォーラム」と呼ばれる) 多数のオーダラーが残っている場合
          • Raft はセットアップが簡単で、ネイティブにサポートされており、Raft を使用すると、すべてがオーダラーに組み込まれます。
          • Kafka と Zookeeper は大規模なネットワークで実行するようには設計されていません。必要なミラーリングを自分で取得する必要があります。Kafka はサーバー プールを使用します。
          • ラフトのコンセプト
            • ログ エントリ: Raft 順序付けサービスの主要な作業単位は「ログ エントリ」であり、エントリの完全なシーケンスは「ログ」と呼ばれます。過半数のメンバー (つまり定足数) がエントリとその順序に同意する場合、エントリが一貫していると見なし、ログを別の順序付け者に複製します。
            • 同意者セット: 特定のチャネルのコンセンサス メカニズムに積極的に参加し、チャネルのログのコピーを受け取る注文者。
            • 有限ステート マシン (FSM)。Raft の各 orderer には FSM があり、各 orderer のログのシーケンスが決定論的 (同じ順序で書き込まれる) であることを一緒に保証します。
            • 定足数。提案を確認する必要がある同意者の最小数を示します。
            • リーダー
            • フォロワー
          • トランザクション フローのラフト: チャネル作成者 (およびチャネル マネージャー) は、利用可能なオーダラーのサブセットを選択し、必要に応じてオーダラーを追加または削除できます (一度に 1 つのノードのみが追加または削除される場合)。eer ノードもアプリケーションも、いつでも誰がリーダー ノードであるかを知る必要はありません。注文者のみが知る必要があります。
          • Raft がリーダーを選出する方法: ノードは常に、フォロワー、候補、またはリーダーの 3 つの状態のいずれかになります。すべてのノードは、最初はフォロワーとして開始されます。この状態では、リーダーからのログ エントリを受け入れるか (既に選出されている場合)、リーダーに投票できます。ログ エントリまたはハートビートが一定期間 (5 秒間など) 受信されない場合、ノードは自身を候補状態に昇格させます。候補状態では、ノードは他のノードからの投票を要求します。候補者が定足数の票を獲得した場合、その候補者はリーダーに昇進します。リーダーは新しいログ エントリを受け入れ、それをフォロワーにレプリケートする必要があります。
          • スナップショット: Raft は、ユーザーがログに保持するデータのバイト数を定義する「スナップショット」と呼ばれるプロセスを使用します。このデータ量によってブロック数が決まります (これは、ブロック内のデータ量によって異なります。完全なブロックのみがスナップショットに保存されることに注意してください)。
            遅延レプリカ R1 がネットワークに再接続したばかりだとします。その最新ブロックは 100 です。リーダー L はブロック 196 にあり、20 ブロックのスナップショットを作成するように構成されています。したがって、R1 は L からブロック 180 を受信し、ブロック 101 から 180 の要求をディスパッチします。次に、ブロック 180 から 196 が通常の Raft プロトコルを介して R1 に複製されます。
        • Kafka (v2.0 で非推奨): Raft ベースのソートと同様に、Apache Kafka は「リーダーとフォロワー」ノード構成を使用する CFT 実装です。Kafka は管理に ZooKeeper を利用します。Kafka ベースの注文サービスは Fabric v1.0 から利用できますが、多くのユーザーは、Kafka クラスターを管理するための追加の管理オーバーヘッドが困難または望ましくないと感じる場合があります。
        • Solo (v2.0 で非推奨): 順序付けサービスの Solo 実装はテスト専用であり、1 つの順序付けプログラムのみが含まれます。これは推奨されておらず、将来のリリースで完全に削除される可能性があります。既存の Solo ユーザーは、同じ機能を得るために単一ノードの Raft ネットワークに移行する必要があります。
  • スマート コントラクトとチェーンコード
    • スマートコントラクト

      

      
      スマート コントラクトは、異なる組織間のルールを実行可能なコードで定義します。アプリケーションはスマート コントラクトを呼び出して、元帳に記録されるトランザクションを生成します。
    • スマート コントラクトは、世界の状態でビジネス オブジェクトのライフ サイクルを制御するトランザクション ロジックを定義し、トランザクション ロジックがチェーン コードにパッケージ化され、チェーン コードがブロックチェーン ネットワークにデプロイされます。スマート コントラクトはトランザクション マネージャーと考えることができ、チェーンコードはスマート コントラクトをデプロイ用にパッケージ化する方法を管理します。

      

      
      スマート コントラクトはチェーンコードで定義されます。また、同じチェーンコードで複数のスマート コントラクトを定義することもできます。チェーンコードがデプロイされると、そのチェーンコード内のすべてのスマート コントラクトがアプリケーションで使用可能になります。
    • 元帳: スマート コントラクトは、主に世界の状態の状態を書き込み (プット)、読み取り (取得)、削除 (削除) し、不変のブロックチェーン トランザクション レコードをクエリすることもできます。
      • ブロックチェーン
      • 世界の状態
      • async createCar(ctx, carNumber, make, model, color, owner) { const car = { color, docType: 'car', make, model, owner, }; await ctx.stub.putState(carNumber, Buffer.from(JSON.stringify(car)));}
    • 承認: ブロックチェーン ネットワーク内のどの組織が、特定のスマート コントラクトによって生成されたトランザクションに署名して、トランザクションが有効であることを宣言する必要があるかを示します。

      

      
      すべてのスマート コントラクトには、それに関連付けられた承認ポリシーがあります。この承認ポリシーは、スマート コントラクトによって生成されたトランザクションが有効であると認定される前に、そのトランザクションに同意する必要がある組織を定義します。
      • ブロックチェーン ネットワークに参加している 4 つの組織のうち 3 つが、有効と見なされる前にトランザクションに署名する必要があります。有効か無効かにかかわらず、すべてのトランザクションが元帳に追加されますが、有効なトランザクションのみが世界の状態を更新します。
    • 有効な取引
      • スマート コントラクトは、トランザクション提案と呼ばれる一連の入力パラメーターを抽出し、それらをプログラム ロジックと組み合わせて使用​​して台帳を読み書きします. 世界の状態の変化は、読み取りを含むトランザクション提案応答 (または単にトランザクション応答) としてキャプチャされます。読み取り状態と書き込まれていない新しい状態の両方を含む書き込みセット (トランザクションが有効な場合)
      • スマート コントラクトの実行中に世界の状態が更新されない

        

        
        すべてのトランザクションには、組織のグループによって署名された識別子、提案、および応答があります。有効かどうかにかかわらず、すべてのトランザクションがブロックチェーンに記録されますが、有効なトランザクションのみが世界の状態を更新します。
      • トランザクションはネットワーク内のすべてのノードに分散され、各ノードは 2 つのフェーズでトランザクションを検証します。
        • 最初に、トランザクションが十分な数の組織によって署名されていることを確認するために、承認ポリシーに対してトランザクションがチェックされます。
        • 次に、トランザクションのチェックを続けて、承認ノードによってトランザクションが署名されたときに、そのトランザクションのリードセットがワールド ステートの現在の値と一致し、途中で更新されていないことを確認します。トランザクションが両方のテストに合格すると、有効とマークされます。
    • 通路側

      

      
      チャネルは、組織のグループ間で完全に独立した通信メカニズムを提供します。チェーンコード定義がチャネルに送信されると、チャネル上のすべてのアプリケーションがこのチェーンコードのスマート コントラクトを使用できます。
      • スマート コントラクト コードは、組織ノードのチェーン コード パッケージにインストールされますが、チャネル上でチェーン コードが定義された後にのみ、チャネル上のメンバーはスマート コントラクトを実行できます。
    • 相互通信: スマート コントラクトは、同じチャネルの他のスマート コントラクトだけでなく、他のチャネルのスマート コントラクトも呼び出すことができます。これにより、スマート コントラクトは、そうでなければスマート コントラクトの名前空間のためにアクセスできないワールド ステート データを読み書きできるようになります。
    • システムチェーンコード
      • ライフサイクル システム チェーンコード (LSCC)
      • システム チェーンコード (CSCC) の構成
      • クエリ システム チェーンコード (QSCC)
      • 承認システム チェーンコード (ESCC)
      • 検証システム チェーンコード (VSCC)
    • チェーンコードのライフサイクル - チャネルでの定義
      • チャネル メンバーは、チャネル内のすべての組織が完了する必要があるわけではない次の手順に同意します。
        • チェーンコードのパッケージ化
        • チェーンコードをピアにインストールする
        • 組織でチェーンコード定義を承認する
        • チャネルにチェーンコードを適用する
      • フェーズ 1: スマート コントラクトのパッケージ化

        

        
        チェーンコードは .tar.gz ファイル拡張子で終わる tar ファイルにパッケージ化する必要があります。
        • tar ファイルには、メタデータ ファイル「metadata」の 2 つのファイル (ディレクトリなし) が含まれている必要があります。Json" および別の tar "code.tar.gz" には、チェーンコード ファイルが含まれています。
        メタデータ。チェーンコード言語、コード パス、パッケージ ラベルを指定する json が含まれています。メタデータ ファイルの例を以下に示します
        。 Org1 と Org2 は別々にパッケージ化されます。両方の組織は、名前とバージョンを使用してパッケージを識別するためにパッケージ ラベルとして MYCC_1 を使用します。組織が同じパッケージ ラベルを使用する必要はありません。
      • フェーズ 2: チェーンコードをピアにインストールする

        

        
        Org1 と Org2 のピア管理者は、チャネルに接続されたピアにチェーンコード パッケージ MYCC_1 をインストールします。
        チェーンコード パッケージをインストールすると、チェーンコードがビルドされ、パッケージ識別子の MYCC_1:hash が作成されます。
      • フェーズ 3: 組織でチェーンコード定義を承認する
        • 組織の承認プロセスは、承認投票に相当します. チャネルメンバーは、使用を許可した後に使用できます. これには、組織間で一貫性が必要な次のパラメーター (パッケージ識別子) が含まれます.
          • 名前
          • バージョン
          • 順序
          • 承認ポリシー
          • コレクション構成
          • ESCC/VSCC プラグイン
          • 初期化: Fabric Chaincode Shim API によって提供される低レベル API を使用する場合、チェーンコードを初期化するための Init 関数をチェーンコードに含める必要があります。

        • 

          
          Org1 と Org2 の組織管理者は、組織 MYCC のチェーンコード定義を承認します。
          チェーンコード定義には、チェーンコード名、バージョン、承認ポリシーなどのフィールドが含まれます。両方の組織がチェーンコードを使用してトランザクションをサポートするため、両方の組織の承認定義に packageID を含める必要があります。
          な
      • 第 4 段階: 十分な数のチャネル メンバーがチェーンコード定義を承認すると、チェーンコード定義がチャネルに送信され、最初にチャネル メンバー ピアに送信されます。ピアは承認されたチェーンコード定義を検証し、承認し、ソーティング サービスに送信します。 、そしてチャネルに戻ります

        

        
        Org1 または Org2 の組織管理者がチェーンコード定義をチャネルにコミットします。チャネルの定義には packageID が含まれていません。
        • 組織は、チェーンコード パッケージをインストールせずにチェーンコード定義を承認できます
        • チャネルで MYCC が定義されると、Org1 と Org2 はチェーンコードの使用を開始できます。チェーンコードの最初の呼び出しにより、各ピアでチェーンコード コンテナーが開始されます。
    • チェーン コードを更新する: チェーン コードは承認フォームを更新でき、チャンネルに送信した直後に有効になります。特別に呼び出す必要はありません。
      • チェーンコードを再パックする
      • ノードに新しいチェーンコード パッケージをインストールする
      • 新しいチェーンコード定義を承認する
      • 定義をチャネルにコミットします
  • 個人データ
    • 個人データ収集:

      

      • 実際の個人データ: ゴシップ プロトコルは、それを見ることができる組織にポイント ツー ポイントで送信され、他の組織はそれを見ることができません
      • データのハッシュ値: 承認ソート後に台帳に書き込まれる公開部分
    • 別のチャネルを使用するか、既存のチャネル内でプライベート データ コレクションを使用するかについて:
      • チャネル: 元帳全体を秘密にしておく必要があります
      • コレクション: 一部

        

        
        図を例にとると、異なる組織間で異なる機密保持要件
    • 個人データを利用した取引の流れ
      • クライアント アプリケーションは、承認されたセットに属するエンドーサーにチェーンコード機能 (プライベート データの読み取りまたは書き込み) を実行させるための提案要求を送信します。非公開データ、またはチェーンコードで非公開データを生成するために使用されるデータは、提案の一時フィールドで送信されます。
      • 保証ノードはトランザクションをシミュレートし、プライベート データを一時データ ストア (ノードのローカル一時ストレージ) に格納します。彼らは、組織コレクションのポリシーに従って、[gossip]() を介して承認されたピア ノードにプライベート データを配布します。
      • 承認ピアは、提案応答をクライアントに送り返します。提案応答には、承認された読み取り/書き込みセットが含まれます。これには、公開データと、秘密データのキーと値のハッシュが含まれます。個人データがクライアントに返送されることはありません。プライベート データを使用した推薦についての詳細
      • クライアント アプリケーションは、トランザクション (プライベート データ ハッシュを含む提案応答を含む) を順序付けサービスに送信します。プライベート データ ハッシュを含むトランザクションもブロックに含まれます。プライベート データ ハッシュを持つブロックは、すべてのノードに分散されます。このようにして、チャネル内のすべてのノードは、実際のプライベート データを知らなくても、同じ方法でプライベート データ ハッシュ値を使用してトランザクションを検証できます。
      • ブロック送信時に、許可されたノードは、集合ポリシーに従ってプライベート データにアクセスできるかどうかを決定します。ノードにアクセス権がある場合、ノードはまずローカルの一時データ ストアをチェックして、チェーンコードの承認時にプライベート データを受信したかどうかを確認します。そうでない場合は、承認された他のノードからプライベート データを取得しようとし、パブリック ブロックのハッシュに対してプライベート データを検証し、トランザクションを送信してブロックします。
      • 検証または送信が完了すると、プライベート データはこれらのノードのプライベート データベースとプライベート読み取り/書き込みストレージのコピーに移動されます。その後、一時データ ストアに格納されたこれらのプライベート データは削除されます。
    • 個人データを共有する
      • 対応する公開鍵を使用して公開状態を追跡し、秘密にも同じことを行います
      • クライアントがチェーン コードを介してプライベート データにアクセスできるかどうかを制御します (それが証明書にあるかどうか、またはパスワードが一貫しているかどうか)。
      • 帯域外共有: 検証ハッシュ
      • プライベート データを他のコレクションと共有する: チェーンコード GetPrivateDataHash() は、コレクションにプライベート データがあるかどうかを検証し、検証が成功した後にコレクション内のデータを削除し、他の組織のコレクションにキーを生成します。これには、追加の承認が必要になる場合があります。
      • トランザクションの承認にプライベート データを使用する: トランザクションが完了する前に相手方の承認を得るために、チェーン コードにより、事前同意を取得するか、自分のプライベート データ セットの秘密鍵に署名し、GetPrivateDataHash() を使用してチェック
      • トレーダーのプライバシーを守る: プライベート データのハッシュの使用