Hyperledger Fabicのネットワーク設計

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

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

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

• 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

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

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

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

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

流れと各フェーズの目的を理解しておく 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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 他者ノードを通じて利用他者アプリを通じて利用

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

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

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

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

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

• トランザクション（で扱うあるデータの単位）自体は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

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

• ブロックチェーン上に暗号化したデータを書き込み、意図した相手（復号鍵の所有者）にのみ内容が見られるようにするアプローチ • 共有範囲ごとに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

• 「あるメンバーに読み取りはさせたいが更新はさせたくない」という要件が存在する場合には、 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

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

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

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

• 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

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

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

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

各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

• 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

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

• スループット、ターンアラウンドタイムについてそれぞれ実現可能な規模感を把握しておき、それに照らして要求が厳しいと思われる場合には注意しておく • ターンアラウンドタイム：ここではクライアントアプリケーションが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

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

後半部分：トランザクションの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

• 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

必要な性能要件とボトルネックを見極めた上で手当てしていくボトルネック箇所の特定： • 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

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

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

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

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

同一レコードに対して頻繁に読み書きするとタイミング次第でしばしば発生する 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

スループット向上のための独自のトランザクション最適化 • 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

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

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

Hyperledger Fabicのネットワーク設計

Hyperledger Fabicのネットワーク設計

More Decks by gakumura

Other Decks in Technology

Featured

Transcript