Fabric ブログ 2019/04/02

gistfile1.txt

Chris Ferris のブログで開発動向が紹介されている。
https://www.ibm.com/blogs/blockchain/2019/04/does-hyperledger-fabric-perform-at-scale/

- スケーラビリティの話には 2 つの次元がある。
- 一つは channel 数、peer 数、organization 数に基づく性能のスケーラビリティ。
- もう一つはチャネルやチェーンコードの管理のスケーラビリティ。
- 後者も重要で、Fabric の channel は sharding として使うこともでき、あるチャネルのトランザクションのロードが限界に近づいたら、別のチャネルに分離する選択肢がある。
- しかし v1.4 時点でも運用管理ツールはまだ発展途上で、運用管理の手間は大きい。
- v2.0 のベータ版が 5 月に予定されている。
- chaincode lifecycle が改善され、チャネルの生成・管理の手間が軽減される予定である。

- v1.4 系で性能・スケーラビリティのテストは実施されている.
- 32 organizations (26 banks, 6 auditors)、チャネルは全ての 2 bank ペアごとに生成、それぞれに 1 auditor が参加という状況。
- 各組織は 4 peer を運営していて、全て endorsor として動作する。
- peer 数は 128, チャネル数は N (N-1) / 2 だから N=26 で 325
- IBM cloud の kubernetes 上で、16CPU-16GB ディスクの worker node 上で動く、LevelDB を使用
- 2peer, 1 channel で 1k TPS、128peer, 325 channel で 13kTPS を達成したという。
- これは peer あたりに置き換えるとほぼ同等のスループット、1 channel あたり 2 peer なので 13k / (25/2) ~= 1k、つまりちゃんとスケールしている。

- 各 bank ペア間に全て channel を作成するというのはテストの便宜上で、実際は共有するデータの性質により決めればよい。
- チャネルに多数の組織を入れてアクセスコントロールはスマートコントラクトで実施するという方法もある。
- 最近入った idemix や private data collection もチャネル設計上の選択肢を増やしてくれている
- private data collection はトランザクションに関する小さなメタデータを秘匿するという思想で設計されているので、ドキュメントの秘匿のような大きなデータでの利用には向かない。
- collection の定義・管理に手間がかかるのが課題なので、新しい機能として implicit collection というのを検討しているという。
- そこではクライアントから事前設定なく秘匿データの共有先を指定することが可能になるという。
- ただ実現は 2020 年以降を予定しているようだ。
- このように privacy の調整が channel 分割以外にない、という状況は徐々に改善しつつある。
- v1.4.1 から Raft consensus がサポートされる、ordering service の非中央集権化を実現する。
- Kafka + ZooKeeper と比べて簡略化されるため、遅延の解消にもつながるようだ

   - Kafka: https://www.ibm.com/blogs/blockchain/wp-content/uploads/2019/04/HFScale4-768x233.png  
   - Raft:  https://www.ibm.com/blogs/blockchain/wp-content/uploads/2019/04/HFScale5-768x229.png
   - スループットは Kafka ~1kTPS/channel, Raft が ~2kTPS/channel
   - 遅延は Kafka: 平均 3-5 秒で最悪 10 秒程度, Raft: 平均 1 秒で最悪 2-3 秒