WIPHyperledger Fabricのコンセンサスアルゴリズム コンセンサスアルゴリズムとは
https://gyazo.com/3a299e6e44aac2f2daf382a2a1939c79
Hyperledger Fabricにおけるコンセンサスアルゴリズム
Hyperledger FabricではEndorsment、Ordering、Validiationの3つのプロセスを経て合意形成を行います。
https://gyazo.com/c9918b3bbc71bce511fa3fbed73cf1d0
Endorsment
上図の(1)、(2)にあたります。
1.クライアントから Peer に対して通信を開始します。
2. 通信の確認後、台帳のデータを参照するためのトランザクションを Peer に送信します。
3.Peer はトランザクションに含まれるクライアントの署名を検証し、
4.承認した時のみ、チェーンコードを実行して結果をクライアントに返します。
5.Query の場合はこの結果にクライアントが参照したい情報が含まれています。
Ordering
上図の(3)、(4)にあたります。
6. Peer からチェーンコードの実行結果を受け取ると、クライアントはトランザクションを Orderer に送信しましす。
7. Orderer は受け取ったトランザクションの順序付けをしてブロックを作成します。
8. Orderer は作成したブロックを送付します。
Validiation
上図の(5)にあたります。
9. Peer はブロックを受け取り、Endorsement Policy を満たすために必要な Endorsing Peer の署名が集まっているか、検証時とトランザクションの結果が変わっていないかを確認した上で台帳に書き込みます。 この時の検証を MVCC 検証 (MultiVersion Concurrency Control) と言います。 MVCC 検証は複数のリクエスト (Query/Invoke) を並列処理する際に、情報の一貫性を保証する仕組みです。
10. 最後に Peer は結果をイベントとしてクライアントに送信します。
Orderingノード間のコンセンサス
無許可型(Ethereum、 Bitcoin)
→確率的ファイナリティ
許可型(Hyperledger)
→決定的ファイナリティ
Ordering serviceのノードは多数のアプリケーションclientから同時にトランザクションを受信します。Ordering serviceのノードは協力してトランザクションの順序づけを行います。仕事としては提出されたトランザクションのバッチで処理します(実行順序を定義し、大量のデータをブロックに格納する)。Hyperledger Fabricにおいてはordering serviceによって作成されたブロックでファイナライズします。これは台帳内でのフォークがなく、書き換えられることがないからです。
Raft
Kafka/Zookeeper
Solo (dev限定)
Solo
ordering nodeは一つの前提で故障への耐性などは考慮しない。故に実際のプロダクション環境では使用できない(PoCや開発環境専用)。チュートリアルの設定はSoloになっている。テスト環境からそのまま商用化を検討している場合はRaftを単一ノードで運用することが推奨されている。
v1.4.1から登場。クラッシュ耐性(CFT) あり。“leader and follower” モデルを採用。チャネルごとにリーダーが選ばれ、フォロワーはリーダーの決定を承認する。Kafka/Zookeeperと類似しているが、相違点はorderindg serviceの運営にある。
“leader and follower” モデル
チャネル内のノードはリーダーを決める投票を行う。リーダーは新しいログを生成し、followerに伝搬するという責任を負います。FollowerはLeaderからlogsを受信し、決定的に検証する。また、Leaderから定期的に“heartbeat”と呼ばれるメッセージを受信し、故障してないか検証している。リーダーからメッセージを受信できない場合はもう一度選挙を行いリーダーを選出する。
チャネルごとに別々のRaftプロトコルのインスタンスを使用しており、チャネルごとにリーダーが存在している。
Kafka比較メモ
1. Kafkaと比べて設定が楽。
2. Kafka・ Zookeeperは小規模なネットワークで動くことが前提になっている。Kafkaクタスターをうごかすのは一つの組織のみ(単一障害)
3. Kafkaはオープンソースのapacheによってサポートされているが、RaftはFabricによってサポートされている
4. KafakaはKafka brokersというサーバーのプールを使いordererのorganizationのアドミンが特定のチャンネルないでいくつのノードを使用するかを決める。Raftはユーザーがどのチャンネルにどのノードが入るか決める。
Kafka/Zookeeper
Ordering Service の冗長化。Kafkaはスケーラビリティに優れた分散メッセージキューです。
Kafka は 4 台以上の構成が推奨され、ディスクにファイルとしてデータを保存して、クラスタ内でデータのレプリカを作成することも可能
Ordering Service は Kafka を使ってトランザクションの順番を定義
Zookeeper は分散システムを構築する上で、必要となる、データの同期、設定管理、参加者のグルーピング、名前管理等の機能を提供するサービス
Hyperledger Fabric で Zookeeper を利用する場合は 3,5,7 の奇数台数構成が推奨されます。7 台以上は性能があまり変わりません。
クライアントから送信されたトランザクションを Orderer が Kafka に送信して、Kafka にトランザクションを溜め込みます。 Kafka では送信されたトランザクションをチャネルごとに分けて管理をしています。
Orderer は Ordering Service を提供するノードを表しています。クライアント/Peer と Kafka 間のトランザクションを中継する役割を担っています。 溜め込んだトランザクションは一定量、もしくは一定時間が経過すると、一つのブロックにまとめられ、Committing Peer へ送信されます。
https://gyazo.com/69b6b6151e155e1e97d3f02bc97b99af
参考