【図解】Hyperledger Fabric の全体像を理解する
https://gyazo.com/35674f3e3e8dbe270aa9952af4c32598
これは何
Hyperledger Fabricの基本的な仕組みを理解するメモ
(1) 特徴
1. コンソーシアム型チェーン
permission blockchainなので信頼できる主体しか参加してこない
2. 迅速なコンセンサス・ファイナリティ
各参加者の合意を得ることでFinalityとするので、PoWなどのようにコンセンサスのために頑張る必要がない
3. チェーンコードの実行が可能
Ethereumでいうスマートコントラクトのようにチェーン上でプログラムが動かせる
4. 最新の状態DBの保持
各ノードが最新の状態のState DBを保持することで、ノードは全ブロックを参照する必要がない
5. 1つのチェーンをチャネル(channel)に分けることができる
別のチャネルの中のチェーンコードやDBの状態は他のチャネルからは見ることができない
(2) 全体アーキテクチャ
https://gyazo.com/17ba85edb728cfe1e6db4a3e8b736af6
Organization : Hyperledger Fabricネットワークに参加する組織を表す
Peer : 各Organization内のNodeを表す。Chain code, Blockchain, State DBを保持する。「トランザクションの承認と実行」をするEndorserと、「トランザクションの実行結果の検証とDBへの書き込み」の役割を持つCommitterの機能のみを持つPeerも存在する。
Chaincode : Hyperledger Fabricチェーン上で実行可能なプログラム
トランザクションのリクエストによってのみ実行される。チェーンコードから別のチェーンコードを実行することも可能。
Ethereumでいうコントラクト。
開発言語は、現在Go (JavaやNode.js版も開発されている)
ただし、あるチェーンコードがState DBに書き込んだデータは他のチェーンコードからは参照できない。
Blockchain : 特徴として「チェーンコード実行によってState DBに書き込まれたデータ(RWSet)を そのままBlockに格納する」
それ以外は普通のブロックチェーン
State DB : トランザクションを実行した結果として得られる”状態”の最新を常に格納するDB。
デフォルトでは、LevelDBが使用されているが、JSON形式のドキュメントを格納可能なApache CouchDBも利用可能。
RDBのサポートも鋭意開発中。
MSP(Membership Service Provider) : HLFがデフォルトで提供するCA(Certificate Authority:認証局)または外部のCAから「ユーザーの登録と Erect (Enrollment Certificate)の発行」を行う。
MSPと CAは各Organizationに作成することも可能。
Endorsement Policy :
トランザクションの承認ルールのこと。「A商事(特定のOrganization)が承認したら OK」とか「全Organizationのうち過半数が承認したらOK」とか。
Orderer : EndorserによってEndorsement(同意・承認) されたトランザクションの結果を受け取って、書き込みを行うCommitterに配分する役割を持つ。SPOFにならないように冗長化するための機能
※OrdererがSPOFになってしまう問題の対策
Ordering の手法には 以下の3つがある。
SOLO : OrdererはどこかのOrganizationが管理している1つ
Kafka : 分散メッセージングの仕組みであるApache Kafkaを使って複数のOrderer間でRWSetをやり取りして、合意の上でPeerに分配する
SBFT : 各OrganizationがOrdererを持ったとして、悪意のあるOrdererが出てきたとしても合意が取れる仕組み(BFT性を持つ)。開発中。
(3) Hyper Ledger Fabricの利用方法
「HyperLedger Fabric SDK」
クライアント用のSDKで、HLFの機能を利用するためのAPIが提供されているので、これでトランザクションを実行したりする。
現在は、 Node.js版、Java版がリリースされている。
Go版、Python版も開発中。
(4) トランザクション実行の流れ
1.
https://gyazo.com/21b5c6d904e8effff263fff0a2dd760a
HLF SDKに対してOrganizationのCA・MSPからEcertを貰うことで、HLFネットワークとのやりとりが可能になる。
2.
https://gyazo.com/ab1648c423f3ecb79b59996ba21cee0e
User (ここでは実際にシステムを使って業務を行うC銀行社員を想定)がWebアプリ等を通してトランザクションのリクエストを飛ばす。
3.
https://gyazo.com/ab1648c423f3ecb79b59996ba21cee0e
SDKが該当のチェーンコードを実行するトランザクションを生成し、対象となるOrganization内の任意のEndorserにEndorsement Policyに従って 「Transaction Proposal」を飛ばす。
4.
https://gyazo.com/67ef5f44ed386d353697f501961503ca
Transaction Proposalを受け取ったEndorserは、そのTransactionを実行してみて、実行した結果をRWSetとして保持。この時State DBやblockchainへの書き込みは行わない。
5.
https://gyazo.com/c8242719f2af7ed642ba31dff38b987a
各EndorserがTransactionの実行結果から承認・非承認を決定し、トランザクションを承認する場合は、RWSetにデジタル署名をしてクライアント側(SDK)に送信する。
6.
https://gyazo.com/bb7224bc8cb72ce98da4fa861efc27cc
SDKが集まってきた各Endorserのデジタル署名付きRWSetから、Endorsement Policyが満たされているかを確認。
満たされたいない場合は、ここで「トランザクション却下」通知をUserに送るなどする。
7.
https://gyazo.com/eb40496ee0f62b1c8bec6b1cdb27613d
Endorsement Policyが満たされていれば、集まってきた全ての署名付きRWSetをOrdererに送信
8.
https://gyazo.com/92c215c040b3fe86eb8f2662d7a132d9
上記の図のように、Ordererには同時にあらゆるクライアントからこのTransactionが送られてきているため、Ordererは受け取ったTransactionを一旦プールし、トランザクションの順序を整理。
これをしないと、トランザクションAを前提としたトランザクションBがAが書き込まれるよりも前に実行されてしまったりする。
9.
https://gyazo.com/137e77d9f690ccff641ec3332bf558c2
OrdererがTransactionを順序通りに、各OrganizationのLeader Peer(Committer)に送信する。
ここでは、Leader Peerのみに送信し、全てのPeerには送信しないことで、OrganizationやPeerの数が膨大になっても対応可能なスケーラビリティを実現している。(これをGosip Protocolと呼ぶ)
10.
https://gyazo.com/27b7facc8947ce6ad38129c77f499c3c
各Committerは、受け取った 署名付きRWSetを検証する。
検証項目は以下の項目など
Endorsement Policy が満たされているか
RWSetに格納されているキー項目のversion番号が現在のState DBの該当キー項目と一致しているか
検証した結果、正当なRWSetであれば、それをState DBに書き込む
11.
https://gyazo.com/6dcdb70b7e7057c53acc1c34e16bd7c4
各Committerが、その結果をEventとしてクライアント側(SDK)に通知する
< なぜTransaction Proposalが存在するのか >
Transaction Proposalの段階でEndorserによる「トランザクションの実行」
その後は、トランザクションの実行結果をやり取り・検証し、Transactionのsubmit, 配布の段階でCommitterによる「実行結果の書き込み」
と実行と書き込みを分離することによって、トランザクション実行時に順序を気にする必要がなくなり、並列処理が可能になるためスケーラビリティの向上になるから。
(5) チャネルという概念
https://gyazo.com/77835910afa6d4e5db726d982bf2077f
1つのHLFネットワークの中で、さらに分割したネットワークとしてChannelを作成することが可能。
各チャネルの中だけでChain Code、Blockchain, State DBを管理できる。
上記の図で言うと、赤チャネル、青チャネル、緑チャネルが存在していることになる。
Organizationに囚われず、Peer毎に所属するチャネルすなわちチェーンを作成することができる。
一つのPeerが複数のチャネルに所属することも可能(上図のC銀行のPeer1)
チャネルが分かれている場合のトランザクション実行は以下のようになる。
https://gyazo.com/7c71c0e255e1c4a3d3a36eb1659d1b03
SDKがどのチャネルへのトランザクションリクエストかを判別して、該当チャネルのEndorserにのみTransaction Proposalを送る
https://gyazo.com/ba66d58cc95d1810261d433abcfd81d3
Ordererは受け取った署名付きRWSetをチャネル毎にPeerに分配する。
こうすることで、あるチャネルのChain code, blockchain, State DBは他のチャネルからは閲覧できないように管理することができる。