Gossip data dissemination protocol
==================================

Hyperledger Fabricは、トランザクションの処理負荷をピア上での実行（エンド―シングとコミット）とオーダリングノード上での実行という形で分割することで、ブロックチェーンネットワークのパフォーマンス、セキュリティとスケーラビリティを最適化しています。このネットワーク運用上の分離では、データの完全性と一貫性を担保するために、安全で信頼性が高くスケーラブルなデータ伝送プロトコルが必要になります。これらの要求を満たすために、Fabricでは **ゴシップデータ伝送プロトコル** を使用しています。

Gossip protocol
---------------

ピアはスケーラブルな方法で台帳やチャネルのデータを伝送するためにゴシップを利用します。ゴシップの伝送方法には継続性があり、チャネルに所属するピアは、複数のピアから定期的に最新且つ一貫性のある台帳データを受け取ります。各ゴシップのメッセージは署名されており、ビザンチン参加者が送信した不正なメッセージを容易に識別することができ、不要なターゲットにメッセージが伝送されることを防ぎます。ピアは遅延やネットワーク分断等が原因でいくつかのブロックを受け取り損ねることがありますが、受け取り損ねたブロックを保持するピアとやり取りすることで台帳を最新の状態にすることができます。

ゴシップをベースにしたデータ伝送プロトコルは、Fabricネットワークに3つの主要な機能をもたらします。

1. 利用可能なメンバーピアを特定し、オフラインのピアを検出することで、ピアディスカバリとチャネルメンバーシップを管理します。
2. チャネルに所属する全てのピアへ台帳データを伝送します。チャネル内で同期されなかったピアは不足したブロックを識別し、正しいデータをコピーして同期します。
3. 新しく接続されたピアは、ピアからピアへのステート移行により、迅速に台帳データが更新されます。

ゴシップをベースにしたブロードキャスティングは、ピアがチャネル内の他のピアからメッセージを受け取り、ランダムに選ばれたピアに転送されます。ランダムに選ぶピアの数は、設定が可能です。またピアは、メッセージを待って受信するというよりは自ら取得します。チャネルメンバーシップの結果、このサイクルが繰り返され、台帳とステートは最新の状態が保たれます。最新ブロックの伝送のために、チャネルに所属する **リーダー** ピアは、オーダリングサービスからデータを取得し、同じ組織内のピアへゴシップでの伝送を開始します。

Leader election
---------------

リーダー選出のメカニズムには、 組織毎にあるピアが **選出** される仕組みが使用されています。この組織は、オーダリングサービスとの接続を維持しており、新たに受信したブロックを組織内のピアに伝送します。この仕組みを用いることで、システムはオーダリングサービスの処理能力を有効に活用することが可能になります。リーダー選出のモジュールには、2つのオペレーションモードがあります:

1. **スタティック** --- システム管理者が手動で組織内のピアをリーダーに設定します。
2. **ダイナミック** --- ピアがリーダー選出手順で、組織内のあるピアをリーダーとして選出します。

Static leader election
~~~~~~~~~~~~~~~~~~~~~~

スタティックなリーダー選出は、手動で組織内の1つもしくは複数のピアをリーダーピアとして設定します。しかし、複数のピアをオーダリングサービスに接続しすぎると、処理能力を有効に活用できなくなることに注意が必要です。スタティックなリーダー選出モードを有効に使用するために、 ``core.yaml`` にある以下のパラメータを設定します:

::

    peer:
        # Gossip related configuration
        gossip:
            useLeaderElection: false
            orgLeader: true

また、これらのパラメータを、環境変数で設定して上書きすることも可能です:

::

    export CORE_PEER_GOSSIP_USELEADERELECTION=false
    export CORE_PEER_GOSSIP_ORGLEADER=true

.. note:: 以下の設定でピアを **スタンバイ** モードにすることで、ピアをリーダーにしないようにできます。

::

    export CORE_PEER_GOSSIP_USELEADERELECTION=false
    export CORE_PEER_GOSSIP_ORGLEADER=false

1. ``CORE_PEER_GOSSIP_USELEADERELECTION`` と ``CORE_PEER_GOSSIP_ORGLEADER`` に ``true`` を設定した場合、矛盾した設定であるためエラーとなります。
2. スタティックモードに設定している組織の管理者は、不具合や障害耐性を考慮してリーダーノードの高可用性を担保しなければなりません。

Dynamic leader election
~~~~~~~~~~~~~~~~~~~~~~~

ダイナミックなリーダー選出は、オーダリングサービスに接続し新しいブロックを取得するあるピアを組織から **選出** します。このリーダーは組織のピアから独自に選出されます。

選出されたリーダーは、生存していることを示すために、他のピアに **ハートビート** を送信します。1つ以上のピアが決められた時間内に **ハートピート** を受信しなかった場合、新しいリーダーを選出します。

ネットワーク分断という最悪なケースでは、組織内のピアが動作し続けることを目的としてレジリエンスと可用性を担保するために、1つより多くのアクティブなリーダーを組織に用意します。ネットワーク分断が回復した後、1つのリーダーがリーダーシップを放棄します。ネットワーク分断がない安定した状況では、1つのアクティブなリーダー **だけ** が、オーダーリングサービスに接続します。

以下により、リーダーの **ハートピート** メッセージの頻度を設定することができます。

::

    peer:
        # Gossip related configuration
        gossip:
            election:
                leaderAliveThreshold: 10s

ダイナミックなリーダー選出を可能にするため、以下のパラメータを ``core.yaml`` に設定する必要があります。

::

    peer:
        # Gossip related configuration
        gossip:
            useLeaderElection: true
            orgLeader: false

また、パラメータを環境変数として設定することもできます。

::

    export CORE_PEER_GOSSIP_USELEADERELECTION=true
    export CORE_PEER_GOSSIP_ORGLEADER=false

Anchor peers
------------

アンカーピアは、異なる組織のピアの情報を知るためにゴシップで使用されます。

アンカーピアを更新するコンフィギュレーションブロックがコミットされた場合、ピアはアンカーピアとやり取りし、アンカーピアが知る全てのピアの情報を取得します。各組織のピアがアンカーピアと1回でもやり取りをしていれば、アンカーピアはチャネルに所属するピアを知っています。ゴシップの通信は継続的で、ピアは常に知らないピアの存在を提供するように求めるので、メンバーシップの共通観点がチャネル内で規定されます。

具体例として、 ---`A`, `B`, `C`--- 3組織の例を挙げます。各組織は、チャネルに所属し、1つのアンカーピアを保有します。 ---`peer0.orgC`--- 組織 `C` に所属するピアです。組織 `A` に所属する `peer1.orgA` が `peer0.orgC` とやり取りをすると、 `peer0.orgA` の情報を提供します。さらに、 `peer1.orgB` が `peer0.orgC` とやり取りをすると、 `peer0.orgC` は `peer1.orgB` に、 `peer0.orgA` の情報を提供します。それ以降、組織 `A` と組織 `B` は `peer0.orgC` が媒介することなくメンバーシップ情報を直接交換し始めます。

組織間通信はゴシップに依存しており動作させるためには、少なくとも1つのアンカーピアをチャネル設定に定義する必要があります。各組織は高可用性と冗長性を持たせたアンカーピアを提供することが強く推奨されます。また、アンカーピアはリーダーピアと同一である必要はありません。

External and internal endpoints
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

ゴシップを効果的に動かすために、ピアは、他の組織のピアから取得する情報と同様に、同じ組織のピアのエンドポイント情報を保有する必要があります。

ピアはブートストラップする際、自分の情報を提供しメンバーシップ情報を交換するために ``core.yaml`` 内の ``peer.gossip.bootstrap`` を使用し、組織内全ての利用可能なピアのビューを構築します。

ピアの ``core.yaml`` 内の ``peer.gossip.bootstrap`` は、**組織内** のゴシップのブートストラップに使用されます。ゴシップを使用する場合、組織内の全てのピアに、ブートストラップピアを示す初期設定（対象のピアをスペース区切りで指定することができます。）が必要です。内部のエンドポイントは通常ピアにより自動的、もしくは ``core.yaml`` 内の ``core.peer.address`` を基にして設定されます。この値を上書きする場合、環境変数 ``CORE_PEER_GOSSIP_ENDPOINT`` で設定します。

ブートストラップ情報は、同様に  **組織間** 通信の設定に必要です。組織間ブートストラップの初期情報は、前述のアンカーピアから提供されます。もし組織内のピアを他の組織に知らせたいのであれば、 ``core.yaml`` 内の ``peer.gossip.externalendpoint`` を設定する必要があります。設定されていない場合、ピアのエンドポイント情報が他の組織のピアにブロードキャストされません。

エンドポイントを設定する方法:

::

    export CORE_PEER_GOSSIP_BOOTSTRAP=<所属する組織内のピアのエンドポイントのリスト>
    export CORE_PEER_GOSSIP_EXTERNALENDPOINT=<他の組織に知られているピアのエンドポイント>

Gossip messaging
----------------

オンラインのピアは、 **public key infrastructure (PKI)** ID と送信者の署名を含む "生存" メッセージを継続的にブロードキャストすることで可用性を示します。ピアは生存メッセージを収集することでチャネルメンバーシップを維持します。特定のピアからどのピアも生存メッセージを受け取らなかった場合、そのピアは "死んでいる" ピアであり、チャネルメンバーシップから削除されます。 "生存" メッセージは暗号論に基づいた署名を含むため、ルートCAが発行した署名鍵を保持していない悪意のあるピアが他のピアに成りすますことはできません。

受信したメッセージの自動転送に加えて、ステート修正プロセスでは、各チャネルに所属するピアの **ワールドステート** と同期します。ピアがステートの相違を認識した場合、その相違を修正するために、ピアは同じチャネルの他のピアから継続的にブロックを取得します。ゴシップを基にしたデータ伝送を維持するためにネットワーク接続を修復することは求められていないため、プロセスは確実に共有台帳とのデータの一貫性と完全性、またノードの耐障害性を提供します。

チャネルは分離されているので、あるチャネルに所属するピアは他のチャネルにメッセージ送信や情報を共有することはできません。どのピアも複数のチャネルに所属できますが、所属する各チャネルで合意されたメッセージルーティングポリシーによりメッセージ交換が分割されているため、チャネルに所属していないピアにはブロックは伝送されません。

.. note:: 1. point-to-pointでのメッセージのセキュリティはピアのTLSレイヤーで掌握されており、署名は不要です。ピアは、CAが署名した証明書によって認証されます。TLSの証明書も使用されますが、ゴシップレイヤーでの認証ではピアの証明書が使用されます。ブロックはオーダリングサービスに署名された後、チャネルに所属するピアに配信されます。

          2. 認証は、ピアのメンバーシップサービスプロバイダによって管理されます。ピアが初めてチャネルに接続した際に、TLSセッションがメンバーシップアイデンティティに紐づきます。これは本質的に各ピアがネットワークやチャネルのメンバーシップに則って認証されることを示します。

.. Licensed under Creative Commons Attribution 4.0 International License
   https://creativecommons.org/licenses/by/4.0/