2021/5/25 Blockchain GIG#9でしゃべった内容 →2022/10/11 Blockchain GIG特別編 HLF集中講義#1 Hyperledger Fabric(再)入門 でリバイズ Hyperledger Fabricのコンポーネントやトランザクションフローなど基本を解説
Hyperledger Fabric再入門Blockchain GIG特別編 HLF集中講義#1中村 岳クラウド事業統括/クラウド・エンジニアリング統括/ソリューション・アーキテクト本部2022/10/11
View Slide
Copyright © 2022 Oracle and/or its affiliates2中村 岳Twitter @gakumuraはてなブログ @gakumura…主にHyperledger Fabric関連• 現職:ソリューションエンジニア@日本オラクル• 担当:Oracle Blockchain Platform、Blockchain Table• 前職:金融決済系SIerでパッケージ開発• SWIFT、CLS、日銀ネット関連の銀行間決済システム
Hyperledger Fabricをベースにエンタープライズ利用向けPaaSとオンプレミスで提供• 数ステップで構築完了、GUIコンソールで管理・運用も容易• エンタープライズグレードの耐障害制、堅牢性• マルチクラウド、ハイブリッドクラウド、オープンなネットワーク構成が可能• Oracle独自の付加価値:• State DBとしてBerkeley DBを利用:パフォーマンスとクエリ利便性向上、Hyperledger FabricのPhantom Read問題に係る制約も解消• 多機能なREST API:スマートコントラクトの利用を容易に• 台帳のデータをRDBに複製:大量照会、分析、データ統合Oracle Blockchain PlatformCopyright © 2022 Oracle and/or its affiliates3東京DCからもサービス提供中
• 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 affiliates4
• 主要なエンタープライズブロックチェーン基盤のひとつに数えられ、その中でもユースケースでの実績数や開発者数がとりわけ多いHyperledger Fabric• 一方で、「難しそう」「とっつきづらい」といったイメージを持たれがち• ここでは特に複雑なところ、Hyperledger Fabric独特なところを重点的に解説• つまづきポイントをクリアして、Hyperledger Fabricにスムーズに入門しよう!!!!本セッションのねらいCopyright © 2022 Oracle and/or its affiliates5
• はじめに• Hyperledger Fabricを構成する基本的な要素• トランザクションフロー• ChannelとPrivate Data※なお、文中のHLF=HyperLedger Fabric本セッションの内容Copyright © 2022 Oracle and/or its affiliates6
Copyright © 2022 Oracle and/or its affiliates7はじめに
エンタープライズ用途を目的として開発されたブロックチェーンHyperledger : Linux財団がホストするオープンなコミュニティ• 世界で最も成功したOSS=Linuxでの成功実績に基づいた運営• さまざまな業種の企業およびIT企業、研究機関が240以上参加• Fabricをはじめ、複数ブロックチェーン/DLT基盤およびツール等をOSSとして開発Fabric : エンタープライズ領域汎用用途のためのブロックチェーン基盤• メンバー管理サービスを備えたパーミッションドブロックチェーンを実装• セキュリティ、機密性/プライバシーを強化するための多様な機能• スマートコントラクトによって業務を自動化• 大量処理をサポートするためのスケーラブル、プラガブルな設計• マイニングなどの大規模コンピューターパワー投入は不要&ファイナリティ有Hyperledger FabricCopyright © 2022 Oracle and/or its affiliates8
HyperledgerのラインナップCopyright © 2022 Oracle and/or its affiliates9Hyperledger projectsFrom:https://www.hyperledger.org/
ネットワーク参加の制限有無によるブロックチェーンの分類Copyright © 2022 Oracle and/or its affiliates10• 誰でもネットワークに参加しノードを持てる(公開制、オープン、匿名性)• 経済的インセンティブによって不正を抑止する比較的低速なトランザクション処理パーミッションレス a.k.a. パブリック• 招待されたメンバーのみが参加しノードを保持(許可制、クローズド、顕名)• メンバーを識別、一定程度信頼できることに依拠した高速なトランザクション処理パーミッションド a.k.a. プライベート
ネットワークの参加者によるブロックチェーンの分類Copyright © 2022 Oracle and/or its affiliatesパブリック公開制のネットワークを不特定多数で運用コンソーシアム許可制のネットワークを複数組織で運用プライベート許可制のネットワークを単一組織で運用パーミッションレス← →パーミッションド11
よく比較検討されるエンタープライズブロックチェーン基盤a.k.a.「3大エンタープライズブロックチェーン」• 共通点は…• 許可制のネットワークを構成できる• コンソーシアムでの活用を意図した機能を備えている• すでに多くの利用実績がある• 基盤によって思想、個性の違いがあり、その結果としてユースケースの得意不得意がある12 Copyright © 2022 Oracle and/or its affiliatesQuorum(& Besu)HyperledgerFabric Corda
しばしば「Hyperledger Fabricは難しい」と言われがちだが、「難しい」点は概ね以下3つ:• 機能が多く、要素と構造が多層的に絡みあっており複雑• トランザクションフローが独特• サンプルネットワーク構築チュートリアルのステップ数、必要となる前提知識が多い理解を妨げるありがちなパターンは:• そもそもブロックチェーン全般の知識がなく、なぜコンセンサス取らないといけないのかなどの前提からわかっていない• EthereumやQuorumを知っているが故に、そちらに引きずられてHLF独特の要素に混乱する• トランザクションフローの仕組みの意図、理由がわからない• 要素と独特な構造の関係がこんがらがるなぜ「Hyperledger Fabricは難しい」のかCopyright © 2022 Oracle and/or its affiliates13
• 機能が多く、要素と構造が多層的に絡みあっており複雑• トランザクションフローが独特• サンプルネットワーク構築チュートリアルのステップ数、必要となる前提知識が多い「難しい」要素の傾向と対策Copyright © 2022 Oracle and/or its affiliates14Docker、NW設定など引っかかるところが多くネットワーク構築でめげてしまいがち• クラウド上で利用できるテンプレートやBaaSを利用してスキップしてしまうのがオススメ• 最近は公式ドキュメントやブログなどの情報も徐々に充実、親切になってはきている• 背景にある目的、思想をまずは抑えておくと理解しやすくなる• 他ブロックチェーン基盤にはないHLF独特なポイントを意識して学ぶと混乱しにくい
なぜ複雑なトランザクションやデータ構造などの仕組みが必要になるのか?• ブロックチェーン/DLTは一般に、(単一の管理体ではなく)複数の個人や組織が分散して所有・管理するノード間でのデータ複製を確実に行うという「お題」に取り組んでいる(と捉えられる)• 故障やミスだけでなく悪意にも備える必要がある• 他参加者がデータの書き換え(改ざん)を試みるかも• 他参加者のノードは不正に改造されたものかも• 他参加者がネットワークへの攻撃を試みるかも• 以下の要素の組み合わせで実現している(と整理できる)• データの耐改ざん性と検証可能性(→データ構造としてのブロックチェーン)• 状態遷移ロジックの事前定義(→スマートコントラクト)• トランザクション実行時合意(→トランザクションとコンセンサスのメカニズム)ブロックチェーン一般が取り組む共通の「お題」Copyright © 2022 Oracle and/or its affiliates15StatenStaten+1TxノードStatenStaten+1TxノードState Machine Replication
ブロックチェーン一般の前提に加え、HLFの設計思想を抑えておくHLFの多くの機能や独特の仕様には、以下のような目的、背景があると考えると理解しやすくなる• 複数の企業/組織から成るコンソーシアム型のユースケースに最適化する• ネットワークの中で更にデータ共有範囲を分割/制御する• 重大なオペレーションの安全かつ分権したガバナンスを実現する• 耐障害性と可用性をブロックチェーン基盤の機能として確保する• ネットワークメンバー数とトランザクション処理能力のスケーラビリティを確保するHyperledger Fabricの特色Copyright © 2022 Oracle and/or its affiliates16
Copyright © 2022 Oracle and/or its affiliates171. Hyperledger Fabricを構成する基本的な要素
凡例D社C社B社A社ノードシンプルなコンソーシアム型ブロックチェーンのネットワーク超概観図Copyright © 2022 Oracle and/or its affiliates18SC LノードSC LノードSC LノードSC L個社アプリブロックチェーンネットワーク個社アプリ共有アプリオペレーター他システムSC スマートコントラクトL 台帳
OrdererHyperledger Fabricネットワークの概観図19PeerClientAppCAChainCode LedgerOrdererA社OrdererPeer CAChainCode LedgerOrdererOrdererOrdererPeerChainCode LedgerCAOrdererCAOrdererPeerChainCode LedgerB社 D社C社ClientAppClientAppClientAppCopyright © 2022 Oracle and/or its affiliates
独特な点:ブロック生成専用のノードの分離と階層型アイデンティティの採用Organization• ネットワークに参加するメンバーの「組織」を表す抽象的な単位• コンポーネントやユーザーが所属Peerノード• 台帳(World StateとBlockchain)を保持• Chaincodeをリクエストに応じて実行するOrdererノード• ひとつ~複数のOrdererノードでOrderingServiceを構成• トランザクションの順序を確定し、ブロックを生成しPeerノードに配布Chaincode(スマートコントラクト)• 台帳の更新、照会のビジネスロジッククライアントアプリケーション• Hyperledger Fabricを利用するアプリCA(Certificate Authority)• 各コンポーネントやユーザーのアイデンティティ(証明書)を発行するPKIの認証局• 通常、Fabric CAを利用するが他の実装も利用可能登場する要素、コンポーネント20 Copyright © 2022 Oracle and/or its affiliates
OrdererOrganization21PeerClientAppCAChainCode LedgerOrdererA社OrdererPeer CAChainCode LedgerOrdererOrdererOrdererPeerChainCode LedgerCAOrdererCAOrdererPeerChainCode LedgerB社 D社C社ClientAppClientAppClientAppCopyright © 2022 Oracle and/or its affiliates
コンポーネント、ユーザーが所属するアイデンティティレイヤー• HLFにはネットワークに参加する主体(多くの場合は企業などの組織の単位、時には個人)を表現するための抽象アイデンティティレイヤーであるOrganization(Org)がある• Ordererノード、PeerノードおよびCAのコンポーネント、また、アプリケーションが用いるユーザーのアイデンティティは、必ずいずれかひとつのOrgに属する• (他の基盤のように具体的な秘密鍵単位ではなく)「どのOrg配下のコンポーネント/ユーザーか」に基づいてオペレーション、ガバナンス、ネットワーク構成を設計できる• PKIの階層構造と結びついている• 自身のOrg配下のコンポーネントやユーザー用の秘密鍵/証明書は自身のCAで発行するOrganizationCopyright © 2022 Oracle and/or its affiliates22NetworkOrganization AOrdererノードPeerノードAdminユーザーClientユーザーOrganization BOrdererノードPeerノードAdminユーザーClientユーザーOrdererノードPeerノードAdminユーザーClientユーザーCA
メッセージやデータのデジタル署名とその検証Copyright © 2022 Oracle and/or its affiliates23ClientAppOrdererOrdererClientAppPeer PeerMSPMSPMSPMSP• やり取りされるメッセージ、およびその中のデータ(ブロック、トランザクションなど)にはデジタル署名が付与されている• 各ノードやユーザーのアイデンティティに紐づいた秘密鍵でデジタル署名を行う• 不正な送信者の介入や、メッセージ内容の中途での改ざんを防ぐ• 各コンポーネントの持つMSP(Membership ServiceProvider)というモジュールが署名の検証を担う
エンドユーザー(消費者)のアイデンティティを扱うケース• Ethereum(およびパブリックブロックチェーン一般)では基本的にエンドユーザーが自身の秘密鍵を用いてトランザクションに署名し発行する=エンドユーザーのブロックチェーン上のID(アドレス)が直接伝わってくる• 通常、HLFでは個々の消費者に対してはブロックチェーン上のIDを持たせない(割り当てない)• エンドユーザーが消費者の場合、トランザクションに署名し発行するのは中間オペレーター(のアプリ)• この場合、「トランザクション署名者がTokenのOwnerのIDと一致しているか」では権限制御できない• 必要に応じロールベース(RBAC)や属性ベース(ABAC)のオンチェーン権限制御ロジックを実装する24 Copyright © 2022 Oracle and/or its affiliatesウォレット(サーバーサイド)アプリコントラクトChaincodeアプリの認証(ID/PW等)操作ブロックチェーンのトランザクションエンドユーザー(消費者)自身の秘密鍵で署名トランザクションアプリの抱える秘密鍵で署名Ethereum等パブリックBCHyperledgerFabric消費者消費者
Hyperledger Fabricにおけるスマートコントラクト• 所謂「スマートコントラクト」だが、単に「台帳の読み書きのロジック」と考えるとわかりやすい• 「RDBにおけるストアドプロシージャのようなもの」という説明もある• HLFでは多くの場合、Chaincodeはそれほど複雑にも大規模にもならない• 認証認可やプライバシーを基盤機能で担当するのでChaincode側でやるロジックはそれほどない• Ethereumにおけるスマコン(ERC、Open Zeppelin、etc.の学習が必須)とは事情はかなり異なる• 専用のライブラリを組み込んで台帳(World StateおよびBlockchain)にアクセス• 機能数は限られており習得は難しくない• Chaincode開発言語の選択肢:Node.js、Go、JavaChaincodeCopyright © 2022 Oracle and/or its affiliates25PeerノードLedgerChaincode
• 各々が自身のPeerにInstallした後に、Channelで有効化することで実行可能に• 有効化の手続きはv1.x系とv2.x系で異なる(v2.x系ではオペレーションが一層分権化)• バージョンアップ可能:Chaincodeはバージョンアップできるため、稼働後も修正や改善が可能• 新バージョンで旧バージョンのChaincodeが書いたレコードにもアクセスできるChaincodeのライフサイクルCopyright © 2022 Oracle and/or its affiliates26Install有効化 Upgrade新バージョンのInstall各Orgで行うローカルなオペレーションネットワークのオペレーション新バージョン稼働
Hyperledger Fabricの種々の機能を利用するアプリケーション• クライアントアプリケーションはFabric SDKを通じてHLFの機能を使う• 基本的には台帳に関する読み書き関連の機能を利用• Peerノードに対してChaincode実行を依頼する• Peerノードから返ってきたEndorsementを集める• Ordering ServiceにTransactionを送付する• 機能の利用にあたってはCAから発行されたアイデンティティ(秘密鍵/証明書)を用いて認証する• Fabric SDKはNode.js版とJava版が正式リリースクライアントアプリケーションCopyright © 2022 Oracle and/or its affiliates27Client AppFabric SDKPeerノードLedgerChaincode証明書
PeerPeerノードが保持する分散台帳の1コピーHyperledger Fabricにおける「台帳」28• 台帳は以下ふたつの要素から構成される+Blockchain:履歴• トランザクションの履歴が格納されるハッシュチェーンで連結されたブロックのファイル• 追記オンリーで蓄積していくWorld State:状態• 各Keyに対する現在(最新)バージョンの値を保持• レコードは更新、削除が可能(履歴はBlockchainに残っている)• State DBと呼ばれるDBに格納されるLedgerPeerLedgerPeerLedgerPeerLedgerCopyright © 2022 Oracle and/or its affiliates
台帳に保存される「現在の値(ステート)」とそれを保持するデータベースWorld StateはKey-Valueストアで、Valueには任意の文字列やバイナリを格納可能• ChaincodeはWorld StateからKeyのValueを読み出し、書き込むことで台帳上のデータに対してのビジネスロジックを表現する• State DBと呼ばれるデータベースに保持される通常のHLFではState DBにはLevelDBかCouchDBを選択可能• LevelDB:シンプルなデータ構造を扱う場合向き(例:口座番号がKey/残高がValue)• Keyを指定するステート検索しかできない(単一指定or範囲指定)• CouchDB:複数の属性を持つValueを扱いやすい• JSON形式でValueを格納すると、Attributeを条件に指定して検索できる(リッチクエリ)• LevelDBに比べると低速な点、Phantom Read問題に係る制約には留意World StateとState DB29 Copyright © 2022 Oracle and/or its affiliates
ある程度柔軟なデータ構造を扱え、State DBによる検索の表現能力もそこそこWorld Stateで扱うデータ構造の例Copyright © 2022 Oracle and/or its affiliates30Key:口座番号 Value:残高1020345 10,000,0001020346 56,400Key:アセット種別とID Value:アセット情報car^aaa111 {“color”:”red”, “price”:10000, “owner”:”Bob”, “drive”:”front”}car^bbb222 {“color”:”blue”, “price”:30000, owner”:”Alice”, “drive”:”AWD’}bike^xyz345 {“color”:”green”, “price”:30000, owner”:”Alice”, “CC”:”1800’}シンプルなKey-Value構造:口座複合キーとJSONを用いたKey-Value構造:アセット台帳Keyの値を指定してValueを読み取る/書き込む複合キーの利用やKey値の範囲指定のクエリも可State DBにCouchDBを使いValueをJSONにしておくとリッチクエリが使える(例:ownerがAliceのアセットを全件取得)
State DB内ではレコードにはKeyとValueの他にも以下の情報が付随している• Channel、Chaincode ID…どのChannelのどのChaincodeのレコードかを表し、名前空間として機能(Channel+Chaincode ID+Keyで一意)• Version…そのレコードはどのBlockのどのTransactionにより書き込まれたものかを示し、トランザクションの整合性検証に使用される(後で説明)State DB内に保持されているデータの付随情報Copyright © 2022 Oracle and/or its affiliates31Channel Chaincode ID Key Value Versionch1 accountCC 1020345 10,000,000 Block17,Tx5ch1 motorCC car^aaa111 {hogehoge... Block3,Tx1ch2 marbleCC marble123 {fugafuga... Block1,Tx3ch2 accountCC 3040567 300 Block1,Tx4
独特な点:ブロック生成専用のノードの分離と階層型アイデンティティの採用Organization• ネットワークに参加するメンバーの「組織」を表す抽象的な単位• コンポーネントやユーザーが所属Peerノード• 台帳(World StateとBlockchain)を保持• Chaincodeをリクエストに応じて実行するOrdererノード• ひとつ~複数のOrdererノードでOrderingServiceを構成• トランザクションの順序を確定し、ブロックを生成しPeerノードに配布Chaincode(スマートコントラクト)• 台帳の更新、照会のビジネスロジッククライアントアプリケーション• Hyperledger Fabricを利用するアプリCA(Certificate Authority)• 各コンポーネントやユーザーのアイデンティティ(証明書)を発行するPKIの認証局• 通常、Fabric CAを利用するが他の実装も利用可能(再掲)登場する要素、コンポーネント32 Copyright © 2022 Oracle and/or its affiliates
Copyright © 2022 Oracle and/or its affiliates332. トランザクションフロー
• HLFのトランザクションはフローが独特で「まわりくどい」「わかりづらい」と言われがち• ここでトランザクションとは、台帳を更新する一連の(1セットの)処理• しかしトランザクションの流れの理解は必須(細部はさておき)• トランザクションフローの理解が不足していると…• 発生するエラー(無効なトランザクション)の原因が理解できず対処できない• 不適切なChaincodeロジックおよびアプリケーションロジックを設計してしまう• パフォーマンスに問題が生じたときにボトルネックが特定できず対処できない• 各フェーズでのアクションが何のために行われているのか、全体としてどうしてそのような作りになっているのか、の目的を意識して学ぶと理解しやすいトランザクションフローをなぜ理解するべきか、どう学ぶべきかCopyright © 2022 Oracle and/or its affiliates34
• 「Hyperledger FabricのコンセンサスアルゴリズムはPBFT」はまちがい• HLF v0.6ではPBFT(Practical Byzantine Fault Tolerant)だった• HLF v1.0以降はPBFTではない• 「Hyperledger FabricのコンセンサスアルゴリズムはRaft」も微妙• RaftはOrdering Serviceのコンセンサスアルゴリズム(のオプションのひとつ)である• Q. 「じゃあHLF のコンセンサスアルゴリズムはなんなんですか?」→A. 「……。」• HLFの公式ドキュメントでは「コンセンサスアルゴリズム」という語は使わず、「トランザクションフロー」として説明しているのでここでもそれに倣う• 一応書き添えておくとPoWなどにある多大な電力消費とは無縁説明に入る前に…Copyright © 2022 Oracle and/or its affiliates35
Endorsement・Ordering・Validationの3フェーズから構成Endorsement:トランザクションの内容について合意する• クライアントアプリケーションからPeerにChaincode実行依頼(Transaction Proposal)を送付• PeerノードがChaincodeを実行(※)し署名を付けて結果(Endorsement)を返却• クライアントはEndorsement Policyで定められた必要な分のEndorsementを収集する(※)この時点では台帳に反映しないため「シミュレーション実行」と言われることもあるOrdering:トランザクションの順序を確定しブロックを生成・配布する• Endorsementを集め終えたクライアントアプリケーションがTransactionを送付• 受け取ったOrdering ServiceがTransactionを詰めたBlockを生成、Peerノードに配布Validation:トランザクションの有効性を検証したうえで反映する• Peerがブロック内のTransactionを検証し台帳に反映(コミット)3フェーズのトランザクションフロー36 Copyright © 2022 Oracle and/or its affiliates
トランザクションフローの図Copyright © 2022 Oracle and/or its affiliates37PeerChainCode LedgerClientAppOrdererOrdererOrdererClientAppClientAppPeerChainCode LedgerPeerChainCode Ledger11.51.512233.54445551)TransactionProposal 送付 1.5)Chaincode実行 2) Endorsement返却3)Transaction送付3.5)Block生成4)Block配布5)Validation→Commit2.5) Endorsement収集2.5
38From: https://hyperledger-fabric.readthedocs.io/en/latest/txflow.html①TransactionProposal送付 (1.5)Chaincode実行(2.5)Endorsement収集③Transaction送信④Block配布(5)Validation→Commit(※)Tx Event通知②Endorsement返却(3.5)Block生成Copyright © 2022 Oracle and/or its affiliates
何を、何のためにやっているのか?再掲)Endorsement:トランザクションの内容について合意する• クライアントアプリケーションからPeerにChaincode実行依頼(Transaction Proposal)を送付• PeerノードがChaincodeを実行(※)し署名を付けて結果(Endorsement)を返却• クライアントはEndorsement Policyで定められた必要な分のEndorsementを収集する(※)この時点では台帳に反映しないため「シミュレーション実行」と言われることもあるEndorsementフェーズの意図• 別の組織が所有する複数のPeerで同一のChaincode(=事前合意されたロジック)を実行し、同一の結果になること(=トランザクション内容についての合意)を担保する• 以下のような事態を防ぐことができる• 自身の所有するPeerのみに依頼し、都合よく改変した不正なロジックを実行させ、その結果を正としてトランザクションが進んでしまう• 単一のPeerの持つなんらかの不具合、ミス、障害あるいは悪意により不正な状態になった台帳のデータをもとにトランザクションが進んでしまうEndorsementフェーズ39 Copyright © 2022 Oracle and/or its affiliates
トランザクション内容へのPeerの「裏書」Endorsement:Chaincode実行結果にPeerが署名したもの• クライアントは複数Peerから「同一の」実行結果を集める必要がある(値がバラバラだと無効)Endorsement Policy:あるトランザクションを台帳に反映するために、どのようなEndorsementを集めてこなければならないかを予め定義した条件(どうしたらコンセンサスが取れたことになるか)• 柔軟な設定が可能• EndorsementはPeer単位ではなく、Organization単位でカウントされる• 単一のOrg配下の複数Peerから取ってきても意味がないシンプルなEndorsement Policyの例:Org 1,2,3で構成されるネットワークの場合に、• AND(‘Org1.member’, ‘Org2.member’, ‘Org3.member’) // 全Org必須• OR(‘Org1.member’, ‘Org2.member’) // Org1かOrg2どちらかひとつ• OutOf(2, ‘Org1.member’, ‘Org2.member’, ‘Org3.member’) // いずれか2つEndorsementとEndorsement PolicyCopyright © 2022 Oracle and/or its affiliates40
Chaincode(シミュレーション)実行のBefore/Afterの状態セットRWSet(Read-Write-Set)と呼ばれるトランザクションの仕組み上必要なデータと、クライアントアプリケーションへの返り値がChaincode実行結果には含まれているRWSet:Chaincodeを実行するなかでの、• World Stateから読み取った値があればそのKeyとバージョンのセット(Read-Set)• World Stateに書き込む(予定の)値があればそのKeyとValueのセット(Write-Set)HLFのトランザクションフロー上、以下のような意味を持っている• Read-Set:そのトランザクションが前提とした台帳の状態• Write-Set:そのトランザクションが有効となった場合に書き込む値「Chaincode実行結果」とRWSetCopyright © 2022 Oracle and/or its affiliates41
あるTransactionがWorld Stateから読んだレコード、書き込む(予定の)値RWSetの例 ※バージョンの形式は単純化しており正確なものではないCopyright © 2022 Oracle and/or its affiliates42• K1とK2のレコードを読んでいる• それぞれバージョンは”1”• K1に”V1”という値を、K3に”V2”という値をそれぞれ書き込もうとしている• K4のレコードを削除しようとしている
再掲)Ordering:トランザクションの順序を確定しブロックを生成・配布する• Endorsementを集め終えたクライアントアプリケーションがTransactionを送付• 受け取ったOrdering ServiceがTransactionを詰めたBlockを生成、Peerノードに配布Ordering Service内にもコンセンサスがある:• Ordering Serviceは1~複数のOrdererノードから成るクラスター• このクラスターの中で受け取ったTransactionの順序を合意し決定している(現在はRaftを利用)OrderingフェーズCopyright © 2022 Oracle and/or its affiliates43ClientAppOrdererOrdererOrdererClientAppClientAppTx1Tx2Tx3BlockTx1Tx2Tx3PeerPeerPeer
ブロック生成ノードを分権で持つ+冗長性により耐障害性を確保Ordering Serviceのクラスターとコンセンサス(Raftの場合)Copyright © 2022 Oracle and/or its affiliates44PeerChainCode LedgerClientAppOrdererOrdererOrdererClientAppClientAppPeerChainCode LedgerPeerChainCode LedgerLRaftコンセンサスどのOrdererノードに到達してもクラスター内で共有されるその時点でLeaderの役割を持っているノードがBlockを生成する
Peer Ledgerトランザクションの有効性を検証したうえで台帳に反映する• Validation:Blockを受け取った各Peerは、含まれるTransactionそれぞれを検証する• Endorsement Policyを満たしているか(含:各Endorserの戻したRWSetの比較)• 各署名(クライアント、Endorser、Orderer)は正しいか• Read-Set Validation:Read-Setに含まれるKeyのバージョンが自身の現在のWorld Stateのそれと一致しているか• Commit:ValidなTransactionについてはWrite-Setの値をWorld Stateに反映• 併せて、Block、Transactionの内容およびメタデータをBlockchain部に保存ValidationフェーズCopyright © 2022 Oracle and/or its affiliates45BlockTx1Tx2Tx3World State
Tx2• Read-Setに含まれるKeyのバージョンが自身の現在のWorld Stateのそれと一致しているか• 言い換えると、Chaincode実行時点(Endorsementフェーズ)で読み取ったレコードのValueが、Validation時点までに更新されていないことをチェックしているRead-Set Validationの必要性:• HLFはあるトランザクションでStateをReadする時点とWrite/Commitする時点が離れており、その間のロックもしていない• Read時点からWrite時点までにトランザクションの前提としたStateの状態が変わってしまうケースがある• i.e. 他のトランザクションによって更新• 前提が変わっている場合には検出してトランザクションを無効にする必要があるRead-Set ValidationCopyright © 2022 Oracle and/or its affiliates46World StateKey Value VersionA 0 4不一致
ロジックとデータの整合性がおかしくなってしまう例例:残高1000円の口座Aから1000円引き落とすTx1と200円引き落とすTx2をほぼ同時に発行• Endorsement:• Tx1:1000円の状態を読んで1000円マイナスし0円に更新する(予定、Write-Set)• Tx2:1000円の状態を読んで200円マイナスし800円に更新する(予定、Write-Set)• Ordering:Tx1→Tx2の順序に決定• Validation:• Tx1反映後:0円を書き込み• Tx2反映後:800円を書き込み←1000円の口座から計1200円引き落としたはずなのに…こういう場合はTx2は無効になってほしいのでRead-Set Validationで検出するもしRead-Set Validationをしていなかったら…Copyright © 2022 Oracle and/or its affiliates47
同一レコードに対して頻繁に読み書きするとタイミング次第でしばしば発生するRead-Set Validationで無効になるパターンのシーケンスCopyright © 2022 Oracle and/or its affiliates48レコード xTx1Tx2Read(x)Read(x)RS-V (x) Write(x)RS-V(x)version=nversion=n?OKversion=nversion=n?NGEndorsement Ordering ValidationEndorsement Ordering Validationversion=n+1
Endorsement・Ordering・Validationの3フェーズから構成Endorsement:トランザクションの内容について合意する• クライアントアプリケーションからPeerにChaincode実行依頼(Transaction Proposal)を送付• PeerノードがChaincodeを実行(※)し署名を付けて結果(Endorsement)を返却• クライアントはEndorsement Policyで定められた必要な分のEndorsementを収集する(※)この時点では台帳に反映しないため「シミュレーション実行」と言われることもあるOrdering:トランザクションの順序を確定しブロックを生成・配布する• Endorsementを集め終えたクライアントアプリケーションがTransactionを送付• 受け取ったOrdering ServiceがTransactionを詰めたBlockを生成、Peerノードに配布Validation:トランザクションの有効性を検証したうえで反映する• Peerがブロック内のTransactionを検証し台帳に反映(コミット)(再掲)3フェーズのトランザクションフロー49 Copyright © 2022 Oracle and/or its affiliates
どうしてこのようなフローになっているのか• スマートコントラクトロジック実行とブロック生成を分離できる• 比率的に重いChaincode実行はPeerノードに、トランザクション順序の決定とブロック生成はOrderingServiceにそれぞれ分離することによる処理能力向上• ネットワーク規模拡大がスマートコントラクトロジック実行の処理負荷増大に直結しない• Endorsement Policy次第で、必ずしもネットワーク参加メンバー拡大に比例したかたちで冗長にChaincode実行をするPeerノードが増えていかない(→スケーラビリティ)• トランザクションの並列実行可能性の向上• Chaincode実行の処理量を複数Peerで水平分散できる• (更新するレコードが十分に分散している限りにおいて)同時/並列に処理できるトランザクション量を増やすことができるEndorsement・Ordering・Validationフローの主な利点Copyright © 2022 Oracle and/or its affiliates50
Copyright © 2022 Oracle and/or its affiliates513. ChannelとPrivate Data
• ブロックチェーン/DLTはネットワーク内のすべてのノードで同一のデータを複製し共有するというのが基本のアイディア• 一方で、エンタープライズ領域ではあるデータをネットワークのうち一部の参加者にしか見せたくない、というニーズが頻出する• エンタープライズ用ブロックチェーン基盤ではこうしたニーズに応えるため、データ共有範囲をネットワークの一部に限定するための機能を備えているものが多いエンタープライズブロックチェーン基盤のデータ共有範囲制御Copyright © 2022 Oracle and/or its affiliates52A BDCA BDC全データを全ノードで共有 一部のデータは限られたノードで共有
ChannelとPrivate Dataのふたつの機能の使い分け/組み合わせが可能Channelネットワークをサブネットワークに分割し、トランザクションそのものの(すなわち、そこで扱われるデータの)共有範囲を限定Private DataChannel内で共有されるトランザクションのうち、一部のデータ項目を更に範囲を限定して共有できるHLFのデータ共有範囲制御53L1L2L3【お客様情報レコード】“ID : 1234567890”“生年月日 : 1987年1月1日”“性別 : 男性”“名前 : 鈴木太郎”“住所 : 東京都千代田区X-X-X”“電話番号 : 080XXXXXXXX”“契約コース : 従量制A”“契約日時 : 2019/1/21”Channel内の一部のメンバーのみデータを共有(他のメンバーには秘匿)Copyright © 2022 Oracle and/or its affiliates
• HLFネットワーク内のサブネットワークである• あるChannelにはネットワークのうち一部~全部のOrganizationが所属する• 更にPeerノードやOrdererノードにもChannelへの参加/不参加がある• Channelごとに台帳が存在する、すなわちChannelが台帳の共有範囲である• Channelごとにトランザクションが実行されるChannelの概要Copyright © 2022 Oracle and/or its affiliates54OrgA Peer OrgB Peer OrgC PeerCH1 L1L2L1 L1L2L3 L3CH2CH3OrgAOrgBOrgC
HLFにとってChannelは多くの要素の基礎となる構造• Orgの参加/不参加• Orgの権限(ReadOnly/ReaderWriter)• Peerノードの参加/不参加• Ordering Serviceクラスター• 参加するOrdererノード• Ordering Serviceの設定• Chaincodeの稼働• Endorsement Policy• トランザクション• Chaincode実行• ブロック生成• ブロック配布• 整合性• 台帳• World State• Blockchain• Private Data• Private Data Collection定義Channelをスコープとする主な要素(設定、定義、処理など)Copyright © 2022 Oracle and/or its affiliates55
ChannelとOrg、Ledger、Peer、Orderer、Chaincodeの関係の例Copyright © 2022 Oracle and/or its affiliates56P1 P2 P3 P4 P5 P6Ch1PeerOrdererOrganizationChannelOrgAOrgBOrgCO1 O2 O3 O4 O5 O6Ch2CC1 L1L2CC2L2CC2 L2CC2 L2CC2L1CC1 L1CC1CC2CC1 CC1 CC1CC1
Channel作成、ノード追加、Chaincodeインストール、Chaincode稼働の順序ChannelとOrg、Ledger、Peer、Orderer、Chaincodeの関係の例Copyright © 2022 Oracle and/or its affiliates57P1 P2 P3 P4 P5 P6Ch1PeerOrdererOrganizationChannelOrgAOrgBOrgCO1 O2 O3 O4 O5 O6CC1 L1L1CC1 L1CC1①Ch作成&参加Org定義②OrgがChにノードを追加③Chに参加したPeerはLedgerを保持④OrgがPeerにCCをインストール⑤ChでCCを稼働
ChannelとOrg、Ledger、Peer、Orderer、Chaincodeの関係の例Copyright © 2022 Oracle and/or its affiliates58P1 P2 P3 P4 P5 P6Ch1PeerOrdererOrganizationChannelOrgAOrgBOrgCO1 O2 O3 O4 O5 O6Ch2CC1 L1L2CC2L2CC2 L2CC2 L2CC2L1CC1 L1CC1CC2CC1 CC1 CC1CC1CCのInstall有無はPeer個別に選択Peerは・複数Chに参加可・複数CCを保持可Chは複数CCを稼働可能同一CCを複数Chで稼働可能(台帳は別)
• あるトランザクションのうち一部のデータを一部のChannelメンバーに限定して共有する(他のメンバーからは隠す)オプショナルな機能としてPrivate Dataがある• 共有先Orgは事前に定義しておく…Private Data Collection定義• Private Dataの内容は台帳の外で保持され(※)、削除(Purge)が可能• つまりWorld Stateに載らない、Blockchainにも残らないPrivate Dataの概要Copyright © 2022 Oracle and/or its affiliates59OrgA Peer OrgB Peer OrgC PeerChannel 1L1PD1L1 L1Private DataCollection 1PD1※Private Dataが台帳に含まれるかどうかはHLFの公式ドキュメント内でも記載がブレているが、台帳外であるとしたほうがわかりやすいのでここではそのように整理する
• Private Dataを格納する容れ物をPrivate Data Collectionと呼ぶ• Private Data CollectionはWorld Stateとは別の領域のKey-ValueストアとしてState DB内に保持される• Chaincodeの中で利用するPrivate Data Collectionは、ChaincodeをChannelで稼働させる際に定義(宣言)する必要がある• この中でChannelメンバーのうちどのOrgのPeerがそのPrivate Data Collectionを保持するかを設定するPrivate Data Collection(PDC)Copyright © 2022 Oracle and/or its affiliates60{"name": "collectionMarbles","policy": "OR('Org1MSP.member’,'Org2MSP.member’)”,...}Peer LedgerBlockchainState DBPDCWorldStatePrivate Data Collection定義の例
• PDの内容はトランザクションに載らずPDC保持メンバーのPeerのみに共有• PD内容はOrdering Serviceを通らず、Peer間のGossipで伝播する• 内容(KeyとValueそれぞれ)をハッシュ化したもの(Private Data Hash)はPDC保持メンバー以外のChannelメンバーにも共有される• PD Hashはトランザクションに載り、World Stateにも格納される• PD HashによりPrivate Dataの存在有無および内容は検証可能になる• 必要に応じてPDC保持メンバーはPrivate Dataが改ざんされていないことをPD Hashと突合することで確認、証明できるPrivate Data(PD)の内容とPrivate Data Hash(PD Hash)Copyright © 2022 Oracle and/or its affiliates61Ledger BlockTx World StatePD Hash PD HashPDCPD内容ハッシュ化
Private Dataの絡むトランザクションフローの図Copyright © 2022 Oracle and/or its affiliates62ClientApp PeerPDCPD内容ChainCodePeerLedgerChainCodeOrderingService11.52 LedgerPeerPDCChainCodeLedgerPeerPDCChainCodeLedgerPD内容1.5123 3.545PD内容4554 451)TransactionProposal 送付1.5)Chaincode実行2) Endorsement返却3)Transaction送付(PD Hashを含むがPD内容は含まない) 3.5)Block生成2.5) Endorsement収集2.5PD内容を伝播(Gossipプロトコル)
Copyright © 2022 Oracle and/or its affiliates63まとめの振り返り
OrdererポイントはOrganizationHyperledger Fabricネットワークの概観図64PeerClientAppCAChainCode LedgerOrdererA社OrdererPeer CAChainCode LedgerOrdererOrdererOrdererPeerChainCode LedgerCAOrdererCAOrdererPeerChainCode LedgerB社 D社C社ClientAppClientAppClientAppCopyright © 2022 Oracle and/or its affiliates
流れと各フェーズの目的を理解しておく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から成るトランザクションフロー65 Copyright © 2022 Oracle and/or its affiliates
ChannelはHLFの基礎の一部、Private DataはオプショナルChannelネットワークをサブネットワークに分割し、トランザクションそのものの(すなわち、そこで扱われるデータの)共有範囲を限定Private DataChannel内で共有されるトランザクションのうち、一部のデータ項目を更に範囲を限定して共有できるChannelとPrivate Data66L1L2L3【お客様情報レコード】“ID : 1234567890”“生年月日 : 1987年1月1日”“性別 : 男性”“名前 : 鈴木太郎”“住所 : 東京都千代田区X-X-X”“電話番号 : 080XXXXXXXX”“契約コース : 従量制A”“契約日時 : 2019/1/21”Channel内の一部のメンバーのみデータを共有(他のメンバーには秘匿)Copyright © 2022 Oracle and/or its affiliates
なぜこんな設計になってるのか?と思ったらここに立ち戻るHLFの多くの機能や独特の仕様には、以下のような目的、背景があると考えると理解しやすくなる• 複数の企業/組織から成るコンソーシアム型のユースケースに最適化する• ネットワークの中で更にデータ共有範囲を分割/制御する• 重大なオペレーションの安全かつ分権したガバナンスを実現する• 耐障害性と可用性をブロックチェーン基盤の機能として確保する• ネットワークメンバー数とトランザクション処理能力のスケーラビリティを確保するHyperledger Fabricの特色Copyright © 2022 Oracle and/or its affiliates67
Thank youCopyright © 2022 Oracle and/or its affiliates68