Hyperledger Fabricアプリケーション設計入門ガイド

2019年7月20日

Hyperledger Fabricを利用したアプリケーション設計のポイントが簡潔にまとまっていて、参考になりました。サービス構成やブロックチェーンに何を書き込むか、という理解は深まりました。一方で、ブロックチェーンにどのような形式で残すか、エラーハンドリングはどうするか、という疑問は解消できませんでした。

参考になったこと

  • P.28 Fabric SDKのトランザクションフロー

図解がステキ。submitTransactionで何をやっているのか理解できました。

  • P.37 どのようなネットワークを構成するか
    • ブロックチェーンを生かすには個別管理か共同管理方式だけど、イニシアティブを取って進められる組織が必要。
  • P.43 ブロックチェーン台帳を利用するアプリケーションのあり方
    • Fabric SDKを利用するクライアントアプリケーションの信頼性自体も担保しないとダメ。
    • コンソーシアム型なので悪意をもったチェーンコードを実行されるリスクは低いけど。
  • P.52 データ設計:台帳と個別データストアの棲み分け
    • 証跡として残すデータに何かしらのコード情報があるのであれば、そのマスタも台帳に持っておく。
  • P.61 トランザクション設計:分散トランザクション設計
    • タイムアウト時のエラーハンドリングが大事。
    • チェーンに書き込まれたことをPeerからイベント通知を受け取ることも可能だが、しかし・・・。
  • P.69 Endorsement Policy設計
    • 基本的にはm out of n(n個のOrgのうちm個)のモデルで考える。
  • P.113 CouchDBのPhantom Read問題:説明2
    • Validation時にリッチクエリは再実行されない。あくまでEndorsement時にマッチしたレコードセットが更新対象になる。

あらかじめ公式サイトやIBM DeveloperのHyperledger Fabric入門を読んだあとに、IBM Blockchain Platformを触って試してみると理解が深まります。

IBM Blockchain Platformについてはこちらの記事を参考ください。

【Hyperledger Fabric】Windows上でVisual Stadio CodeのIBM Blockchain Platformプラグインを使ってみた

まだ良く分かっていないこと

  • ブロックチェーンレイヤーでもステートDBにクエリが投げられる。CouchDBが改ざんされた場合を考慮すると、台帳ってこれでいいんだっけ・・・?
  • データの耐改ざん性があっても、書き込むデータの真正性が担保できていないと意味が無い。様々なサービスは、どうやって課題解決しているんだろう。
  • 正常にブロックチェーンに書き込まれたか、CommitingPeerから結果通知(Event)を受け取ることができる。だがしかし、クライアント側からポーリングして確認するような機構が別途必要なのでは。