Hyperledger Fabicのネットワーク設計

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

はじめに：入門編の振り返り
6

View Slide

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

View Slide

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

View Slide

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
9

View Slide

流れと各フェーズの目的を理解しておく
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から成るトランザクションフロー
10

View Slide

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内の
一部のメンバーのみ
データを共有
（他のメンバーには
秘匿）
11

View Slide

設計の前提を整理する
12

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

凡例
D社
C社
B社
A社
ノード
3. 誰がノードを持つのか？
SC L
ノード
SC L
ノード
SC L
ノード
SC L
個社
アプリ
個社
アプリ
共有
アプリ
オペレーター
他システム
SC スマート
コントラクト
L 台帳
18

View Slide

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

View Slide

凡例
D社
C社
B社
A社
ノード
アプリは？
SC L
ノード
SC L
ノード
SC L
ノード
SC L
個社
アプリ
個社
アプリ
共有
アプリ
オペレーター
他システム
SC スマート
コントラクト
L 台帳
20

View Slide

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

View Slide

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

View Slide

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

View Slide

Hyperledger Fabricネットワーク構成を
設計する
24

View Slide

Orderer
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
この範囲についてどう設計を進めていくべきかの流れを説明
25

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

• 「あるメンバーに読み取りはさせたいが更新はさせたくない」という要件が存在する場合には、
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：更新パーミッションの制御
Org
A
Org
B
Chaincode
関数
アクセス制御
Ledger
Private
Data
36

View Slide

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

View Slide

Fine-Grained Access Controlライブラリの利用イメージ
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 Slide

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

View Slide

• 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要求数増は性能上はネガティブな要素
40

View Slide

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

View Slide

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

View Slide

Organizationの役割を整理する
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 Slide

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

View Slide

• 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前提）
45

View Slide

Orderer
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
だいたい設計できそう！！！
46

View Slide

パフォーマンスあれこれ
47

View Slide

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

View Slide

トランザクションのターンアラウンドタイム
クライアントから見たときの
ターンアラウンドタイムとは：
Transaction Proposalを送信～Peerでの
ターンアラウンドタイム
49

View Slide

ターンアラウンドタイムの内訳
内訳としては２段階：
• Transaction Proposalを送信してから必要
なEndorsementが集まるまで
• Transactionを送信してからPeerでの
50

View Slide

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

View Slide

後半部分：トランザクションのOrdering＋Validation/Commitフェーズ
要素：
• メッセージ、ブロック、イベント伝送時間
• Ordering Serviceでのブロック生成時間
• Committing PeerでのValidation/Commit時間
改善材料：
• Ordering Serviceのブロック生成設定を見直す
• バッチタイムアウト時間を減らす
（デフォルト2秒になってるので…）
• Ordering Serviceの構成Ordererを見直す
• Ordererを減らす
• Ordererの負荷分散
• Ordererのリソース（CPU／メモリ／IO）を増やす
52

View Slide

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

View Slide

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

View Slide

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

View Slide

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
56

View Slide

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

View Slide

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

View Slide

同一レコードに対して頻繁に読み書きするとタイミング次第でしばしば発生する
Read-Set Validationで無効になるパターンのシーケンス
レコード 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 Slide

つまり…？
60
あるレコード（Key）の
値（Value）は
1度に1トランザクションしか
更新できない
複数クライアントが
同時に同一のレコードを
更新を試みることが
あり得るパターンには注意

View Slide

スループット向上のための独自のトランザクション最適化
• 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の改善点
61
詳細は以下のブログを参照：
https://blogs.oracle.com/blockchain/post/obptokenoptimization
61

View Slide

まとめ
62

View Slide

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

View Slide

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

View Slide

6. Ordering Serviceの構成を設計する
ネットワーク設計の流れ
65

View Slide

Thank you
66

View Slide

View Slide

Hyperledger Fabicのネットワーク設計

Hyperledger Fabicのネットワーク設計

gakumura

More Decks by gakumura

Other Decks in Technology

Featured

Transcript