Hyperledger概要と技術課題 (Theory Meets Blockchain Engineering (TMBE)での登壇発表資料)

2024/01/26-27に開催されたブロックチェーンエンジニアと暗号系研究者が交流/議論するワークショップイベントTMBE(Theory Meets Blockchain Engineering)の中で、エンジニアTalk枠で登壇発表したHyperledger関連の内容です。

TMBE
http://bsafe.network/TMBE/public/

Transcript

1. © Hitachi, Ltd. 2024. All rights reserved. Hyperledger概要と技術課題 日立製作所 研究開発グループ 2024/01/27 佐藤竜也 (Tatsuya Sato) 池川航史 (Koshi Ikegawa) 長谷川学 (Manabu Hasegawa) Theory Meets Blockchain Engineering (TMBE)
2. 1 © Hitachi, Ltd. 2024. All rights reserved. はじめに 我々はエンタープライズ向けブロックチェーンのオープンソースコミュニティで あるHyperledger Foundationに参画し、オープンな開発に貢献する とともに、開発されたソフトウェアを活用したサービス創生に取り組んでい ます。 本セッションでは、Hyperledger Foundationについて我々が特に着 目してきたプロジェクトを中心に紹介し、そのセキュリティ観点での課題に ついて共有します。
3. 2 © Hitachi, Ltd. 2024. All rights reserved. 本発表のアジェンダ 1. Hyperledger Foundation全体概要 2. Hyperledger Fabric (パーミッションドブロックチェーン基盤) について 3. Hyperledger Aries/Indy (SSI/VC) について 4. (具体ユースケース紹介 (ブロックチェーン×物流))
4. 3 © Hitachi, Ltd. 2024. All rights reserved. 1. Hyperledger Foundation全体概要
5. 4 © Hitachi, Ltd. 2024. All rights reserved. 1-1. Hyperledger Foundation Premier (5社) General (60社) Associate (69) (NPO、学術機関、公共機関、 他OSSプロジェクト等) (2024/01現在) エンタープライズ向けブロックチェーン技術を開発するためのOSSコミュニティ オープンガバナンスの下、様々な企業や組織が参加 – 2016年にLinux Foundationが設立 – 日立は設立(2016年)当初からPremier Memberとして参加 – ソフトウェア開発(後述のFabricを中心にパッチ投稿、機能提案、サブPJメンテナ)や国内外 での啓蒙活動(日本チャプター、ドキュメント翻訳、ミートアップ登壇)を通じて幅広く貢献中
6. 5 © Hitachi, Ltd. 2024. All rights reserved. 1-2. Hyperledger傘下のプロジェクト Distributed Ledgers Libraries Tools (2024/01現在) アンブレラ型の運営方式を採用し、様々な種類のプロジェクトが存在 パブリック/プライベートネットワーク両方 に利用できるEthereumクライアント (メインネットのノード全体の10%+で利用) パーミッションド パーミッションド/パーミッションレス両方可 構築/開発 ツール Interoperability SSI/VC Solidityコンパイラ SSI/VCエコシステムを形成 機能や得意分野の異なる複数の分散台帳実装が存在 本日紹介 本日紹介 SSI: Self-Sovereign Identity VC: Verifiable Credential
7. 6 © Hitachi, Ltd. 2024. All rights reserved. 補足. ブロックチェーンの分類 ネットワーク参加者に対する制限有無により、パブリック型とコンソーシアム型が存在 パブリックブロックチェーン コンソーシアムブロックチェーン 概要 公開性のネットワークを不特定多 数で運用 許可制のネットワークを複数組織 で運用 ノード運用者 不特定多数 (パーミッションレス) 許可された複数組織 (パーミッションド) エンドユーザ 誰でも (オープン) 認証されたユーザ (クローズド) データ共有範囲 パブリックに公開 参加組織がクローズドに共有 合意形成アルゴリズム 不特定多数での取引の 信頼確保 (PoW, PoS) 特定組織間での高速取引 (分散システム由来) 実装ソフトウェア Hyperledger Besu Hyperledger Fabric, Corda Hyperledger Besu PoW: Proof of Work PoS: Proof of Stake
8. 8 © Hitachi, Ltd. 2024. All rights reserved. 2. Hyperledger Fabric (パーミッションドブロックチェーン基盤) について
9. 9 © Hitachi, Ltd. 2024. All rights reserved. 2-1. Hyperledger Fabric エンタープライズ向けパーミッション型ブロックチェーンプラットフォーム – エンタープライズ利用に求められる要件に対応した機能/非機能を提供 • 幅広い業界/ユースケースに対応可能な汎用的な仕組み • 性能確保/向上のためのアーキテクチャ設計 • コンソーシアム内でのデータアクセス制御機能を提供 – 本番適用に向けた安定性やサポート状況 • 成熟していることを示す”Graduated”ステータスのプロジェクト • コミュニティ内で開発ロードマップが策定されており継続的に開発が進んでいる • 特定バージョンについてコミュニティによりLong Term Support (LTS)される – ‘23年3月に新しいLTS版であるv2.5系がリリース • 複数の事業者がBlockchain as a Service (BaaS)として提供 Graduated
10. 10 © Hitachi, Ltd. 2024. All rights reserved. サプライチェーン/トレーサビリティ 金融分野 2-2. Hyperledger Fabricのユースケース • 様々な業種でB2Bユースケースを中心に活用されている (本番・実証中含む) – 以下ではLinux FoundationおよびHyperledger Foundationの公式ページ (Publications, Wikiなど)に掲載される事例を中心にいくつか抜粋 貿易金融 (GSBN): GSBN は海運コンソーシアムである。 BCを活用しステークホルダー が関わる貨物リリースや貿易 金融プロセスのデジタル化。 ヘルスケア 食品サプライチェーン (Walmart): 食品の出所追跡を数秒に短縮。 同社は25+の食品に適用済で葉 物野菜に義務付けなど範囲拡大。 ダイヤモンド管理 (EverLedger): ダイヤの出自情報や取引来歴を BC上で管理する。 CBDC (各国事例): ナイジェ リア(eNaria)では本番稼働中。 保険 (openIDL): 米国にて 保険会社と規制者間での データ共有を安全/効率化。 製造部品管理 (GoDirect Trade): 中古航空機部品マーケットプレイス 。部品ライフライクル全体を記録。 購入時間が数日から数分に短縮。 サステナブル/ESG 医療品サプライチェーン (BRUINchain): 医薬品の 供給をリアルタイムに薬局の 冷蔵庫レベルまで追跡可能。 (*) 留意点: 各リンクの通り、主にケーススタディやホワイトペーパーなどに記載の情報に基づくため最新の情報でない可能性があります。 ESG情報可視化 (4AIR社 (HyperledgerClimate記事より)): 持続可能な航空燃料(SAF) のカーボンフットプリントにBC を活用。航空燃料バッチを トークン化して流通管理。
11. 11 © Hitachi, Ltd. 2024. All rights reserved. 2-3. Hyperledger Fabricの技術的特徴 • エンタープライズ向けパーミッション型ブロックチェーンプラットフォーム – あらかじめ許可された参加「組織」でコンソーシアム(ブロックチェーンネットワーク)を形成 • 「組織」 (Organization) をトラストの単位とする – 電子証明書(X.509)によるアイデンティティ – スマートコントラクトは「チェーンコード」(chaincode)と呼ばれる • 汎用的なプログラミング言語(Go, JavaScript, Java)で記述 • 主な特徴 – データモデル: ブロックチェーンとステートデータベース(最新状態のスナップショット)を保持 – コンセンサス: Endorse-Order-Validateモデル (性能向上のためv1.0でアーキ大幅改定) – データアクセス制御: レベルの異なるデータアクセス制御の仕組みを提供 Graduated
12. Peer Chaincode 2-4. Hyperledger Fabricコンセンサス処理フロー • Execute-Order-Validateモデルで複数組織間でのTXを承認 – FabricではトラストモデルをTX順序とTX検証の2つに分割 – トラストモデル: TX順序は合意プロトコルに、TX検証はエンドースメントポリシー設定に依存 Peer Chaincode Client Ordering Service Peer Chaincode CA (1-1) TX提案送信 (1-2) (仮)実行 (1-3) エンドースメント (2-1) エンドースメント済TX提案送信 (2-2) ブロック生成/配布 (3) 検証 秘密鍵/証明書発行 Org1 Org2 Org3 (*) CA: Certificate Authority, TX: Transaction CA CA Client Client (3) (3) (1-1) (1-3) (1-2) Orderer Node Orderer Node … Orderer Node
13. 13 © Hitachi, Ltd. 2024. All rights reserved. 2-5. Hyperledger Fabricにおけるデータアクセス制御 • チャネル – コンソーシアムに所属する組織の部分集合 (イメージとしてはサブネットワーク) – LedgerやChaincodeはチャネルごとに管理される • 少なくとも一つのチャネルが必要 – チャネル内ではブロック・ステート・Chaincodeは共有 • プライベートデータ – チャネル内でアクセス可能な組織を限定したデータ • 範囲などはプライベートデータコレクションとして定義 – ブロック(チャネル内すべての組織に公開)には、 書き込んだキー・値のハッシュ値のみ記録 • データプライバシーを維持しつつ検証可能とする Org1 Org2 Org3 Org4 CH1 CH2 PDC L1 L1 L2 L2 PD PD ハッシュ値のみ 公開/記録 CH: Channel L: Ledger PDC: Private Data Collection PD: Private Data L1 L1 L2
14. 14 © Hitachi, Ltd. 2024. All rights reserved. 2-6. Hyperledger Fabricのセキュリティに関する議論ポイント • 単一信頼点を回避するシステム設計/運用設計 – 信頼性と処理効率を考慮した適切なエンドースメントポリシー設計/設定管理が必要 – ガバナンス/システム運用面でも単一信頼点を排除するべき (オンチェーンでの設定管理は 仕組みとしては実現済みであとはいかに正しく活用するか) システム全体として単一信頼点がないことの評価方法をどうするべきか？ • 証明書まわりの運用 – 組織ごとに手作業ベースで証明書更新管理 (期限切れで大混乱した事例も) • スマートコントラクト(Chaincode)の脆弱性 – パブリック型ではない分不特定多数には晒されないものの、汎用的なプログラミング言語で 記述できるため自由度が高く脆弱性混入リスクあり 検出ノウハウ/ツールは未成熟 • Fabric Private Chaincode – TXおよびデータの内容を秘匿(暗号化)した状態でChaincodeの実行を可能とする • TEEと呼ばれるCPUに搭載されるセキュリティ機能を活用 (具体的にはIntel SGXを利用) 利用できるインスタンスが限定されることや性能面から実用はなかなか難しい (*) TEE: Trusted Execution Environment
15. 15 © Hitachi, Ltd. 2024. All rights reserved. 3. Hyperledger Aries/Indy (SSI/VC) について
16. 16 © Hitachi, Ltd. 2023. All rights reserved. 3-1. 自己主権型ID (Self-sovereign Identity, SSI) Issuer （企業や政府、団体） Holder （個人などのID保有者） Verifier （サービスプロバイダなど） VDR (Verifiable Data Registry) Blockchain, Secure DB, etc… Wallet Private key Verifiable Credentials VC (Verifiable Credential) を発行 VP (Verifiable Presentation) を提示 Schema* CRED_DEF* を登録 CRED_DEFを 取得してVPを検証 Schema Cred_def *SCHEMA – VCのClaim定義を持つ *CRED_DEF- Credential Defiintion. Schemaの各Claimに対する公開鍵などを持つ
17. 17 © Hitachi, Ltd. 2023. All rights reserved. 3-2. Hyperledger SSI Projects ❚ Hyperledger Indy (Blockchain, VDR) • SSIの実現に特化したHyperledger管轄のPublic-Permissioned Blockchain – ノードの所有者は信頼されている組織・団体（Permissioned） – VC発行検証に関するトランザクションのR/Wは基本的に誰でも可能（Public） • DID Documentsを保存するためのVDRとして利用 ❚ Hyperledger Aries (SSI Agent, ユーザクライアント) • SSIを実現するAgent機能実現するライブラリ • Verifiable Credentials (VCs) 、DIDの操作、およびAgent間のメッセージング等の機能 ❚ Hyperledger AnonCreds (VCの仕様, その実装、ライブラリ) • ゼロ知識証明暗号を利用したプライバシー保護機能をサポートする検証可能な証明書の仕様 • Ariesに組み込む形で実装されているライブラリ
18. 18 © Hitachi, Ltd. 2023. All rights reserved. 3-3. Hyperledger SSI Projectsとのマッピング Issuer （企業や政府、団体） Holder （個人などのID保有者） Verifier （サービスプロバイダなど） VDR (Verifiable Data Registry) Blockchain, Secure DB, etc… Wallet Private key Verifiable Credentials VC (Verifiable Credential) を発行 VP (Verifiable Presentation) を提示 Schema Cred_def Schema* CRED_DEF* を登録 CRED_DEFを 取得してVPを検証 *SCHEMA – VCのClaim定義を持つ *CRED_DEF- Credential Defiintion. Schemaの各Claimに対する公開鍵などを持つ
19. 19 © Hitachi, Ltd. 2023. All rights reserved. 3-4. Hyperledger SSI Projectsの歴史 利便性や規格化の観点からIndyから派生したり統廃合したりと歴史がある ❚ 過去：IndyにVDR, Agent, VCの仕様および実装がすべて含まれていた ❚ 少し前：IndyからAgent部分を切り分けてVDRとAgentを独立させた ❚ 今後：VCの仕様をAnoncredsと定め規格化(wip)、Indy以外の台帳にも対応できるように • EthereumベースのVDRで動かしている話もちらほら 初期 少し前 今・今後 VDR Blockchain Agent VC仕様
20. 20 © Hitachi, Ltd. 2023. All rights reserved. 3-5. 議論ポイント ❚ Aries Holder AgentのWalletの扱いに関して • Aries-Askar：PostgreSQL/SQLiteに対してR/Wを実行する際に暗号化してWalletを実現 – ここでいうWalletは秘密鍵に加えてVCも保管 • Walletのバックアップやリストアを運用するうえで気をつけるべきこと ❚ Anoncredsによるゼロ知識証明を用いたVP検証に関して • 以下のゼロ知識証明技術が利用されている（らしい…） – CL Signatures（Camenisch-Lysyanskaya Signatures） » ユーザーが特定の属性（例えば年齢や国籍など）を持っていることを証明 – Predicate Proofs: 特定の条件（例えば「年齢が18歳以上」）が真であることを証明するために使用 » 現在の実装では整数値のみに対してVerifierが提示した数値と比較して以上以下超過未満（<, >, <=, >=）の4種類の演 算子のみを用いて数値を秘匿した状態で証明可能 » 使い方の例) 年齢を秘匿した状態で20歳以上であることを証明し酒類の購入に使う • 現代の最新のゼロ知識証明研究を応用すると上記以外にどこまでできるようになるのか？
21. 21 © Hitachi, Ltd. 2024. All rights reserved. 4. 具体ユースケース紹介 (ブロックチェーン×物流)
22. 22 © Hitachi, Ltd. 2024. All rights reserved. 4-1. ブロックチェーン×物流のユースケース 運送会社の資金繰り改善 メーカーのリコール対応効率化 運送会社の配送効率化 物流データを銀行と連携し、 荷主、配送会社間で即日支払い による資金繰り改善 サプライチェーン間での情報を共 有し、ネットワーク分析による見え る化。リコール対応などに活用。 運送会社間での情報を共有し、 共同配送による配送効率化 ブロックチェーンを活用した情報共有によりメーカー、運送会社などの視点から ｢リコール対応｣ ｢資金繰り｣ ｢配送効率｣ の課題を解決 （１） （２） （３）
23. 23 © Hitachi, Ltd. 2024. All rights reserved. 4-2. メーカーのリコール対応効率化 サプライチェーン間での情報を共有し、ネットワーク分析による見える化。 項目 内容 ステークホルダ メーカー、卸業者、倉庫業者、小売業者 共有するデータ 製造、輸送、販売などの履歴 スマートコントラクトの内容 リコール対応のプロセスを自動化 生産会社 物流会社 倉庫会社 卸会社 小売/商社 台帳情報 台帳情報 台帳情報 台帳情報 台帳情報 既存 本提案 各社でトレーサビリティ管理を実施 生産会社 物流会社 倉庫会社 卸会社 小売/商社 サプライチェーン全体でトレーサビリティ管理を実施 SCデータ連携システム(物流データPF) Block Chain
24. 24 © Hitachi, Ltd. 2024. All rights reserved. 4-3. 運送会社の資金繰り改善 （１） （２） （３） 物流データを銀行と連携し、荷主、配送会社間で即日支払いによる資金繰り改善 項目 内容 ステークホルダ 荷主、配送業者、銀行 共有するデータ 配送情報、取引情報 スマートコントラクトの内容 即日支払いのプロセスを自動化
25. 25 © Hitachi, Ltd. 2024. All rights reserved. 4-4. 運送会社の配送効率化 （１） 運送会社間での情報を共有し、共同配送による配送効率化 項目 内容 ステークホルダ 配送業者 共有するデータ 荷物の配送依頼情報、既存の配送計画 スマートコントラクトの内容 荷物を運んでほしい人、運びたい人のマッチングのプロセスを自動化
26. 26 © Hitachi, Ltd. 2024. All rights reserved. 4-5. セキュリティに関する議論ポイント 隠したい情報： 配送経路など 解きたい問題： 1 2 1 2 3 1 2 1 2 1 2 1 2 3 1 2 1 2 マッチング前 マッチング後 配送依頼 配送経路 情報を秘匿したまま、演算を行い、その結果が妥当であることを検証ができるか 巡回セールスマン問題。走行距離、公平性、荷物と配送業者の相性 などを考慮して、適切な配送業者にマッチングさせる。
27. Trademarks • Hyperledger、Hyperledger Fabric、Kubernetesは、The Linux Foundationの 商標または登録商標です • GitHubは、GitHub Inc.の商標または登録商標です • その他記載の会社名、製品名、サービス名、その他固有名詞は、それぞれの会社 の商標または登録商標です • 本発表中の文章、図では、TM、🄬マークは表記しておりません