Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Hyperledger Fabicのネットワーク設計

gakumura
October 18, 2022

Hyperledger Fabicのネットワーク設計

2021/7/15 Blockchain GIG#10でしゃべった内容
→2022/10/18 Blockchain GIG特別編 HLF集中講義#2 Hyperledger Fabicのネットワーク設計 でリバイズ
Hyperledger Fabricのネットワークを設計していくにあたっての流れと考え方

gakumura

October 18, 2022
Tweet

More Decks by gakumura

Other Decks in Technology

Transcript

  1. Hyperledger Fabricの
    ネットワーク設計
    Blockchain GIG特別編 HLF集中講義#2
    中村 岳
    クラウド事業統括/クラウド・エンジニアリング統括/ソリューション・アーキテクト本部
    2022/10/18

    View full-size slide

  2. Copyright © 2022 Oracle and/or its affiliates
    2
    中村 岳
    Twitter @gakumura
    はてなブログ @gakumura
    …主にHyperledger Fabric関連
    • 現職:ソリューションエンジニア@日本オラクル
    • 担当:Oracle Blockchain Platform、
    Blockchain Table
    • 前職:金融決済系SIerでパッケージ開発
    • SWIFT、CLS、日銀ネット関連の銀行間決済システム

    View full-size slide

  3. Hyperledger Fabricをベースにエンタープライズ利用向けPaaSとオンプレミスで提供
    • 数ステップで構築完了、GUIコンソールで管理・運用も容易
    • エンタープライズグレードの耐障害制、堅牢性
    • マルチクラウド、ハイブリッドクラウド、
    オープンなネットワーク構成が可能
    • Oracle独自の付加価値:
    • State DBとしてBerkeley DBを利用:パフォーマンスとクエリ利便性向上
    • 多機能なREST API:スマートコントラクトの利用を容易に
    • 台帳のデータをRDBに複製:大量照会、分析、データ統合
    • スマートコントラクトを容易に開発:付属の開発ツールでアセット仕様からコードを自動生成
    • 複数ChannelのアトミックトランザクションとXA対応:複数Channelでの更新のアトミックな実行
    や、ローカルのDB、MQなどとのグローバルトランザクションをサポート
    Oracle Blockchain Platform
    Copyright © 2021 Oracle and/or its affiliates
    東京DCからも
    サービス提供中
    3

    View full-size slide

  4. • 10/11(火): Hyperledger Fabric(再)入門
    • コンポーネントやトランザクションフローなど基本を解説
    • 10/18(火):Hyperledger Fabricのネットワーク設計
    • ブロックチェーンネットワークの設計の考え方、進め方を解説
    • 10/25(火):Hyperledger FabricアプリとChaincodeの開発
    • クライアントアプリケーションとChaincodeの開発方法を解説
    • 11/1(火):Oracle Blockchain Platformを用いたHLFアプリ開発
    • Oracle Blockchain Platformならではのメリット、開発方法を解説
    集中講義シリーズ
    Copyright © 2022 Oracle and/or its affiliates
    4

    View full-size slide

  5. • はじめに;入門編の振り返り
    • 設計の前提を整理する
    • Hyperledger Fabricのネットワーク構
    成を設計する
    • パフォーマンスあれこれ
    • Chaincodeあれこれ…次回
    • 整合性あれこれ…次回
    内容
    Copyright © 2022 Oracle and/or its affiliates
    • メインのトピック
    • ↑の設計をやる上で把握してお
    いたほうがいい事項
    5

    View full-size slide

  6. Copyright © 2022 Oracle and/or its affiliates
    はじめに:入門編の振り返り
    6

    View full-size slide

  7. なぜ複雑なトランザクションやデータ構造などの仕組みが必要になるのか?
    • ブロックチェーン/DLTは一般に、
    (単一の管理体ではなく)複数の個人や組織が分散して所有・管理するノー
    ド間でのデータ複製を確実に行う
    という「お題」に取り組んでいる(と捉えられる)
    • 故障やミスだけでなく悪意にも備える必要がある
    • 他参加者のノードは不正に改造されたものかも
    • 他参加者がネットワークへの攻撃を試みるかも
    • 以下の要素の組み合わせで実現している(と整理できる)
    • データの耐改ざん性と検証可能性
    (→データ構造としてのブロックチェーン)
    • 状態遷移ロジックの事前定義
    (→スマートコントラクト)
    • トランザクション実行時合意
    (→トランザクションとコンセンサスのメカニズム)
    ブロックチェーン一般が取り組む共通の「お題」
    Copyright © 2022 Oracle and/or its affiliates
    Staten
    Staten+1
    Tx
    ノード
    Staten
    Staten+1
    Tx
    ノード
    State Machine Replication
    7

    View full-size slide

  8. ブロックチェーン一般の前提に加え、HLFの設計思想を抑えておく
    HLFの多くの機能や独特の仕様には、以下のような目的、背景があると考えると理解しやすくなる
    • 複数の企業/組織から成るコンソーシアム型のユースケースに最適化する
    • ネットワークの中で更にデータ共有範囲を分割/制御する
    • 重大なオペレーションの安全かつ分権したガバナンスを実現する
    • 耐障害性と可用性をブロックチェーン基盤の機能として確保する
    • ネットワークメンバー数とトランザクション処理能力のスケーラビリティを確保する
    Hyperledger Fabricの特色
    Copyright © 2022 Oracle and/or its affiliates
    8

    View full-size slide

  9. Orderer
    Organization配下にPeer、Orderer、CAのコンポーネントとクライアントアプリケーション
    Hyperledger Fabricネットワークの概観図
    Peer
    Client
    App
    CA
    Chain
    Code Ledger
    Orderer
    A社
    Orderer
    Peer CA
    Chain
    Code Ledger
    Orderer
    Orderer
    Orderer
    Peer
    Chain
    Code Ledger
    CA
    Orderer
    CA
    Orderer
    Peer
    Chain
    Code Ledger
    B社 D社
    C社
    Client
    App
    Client
    App
    Client
    App
    Copyright © 2022 Oracle and/or its affiliates
    9

    View full-size slide

  10. 流れと各フェーズの目的を理解しておく
    Endorsement:トランザクションの内容について合意する
    • クライアントアプリケーションからPeerにChaincode実行依頼(Transaction Proposal)を送付
    • PeerノードがChaincodeを実行(※)し署名を付けて結果(Endorsement)を返却
    • クライアントはEndorsement Policyで定められた必要な分のEndorsementを収集する
    (※)この時点では台帳に反映しないため「シミュレーション実行」と言われることもある
    Ordering:トランザクションの順序を確定しブロックを生成・配布する
    • Endorsementを集め終えたクライアントアプリケーションがTransactionを送付
    • 受け取ったOrdering ServiceがTransactionを詰めたBlockを生成、Peerノードに配布
    Validation:トランザクションの有効性を検証したうえで反映する
    • Peerがブロック内のTransactionを検証し台帳に反映(コミット)
    Endorsement・Ordering・Validationから成るトランザクションフロー
    Copyright © 2022 Oracle and/or its affiliates
    10

    View full-size slide

  11. ChannelはHLFの基礎の一部、Private Dataはオプショナル
    Channel
    ネットワークをサブネットワークに分割し、
    トランザクションそのものの(すなわち、そこで扱われる
    データの)共有範囲を限定
    Private Data
    Channel内で共有されるトランザクションのうち、一部
    のデータ項目を更に範囲を限定して共有できる
    ChannelとPrivate Data
    L1
    L2
    L3
    【お客様情報レコード】
    “ID : 1234567890”
    “生年月日 : 1987年1月1日”
    “性別 : 男性”
    “名前 : 鈴木太郎”
    “住所 : 東京都千代田区X-X-X”
    “電話番号 : 080XXXXXXXX”
    “契約コース : 従量制A”
    “契約日時 : 2019/1/21”
    Channel内の
    一部のメンバーのみ
    データを共有
    (他のメンバーには
    秘匿)
    Copyright © 2022 Oracle and/or its affiliates
    11

    View full-size slide

  12. Copyright © 2022 Oracle and/or its affiliates
    設計の前提を整理する
    12

    View full-size slide

  13. • はじめにブロックチェーンネットワークの構成を設計するにあたって必要な前提を整理しておく
    • この段階で必要なのは
    • ステークホルダーを特定する
    • ブロックチェーン上で扱う情報を大まかに整理する
    • 誰がブロックチェーンノードを所有するかを検討する
    • ここの流れにはFabric固有の要素は特になく、エンプラブロックチェーン一般で概ね共通と思われる
    設計の前提を整理する
    Copyright © 2022 Oracle and/or its affiliates
    13

    View full-size slide

  14. 凡例
    D社
    C社
    B社
    A社
    ノード
    コンソーシアム型ブロックチェーンのシステム概観
    Copyright © 2022 Oracle and/or its affiliates
    SC L
    ノード
    SC L
    ノード
    SC L
    ノード
    SC L
    個社
    アプリ
    ブロックチェーン
    プラットフォーム
    個社
    アプリ
    共有
    アプリ
    オペレーター
    他システム
    SC スマート
    コントラクト
    L 台帳
    14

    View full-size slide

  15. ブロックチェーン
    プラットフォーム
    凡例
    D社
    C社
    B社
    A社
    ノード
    1. システムのステークホルダーは誰なのか?
    Copyright © 2022 Oracle and/or its affiliates
    SC L
    ノード
    SC L
    ノード
    SC L
    ノード
    SC L
    個社
    アプリ
    個社
    アプリ
    共有
    アプリ
    オペレーター
    他システム
    SC スマート
    コントラクト
    L 台帳
    • 「誰に向けたシステムなのか」「誰が使うシステムなのか」
    は最初に明確にしておく
    • 当たり前のように聞こえるが、コンソーシアム型では
    この点が案外難しい
    • 言い換えると:
    • 解こうとしている課題の持ち主の特定
    • 生み出されるメリットを享受する者の特定
    • 初期の利用者となる組織の特定
    • 将来的な利用者となり得る組織、あるいは
    業種(役割)の構想
    15

    View full-size slide

  16. 凡例
    D社
    C社
    B社
    A社
    ノード
    2. ブロックチェーン上でどのような情報を扱うのか?
    Copyright © 2022 Oracle and/or its affiliates
    SC L
    ノード
    SC L
    ノード
    SC L
    ノード
    SC L
    個社
    アプリ
    ブロックチェーン
    プラットフォーム
    個社
    アプリ
    共有
    アプリ
    オペレーター
    他システム
    SC スマート
    コントラクト
    L 台帳
    16

    View full-size slide

  17. • ブロックチェーン台帳上(⇨ブロックチェーンプラットフォーム)で
    どのような種類の情報(データ)を扱うのかを洗い出しておく
    • この時点ではそれほど詳細になっていなくても良い
    • それらの情報について共有範囲と信頼のあり方を検討する
    • どの範囲で共有可能か(全体/一部/元の持ち主のみ)
    • 秘匿の必要があるか
    • 誰に対して秘匿されるべきか
    • 共有を必要とするのは誰か
    • 誰が/誰に対して不正な情報を示す動機があるか
    • 不正を働かないことは信頼可能か(検証しなくてもよいか)
    • これらがノードを誰が持つべきかの検討のインプットになる
    情報の種類の洗い出しと共有範囲、信頼の検討
    Copyright © 2022 Oracle and/or its affiliates
    L
    17

    View full-size slide

  18. 凡例
    D社
    C社
    B社
    A社
    ノード
    3. 誰がノードを持つのか?
    Copyright © 2022 Oracle and/or its affiliates
    SC L
    ノード
    SC L
    ノード
    SC L
    ノード
    SC L
    個社
    アプリ
    ブロックチェーン
    プラットフォーム
    個社
    アプリ
    共有
    アプリ
    オペレーター
    他システム
    SC スマート
    コントラクト
    L 台帳
    18

    View full-size slide

  19. ブロックチェーンノード所有/管理/運用のパターンはさまざま
    Copyright © 2022 Oracle and/or its affiliates
    分散 集中
    個別所有 部分共有 共有 専有
    Consortium Private
    19

    View full-size slide

  20. 凡例
    D社
    C社
    B社
    A社
    ノード
    アプリは?
    Copyright © 2022 Oracle and/or its affiliates
    SC L
    ノード
    SC L
    ノード
    SC L
    ノード
    SC L
    個社
    アプリ
    ブロックチェーン
    プラットフォーム
    個社
    アプリ
    共有
    アプリ
    オペレーター
    他システム
    SC スマート
    コントラクト
    L 台帳
    20

    View full-size slide

  21. 自前ノードで参加
    自身のノードによるネットワークに参加のみが利用の形態ではない
    「ブロックチェーンのシステムを利用する」モデル
    Copyright © 2022 Oracle and/or its affiliates
    ノード
    SC L
    アプリ
    ノード
    SC L
    アプリ
    ノード
    SC L
    アプリ
    他者ノードを通じて
    利用
    他者アプリを通じて
    利用
    21

    View full-size slide

  22. ノードを直接、自由に触れないことに伴う制約と利用先との信頼の問題
    • 利用先のノード or/and アプリの許す/提供する限りにおいてブロックチェーンプ
    ラットフォームの機能を利用することになる
    • 台帳上のデータ、およびスマートコントラクトロジックの検証可能性が限定され
    る(あるいは全くない)
    • 都合の悪い情報の書き込み/参照をフィルタリングされたり、虚偽の情報を示
    されたりする可能性がある(…ゲートキーパー)
    • 利用先との関係の悪化や、利用先自身の都合により利用が停止され、プラッ
    トフォームへのアクセスができなくなる可能性がある(…アクセシビリティ問題)
    • 使い勝手が利用先の提供サービスに左右される
    • 利用者がアクセスできる情報は基本的には利用先ノードの持ち主もアクセスできる
    ことになるため、秘匿性との折り合いが必要
    • 暗号化などで対処することは可能
    • SSoTとなるデータが自身の手元にない…法的な要件などとの適合性
    他者のノード を通じて利用する方式の留意点
    Copyright © 2022 Oracle and/or its affiliates
    ノード
    SC L
    アプリ
    他者ノード/アプリを
    通じて利用
    アプリ
    22

    View full-size slide

  23. ステークの大きさとのバランス、秘匿要件、信頼の問題を考慮
    • 自前のノードを持って秘匿性、アクセシビリティ、検証可能性を自身の手の内に確保するのは、ブロックチェーンを
    利用するシステムにとって本質的に重要な要素
    • システムの使い勝手の面でも自前ノードのほうが有利
    • 一方で、自前のノードを所有するには一定のコスト負担が、そして構築/管理/運用するには一定の能力が必要
    • 構築や運用はベンダーにアウトソースするのも選択肢となるが、結局運用コストはかかる
    • ステークが小さく、利用先との信頼の問題が折り合う場合は他者の/共有のノードを通じて利用するのも現実的
    なやり方
    • プラットフォームに対してのステークの大きさと負担が釣り合うように検討すべき
    • 最初から管理/運用の分散までを含めたフルスペックでスタートしなくてもよい
    • 後からより分散したかたちに移行していく(移行できる可能性を残す)アプローチも検討する
    • BaaS(Blockchain as a Service)を利用するなどしてノード所有/管理/運用に求められる能力のハー
    ドルを下げるのは、ブロックチェーンを利用するプラットフォームを成立させ、将来的に拡大させ、価値を増していくに
    あたって非常に重要
    ノードの所有、管理/運用は誰が担うべきなのか
    Copyright © 2022 Oracle and/or its affiliates
    23

    View full-size slide

  24. Copyright © 2022 Oracle and/or its affiliates
    Hyperledger Fabricネットワーク構成を
    設計する
    24

    View full-size slide

  25. Orderer
    Organization配下にPeer、Orderer、CAのコンポーネントとクライアントアプリケーション
    Hyperledger Fabricネットワークの概観図
    Peer
    Client
    App
    CA
    Chain
    Code Ledger
    Orderer
    A社
    Orderer
    Peer CA
    Chain
    Code Ledger
    Orderer
    Orderer
    Orderer
    Peer
    Chain
    Code Ledger
    CA
    Orderer
    CA
    Orderer
    Peer
    Chain
    Code Ledger
    B社 D社
    C社
    Client
    App
    Client
    App
    Client
    App
    Copyright © 2022 Oracle and/or its affiliates
    この範囲についてどう設計を進めていくべきかの流れを説明
    25

    View full-size slide

  26. 1. オンチェーンで扱うデータとビジネスロジックを整理する
    2. オンチェーンデータの共有範囲を整理し、実装方法を検討する
    3. Chaincodeを設計する
    4. Endorsement Policyを設計する
    5. Peerの冗長性を確保する
    6. Ordering Serviceの構成を設計する
    流れ
    Copyright © 2022 Oracle and/or its affiliates
    26

    View full-size slide

  27. • Hyperledger Fabricでは、全てのコンポーネントが
    いずれかひとつのOrganization(Org)に属する
    • 即ちノードを所有、管理/運用する組織はOrg
    • 単一の組織を複数のOrgにマッピングしても良い
    (BaaSの制約などの都合)
    • ノード非所有=非Orgの組織のプラットフォームの利
    用形態はどちらかになる
    • いずれかのOrgにクライアントユーザー(Fabric
    上のアイデンティティ)を払い出してもらい、自身
    のアプリでそのユーザーを利用してノードにアクセス
    • 単に他組織の提供するアプリケーションを利用
    Hyperledger Fabricでは…ノード運用に参加=Orgとして構成
    Copyright © 2022 Oracle and/or its affiliates
    27
    Peer
    SC L
    Client
    App
    Peer
    SC L
    Client
    App
    他者ノードを通じて
    利用
    他者アプリを通じて
    利用

    View full-size slide

  28. • 改めてブロックチェーンプラットフォーム上で扱う情報を整理する
    • 共有するデータについては、項目まで具体的、詳細に特定する
    • オンチェーンでのデータ共有は台帳(World State+Blockchain)と
    Private Dataいずれかで行うことになる
    • 場合によりオフチェーン共有ストレージを使う必要も発生する(個人情報、
    サイズの大きなファイルなど)
    • アプリケーション側で個別に持つデータはスコープ外
    (アプリケーション個別の検討が必要になるため後回し&個別検討)
    • 加えて、オンチェーンのデータに対しての操作(ビジネスロジック)を洗い出す
    • Chaincodeとして実装されるべきビジネスロジックはなにか?
    • アプリケーション個別のロジックとしてよいものを除いていく
    1. オンチェーンで扱うデータとビジネスロジックを整理する
    Copyright © 2022 Oracle and/or its affiliates
    アプリケーション
    Peer
    Chaincode
    Ledger
    Private
    Data
    オフチェーン
    共有
    ストレージ
    アプリ個別の
    ロジック
    個別
    データ
    ストア
    個別
    共有
    28

    View full-size slide

  29. 個人情報(PII)に注意
    • 個人情報保護法、GDPRなどの法規制
    • 「削除して」と言われても台帳に書いてあると消せない
    • Private Dataであれば削除(パージ)可能
    • オフチェーン共有ストレージに書いて受け渡し、もよくあるやり方
    サイズに注意
    • 画像イメージや文書ファイルなど、サイズの大きいデータの保管には向かない
    • ×:ファイルそのものを保存
    • ○:ファイルそのものはオフチェーン共有ストレージに配置し、
    台帳にはそのファイルへの参照情報(ID&URLなど)と内容のハッシュ値を保存
    • 台帳への書き込み内容はネットワークを伝播するため、パフォーマンスへの影響が大きい
    • 特にトランザクションボリュームが多い場合は注意
    • 略語を使用してチャネル名や変数名を縮めるなどの細かい努力(Name⇒Nm、Number⇒Numなど)
    台帳に載せるべきでないデータ、向かないデータの考慮
    Copyright © 2022 Oracle and/or its affiliates
    29

    View full-size slide

  30. Chaincodeとアプリケーションでロジックの分担を検討
    • Chaincodeは複雑でコストの重い処理、広い範囲のデータを一括で読み書きする処理にはあまり向いていない
    • Endorsementでは複数Peerでロジックが冗長に実行される
    • State DBはRDBと同じようには使えない…大規模集計、分析は得意ではない
    • トランザクションフローの仕組み上、1トランザクションに大量のRWSetが含まれると他のトランザクションと衝突しや
    すく、結果的に処理性能に問題が発生しやすい
    • 必要な場合はバッチとして切り出して他のトランザクションに影響を与えないように実行する
    • Chaincodeで実現できない/実現が困難な機能は検討に先立って把握しておく必要がある(次回説明)
    • 「Chaincodeにないと困る」機能以外はクライアントアプリケーション側に配置する方向で検討
    • Chaincodeに必須なのはWorld StateとPrivate Dataの更新機能
    +更新の中で必要な参照機能(条件評価など)
    +基本的なクエリのための機能
    オンチェーンのビジネスロジックの範囲
    Copyright © 2022 Oracle and/or its affiliates
    30

    View full-size slide

  31. RDBに複製することでデータ活用の幅、利便性を向上
    • オンチェーンデータをRDBに複製するパターン/テクニックが多くの場合(ほぼ?)使われている
    • 複製したDB上のデータをアプリから参照する、高度な検索や大規模集計/分析をBIツールで行う、他のデータと
    データ統合するなど
    • HLFに限らず(また、エンプラBCに限らず)使われるパターン/テクニックでもある
    • ブロックチェーンユースケースの中心はデータなので、データの活用可能性、使い勝手は非常に重要
    • 方式としては①Event経由で受け取ったデータを蓄積する②Chaincodeでクエリして取得したデータを蓄積する③
    BlockchainからTxを読んでいって逐次反映していく④State DBを直接読む あたり
    • オンチェーン⇔複製で齟齬が発生しないように(齟齬を修正できるように)実装する必要がある
    • 【PR】Oracle Blockchain PlatformにはオンチェーンデータをOracle Databaseに複製する機能あり
    Tips:オンチェーンデータのオフチェーンデータベースへの複製
    Copyright © 2022 Oracle and/or its affiliates

    ブロックチェーン:
    トランザクション
    と値の履歴を格納
    State DB
    (World State):
    現在の値を格納
    台帳(Ledger)
    複製
    31

    View full-size slide

  32. • オンチェーンデータに対して、可視範囲と秘匿性要件を整理する
    • 「A社」や「B社」など具体的な参加者ごとに区切っていくパターンと、
    「製造元」や「配送業者」、「納入先」のようにアセットから見ての役割で区切っていくパターンがある
    • あるデータについて項目レベルで範囲が変わる場合はそれらも定義する
    • 適切な実装方法を検討する。選択肢は:
    • Channelを分割する
    • Private Dataを使う
    • 暗号化して受け渡しする
    2. オンチェーンデータの共有範囲を整理し、実装方法を検討する
    Copyright © 2022 Oracle and/or its affiliates
    データ/項目 原料 製造 小売
    最終製品 × ○ ○
    /識別ID × ○ ○
    / × ○ ○
    部品 ○ ○ ○
    /識別ID ○ ○ ○
    /品質スコア ○ ○ ×
    32

    View full-size slide

  33. • トランザクション(で扱うあるデータの単位)自体はChannel内のメンバー全体に共有するが、その中のある項目を限
    られたn者間に秘匿したい、という用途に使える
    • トランザクション内容の秘匿性についてはPrivate Dataの利用を基本に検討する
    • Private Dataのハッシュ値がChannel内メンバーに共有されるため検証可能性が損なわれないこと、同一
    Channel内であればPDCまたぎのトランザクションも実行可能なことなど、Channelを分割する場合に比べてデメ
    リットが小さい
    • Purgeもできるのでリクエストに応じてオンデマンドデータの受け渡し(⇨HLFを単にメッセージングレイヤーとして使う)
    のような用途にも使いやすい
    Private Dataを使う
    Copyright © 2022 Oracle and/or its affiliates
    OrgA Peer OrgB Peer OrgC Peer
    Channel 1
    L1
    PD1
    L1 L1
    Private Data
    Collection 1
    PD1
    33

    View full-size slide

  34. • トランザクションの存在そのものを秘匿したいケースではChannelによる分割
    が有効
    • トランザクションの量、頻度から何らかの情報が推測されてしまうことを防ぐ
    • トランザクションの存在から取引関係など、n者間の関係性が他の参加者
    にリークしてしまうことを防ぐ
    • 必要なn者間Channelだけ用意する運用だと、Channelの存在自体が関係
    性をリークしてしまう
    • 関係性を秘匿したい場合には使用しないn者間のChannelも用意してお
    く必要性
    • Channelまたぎのビジネストランザクションは普通にやると一貫性、整合性を担
    保することが難しい、また、両方のChannelに参加しているメンバー以外には検
    証可能性がないことは抑えた上で検討
    • 秘匿性担保上、およびパフォーマンスチューニング余地拡張上の効果が大き
    いが、コストも大きい選択肢
    Channelを分割する
    Copyright © 2022 Oracle and/or its affiliates
    Org
    A
    Org
    B
    Org
    C
    34

    View full-size slide

  35. • ブロックチェーン上に暗号化したデータを書き込み、意図した相手(復号鍵の所
    有者)にのみ内容が見られるようにするアプローチ
    • 共有範囲ごとにChannelやPrivate Data Collectionを切らなくていいため
    HLFの構成がシンプルになる
    • 復号鍵の漏洩リスクに注意:台帳上で既に共有されている既存データは更新で
    きないため、復号鍵が漏洩した場合には漏洩先にそれまでのデータを全て復号さ
    れてしまう
    暗号化して受け渡しする
    Copyright © 2022 Oracle and/or its affiliates
    Org
    A
    Org
    B
    From: A
    To: B
    Content: XXXXXX←暗号化
    Org
    C
    復号可能 復号不能
    35

    View full-size slide

  36. • 「あるメンバーに読み取りはさせたいが更新はさせたくない」という要件が存在する場合には、
    Chaincode内でアクセス制御ロジックを作り込むことで対応する
    • Chaincode内でトランザクション実行者のIdentityを取得できる(CID;Client
    Identityライブラリ)ので、そのIdentityのOrganization(MSP)によって制御する
    • 関数単位で利用可否(⇨あるデータについてputState,putPrivateDataする関数を
    使えるかどうか)を制御するのが基本
    • よくある疑問:Chaincode内のアクセス制御ロジックを使い「読み取りパーミッションを付与し
    ない」ことで秘匿性を実現できるのでは???
    ⇨ノードの持ち主はChaincode内部で読み取る以外の方法(Block内のTxを読むな
    ど)でバイパスできるので基本的には使えない
    • なお、Channel Policyで設定できるOrganizationのWriter権限は「World Stateや
    Private Dataを更新できるか」ではなく「ChaincodeをInvokeできるか」の権限(Queryも
    できなくなる)なので名前に騙されないように…
    Tips:更新パーミッションの制御
    Copyright © 2022 Oracle and/or its affiliates
    Org
    A
    Org
    B
    Chaincode
    関数
    アクセス制御
    Ledger
    Private
    Data
    36

    View full-size slide

  37. Chaincodeのオンチェーンアクセス権限制御ライブラリを提供
    • ACLを台帳上に記載したうえで(On-chain ACL)、
    ACLを参照してChaincodeロジックのアクセス制御する
    • Chaincode自体のアップデートをすることなく、
    動的にACLを更新できるメリット
    以下の要素で権限を制御
    • リソース:アクセスを制御する対象
    • アイデンティティ:アクセスする企業やユーザー
    • グループ:アイデンティティのグループ
    • アクセス制御リスト:
    • どのアイデンティティ/グループに
    • どのリソースに対し
    • どのような操作(CREATE、READ、UPDATE、DELETE、etc.)を
    • 許可する/しない
    【参考】 更新パーミッション制御の例:
    Oracle Blockchain PlatformのFine Grained On-Chain Access Control
    Copyright © 2022 Oracle and/or its affiliates
    詳細は以下のドキュメントを参照:
    https://docs.oracle.com/en/cloud/paas/blockchain-cloud/usingoci/using-fine-grained-access-control-library.html
    37
    37

    View full-size slide

  38. Fine-Grained Access Controlライブラリの利用イメージ
    Copyright © 2021 Oracle and/or its affiliates
    Ledger
    Chaincode Identity: O=OrgA,
    CN=UserA1
    業務関数
    ACL
    チェック
    FGAC





    ACL管理
    関数
    業務データ
    ACL関連データ
    リソース グループ
    ACL
    Identity: O=OrgB,
    CN=UserB1
    アクセス権限制御のため
    のデータを台帳上で管理
    Chaincode関数内で
    権限チェックを実施
    Chaincode呼び出しの
    Identity(証明書)を組
    織レベルやユーザーレベ
    ルでグループ化して制御
    ACLの管理に関わる機能も関数として実装し、
    ACL管理関数の権限もACLで管理
    38

    View full-size slide

  39. Chaincodeのロジックの内容
    • ここまでの検討で概ね決まっているはずなので、基本的には素直に設計していくだけ
    • 改めてChaincode独特の制約や留意点には引っかからないようにチェック(後の章で説明)
    • なんらかの問題により適切な実装が困難と考えられる場合には、アプリケーションロジック側に切り出せないかを再検討
    する、ChannelやPrivate Dataの構造から再検討するなどして対処が必要
    Chaincodeのモジュール分割の粒度
    • 複数の種類の業務を単一Channel内で扱う場合には、それぞれでChaincodeを分けておくことでEndorsement
    Policyの設計やChaincode Lifecycleが運用しやすくなる
    • あまり細かく分割しすぎると依存関係が複雑になり、Peerへの各Chaincodeインストール要否やPeer冗長性の検討、
    各ChaincodeのEndorsement Policy間の整合性が複雑になるのでほどほどに…
    3. Chaincodeを設計する
    Copyright © 2022 Oracle and/or its affiliates
    39

    View full-size slide

  40. • Endorsement Policyを設定できるレベルは以下3つ(下位の定義がOverrideし、複数のCollection Level/
    State-basedポリシーが絡む場合は集積して評価される)
    • Chaincode Level:Chaincodeインスタンスごとに設定する(Instantiate時パラメータ/Chaincode
    Specの中で指定)
    • Collection Level:Private Data Collectionごとに設定する(同上)
    • State-based:World State/Private Dataの特定のKeyを指定して設定する(World State/
    Private Dataと同様にトランザクションで更新できる)
    • あんまり凝ったことをやると必要なPeer冗長性の検討が難しくなるので必要な範囲で……
    • 単一のPeerノード内の不正に改造されたロジックによる更新の受け入れを防ぐため、2者以上のEndorsementを
    要求することが望ましい
    • n>3以上のn OutOfが必要か、特定のOrgを指定する必要があるかは参加者間の信頼のあり方次第
    • 多くの場合はそれほど多数のEndorsement要求は不要なのでは?
    • Endorsement要求数増は性能上はネガティブな要素
    4. Endorsement Policyを設計する
    Copyright © 2022 Oracle and/or its affiliates
    40

    View full-size slide

  41. 5. Peerの冗長性を確保する
    ノード、台帳の冗長性確保の必要性
    • 「ブロックチェーンではノードが複数あるので冗長性が担保されていて障害に強
    い!
    互いがバックアップになり台帳のデータが失われる心配がない!」
    • パーミッションレス/パブリック型のブロックチェーンの場合はこの言及は概ね
    正しい
    • パーミッションド/コンソーシアム型では必ずしも当てはまらない
    • コンソーシアム型ネットワークの場合、しばしばあるノードは他ノードと役割
    (権限、責任)が等価ではないので互いに代替にならない
    • あるノードが持つ台帳のデータサブセット(Tx履歴とStateのサブセット)もし
    ばしば他ノードとは異なるのでそのままではバックアップにならない
    Copyright © 2022 Oracle and/or its affiliates
    クライアント
    ノード
    B
    ノード
    A
    他ノードで
    代替可
    台帳を
    Fetchして
    復旧可
    クライアント
    ノード
    B
    ノード
    A
    他ノードで
    代替不可
    台帳を
    Fetchして
    復旧不可
    役割/台帳が同じ場合
    役割/台帳が違う場合
    41

    View full-size slide

  42. 5. Peerの冗長性を確保する
    Hyperledger Fabricでのアプローチ
    • 基盤機能として役割&所有データサブセットが等価のノードを複数構成しておくことができることがHLFの強み
    • 他のブロックチェーン/DLT基盤だと通常のインフラアプローチで個々のノード/バックエンドDBの可用性/耐障害
    性を確保しておく必要がある
    • HW障害等でPeerノードおよびState DBが消失しても、自Org所有、また、他Org所有のPeerノードから台帳およ
    びPrivate Dataをfetchすることでリカバリ可能
    • 既存のPeerをリカバリする方法、新規Peerを追加する方法どちらも取れる
    • ネットワーク全体のスコープで複数Peerノードが同一Channelに参加している&&同一Private Data Collectionを持
    つ&&同一の役割を持つように構成しておくことで冗長性を確保しておく
    Copyright © 2022 Oracle and/or its affiliates
    42

    View full-size slide

  43. Organizationの役割を整理する
    5. Peerの冗長性を確保する
    Copyright © 2022 Oracle and/or its affiliates
    Org
    Channel X Channel Y
    参加
    CC X
    参加
    CC Y1 CC Y2
    Endorse PDC X1 PDC X2 Endorse Endorse
    Org A ○ 必須 ○ ○ ○ 2 OutOf OR(A,B)
    Org B ○ 1 OutOf ○ ○ 2 OutOf OR(A,B)
    Org C ○ 1 OutOf ○ ○ × ×
    Org D × ○ 2 OutOf 必須
    ここまでで切り出されてきたデータサブセット、役割を整理した上で、Organizationを軸に付与状況をまとめる
    • どのデータサブセットを持っているか:Channelへの参加、PDCへの参加
    • どのような役割を持っているか:Chaincode Level/Collection Level/State-basedのEndorsement、(作
    成していれば)更新権限などのカスタムアクセス制御上の権限など
    43

    View full-size slide

  44. 各OrgでPeerの役割を検討し、ネットワーク全体で整理する
    • 各Orgで用意するPeer数、PeerごとのChannelへの参加/不参加とChaincodeのInstall有無
    (Endorsementに参加できるかどうか)を一旦検討し、それらをマージした上でネットワーク全体でPeerの冗長性
    が不足ないかをOrganization役割に照らしてチェックする
    • ある役割に対してOrg内でPeerが冗長になっていると運用面での考慮が楽になる
    • 冗長性が増す方向での追加、調整はあとから各Orgで個々に実施して良い
    • パフォーマンスの改善のためにPeerを追加してスケールアウトしたり役割を分散させたりする必要が生じる場合があ

    • インフラの冗長性、地理分散などが必要な場合はここで各Peerの所在を加味して検討する
    5. Peerの冗長性を確保する
    Copyright © 2022 Oracle and/or its affiliates
    Org Peer
    Channel X Channel Y
    参加
    CC X
    参加
    CC Y1 CC Y2
    Install Install Install
    Org A A1 ○ ○ ○ × ○
    A2 ○ × ○ ○ ×
    A3 ○ ○ ×
    A4 × ○ ○ ○
    44

    View full-size slide

  45. • ChannelごとにOrdering Serviceクラスタを構成する(ChannelごとにOrderingに参加するOrdererを指定す
    る)
    • OrdererにはそのChannelのTransactionが蓄積していく=Ordererの持ち主はそのChannelの台帳の内容を
    ほぼ把握できる(Private Data内容はOrdererに行かないので読めない)
    • 基本的にはそのChannelにPeerを参加させているOrgのOrdererでOrdering Serviceを組んでいく
    • コンソーシアムの成り立ちによってはOrderer専任Orgを設ける例も
    耐障害性
    • Orderingには半数以上(>n/2+1)のOrdererが正常に機能していることが必要
    • Ordering Serviceのクラスタ構成変更にも同様の条件
    • 半数のOrdererがロストして復旧不能になると当該Channel機能のリカバリが非常に困難になる
    性能とのバランス
    • Ordererが増えるとコンセンサスオーバーヘッドが増え、Orderingの処理性能は低下する
    • 一定数以上増やすと耐障害性のメリット<性能上のデメリットになる
    • Orderer数は3、5、7台のどれかとする例が多い(偶数にすると1台無意味なので避ける)
    6. Ordering Serviceの構成を設計する(Raft前提)
    Copyright © 2022 Oracle and/or its affiliates
    45

    View full-size slide

  46. Orderer
    Organization配下にPeer、Orderer、CAのコンポーネントとクライアントアプリケーション
    Hyperledger Fabricネットワークの概観図
    Peer
    Client
    App
    CA
    Chain
    Code Ledger
    Orderer
    A社
    Orderer
    Peer CA
    Chain
    Code Ledger
    Orderer
    Orderer
    Orderer
    Peer
    Chain
    Code Ledger
    CA
    Orderer
    CA
    Orderer
    Peer
    Chain
    Code Ledger
    B社 D社
    C社
    Client
    App
    Client
    App
    Client
    App
    Copyright © 2022 Oracle and/or its affiliates
    だいたい設計できそう!!!
    46

    View full-size slide

  47. Copyright © 2022 Oracle and/or its affiliates
    パフォーマンスあれこれ
    47

    View full-size slide

  48. • スループット、ターンアラウンドタイムについてそれぞれ実現可能な規模感を把握しておき、それに照らして要求が厳しい
    と思われる場合には注意しておく
    • ターンアラウンドタイム:ここではクライアントアプリケーションがTransaction Proposalを送信してからPeerでの
    valid/committedイベント通知が届くまで
    • おおよそ0.x秒後半を見込んでおくとベター
    • ロジックの内容と環境条件によっては、また、スループットに最適化するともっと長くなる場合はある
    • スループット:ここではあるChannelで1秒間に有効なトランザクションを処理できる件数(TPS)
    • 複数のChannelから成るネットワーク全体でのスループットはあまり考える意味がない
    • トランザクションはChannelごとに別々なので、処理を分散できる
    • 台帳を更新しない(OrdererにTxを送信しない)Peerへのクエリ件数はカウント外
    • クライアント⇔Peerのローカルな範囲の話
    • トランザクションの内容によって大いに変わるので事前に見込みが立ちづらい
    • 数千TPS出たよというペーパーはいくつかあるが、あくまで限定的な条件下なので鵜呑みにしない
    • ~数十はまあリーズナブルかな、~数百で最初から性能要件について注意と努力が必要だな、
    千~くらいで細心の注意と大きな努力が必要、くらいのイメージ(個人的な感想)
    パフォーマンスの目安と向上のための施策
    Copyright © 2022 Oracle and/or its affiliates
    48

    View full-size slide

  49. トランザクションのターンアラウンドタイム
    クライアントから見たときの
    ターンアラウンドタイムとは:
    Transaction Proposalを送信~Peerでの
    valid/committedイベント通知が届くまで
    ターンアラウンドタイム
    Copyright © 2022 Oracle and/or its affiliates
    49

    View full-size slide

  50. ターンアラウンドタイムの内訳
    内訳としては2段階:
    • Transaction Proposalを送信してから必要
    なEndorsementが集まるまで
    • Transactionを送信してからPeerでの
    valid/committedイベント通知が届くまで
    ターンアラウンドタイム
    Copyright © 2022 Oracle and/or its affiliates
    50

    View full-size slide

  51. 前半部分:トランザクションのEndorsementフェーズ
    要素:各Endorsing Peerの
    • クライアントとのメッセージ往復時間
    • Chaincode実行時間
    ☆最も遅い応答に依存
    改善材料:
    • PeerのEndorsement負荷分散
    • Endorsement要求数を減らす
    • ネットワーク遅延を減らす
    • Peerのリソース(CPU/メモリ/IO)を増やす
    • Chaincodeの内容を見直す
    ターンアラウンドタイム
    Copyright © 2022 Oracle and/or its affiliates
    51

    View full-size slide

  52. 後半部分:トランザクションのOrdering+Validation/Commitフェーズ
    要素:
    • メッセージ、ブロック、イベント伝送時間
    • Ordering Serviceでのブロック生成時間
    • Committing PeerでのValidation/Commit時間
    改善材料:
    • Ordering Serviceのブロック生成設定を見直す
    • バッチタイムアウト時間を減らす
    (デフォルト2秒になってるので…)
    • Ordering Serviceの構成Ordererを見直す
    • Ordererを減らす
    • Ordererの負荷分散
    • ネットワーク遅延を減らす
    • Ordererのリソース(CPU/メモリ/IO)を増やす
    • Peerのリソース(CPU/メモリ/IO)を増やす
    ターンアラウンドタイム
    Copyright © 2022 Oracle and/or its affiliates
    52

    View full-size slide

  53. • Ordering Serviceは主にふたつの設定値を参照し、①か②の条件
    を満たされた時点でブロックを生成する
    ① BatchSize:ひとつのブロックにいくつのトランザクションを詰め込
    むかの数(デフォルト10)
    ② BatchTimeout:あるブロックのひとつめのトランザクションを受け
    取ったあと、BatchSizeが満たされない場合にブロックを生成する
    までの締め切り時間(デフォルト2000ms=2秒)
    • 設定だけで行えるチューニング項目なので覚えておく/まず試す
    • 過度に細かくブロックを生成、配布するとOrdererおよびPeerの
    処理の負荷とネットワーク帯域への負荷が上昇する
    • 大きすぎる設定はターンアラウンドタイムの分散、遅延につながる
    • 例:Txによってブロック生成を2秒待たされたり、すぐ生成されたりする
    Ordering Serviceの設定
    Copyright © 2022 Oracle and/or its affiliates
    53
    Tx
    Tx Tx Tx Tx
    Tx
    Tx Tx Tx Tx
    Tx
    BatchSize=10
    BatchTimeout=2000ms
    Txひとつしかないけど
    時間切れなのでブロック作ろ
    まだ時間切れじゃないけど
    Txの数Maxなのでブロック作ろ
    Tx
    Tx

    View full-size slide

  54. 必要な性能要件とボトルネックを見極めた上で手当てしていく
    ボトルネック箇所の特定:
    • Chaincodeの実行(Endorsement)
    • Ordering
    • Validation/Commit
    ベンチマークツール:
    • Hyperledger Caliperが代表的なツール
    • 他にPTE(Performance Traffice Engine)、
    BlockBenchなど
    主なスループットの改善要素:
    • PeerのChaincode実行時間を減らす
    • Chaincodeのロジックを改善
    • Peerのリソース(CPU/メモリ/IO)を増やす
    • PeerのChaincode実行(Endorsement)の負
    荷を分散する
    • Ordering Serviceの見直し
    • バッチタイムアウト時間とバッチサイズを増やす…ターンアラ
    ウンドタイムとトレードオフ
    • Ordererを減らす
    • Ordererの負荷分散
    • Ordererのリソース(CPU/メモリ/IO)を増やす
    • PeerのValidation/Commitの負荷を分散する
    • ネットワーク遅延を減らす
    スループット
    Copyright © 2022 Oracle and/or its affiliates
    54

    View full-size slide

  55. Validation/Commitの負荷分散
    • Validation/Commitの処理量はPeerの参加するChannelでのトランザクション数に依存
    • Peerごとに参加するチャネルを分け、トランザクション数を平準化させる
    スループット
    Peer
    CH1 CH2 CH3
    Block
    Peer
    CH1
    Block
    Peer
    CH2
    Peer
    CH3
    Block Block
    Copyright © 2022 Oracle and/or its affiliates
    55

    View full-size slide

  56. Endorsement負荷分散:Peer側の役割分担
    • Chaincodeでの役割分担:PeerごとにインストールするChaincodeを分けておく
    • チャネルでの役割分担:Peerごとに参加するチャネルを分けておく
    スループット
    Peer
    CH1
    CC1
    CC2 CH2
    Proposal
    Peer
    CH1
    CC1
    Peer
    CH2
    CC1
    Peer
    CH1
    CC2
    Peer
    CH2
    CC2
    Prop
    osal
    Prop
    osal
    Prop
    osal
    Prop
    osal
    Copyright © 2022 Oracle and/or its affiliates
    56

    View full-size slide

  57. Endorsement負荷分散:クライアント側のリクエスト戦略
    クライアント側のTransaction Proposalをの分散
    候補のOrg、Peerから単純にラウンドロビンやランダムでリクエスト先を選ぶ
    Chaincode/チャネルでの役割分担を依頼側で行うことも可能
    他参加者も同様のリクエスト戦略で行わないと平準化できない
    スループット
    Peer
    Peer
    Peer
    Peer
    Peer
    Peer
    Peer
    Peer
    Copyright © 2022 Oracle and/or its affiliates
    57

    View full-size slide

  58. • トランザクションフローにおけるRead-Set Validationの関係で、同一の(Keyの)レコードを複数トランザクションが一定以上の
    高頻度で更新することができないという制約がある
    • あるレコードを複数のトランザクションが高頻度に更新しようとする場合、Endorsement~Validationのターンアラウンドタイム
    より間隔が短いと無効になるトランザクションが出てくる
    • この制約が弱みになる苦手パターンがあることは覚えておいたほうがよい
    • 典型的には「単一口座から高頻度で送金」のユースケース(支払いでマイナスにならないか現残高のチェックが必要)だとこれ
    がネックになりやすい
    • なお、「単一口座に高頻度で入金」なら回避できる(現残高チェックはいらないので入金額を別のレコードで記録しておき折を
    見て集計すればよい)ことにも留意
    • 同一のレコードを更新するトランザクションの密度が濃いと、Invalid(Read Conflictエラー)になるトランザクションの割合が増えて
    結果的にスループットが悪化する
    • 時々Invalidになること自体はクライアントがProposalから再トライすれば良いだけで問題ない
    • 密度が濃くInvalidが多発する場合、再トライも増えてますます密度が濃くなる悪循環に陥る
    同一レコードについての更新スループット追及上の限界
    Copyright © 2022 Oracle and/or its affiliates
    58

    View full-size slide

  59. 同一レコードに対して頻繁に読み書きするとタイミング次第でしばしば発生する
    Read-Set Validationで無効になるパターンのシーケンス
    Copyright © 2022 Oracle and/or its affiliates
    レコード x
    Tx1
    Tx2
    Read(x)
    Read(x)
    RS-V (x) Write(x)
    RS-V(x)
    version=n
    version=n?
    OK
    version=n
    version=n?
    NG
    Endorsement Ordering Validation
    Endorsement Ordering Validation
    version=n+1
    59

    View full-size slide

  60. つまり…?
    Copyright © 2022 Oracle and/or its affiliates
    60
    あるレコード(Key)の
    値(Value)は
    1度に1トランザクションしか
    更新できない
    複数クライアントが
    同時に同一のレコードを
    更新を試みることが
    あり得るパターンには注意

    View full-size slide

  61. スループット向上のための独自のトランザクション最適化
    • Oracle Blockchain Platform付属の開発ツールBlockchain App Builder(後述)は
    Fungible Token(お金やポイントなどの数量で表されるアセット)のChaincode開発にも対

    • 口座と残高からなるAccount/Balanceモデルで表現
    • 生成、送付、分割、保留、破棄などの振る舞いをサポート
    • Hyperledger Fabricでトークンを扱う際に制約となる、トランザクションのMVCCに係るRead
    Conflictエラー多発問題を独自の改善で解消
    • Blockchain App Builderで生成したトークンChaincode専用のオプションを有効化すると
    MVCCを最適化し、スループットを改善
    • 「Fungible Tokenの残高」に関しては通常のRead-Set Validationはバイパスし、特別なValidationを
    行う
    • オリジナルHyperledger Fabricでは苦手だった、同一口座の高頻度の入出金を含むユース
    ケースを扱うことが可能に
    【PR】Oracle Blockchain PlatformのFungible Tokenの改善点
    Copyright © 2022 Oracle and/or its affiliates
    61
    詳細は以下のブログを参照:
    https://blogs.oracle.com/blockchain/post/obptokenoptimization
    61

    View full-size slide

  62. Copyright © 2022 Oracle and/or its affiliates
    まとめ
    62

    View full-size slide

  63. • はじめに;入門編の振り返り
    • 設計の前提を整理する
    • Hyperledger Fabricのネットワーク構
    成を設計する
    • パフォーマンスあれこれ
    • Chaincodeあれこれ…次回
    • 整合性あれこれ…次回
    内容
    Copyright © 2022 Oracle and/or its affiliates
    • メインのトピック
    • ↑の設計をやる上で把握してお
    いたほうがいい事項
    63

    View full-size slide

  64. • はじめにブロックチェーンネットワークの構成を設計するにあたって必要な前提を整理しておく
    • この段階で必要なのは
    • ステークホルダーを特定する
    • ブロックチェーン上で扱う情報を大まかに整理する
    • 誰がブロックチェーンノードを所有するかを検討する
    • ここの流れにはFabric固有の要素は特になく、エンプラブロックチェーン一般で概ね共通と思われる
    設計の前提の整理
    Copyright © 2022 Oracle and/or its affiliates
    64

    View full-size slide

  65. 1. オンチェーンで扱うデータとビジネスロジックを整理する
    2. オンチェーンデータの共有範囲を整理し、実装方法を検討する
    3. Chaincodeを設計する
    4. Endorsement Policyを設計する
    5. Peerの冗長性を確保する
    6. Ordering Serviceの構成を設計する
    ネットワーク設計の流れ
    Copyright © 2022 Oracle and/or its affiliates
    65

    View full-size slide

  66. Thank you
    Copyright © 2022 Oracle and/or its affiliates
    66

    View full-size slide