Hyperledger Fabricの成長、成熟を振り返る / Looking back history of Hyperledger Fabric

2024/8/29 Blockchain GIG#19 エンタープライズブロックチェーンの技術的進化のこれまでとこれから　で喋った内容
Hyperledger Fabricのリリース（前）からこれまでの技術的進化、改善点を整理し、今後の展望についても紹介

Transcript

1. Hyperledger Fabricの 成長、成熟を振り返る Blockchain GIG #19 エンタープライズブロックチェーンの技術的進化のこれまでとこれから 中村 岳 日本オラクル株式会社 クラウド・エンジニアリング／CoE統括／ソリューションアーキテクト部 2024/8/28
2. Copyright © 2024, Oracle and/or its affiliates 2 中村 岳 Twitter @gakumura はてなブログ @gakumura …主にHyperledger Fabric関連 • 現職：ソリューションエンジニア@日本オラクル • 担当：Oracle Blockchain Platform、 Blockchain Table、AI関連サービス • 前職：金融決済系SIerでパッケージ開発 • SWIFT、CLS、日銀ネット関連の銀行間決済システム
3. Hyperledger Fabricをベースにエンタープライズ利用向けPaaSとオンプレミスで提供 • 数ステップで構築完了、GUIコンソールで管理・運用も容易 • エンタープライズグレードの耐障害性、堅牢性 • マルチクラウド、ハイブリッドクラウド、 オープンなネットワーク構成が可能 • Oracle独自の付加価値： • State DBとしてBerkeley DBを利用：パフォーマンスとクエリ利便性向上 • 多機能なREST API：スマートコントラクトの利用を容易に • 台帳のデータをRDBに複製：大量照会、分析、データ統合 • スマートコントラクトを容易に開発：付属の開発ツールでアセット仕様からコードを自動生成 • 複数ChannelのアトミックトランザクションとXA対応：複数Channelでの更新のアトミックな実行 や、ローカルのDB、MQなどとのグローバルトランザクションをサポート Oracle Blockchain Platform Copyright © 2024, Oracle and/or its affiliates 東京DCからも サービス提供中 3
4. セッションの内容 • Hyperledger FabricとHyperledger Foundationのキホン • Hyperledger Fabricの黎明期 ~~v1.0以前~~ • v1.0での主要な変更点 • v1.x系での主だった改善点 • v2.x系での主だった改善点 • Hyperledger Fabricのこれまでとこれから 4 Copyright © 2024, Oracle and/or its affiliates
5. Copyright © 2024, Oracle and/or its affiliates 5 Hyperledger Fabricと Hyperledger Foundationのキホン
6. エンタープライズ用途を目的として開発されたブロックチェーン Hyperledger Foundation: Linux財団がホストするオープンなコミュニティ • 世界で最も成功したOSS=Linuxでの成功実績に基づいた運営 • Fabricをはじめ、複数ブロックチェーン/DLT基盤およびツール等をOSSとして開発 Fabric : 汎用ビジネス利用のためのブロックチェーン基盤 • メンバー管理サービスを備えたパーミッションドブロックチェーンを実装 • セキュリティ、機密性/プライバシーを強化するための多様な機能 • スマートコントラクトによって業務を自動化 • 大量処理をサポートするためのスケーラブル、プラガブルな設計 • マイニングなどの大規模コンピューターパワー投入は不要＆ファイナリティ有 Hyperledger Fabric Copyright © 2024, Oracle and/or its affiliates 6 6
7. Hyperledger Foundation エンタープライズ向けのブロックチェーン技術の開発、活用を推進するためのOSSコミュニティ • 2016年に組成し、ITおよび様々な業界から130超の企業メンバーが参加：Premier 3 / General 61 / Associate 71（2023年7月現在） • 名称をHyperledgerからHyperledger Foundationへと変更（2021年10月） 7 Copyright © 2024, Oracle and/or its affiliates 技術的およびビジネス上の ガバナンスに支えられた、 エンタープライズブロックチェーン に関連したニュートラルでオー プンなコミュニティを提供する 分散台帳によって実現される 業界横断的なプラットフォーム の開発と活用を促進する エンタープライズ利用に適した ブロックチェーン技術の 市場機会を広く啓蒙する
8. Hyperledgerのブロックチェーン Copyright © 2024, Oracle and/or its affiliates パブリック 公開制のネットワークを 不特定多数で運用 コンソーシアム 許可制のネットワークを 複数組織で運用 プライベート 許可制のネットワークを 単一組織で運用 パーミッションレス← →パーミッションド 8 8
9. プロジェクトの種類 9 Copyright © 2024, Oracle and/or its affiliates • ブロックチェーンを利用するアプリケーションを 開発、実現するために用いられるライブラリ • ウォレット（エージェント）、Verifiable Credential関連のものなど • 種々のツール • ノードやネットワークのデプロイや管理の補助、 パフォーマンス計測、クロスチェーンのインテグレー ション／インターオペラビリティなど Libraries Tools • ブロックチェーン／分散台帳のプロトコルそのもの • これらを使いノードやブロックチェーンネットワークを 構成する Distributed Ledgers
10. Copyright © 2024, Oracle and/or its affiliates 10 Hyperledger Fabricの黎明期 ~~v1.0以前~~
11. “Hyperledger Fabric“のできるまで • 一般的にはIBMとDigital Asset社によりHyperledger（現：Hyperledger Foundation）への ContributionによりHyperledger Fabricが誕生した、とされている • 初期のHyperledger Fabricのコードの成り立ち： • Digital Asset社のHyperledger…もともとは買収したHyper社が開発していたブロックチェーン基盤プロダクト （HyperのLedgerなのでHyperledger） • ※Digital Asset社は”Hyperledger”という名前の利用権も現Hyperledger Foundationに譲ったということになる • IBMのOpen Blockchain…ハッカソンが元らしい、OpenChainという名前だったが商標権の問題により改名 • ＋ Libconsensus…Blockstream社が開発し、Bitcoin Coreコードベースに含まれていたライブラリ • 参考： • On the origins of Hyperledger Fabric： https://www.linkedin.com/pulse/origins-hyperledger-fabric-maciek-j%C4%99drzejczyk/ • What is the difference between Hyperledger and Hyperledger?： https://www.ofnumbers.com/2016/03/05/what-is-the-difference-between-hyperledger-and-hyperledger/ 11 Copyright © 2024, Oracle and/or its affiliates
12. ざっくりリリースタイムラインの振り返り Copyright © 2024, Oracle and/or its affiliates 12 v0.5* 2016/6/17 v0.6* 2016/9/16 v1.0 2017/7/11 v1.1 2018/3/15 v1.2 2018/7/3 v1.3 2018/10/10 ★ v1.4 2019/1/9 v2.0 2020/1/29 v2.1 2020/4/15 ★ v2.2 2020/7/20 v2.3 2020/11/18 v2.4 2021/11/29 ★ v2.5 2023/3/31 2016 2024 2017 2018 2019 2020 2021 2022 2023 *：Previewリリース ★：LTS（Long Term Support）
13. Hyperledger Fabric v1.0以前（v0.6まで）の大きな違い • コンセンサスアルゴリズムとしてPBFT（Practical Byzantine Fault Tolerant）を採用！ • ※厳密にはPluggableだが、公式にサポートされているのがPBFT（とNone）のみ • トランザクションフローもv1.0以降とぜんぜん違う！ • PeerのうちLeaderがOrdering →Validator Peer全員がExecution →PBFTで合意→Commit 13 Copyright © 2024, Oracle and/or its affiliates 図の引用元：Study on Integrity and Privacy Requirements of Distributed Ledger Technologies https://www.researchgate.net/publication/328334995_Study_on_Integrity_and_Privacy_Require ments_of_Distributed_Ledger_Technologies
14. 【ざっくり】 BFT（Byzantine Fault Tolerant）ってなんだっけ？？？ • BFTとはn個のノードからなる分散システムの合意プロセスにおいて、故障ノードの個数をfとしたときにn=3f+1を満たす 場合に任意の故障（ビザンチン障害）に対して安全な合意を達成できる、という性質 • ビザンチン障害…通常の故障による誤応答や障害による非応答以外の、悪意による改ざんや非応答を含む • 名前はビザンチン将軍問題（裏切り者の指揮官がいる場合に安全な情報交換を達成するには…？）に由来 • ざっくり言うと、「集団内に3分の1未満の人数の嘘つきが紛れ込んでいても、残りが正直者なら真正な情報につい て合意できるよね」ということ • PBFT、BFT-SMaRt、Tendermint-BFTなど複数の実装がある • BFTに対してCFT（Crash Fault Tolerant）と呼称される合意手法もある • CFTではクラッシュ障害に対して、n=2f+1であれば合意可能→過半数が正常稼働していれば合意できる • クラッシュ障害…いわゆるふつうの故障、示し合わせての改ざんなどは含まない • Kafka、Paxos、RaftなどはCFTにあたる 14 Copyright © 2024, Oracle and/or its affiliates
15. Copyright © 2024, Oracle and/or its affiliates 15 Hyperledger Fabric v1.0での主要な変更点
16. 主要な変更点 • v1.0.0（正式）リリース：July 11, 2017 • 主だった変更点（★は後述） • ★トランザクションフロー、コンセンサスアルゴリズムの刷新 • メンバーシップ管理の改善…v0.6まではメンバーシップサービスが認証局を単独で管理し単一障害点となっていた が、認証局が分散配置され単一障害点が排除 • ★Endorsement Policyの導入 • ★Organizationの導入 • ★Channelの導入 • 全体として、BitcoinやEthereumなどの先行（パブリック）ブロックチェーン基盤の影響を脱し、「エンタープライズ領域 向けのパーミッションドブロックチェーン基盤としてどうあるべきか」という考え方で作り直された感 16 Copyright © 2024, Oracle and/or its affiliates
17. トランザクションフロー、コンセンサスアルゴリズムの刷新 • フローがExecute→Order→Validateに • まずロジックを実行 →結果をOrderingしてBlockに詰め配布 →各PeerでValidateしてCommit • Orderingの役割がPeerから分割 →Orderer NodesによるOrdering Service • Ordering ServiceにはKafkaを採用 • ※厳密にはPluggableだが Kafka（とSolo）のみサポート • （Ordering Serviceのコンセンサスも）PBFTではない！ • いまだに「FabricはPBFT！」と誤解している方もちらほら… • いまも英語版WikipediaにはPBFTと書いてあった… • スループットの向上、スケーラビリティが改善 • ここではトランザクションフローを詳しく説明しないので、理解したい方は「Hyperledger Fabric（再）入門」を参照： https://speakerdeck.com/gakumura/blockchain-gig-number-9-hyperledger-fabric-zai-ru-men 17 Copyright © 2024, Oracle and/or its affiliates 図の引用元：Study on Integrity and Privacy Requirements of Distributed Ledger Technologies https://www.researchgate.net/publication/328334995_Study_on_Int egrity_and_Privacy_Requirements_of_Distributed_Ledger_Technologi es
18. 【個人の感想】 BFTでなくていいんだっけ？？？ • Orderingのコンセンサス手法がBFTではなくCFTになったということは、Ordering参加者の悪意による改ざんや非応 答などによって（悪意をもった者が3分の1未満でも）合意＝トランザクションの成立を妨害可能な攻撃方法が存在 するということ • ブロックチェーン（あるいは分散システム）としてのセキュリティが低下したという評価になる • ただし、誰が不正をしたのかの責任追及可能性＝Accountabilityは確保されている • BFTの成立によるセキュリティ向上はスループット／トレーサビリティとトレードオフの関係にある • Hyperledger Fabricが用いられるコンソーシアム型のユースケースの多くの場合において、コンソーシアム内のメンバー には一定の信頼があり、不正の牽制につながるAccountabilityがあればBFTでなくCFTで十分、というのはひとつの合 理的な態度とみなしてよいと考える • 一方で、BFTがほしいケースもあり得るのでBFTのOrdering Serviceはv1.xの時期から要望およびロードマップにある 18 Copyright © 2024, Oracle and/or its affiliates
19. Endorsement Policyの導入 • Endorsement Policy：あるトランザクションを台帳に反映するためには、PeerからどのようなEndorsement（トラン ザクションでの台帳の更新内容に対しての署名）を集めてこなければならないかの条件を予め定義しておく • ざっくり言うと「どうしたらコンセンサスが取れたことにするか」ということ • 全PeerでExecution（Chaincode＝スマートコントラクトのロジックの実行）をしなくて良くなった • 柔軟な設定が可能 • 「全Org必須」、「単一OrgのみでOK」、 「過半数のOrgで成立」、「特定のOrgが必須」 などなど • トランザクションに必要な処理リソースの 削減ができ、スループット＆スケーラビリティ向上 19 Copyright © 2024, Oracle and/or its affiliates
20. Organizationの導入 コンポーネント、ユーザーが所属するアイデンティティレイヤー • ネットワークに参加する主体（多くの場合は企業などの組織の単位、時には 個人）を表現するための抽象アイデンティティレイヤーである Organization（Org）が導入 • Ordererノード、PeerノードおよびCAのコンポーネント、また、アプリケーション が用いるユーザーのアイデンティティは、必ずいずれかひとつのOrgに属する • （他の基盤のように具体的な秘密鍵単位ではなく） 「どのOrg配下のコンポーネント／ユーザーか」に基づいて オペレーション、ガバナンス、ネットワーク構成を設計できる • PKIの階層構造と結びついている • 自身のOrg配下のコンポーネントやユーザー用の秘密鍵／証明書は自 身のCAで発行する 20 Copyright © 2024, Oracle and/or its affiliates Network Organization A Ordererノード Peerノード Adminユーザー Clientユーザー Organization B Ordererノード Peerノード Adminユーザー Clientユーザー Ordererノード Peerノード Adminユーザー Clientユーザー CA
21. Orderer Organizationの概念図 Copyright © 2024, Oracle and/or its affiliates 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 Org A Org B Org D Org C
22. Channelの導入 • HLFネットワーク内のサブネットワークである • あるChannelにはネットワークのうち一部～全部のOrganizationが所属する • 更にPeerノードやOrdererノードにもChannelへの参加／不参加がある • Channelごとに台帳が存在する、すなわちChannelが台帳の共有範囲である • Channelごとにトランザクションが実行される Copyright © 2024, Oracle and/or its affiliates 22 OrgA Peer OrgB Peer OrgC Peer CH1 L1 L2 L1 L1 L2 L3 L3 CH2 CH3 Org A Org B Org C
23. 参考：エンタープライズブロックチェーン基盤のデータ共有範囲制御 • ブロックチェーン／DLTはネットワーク内のすべてのノードで同一のデータを複製し共有するというのが基本のアイディア • 一方で、エンタープライズ領域ではあるデータをネットワークのうち一部の参加者にしか見せたくない、というニーズが頻出 する • エンタープライズ用ブロックチェーン基盤ではこうしたニーズに応えるため、データ共有範囲をネットワークの一部に限定す るための機能を備えているものが多い 23 Copyright © 2024, Oracle and/or its affiliates A B D C A B D C 全データを全ノードで共有 一部のデータは限られたノードで共有
24. Copyright © 2024, Oracle and/or its affiliates 24 Hyperledger Fabric v1.x系での 主だった改善点
25. 主だった改善点 • v1.1 • Node.js Chaincodeのサポート • パフォーマンスの改善…いろいろとありスループットが10倍くらいになった • Event Serviceの導入…フィルタ条件を指定しておくとイベント通知をくれる • v1.2 • ★Private Data Collectionの導入 • Service Discoveryの導入…動的にネットワーク上のノードやChannelなどのトポロジを取得してくれるため、クライ アントアプリ側で事前に静的に設定を書いておかなくてよくなった • v1.3 • Key-level Endorsement Policyの追加…Endorsement Policyをより細かく指定できるように • Java Chaincodeのサポート • v1.4 • ★Raft Ordering Serviceのサポート • クライアントSDKに追加された、より抽象化されたAPIをサポート 25 Copyright © 2024, Oracle and/or its affiliates
26. • あるトランザクションのうち一部のデータを一部のChannelメンバーに限定して共有する （他のメンバーからは隠す）オプショナルな機能としてPrivate Dataがある • 共有先Orgは事前に定義しておく…Private Data Collection定義 • Private Dataの内容は台帳の外で保持され（※）、削除（Purge）が可能 • つまりWorld Stateに載らない、Blockchainにも残らない Private Data Collectionの導入 Copyright © 2024, Oracle and/or its affiliates 26 OrgA Peer OrgB Peer OrgC Peer Channel 1 L1 PD1 L1 L1 Private Data Collection 1 PD1 ※Private Dataが台帳に含まれるかどうかはHLFの公式ド キュメント内でも記載がブレているが、台帳外であるとしたほ うがわかりやすいのでここではそのように整理する
27. • 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 © 2024, Oracle and/or its affiliates 27 { "name": "collectionMarbles", "policy": "OR('Org1MSP.member’, 'Org2MSP.member’)”, ... } Peer Ledger Blockchain State DB PDC World State Private Data Collection定義の例
28. • 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 © 2024, Oracle and/or its affiliates 28 Ledger Block Tx World State PD Hash PD Hash PDC PD内容 ハッシュ化
29. Raft Ordering Serviceの導入 • Raftプロトコルにより分散合意するOrdering Serviceをサポート • Kafka Ordering Serviceはv2.x系ではdeprecatedに • Kafka Ordering Serviceは（事実上）ひとつの組織によるOrdererノードの独占が 必要だったが、Raft Ordering Serviceでは複数組織（Org）に分散して所有／管 理されるOrdererノードからクラスタを構成できるように • 別のOrdererノードから成る複数のOrdering Serviceクラスタを構成し、Channelごと に使い分けることも可能に • ワークロード分散によるスケーラビリティ観点と、Channelごとの台帳の秘匿観点で 有意義 • Kafka/ZooKeeperは構築、運用が煩雑だったがRaftはシンプル • （あとなんかRaft Ordering Serviceのほうが意外と速いらしい） 29 Copyright © 2024, Oracle and/or its affiliates O3 O2 O1 O4 O5 Ordering Service 1 for Channel 1 Ordering Service 2 for Channel 2
30. Copyright © 2024, Oracle and/or its affiliates 30 Hyperledger Fabric v2.x系での 主だった改善点
31. 主だった改善点 • v2.0 • Chaincode Lifecycle関連の変更…Chaincodeのデプロイや更新時のオペレーションについて、より分散したOrgでの適切な運 用ができるような改善が様々入った＆いろいろとシンプルになり便利になった • Private Data関連の改善…Private Data Collection単位でのEndorsement Policyの設定が追加された＆暗黙のPer-Organization Collectionが追加された • Chaincode稼働環境関連の選択肢追加…Dockerコンテナ意外も手組みできるように • Docker ImageでAlpine Linuxを使用…イメージが軽量に • v2.3 • OrdererのChannel管理にSystem Channelが不要に…やや運用しやすくなった？ • 台帳スナップショット（Ledger Snapshot）機能の追加…ストレージ容量節約可能＆新規ノード追加高速化 • v2.4 • ★PeerのFabric Gatewayサービスと新しいモデルのクライアントSDKの追加 • PeerノードのChannelからの離脱（Unjoin）が可能に…ストレージ容量節約可能に • v2.5 • Private Dataのヒストリーを含めた削除（Purge）操作が可能に…ストレージ容量節約可能に 31 Copyright © 2024, Oracle and/or its affiliates
32. PeerのFabric Gatewayサービスと新しいモデルのクライアントSDKの追加 • クライアントアプリケーション側でやっていた必要なPeerへのTransaction Proposal送信（といってもSDK側で Service Discoveryを使ってよきようにやってくれてはいた）とEndorsementの受け取りを、Peer側に追加された Fabric Gatewayサービスに任せられるようになった • 合わせてクライアント側SDKにもGateway追加に対応した新APIモデルが追加されている 32 Copyright © 2024, Oracle and/or its affiliates Org A Client App Org A Peer1 Org B Peer2 Org C Peer3 SDK Org A Client App Org A Peer1 Org B Peer2 Org C Peer3 新 SDK Org D Peer4 Org D Peer4 Gateway
33. Copyright © 2024, Oracle and/or its affiliates 33 Hyperledger Fabricのこれまでとこれから
34. ざっくりリリースタイムラインの振り返り Copyright © 2024, Oracle and/or its affiliates 34 v0.5* 2016/6/17 v0.6* 2016/9/16 v1.0 2017/7/11 v1.1 2018/3/15 v1.2 2018/7/3 v1.3 2018/10/10 ★ v1.4 2019/1/9 v2.0 2020/1/29 v2.1 2020/4/15 ★ v2.2 2020/7/20 v2.3 2020/11/18 v2.4 2021/11/29 ★ v2.5 2023/3/31 2016 2024 2017 2018 2019 2020 2021 2022 2023 *：Previewリリース ★：LTS（Long Term Support） リリース頻繁＆派手な機能追加も多め →成長の時期 リリース間隔が広くなり、変更内容も運用観点の地味なものが多め →成熟の時期
35. Hyperledger Fabricのこれから：Roadmapを覗いてみよう https://wiki.hyperledger.org/display/fabric/Hyperledger+Fabric+Roadmap • Fabric v3.0 • BFT Ordering Service • 待望？のBFTなOrdering Serviceが追加される • CFTのRaftより遅い（と思う）ので今後は使い分けていくことになるはず？ • Fabric v3.x potential future items • Binary chaincode builder - replace default docker builder • Optimize block storage, e.g. de-duplication of certs • Replace Goleveldb with faster database • Validation/Commit path performance improvements • Orderer snapshots RFC - similar to peer snapshots introduced in v2.3 • Block archive and prune - peer and orderer • Quantum safe crypto 35 Copyright © 2024, Oracle and/or its affiliates
36. Hyperledger Meetupもよろしく！ https://www.meetup.com/ja-JP/hyperledger-tokyo/ 36 Copyright © 2024, Oracle and/or its affiliates 前回は • Hyperledger Foundationの Executive DirectorのDanielaさん • 日本企業初のHyperledger Fabric コアメンテナに就任した日立の佐藤さん が登壇！
37. Thank you Copyright © 2024, Oracle and/or its affiliates 37