$30 off During Our Annual Pro Sale. View Details »

Hyperledger Fabric(再)入門

gakumura
October 11, 2022

Hyperledger Fabric(再)入門

2021/5/25 Blockchain GIG#9でしゃべった内容
→2022/10/11 Blockchain GIG特別編 HLF集中講義#1 Hyperledger Fabric(再)入門 でリバイズ
Hyperledger Fabricのコンポーネントやトランザクションフローなど基本を解説

gakumura

October 11, 2022
Tweet

More Decks by gakumura

Other Decks in Technology

Transcript

  1. Hyperledger Fabric再入門
    Blockchain GIG特別編 HLF集中講義#1
    中村 岳
    クラウド事業統括/クラウド・エンジニアリング統括/ソリューション・アーキテクト本部
    2022/10/11

    View Slide

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

    View Slide

  3. Hyperledger Fabricをベースにエンタープライズ利用向けPaaSとオンプレミスで提供
    • 数ステップで構築完了、GUIコンソールで管理・運用も容易
    • エンタープライズグレードの耐障害制、堅牢性
    • マルチクラウド、ハイブリッドクラウド、
    オープンなネットワーク構成が可能
    • Oracle独自の付加価値:
    • State DBとしてBerkeley DBを利用:パフォーマンスとクエリ利便性向上、
    Hyperledger FabricのPhantom Read問題に係る制約も解消
    • 多機能なREST API:スマートコントラクトの利用を容易に
    • 台帳のデータをRDBに複製:大量照会、分析、データ統合
    Oracle Blockchain Platform
    Copyright © 2022 Oracle and/or its affiliates
    3
    東京DCからも
    サービス提供中

    View 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 Slide

  5. • 主要なエンタープライズブロックチェーン基盤のひとつに数えられ、
    その中でもユースケースでの実績数や開発者数がとりわけ多いHyperledger Fabric
    • 一方で、「難しそう」「とっつきづらい」といったイメージを持たれがち
    • ここでは特に複雑なところ、Hyperledger Fabric独特なところを重点的に解説
    • つまづきポイントをクリアして、Hyperledger Fabricにスムーズに入門しよう!!!!
    本セッションのねらい
    Copyright © 2022 Oracle and/or its affiliates
    5

    View Slide

  6. • はじめに
    • Hyperledger Fabricを構成する基本的な要素
    • トランザクションフロー
    • ChannelとPrivate Data
    ※なお、文中のHLF=HyperLedger Fabric
    本セッションの内容
    Copyright © 2022 Oracle and/or its affiliates
    6

    View Slide

  7. Copyright © 2022 Oracle and/or its affiliates
    7
    はじめに

    View Slide

  8. エンタープライズ用途を目的として開発されたブロックチェーン
    Hyperledger : Linux財団がホストするオープンなコミュニティ
    • 世界で最も成功したOSS=Linuxでの成功実績に基づいた運営
    • さまざまな業種の企業およびIT企業、研究機関が240以上参加
    • Fabricをはじめ、複数ブロックチェーン/DLT基盤およびツール等をOSSとして開発
    Fabric : エンタープライズ領域汎用用途のためのブロックチェーン基盤
    • メンバー管理サービスを備えたパーミッションドブロックチェーンを実装
    • セキュリティ、機密性/プライバシーを強化するための多様な機能
    • スマートコントラクトによって業務を自動化
    • 大量処理をサポートするためのスケーラブル、プラガブルな設計
    • マイニングなどの大規模コンピューターパワー投入は不要&ファイナリティ有
    Hyperledger Fabric
    Copyright © 2022 Oracle and/or its affiliates
    8

    View Slide

  9. Hyperledgerのラインナップ
    Copyright © 2022 Oracle and/or its affiliates
    9
    Hyperledger projects
    From:https://www.hyperledger.org/

    View Slide

  10. ネットワーク参加の制限有無によるブロックチェーンの分類
    Copyright © 2022 Oracle and/or its affiliates
    10
    • 誰でもネットワークに参加しノードを持てる
    (公開制、オープン、匿名性)
    • 経済的インセンティブによって不正を抑止する
    比較的低速なトランザクション処理
    パーミッションレス a.k.a. パブリック
    • 招待されたメンバーのみが参加しノードを保持
    (許可制、クローズド、顕名)
    • メンバーを識別、一定程度信頼できることに依拠した
    高速なトランザクション処理
    パーミッションド a.k.a. プライベート

    View Slide

  11. ネットワークの参加者によるブロックチェーンの分類
    Copyright © 2022 Oracle and/or its affiliates
    パブリック
    公開制のネットワークを
    不特定多数で運用
    コンソーシアム
    許可制のネットワークを
    複数組織で運用
    プライベート
    許可制のネットワークを
    単一組織で運用
    パーミッションレス← →パーミッションド
    11

    View Slide

  12. よく比較検討されるエンタープライズブロックチェーン基盤
    a.k.a.「3大エンタープライズブロックチェーン」
    • 共通点は…
    • 許可制のネットワークを構成できる
    • コンソーシアムでの活用を意図した機能を備えている
    • すでに多くの利用実績がある
    • 基盤によって思想、個性の違いがあり、その結果としてユースケースの得意不得意がある
    12 Copyright © 2022 Oracle and/or its affiliates
    Quorum
    (& Besu)
    Hyperledger
    Fabric Corda

    View Slide

  13. しばしば「Hyperledger Fabricは難しい」と言われがちだが、「難しい」点は概ね以下3つ:
    • 機能が多く、要素と構造が多層的に絡みあっており複雑
    • トランザクションフローが独特
    • サンプルネットワーク構築チュートリアルのステップ数、必要となる前提知識が多い
    理解を妨げるありがちなパターンは:
    • そもそもブロックチェーン全般の知識がなく、なぜコンセンサス取らないといけないのかなどの前提からわかっていない
    • EthereumやQuorumを知っているが故に、そちらに引きずられてHLF独特の要素に混乱する
    • トランザクションフローの仕組みの意図、理由がわからない
    • 要素と独特な構造の関係がこんがらがる
    なぜ「Hyperledger Fabricは難しい」のか
    Copyright © 2022 Oracle and/or its affiliates
    13

    View Slide

  14. • 機能が多く、要素と構造が多層的に絡みあっており複雑
    • トランザクションフローが独特
    • サンプルネットワーク構築チュートリアルのステップ数、必要となる前提知識が多い
    「難しい」要素の傾向と対策
    Copyright © 2022 Oracle and/or its affiliates
    14
    Docker、NW設定など引っかかるところが多くネットワーク構築でめげてしまいがち
    • クラウド上で利用できるテンプレートやBaaSを利用してスキップしてしまうのがオススメ
    • 最近は公式ドキュメントやブログなどの情報も徐々に充実、親切になってはきている
    • 背景にある目的、思想をまずは抑えておくと理解しやすくなる
    • 他ブロックチェーン基盤にはないHLF独特なポイントを意識して学ぶと混乱しにくい

    View Slide

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

    View Slide

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

    View Slide

  17. Copyright © 2022 Oracle and/or its affiliates
    17
    1. Hyperledger Fabricを構成する基本的な要素

    View Slide

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

    View Slide

  19. Orderer
    Hyperledger Fabricネットワークの概観図
    19
    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

    View Slide

  20. 独特な点:ブロック生成専用のノードの分離と階層型アイデンティティの採用
    Organization
    • ネットワークに参加するメンバーの
    「組織」を表す抽象的な単位
    • コンポーネントやユーザーが所属
    Peerノード
    • 台帳(World StateとBlockchain)を保持
    • Chaincodeをリクエストに応じて実行する
    Ordererノード
    • ひとつ~複数のOrdererノードでOrdering
    Serviceを構成
    • トランザクションの順序を確定し、ブロックを生成し
    Peerノードに配布
    Chaincode(スマートコントラクト)
    • 台帳の更新、照会のビジネスロジック
    クライアントアプリケーション
    • Hyperledger Fabricを利用するアプリ
    CA(Certificate Authority)
    • 各コンポーネントやユーザーのアイデンティティ(証明
    書)を発行するPKIの認証局
    • 通常、Fabric CAを利用するが他の実装も利用可

    登場する要素、コンポーネント
    20 Copyright © 2022 Oracle and/or its affiliates

    View Slide

  21. Orderer
    Organization
    21
    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

    View Slide

  22. コンポーネント、ユーザーが所属するアイデンティティレイヤー
    • HLFにはネットワークに参加する主体(多くの場合は企業などの組織の単位、
    時には個人)を表現するための抽象アイデンティティレイヤーである
    Organization(Org)がある
    • Ordererノード、PeerノードおよびCAのコンポーネント、また、アプリケーションが
    用いるユーザーのアイデンティティは、必ずいずれかひとつのOrgに属する
    • (他の基盤のように具体的な秘密鍵単位ではなく)
    「どのOrg配下のコンポーネント/ユーザーか」に基づいて
    オペレーション、ガバナンス、ネットワーク構成を設計できる
    • PKIの階層構造と結びついている
    • 自身のOrg配下のコンポーネントやユーザー用の秘密鍵/証明書は自身
    のCAで発行する
    Organization
    Copyright © 2022 Oracle and/or its affiliates
    22
    Network
    Organization A
    Ordererノード
    Peerノード
    Adminユーザー
    Clientユーザー
    Organization B
    Ordererノード
    Peerノード
    Adminユーザー
    Clientユーザー
    Ordererノード
    Peerノード
    Adminユーザー
    Clientユーザー
    CA

    View Slide

  23. メッセージやデータのデジタル署名とその検証
    Copyright © 2022 Oracle and/or its affiliates
    23
    Client
    App
    Orderer
    Orderer
    Client
    App
    Peer Peer
    MSP
    MSP
    MSP
    MSP
    • やり取りされるメッセージ、およびその中のデータ(ブロック、ト
    ランザクションなど)にはデジタル署名が付与されている
    • 各ノードやユーザーのアイデンティティに紐づいた秘密
    鍵でデジタル署名を行う
    • 不正な送信者の介入や、メッセージ内容の中途での改
    ざんを防ぐ
    • 各コンポーネントの持つMSP(Membership Service
    Provider)というモジュールが署名の検証を担う

    View Slide

  24. エンドユーザー(消費者)のアイデンティティを扱うケース
    • Ethereum(およびパブリックブロックチェーン一般)では基本的にエンドユーザーが自身の秘密鍵を用いてトランザク
    ションに署名し発行する=エンドユーザーのブロックチェーン上のID(アドレス)が直接伝わってくる
    • 通常、HLFでは個々の消費者に対してはブロックチェーン上のIDを持たせない(割り当てない)
    • エンドユーザーが消費者の場合、トランザクションに署名し発行するのは中間オペレーター(のアプリ)
    • この場合、「トランザクション署名者がTokenのOwnerのIDと一致しているか」では権限制御できない
    • 必要に応じロールベース(RBAC)や属性ベース(ABAC)のオンチェーン権限制御ロジックを実装する
    24 Copyright © 2022 Oracle and/or its affiliates
    ウォレット
    (サーバーサイド)
    アプリ
    コントラクト
    Chaincode
    アプリの認証(ID/PW等)
    操作
    ブロックチェーンのトランザクション
    エンドユーザー(消費者)自身の秘密鍵で署名
    トランザクション
    アプリの抱える秘密鍵で署名
    Ethereum等
    パブリックBC
    Hyperledger
    Fabric
    消費者
    消費者

    View Slide

  25. Hyperledger Fabricにおけるスマートコントラクト
    • 所謂「スマートコントラクト」だが、単に「台帳の読み書きのロジック」と考えるとわかりやすい
    • 「RDBにおけるストアドプロシージャのようなもの」という説明もある
    • HLFでは多くの場合、Chaincodeはそれほど複雑にも大規模にもならない
    • 認証認可やプライバシーを基盤機能で担当するのでChaincode側でやるロジックはそれほどない
    • Ethereumにおけるスマコン(ERC、Open Zeppelin、etc.の学習が必須)とは事情はかなり異なる
    • 専用のライブラリを組み込んで台帳(World StateおよびBlockchain)にアクセス
    • 機能数は限られており習得は難しくない
    • Chaincode開発言語の選択肢:Node.js、Go、Java
    Chaincode
    Copyright © 2022 Oracle and/or its affiliates
    25
    Peerノード
    Ledger
    Chaincode

    View Slide

  26. • 各々が自身のPeerにInstallした後に、Channelで有効化することで実行可能に
    • 有効化の手続きはv1.x系とv2.x系で異なる(v2.x系ではオペレーションが一層分権化)
    • バージョンアップ可能:Chaincodeはバージョンアップできるため、稼働後も修正や改善が可能
    • 新バージョンで旧バージョンのChaincodeが書いたレコードにもアクセスできる
    Chaincodeのライフサイクル
    Copyright © 2022 Oracle and/or its affiliates
    26
    Install
    有効化 Upgrade
    新バージョン
    のInstall
    各Orgで行う
    ローカルな
    オペレーション
    ネットワークの
    オペレーション
    新バージョン
    稼働

    View Slide

  27. Hyperledger Fabricの種々の機能を利用するアプリケーション
    • クライアントアプリケーションはFabric SDKを通じてHLFの機能を使う
    • 基本的には台帳に関する読み書き関連の機能を利用
    • Peerノードに対してChaincode実行を依頼する
    • Peerノードから返ってきたEndorsementを集める
    • Ordering ServiceにTransactionを送付する
    • 機能の利用にあたってはCAから発行されたアイデンティティ(秘密鍵/証明書)を用いて
    認証する
    • Fabric SDKはNode.js版とJava版が正式リリース
    クライアントアプリケーション
    Copyright © 2022 Oracle and/or its affiliates
    27
    Client App
    Fabric SDK
    Peerノード
    Ledger
    Chaincode
    証明書

    View Slide

  28. Peer
    Peerノードが保持する分散台帳の1コピー
    Hyperledger Fabricにおける「台帳」
    28
    • 台帳は以下ふたつの要素から構成される

    Blockchain:履歴
    • トランザクションの履歴が格納される
    ハッシュチェーンで連結されたブロックのファイル
    • 追記オンリーで蓄積していく
    World State:状態
    • 各Keyに対する現在(最新)バージョンの値を保持
    • レコードは更新、削除が可能
    (履歴はBlockchainに残っている)
    • State DBと呼ばれるDBに格納される
    Ledger
    Peer
    Ledger
    Peer
    Ledger
    Peer
    Ledger
    Copyright © 2022 Oracle and/or its affiliates

    View Slide

  29. 台帳に保存される「現在の値(ステート)」とそれを保持するデータベース
    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 DB
    29 Copyright © 2022 Oracle and/or its affiliates

    View Slide

  30. ある程度柔軟なデータ構造を扱え、State DBによる検索の表現能力もそこそこ
    World Stateで扱うデータ構造の例
    Copyright © 2022 Oracle and/or its affiliates
    30
    Key:口座番号 Value:残高
    1020345 10,000,000
    1020346 56,400
    Key:アセット種別と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のアセットを全件取得)

    View Slide

  31. State DB内ではレコードにはKeyとValueの他にも以下の情報が付随している
    • Channel、Chaincode ID…どのChannelのどのChaincodeのレコードかを表し、名前空間として機能
    (Channel+Chaincode ID+Keyで一意)
    • Version…そのレコードはどのBlockのどのTransactionにより書き込まれたものかを示し、トランザクションの整合性検
    証に使用される(後で説明)
    State DB内に保持されているデータの付随情報
    Copyright © 2022 Oracle and/or its affiliates
    31
    Channel Chaincode ID Key Value Version
    ch1 accountCC 1020345 10,000,000 Block17,Tx5
    ch1 motorCC car^aaa111 {hogehoge... Block3,Tx1
    ch2 marbleCC marble123 {fugafuga... Block1,Tx3
    ch2 accountCC 3040567 300 Block1,Tx4

    View Slide

  32. 独特な点:ブロック生成専用のノードの分離と階層型アイデンティティの採用
    Organization
    • ネットワークに参加するメンバーの
    「組織」を表す抽象的な単位
    • コンポーネントやユーザーが所属
    Peerノード
    • 台帳(World StateとBlockchain)を保持
    • Chaincodeをリクエストに応じて実行する
    Ordererノード
    • ひとつ~複数のOrdererノードでOrdering
    Serviceを構成
    • トランザクションの順序を確定し、ブロックを生成し
    Peerノードに配布
    Chaincode(スマートコントラクト)
    • 台帳の更新、照会のビジネスロジック
    クライアントアプリケーション
    • Hyperledger Fabricを利用するアプリ
    CA(Certificate Authority)
    • 各コンポーネントやユーザーのアイデンティティ(証明
    書)を発行するPKIの認証局
    • 通常、Fabric CAを利用するが他の実装も利用可

    (再掲)登場する要素、コンポーネント
    32 Copyright © 2022 Oracle and/or its affiliates

    View Slide

  33. Copyright © 2022 Oracle and/or its affiliates
    33
    2. トランザクションフロー

    View Slide

  34. • HLFのトランザクションはフローが独特で「まわりくどい」「わかりづらい」と言われがち
    • ここでトランザクションとは、台帳を更新する一連の(1セットの)処理
    • しかしトランザクションの流れの理解は必須(細部はさておき)
    • トランザクションフローの理解が不足していると…
    • 発生するエラー(無効なトランザクション)の原因が理解できず対処できない
    • 不適切なChaincodeロジックおよびアプリケーションロジックを設計してしまう
    • パフォーマンスに問題が生じたときにボトルネックが特定できず対処できない
    • 各フェーズでのアクションが何のために行われているのか、全体としてどうしてそのような作りになっているのか、の目
    的を意識して学ぶと理解しやすい
    トランザクションフローをなぜ理解するべきか、どう学ぶべきか
    Copyright © 2022 Oracle and/or its affiliates
    34

    View Slide

  35. • 「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 affiliates
    35

    View Slide

  36. 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

    View Slide

  37. トランザクションフローの図
    Copyright © 2022 Oracle and/or its affiliates
    37
    Peer
    Chain
    Code Ledger
    Client
    App
    Orderer
    Orderer
    Orderer
    Client
    App
    Client
    App
    Peer
    Chain
    Code Ledger
    Peer
    Chain
    Code Ledger
    1
    1.5
    1.5
    1
    2
    2
    3
    3.5
    4
    4
    4
    5
    5
    5
    1)Transaction
    Proposal 送付 1.5)Chaincode
    実行 2) Endorsement
    返却
    3)Transaction
    送付
    3.5)Block生成
    4)Block配布
    5)Validation
    →Commit
    2.5) Endorsement
    収集
    2.5

    View Slide

  38. 38
    From: https://hyperledger-fabric.readthedocs.io/en/latest/txflow.html
    ①Transaction
    Proposal送付 (1.5)Chaincode実行
    (2.5)
    Endorsement収集
    ③Transaction送信
    ④Block配布
    (5)Validation
    →Commit
    (※)Tx Event通知
    ②Endorsement
    返却
    (3.5)Block生成
    Copyright © 2022 Oracle and/or its affiliates

    View Slide

  39. 何を、何のためにやっているのか?
    再掲)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

    View Slide

  40. トランザクション内容への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 Policy
    Copyright © 2022 Oracle and/or its affiliates
    40

    View Slide

  41. 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実行結果」とRWSet
    Copyright © 2022 Oracle and/or its affiliates
    41

    View Slide

  42. あるTransactionがWorld Stateから読んだレコード、書き込む(予定の)値











    RWSetの例 ※バージョンの形式は単純化しており正確なものではない
    Copyright © 2022 Oracle and/or its affiliates
    42
    • K1とK2のレコードを読んでいる
    • それぞれバージョンは”1”
    • K1に”V1”という値を、K3に”V2”という値を
    それぞれ書き込もうとしている
    • K4のレコードを削除しようとしている

    View Slide

  43. 再掲)Ordering:トランザクションの順序を確定しブロックを生成・配布する
    • Endorsementを集め終えたクライアントアプリケーションがTransactionを送付
    • 受け取ったOrdering ServiceがTransactionを詰めたBlockを生成、Peerノードに配布
    Ordering Service内にもコンセンサスがある:
    • Ordering Serviceは1~複数のOrdererノードから成るクラスター
    • このクラスターの中で受け取ったTransactionの順序を合意し決定している(現在はRaftを利用)
    Orderingフェーズ
    Copyright © 2022 Oracle and/or its affiliates
    43
    Client
    App
    Orderer
    Orderer
    Orderer
    Client
    App
    Client
    App
    Tx1
    Tx2
    Tx3
    Block
    Tx1
    Tx2
    Tx3
    Peer
    Peer
    Peer

    View Slide

  44. ブロック生成ノードを分権で持つ+冗長性により耐障害性を確保
    Ordering Serviceのクラスターとコンセンサス(Raftの場合)
    Copyright © 2022 Oracle and/or its affiliates
    44
    Peer
    Chain
    Code Ledger
    Client
    App
    Orderer
    Orderer
    Orderer
    Client
    App
    Client
    App
    Peer
    Chain
    Code Ledger
    Peer
    Chain
    Code Ledger
    L
    Raft
    コンセンサス
    どのOrdererノードに到達して
    もクラスター内で共有される
    その時点でLeaderの役割
    を持っているノードが
    Blockを生成する

    View Slide

  45. 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 affiliates
    45
    Block
    Tx1
    Tx2
    Tx3
    World State

    View Slide

  46. 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 Validation
    Copyright © 2022 Oracle and/or its affiliates
    46
    World State


    Key Value Version
    A 0 4
    不一致

    View Slide

  47. ロジックとデータの整合性がおかしくなってしまう例
    例:残高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 affiliates
    47

    View Slide

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

    View Slide

  49. 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

    View Slide

  50. どうしてこのようなフローになっているのか
    • スマートコントラクトロジック実行とブロック生成を分離できる
    • 比率的に重いChaincode実行はPeerノードに、トランザクション順序の決定とブロック生成はOrdering
    Serviceにそれぞれ分離することによる処理能力向上
    • ネットワーク規模拡大がスマートコントラクトロジック実行の処理負荷増大に直結しない
    • Endorsement Policy次第で、必ずしもネットワーク参加メンバー拡大に比例したかたちで冗長にChaincode
    実行をするPeerノードが増えていかない(→スケーラビリティ)
    • トランザクションの並列実行可能性の向上
    • Chaincode実行の処理量を複数Peerで水平分散できる
    • (更新するレコードが十分に分散している限りにおいて)同時/並列に処理できるトランザクション量を増やすこと
    ができる
    Endorsement・Ordering・Validationフローの主な利点
    Copyright © 2022 Oracle and/or its affiliates
    50

    View Slide

  51. Copyright © 2022 Oracle and/or its affiliates
    51
    3. ChannelとPrivate Data

    View Slide

  52. • ブロックチェーン/DLTはネットワーク内のすべてのノードで同一のデータを複製し共有するというのが基本のアイディア
    • 一方で、エンタープライズ領域ではあるデータをネットワークのうち一部の参加者にしか見せたくない、というニーズが頻出
    する
    • エンタープライズ用ブロックチェーン基盤ではこうしたニーズに応えるため、データ共有範囲をネットワークの一部に限定す
    るための機能を備えているものが多い
    エンタープライズブロックチェーン基盤のデータ共有範囲制御
    Copyright © 2022 Oracle and/or its affiliates
    52
    A B
    D
    C
    A B
    D
    C
    全データを全ノードで共有 一部のデータは限られたノードで共有

    View Slide

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

    View Slide

  54. • HLFネットワーク内のサブネットワークである
    • あるChannelにはネットワークのうち一部~全部のOrganizationが所属する
    • 更にPeerノードやOrdererノードにもChannelへの参加/不参加がある
    • Channelごとに台帳が存在する、すなわちChannelが台帳の共有範囲である
    • Channelごとにトランザクションが実行される
    Channelの概要
    Copyright © 2022 Oracle and/or its affiliates
    54
    OrgA Peer OrgB Peer OrgC Peer
    CH1 L1
    L2
    L1 L1
    L2
    L3 L3
    CH2
    CH3
    Org
    A
    Org
    B
    Org
    C

    View Slide

  55. 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 affiliates
    55

    View Slide

  56. ChannelとOrg、Ledger、Peer、Orderer、Chaincodeの関係の例
    Copyright © 2022 Oracle and/or its affiliates
    56
    P1 P2 P3 P4 P5 P6
    Ch1
    Peer
    Orderer
    Organization
    Channel
    Org
    A
    Org
    B
    Org
    C
    O1 O2 O3 O4 O5 O6
    Ch2
    CC1 L1
    L2
    CC2
    L2
    CC2 L2
    CC2 L2
    CC2
    L1
    CC1 L1
    CC1
    CC2
    CC1 CC1 CC1
    CC1

    View Slide

  57. Channel作成、ノード追加、Chaincodeインストール、Chaincode稼働の順序
    ChannelとOrg、Ledger、Peer、Orderer、Chaincodeの関係の例
    Copyright © 2022 Oracle and/or its affiliates
    57
    P1 P2 P3 P4 P5 P6
    Ch1
    Peer
    Orderer
    Organization
    Channel
    Org
    A
    Org
    B
    Org
    C
    O1 O2 O3 O4 O5 O6
    CC1 L1
    L1
    CC1 L1
    CC1
    ①Ch作成&
    参加Org定義
    ②OrgがChに
    ノードを追加
    ③Chに参加したPeerは
    Ledgerを保持
    ④OrgがPeerにCC
    をインストール
    ⑤ChでCCを稼働

    View Slide

  58. ChannelとOrg、Ledger、Peer、Orderer、Chaincodeの関係の例
    Copyright © 2022 Oracle and/or its affiliates
    58
    P1 P2 P3 P4 P5 P6
    Ch1
    Peer
    Orderer
    Organization
    Channel
    Org
    A
    Org
    B
    Org
    C
    O1 O2 O3 O4 O5 O6
    Ch2
    CC1 L1
    L2
    CC2
    L2
    CC2 L2
    CC2 L2
    CC2
    L1
    CC1 L1
    CC1
    CC2
    CC1 CC1 CC1
    CC1
    CCのInstall有無は
    Peer個別に選択
    Peerは
    ・複数Chに参加可
    ・複数CCを保持可
    Chは複数CCを
    稼働可能
    同一CCを複数Chで
    稼働可能
    (台帳は別)

    View Slide

  59. • あるトランザクションのうち一部のデータを一部のChannelメンバーに限定して共有する
    (他のメンバーからは隠す)オプショナルな機能としてPrivate Dataがある
    • 共有先Orgは事前に定義しておく…Private Data Collection定義
    • Private Dataの内容は台帳の外で保持され(※)、削除(Purge)が可能
    • つまりWorld Stateに載らない、Blockchainにも残らない
    Private Dataの概要
    Copyright © 2022 Oracle and/or its affiliates
    59
    OrgA Peer OrgB Peer OrgC Peer
    Channel 1
    L1
    PD1
    L1 L1
    Private Data
    Collection 1
    PD1
    ※Private Dataが台帳に含まれるかどうかはHLFの
    公式ドキュメント内でも記載がブレているが、台帳
    外であるとしたほうがわかりやすいのでここではそ
    のように整理する

    View Slide

  60. • 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 affiliates
    60
    {
    "name": "collectionMarbles",
    "policy": "OR('Org1MSP.member’,
    'Org2MSP.member’)”,
    ...
    }
    Peer Ledger
    Blockchain
    State DB
    PDC
    World
    State
    Private Data Collection定義の例

    View Slide

  61. • 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 affiliates
    61
    Ledger Block
    Tx World State
    PD Hash PD Hash
    PDC
    PD内容
    ハッシュ化

    View Slide

  62. Private Dataの絡むトランザクションフローの図
    Copyright © 2022 Oracle and/or its affiliates
    62
    Client
    App Peer
    PDC
    PD内容
    Chain
    Code
    Peer
    Ledger
    Chain
    Code
    Ordering
    Service
    1
    1.5
    2 Ledger
    Peer
    PDC
    Chain
    Code
    Ledger
    Peer
    PDC
    Chain
    Code
    Ledger
    PD内容
    1.5
    1
    2
    3 3.5
    4
    5
    PD内容
    4
    5
    5
    4 4
    5
    1)Transaction
    Proposal 送付
    1.5)Chaincode実行
    2) Endorsement返却
    3)Transaction送付
    (PD Hashを含むがPD内容は含まない) 3.5)Block生成
    2.5) Endorsement収集
    2.5
    PD内容を伝播
    (Gossipプロトコル)

    View Slide

  63. Copyright © 2022 Oracle and/or its affiliates
    63
    まとめの振り返り

    View Slide

  64. Orderer
    ポイントはOrganization
    Hyperledger Fabricネットワークの概観図
    64
    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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  69. View Slide