目次


Hyperledger Fabric 入門, 第 3 回

コンセンサス/Ordering Service/Kafka/Zookeeper

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: Hyperledger Fabric 入門, 第 3 回

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:Hyperledger Fabric 入門, 第 3 回

このシリーズの続きに乞うご期待。

第 3 回は Hyperledger Fabric のコンセンサス、Ordering Service について紹介します。

1

はじめに

ブロックチェーンではネットワーク内に分散されたノードが同じ情報を持つことで、高い可用性、データの完全性を提供します。 Hyperledger Fabric においてこれらを実現するために重要なコンセンサス、Ordering Service について紹介します。

2

コンセンサス

Hyperledger Fabric のネットワーク内のノードが同じ情報を保持するためには、更新する情報が正しいこと、その情報が全てのノードに保存されたことを確認する必要があります。この確認する仕組みをコンセンサス (合意形成) と呼びます。 Hyperledger Fabric のコンセンサスは Endorsement、Ordering、Validation の 3 つのフェーズに分かれています。

  • Endorsement フェーズ

    Endorsement フェーズではクライアントが Endorsing Peer にランザクションを送付し、Endorsement Policy がそのトランザクションをシミュレーションして、自身の署名を加えて、クライアントに返信します。Endorsing Peer はシミュレーションをする際に、送信元のクライアントの証明書が有効かどうか、対象のチャネルに対してアクセスすることができる権限があるかどうか等のチェックもしています。 Endorsing Peer、Endorsement Policy については第 2 回の記事をご確認ください。

  • Ordering フェーズ

    Ordering フェーズでは、クライアントが Ordering Service にトランザクションを送付します。 このトランザクションには、Endorsing Peer がシミュレーションした結果の情報と Endorsing Peer の署名、チャネル ID 等が含まれて居ます。 Ordering Service では受け取ったトランザクションをチャネルごとに順序付してブロックにパッケージングし、Committing Peer にブロックを送付します。 チャネルについては第 2 回の記事をご確認ください。

  • Validation フェーズ

    Validation フェーズでは Ordering Service から受け取ったトランザクションを Committing Peer が検証します。 Committing Peer は Endorsement Policy を満たしているか、複数のトランザクションが同じ値を更新して競合していないか (MVCC 検証) を検証します。 検証の結果、問題なければ、Committing Peer はブロックを台帳に書き込み、ステート DB を更新します。

下の図はコンセンサスの流れを表しています。

  1. クライアントはトランザクションの提案を Endorsing Peer 宛に送付します。
  2. Endorsing Peer はクライアントからトランザクションを受け取るとチェーンコードでトランザクションをシミュレーションし、結果をクライアントに返します。
  3. クライアントは Endorsement Policy を満たしていることを確認し、トランザクションを Ordering Service に送付します。
  4. Ordering Service はクライアントからトランザクションを受け取ると、トランザクションの順番を定義し、ブロックを作成します。作成したブロックを Committing Peer に送付します。
  5. Committing Peer は Ordering Service からブロックを受け取ると、Endorsement Policy を満たしているか、(2) のシミュレーション実行時とデータの整合性が取れているかを確認します。確認後、問題がなければ、ブロックを台帳へ書き込みます。
「Hyperledger Fabricにおけるコンセンサスの流れ」を示したフロー図
「Hyperledger Fabricにおけるコンセンサスの流れ」を示したフロー図

 

3

Ordering Service

Ordering Service はトランザクションを含むメッセージのブロードキャストサービスを提供し、トランザクションの順序付けとブロックの作成を行うサービスです。 このメッセージのブロードキャストサービスを使って、チャネル単位で該当する Peer にブロックを送信します。

また 1 つのブロックに入れることのできるトランザクションの数はブロック内の容量と時間で決めることができるので、適用するビジネスプロセスによってトランザクションを確定させるまでの所用時間を調節することができます。

Ordering Service が提供する API によって、クライアントと Peer は Hyperledger Fabric のネットワークと通信し、台帳の更新や参照を行います。 ここでは Ordering Service が提供する主な API を 2 つ紹介します。

  • broadcast(blob)

    クライアントが broadcast( ) を呼び出すことによってチャネルに任意のメッセージ (blob) をブロードキャストすることができます。 この blob にはトランザクションの実データとクライアントの署名が含まれています。 Endorsing Peer や Orderering Service にトランザクションを送信する際に利用します。

  • deliver(seqno,prevhash,blob)

    Ordering Service が deliver( ) を呼び出すことによって、peer に任意のメッセージ (blob) を送信します。 Ordering Service が生成したブロックを Peer に送信する時に利用します。 seqno は正の整数で表示される順序番号で、prevhash とはこのメッセージを送る一つ前の deliver( ) のハッシュ値、blob は実際に Peer に送るメッセージを表します。seqno によって全 Peer で同じ順番にトランザクションが実行され、prebhash によって、改ざんが困難なハッシュチェーンが生成されます。

    「主な Orderering Service の API の概略図」を示したフロー図
    「主な Orderering Service の API の概略図」を示したフロー図

     

その他、Ordering Service が提供する機能を 2 つ紹介します。

  • チャネルの再構成と構築

    ブロックチェーンネットワーク内のメンバーがあるチャネルを再構成したい場合、_そのチャネルの構成情報を含んだトランザクションを Ordering Service に送信します。Ordering Service はそのトランザクションを受け取るとチャネルを再構築します。 新規に構築する時も同様に構成情報を含んだトランザクションを受け取って、Ordering Service がチャネルを構築します。

  • クライアントのアクセス制御

    Ordering Service はアクセス制御を実行してクライアントが特定のチャネルにトランザクションをブロードキャストしてよいか、ブロックの情報を受け取ってもよいかを確認しています。

Hyperledger Fabric では現時点で 2 種類の Ordering Service 構成オプションがあり、Solo と Kafka/Zookeeper があります。 Solo は検証環境向けの単体ノード構成で、Kafka/Zookeeper は本番環境向けの複数ノード構成で高い可用性を高めます。(Crash Fault Tolerance) また、ビザンチン耐性を持つ BFT (Byzantine Fault Tolerance) は今後、提供される見込みです。

4

Kafka/Zookeeper

Hyperledger Fabric では Kafka/Zookeeper を使って Ordering Service の冗長化を実現しています。 Kafka はオープンソースの分散メッセージングシステムです。Web サービス等から発せられる大容量のデータを高スループットに取集し、配信することができます。Kafka は 4 台以上の構成が推奨され、ディスクにファイルとしてデータを保存して、クラスタ内でデータのレプリカを作成することも可能です。

Ordering Service は Kafka を使ってトランザクションの順番を定義しています。 Zookeeper は分散システムを構築する上で、必要となる、データの同期、設定管理、参加者のグルーピング、名前管理等の機能を提供するサービスです。 Hyperledger Fabric で Zookeeper を利用する場合は 3,5,7 の奇数台数構成が推奨されます。7 台以上は性能があまり変わりません。

図は Kafka/Zookeeper 構成の Ordering Service の例です。 クライアントから送信されたトランザクションを Orderer が Kafka に送信して、Kafka にトランザクションを溜め込みます。 Kafka では送信されたトランザクションをチャネルごとに分けて管理をしています。

Orderer は Ordering Service を提供するノードを表しています。クライアント/Peer と Kafka 間のトランザクションを中継する役割を担っています。 溜め込んだトランザクションは一定量、もしくは一定時間が経過すると、一つのブロックにまとめられ、Committing Peer へ送信されます。

「Kafka / Zookeeper 構成の Ordering Service」を示したフロー図
「Kafka / Zookeeper 構成の Ordering Service」を示したフロー図

 

5

まとめ

今回は Hyperledger Fabric のコンセンサスの仕組み、Ordering Service について学びました。 Hyperledger Fabric ではこれらの仕組みを利用して、トランザクションの検証、ブロックの生成を行い、データの完全性や可用性を担保しています。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=1061805
ArticleTitle=Hyperledger Fabric 入門, 第 3 回: コンセンサス/Ordering Service/Kafka/Zookeeper
publish-date=06142018