Hyperledger Fablicについて

#Hyperledger Fablicとは

• コンソーシアム型ブロックチェーン
• コンソーシアム型とは共同体に参加するグループだけが参加できるブロックチェーン
• 貿易における書類の共有、複数の金融機関で決済用に使うなどのユースケースがある
• 公式サイト: https://www.hyperledger.org/projects/fabric

• コンセンサス方式

• パブリックブロックとチェーンでみられる「マイニング」の概念がなく, 特定のグループだけが参加できるネットワークを形成するので各組織の合意を得るだけ.

• そのためトランザクションを迅速にさばける, ファイナリティを確保できる.

• コンセンサス - 分散台帳の更新とトランザクション記録についての合意

• ファイナリティ - 経済用語. ブロックチェーン関係の話では「ブロックの正当性を最終的に確定した状態」を指す.

• トランザクション実行後の最終状態の保持

• StateDBというデータストアにトランザクション実行した結果得られる最新の状態(貿易の場合は物資の経路の記録など)を保持する. ビットコインなどのように全トランザクションを参照することなく, その時点での状態を確認できる.

以下ブロックチェーンをBC, Hyperledger Fablic SDKをSDKと省略することがある.

##Hyperledger Fablicの構成要素

• Hyperledger FablicClient SDK

• クライアント用のSDK

• Hyperledger Fabricの機能を利用するためのAPIが提供されている

• トランザクションを実行できる

• Organization

• ネットワークに参加する組織を表現する単位

• 後述するピアやオーダラーが含まれる

• Peer(ピア)

• Organization内のノードを表す単位

• ブロックチェーン, StateDB, チェーンコードを保有

• Endorser, Committerの役割を持つ

• Endorser - トランザクションに同意する

• Committer - トランザクションと実行結果の妥当性を確認してStateDBとBCを更新する

• Orderer(オーダラー)

• Endorserによって同意されたトランザクションの結果をブロックチェーンとStateDBに書き込む順番を決める

• ネットワーク上の全てのトランザクションを制御する

• チェーンコード(Chaincode)

• スマートコントラクトを実行するプログラム

• 現在node.js, go, javaで書ける

• State DB

• トランザクション実行後に得られる最新の状態(残高とか)を格納するデータストア

• LevelDBというKEY-VALUE形式のものやApache CouchDBというJSON形式のものが利用できる

• MSP(メンバーシップサービスプロバイダ)

• Hyperledger Fabricが提供するCA(認証局), または外部のCAと連携してユーザーの登録, ユーザー証明書(Ecert)の発行を行う

• 各OrganizationでそれぞれMSPを実装できる

• Endorsement Policy

• BCやStateDBを更新するために同意(Endorsement)が必要なOrganizationにポリシーを規定するもの

• 「A社の合意のみが必要」などのルールが決めれるということ

• チャネル(Channel)

• ネットワークを分割したネットワーク

• 各チャネル内で同一のStateDBとBCを保持する

• A社、B社、C社が参加するネットワークにチャネル1, ２があるとする

• A社はチャネル1と２, B社はチャネル１, C社はチャネル2に参加しているとすると3社は参加しているチャネルのStateDBとBCを持つ(複数のStateDBとBCを持つことがある)

##トランザクション処理の流れ

1. SDKを利用するクライアント(webアプリケーションなど)からチェーンコードの実行がリクエストされる(Transaction Proposal). Endorsement Policyのポリシーに従って対象のOrganizationのピア(Endorser)に対して要求される. ピアはBC, StateDB, チェーンコードを持つことを思い出そう.

2. Endorser(トランザクションに同意する人)がチェーンコードをシミュレートする. この時はStateDBへの書き込みを行わず, RWset(Read/Write set)を発行する. RWsetはチェーンコードをシミュレート時の読み込み対象と書き込み対象のキー項目とバージョン番号, 書き込む値を格納する.

3. Endorserが署名したRWsetをクライアントに応答する. これによってトランザクションはOrganizationから認められたものとなる.

4. SDKは対象のOrganization内の署名つきRWsetによりEndorsement Policyが満たされることを確認する. この情報を元にOrdererにトランザクションの制御を要求する.

5. Ordererはトランザクションの順番を決める. 順番が決められたトランザクション(署名つきRWset)はネットワーク内のピア(Committer)に送られる.

6. Committerがトランザクション(署名つきRWset)を検証. 成功するとStateDBとBCを更新する. 検証としてはRWsetに入っているキー項目のバージョン番号とStateDBのキー項目のバージョン番号が同じであるかをチェックする.

7. Committerはトランザクションの検証が成功したか否かを, イベントを発行してクライアント側に通知する. 検証に失敗したら対応が必要になる.

##感想
なんか複雑だなと思ってまとめてみたがやっぱり複雑だった. パブリックブロックチェーンと違っている点が多々あり面白いと感じた. パブリックでやる必要がない部分やパブリックでやることがNGな領域(貿易など)で活躍すると思う.

##参照
～ブロックチェーンの革新技術～ Hyperledger Fabricによるアプリケーション開発
https://www.amazon.co.jp/dp/B07JNY46ZS/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1