こんにちは！サイオステクノロジーの安藤 浩です。
エンタープライズ向けブロックチェーンのデファクトスタンダードといわれているHyperledger Fabricの入門の続きとして、Hyperledger Fabricでいうところの合意形成の仕組みであるトランザクションフローについて説明していきます。説明や用語などは以下の前回の記事をもとにしています。
Hyperledger Fabric 入門 – Hyperledger Fabricとは、Hyperledger Fabricのコンポーネントの説明 –
はじめに
Hyperledger Fabricには以下の3つのステップで構成されるトランザクションフローによって合意形成がなされます。
ステップ1: Endorsement
トランザクションの内容について合意するステップです。(Chaincode実行結果にPeerが署名したもの)
ステップ2: Ordering
トランザクションの順序を確定しプロックを生成・配布するステップです。
ステップ3: Validation & Commit
トランザクションの有効性を検証したうえで反映するステップです。
ステップ1～3のトランザクションフローが完了したときにクライアントアプリケーションにLedger(台帳)の更新が通知されます。
ここからはそれぞれのステップにおいてどのような処理がされているか詳しく見ていきます。
ステップ1: Endorsement
目的：
複数の組織で複数のPeerを所有する場合、Chaincodeを実行することで同一の結果が得られることを確認したい
理由：
Peerに対して不正を働いた、不具合があった、ミスや障害などで不正な状態のLedgerのデータをもとにTransaction が処理されることを防ぎたい。
以下の図に記載の順でEndorsementのステップ(青色の部分)は実行されます。
1.Transaction Proposal 送付
まず、クライアントアプリケーション(図内のClient App)がPeer に対して、Chaincodeを実行するように要求を行います。これをTransaction Proposalといいます。この要求はLedger に対しての読み込みや書き込みが該当します。
2.Chaincode 実行
Peer 内のChaincodeを実行し、署名を付けます。この結果をEndorsementといいます。※ここでは実際にLedgerに対して反映することはないため、シミュレーション実行とも呼ばれます。
3.Endorsement 返却
2のEndorsementをクライアントアプリケーション(図内のClient App)に返却します。
4.Endorsement Policy に基づきEndorsementを収集
Client AppはPeerから返却されたEndorsementをあらかじめ決められたEndorsement Policyに基づいてEndorsementを収集します。Endorsement Policyとは、あるTransaction をLedgerに反映するために、どのようなEndorsementを集めてこなければならないかをあらかじめ定義した条件のこと。
例：Organization1, Organization2, Organization3 で構成されるネットワークとしたとき。
・Organization1, Organization2のどちらからもEndorsementを収集しなければならない条件。
・Organization1, Organization2, Organization3のいずれか2つのOrganizationからEndorsementを収集しなければならない条件。
ステップ2: Ordering
目的：
Transactionの集合を適切な順序で配置し、それらをBlockにまとめることです。そのBlockをPeerに配布して最終的なValidation を実施して、Ledgerに書き込みます。
理由：
Transaction の順序を決めないとデータの不整合が発生してしまうため。
以下の図に記載の順でOrderingのステップ(緑色の部分)は実行されます。
5.Transaction 送付
Endorsementを収集したクライアントアプリケーション(図内のClient App)がTransactionをOrdering Service に送付します。まず、図の点線部分でPeerのFabric Gateway(v2.4で導入された)を介して、TransactionをOrdering Service に送付されます。
※ここでOrdering Serviceは複数ノードで構成されます。
Transaction にはPeerから署名済のTransaction Proposalへのレスポンスが含まれます。
6.Block生成
1. Ordering Service で受け取ったTransaction の順序を合意し、決定します。(コンセンサスアルゴリズム: Raftを利用)
2. Ordering ServiceがTransactionを組み込んだBlockを生成します。
7.Block配布
Ordering Serviceは生成したBlockをPeer に配布します。
また、Peerが停止していた、または後からChannelに参加した場合はOrdering Service に再接続した際にBlockを受信します。
ステップ3: Validation & Commit
目的：
最終的に Transaction の有効性を検証したうえでLedger に反映したい。
理由：
ステップ1で実行した結果と一致するか、署名やTransaction が改変されていないかなどの不正が起こっていないかをチェックするため。
以下の図に記載の順でValidation & Commit のステップ(紫色の部分)は実行されます。
8.Validation → Commit
1.Peer はOrdering Service から配布されたBlock内のTransaction を検証(Validation)します。
2.Validationが完了したら、Ledgerに対して反映(Commit)します。
Validationの際にはやることは以下です。
・各Transactionを検証
・Transaction が必要な組織のPeerによってエンドース(署名がついている)されていること
・Endorsementが一致していること
・Read-Set に含まれるKeyに対するVersionが現在の World State のKeyのVersionから変更されていなければTransaction を有効とする。変更されていればTransaction を無効とする。
最後の点が分かりにくいので、用語の説明とともに詳細を説明していきます。
用語の説明
World State
ここでWorld Stateとは、World StateはKeyの現在のValueを格納されているデータストアです。
また、各Keyに対するVersionも持っており、レコードがどのBlockのどのTransaction によって書き込まれたかを表します。
以下の例のようなデータをもっています。
Read-Set
Read-Setとは、ステップ1のEndorsementの際にChaincodeの実行によって取得されたKeyとVersionのリストです。
以下は仮想的な例ですが、read-setのブロックで囲まれた箇所です。
<TxReadWriteSet>
<NsReadWriteSet name="chaincode1">
<read-set>
<read key="WaterBottle1", version="0">
<read key="WaterBottle2", version="0">
</read-set>
<write-set>
<write key="WaterBottle1", value="LION">
<write key="WaterBottle2", value="MAMMOTH">
<write key="WaterBottle3", isDelete="true">
</write-set>
</NsReadWriteSet>
<TxReadWriteSet>「Read-Set に含まれるKeyに対するVersionが現在の World State のKeyのVersionから変更されていなければTransaction を有効とする。変更されていればTransaction を無効とする。」について
用語の説明はできたと思うので、「・Read-Set に含まれるKeyに対するVersionが現在の World State のKeyのVersionから変更されていなければTransaction を有効とする。変更されていればTransaction を無効とする。」については、ステップ1のEndorsementでChaincodeを実行した際に生成されたRead-Setと現在のLedger内のWorld State の状態が一致するかということを検証しています。
Endorsement からValidationまでにほかのTransaction などによってWorld StateのKeyに対するValueが変更されている可能性があるため、最終的にValidationをしています。
9.BlockがLedgerにCommitされたことを通知
最後にBlockがPeer内のLedgerに反映されたことをもって、トランザクションフローが完了します。これをクライアントアプリケーション(図内のClient App)に通知して終わりです。
また、Ordering Service に接続していないPeerの場合はほかのPeerからGossip プロトコルによりBlockが配布されます。Private DataについてもGossip プロトコルによってPrivate DataをもっているPeerから配布されます。
まとめ
トランザクションフローは3つのステップで実行され、システム全体の合意形成がなされることを説明しました。
ステップ1: Endorsement (Transaction の内容について合意)
ステップ2: Ordering (Transaction の順序を確定しプロックを生成・配布)
ステップ3: Validation & Commit (Transaction の有効性を検証したうえで反映)
参考URL
Transaction Flow — hyperledger-fabricdocs main ドキュメント
Glossary (用語集) — hyperledger-fabricdocs main ドキュメント
