More Related Content Similar to エンタープライズブロックチェーン構築の基礎
Similar to エンタープライズブロックチェーン構築の基礎 (20) More from Hyperleger Tokyo Meetup
More from Hyperleger Tokyo Meetup (18) エンタープライズブロックチェーン構築の基礎1. © Hitachi, Ltd. 2023. All rights reserved.
エンタープライズブロックチェーン構築の基礎
Building Enterprise Blockchain
日立製作所 研究開発グループ
2023/7/26
佐藤竜也 (Tatsuya Sato)
近藤佑樹 (Yuki Kondo)
Hyperledger Workshop at WebX 2023
2. 1
© Hitachi, Ltd. 2023. All rights reserved.
本発表のアジェンダ
1. エンタープライズブロックチェーンおよびHyperledger Fabricの概要
2. Hyperledger Fabricの技術概要
3. Hyperledger Fabricのトークンユースケース
3. 2
© Hitachi, Ltd. 2023. All rights reserved.
1. エンタープライズブロックチェーンおよび
Hyperledger Fabricの概要
4. 3
© Hitachi, Ltd. 2023. All rights reserved.
1-1. エンタープライズブロックチェーンについて
• 目的: 複数企業間での信頼できる取引を実現 (ワークフロー効率化/新しい価値創成)
• エンタープライズに特に求められる要件:
– スケーラビリティ(参加者数)よりもトランザクション性能(主にスループット)が優先
– 情報全公開は難しいため、データ公開範囲のコントロールが必要
– 本番利用に向けては品質面やサポートが気にされる
エンタープライズ
での利用に期待
パーミッションレス型 パーミッション型
プラットフォーム例 Bitcoin, Ethereum Hyperledger Fabric
ネットワーク形態 パブリック コンソーシアム
参加者 不特定多数 許可された複数組織
合意形成アルゴリズム 不特定多数での取引の
信頼確保 (PoW, PoS)
特定組織間での高速取引
(分散システム由来)
エンタープライズ分野でのブロックチェーン利用
ブロックチェーンの分類 : 特徴が異なるため使い分けが必要
PoW: Proof of Work
PoS: Proof of Stake
5. 4
© Hitachi, Ltd. 2023. All rights reserved.
1-2. Hyperledger Fabric
• エンタープライズ向けパーミッション型ブロックチェーンプラットフォーム
– エンタープライズ利用に求められる要件に対応した機能/非機能を提供 (後述)
• 幅広い業界/ユースケースに対応可能な汎用的な仕組み
• 性能確保/向上のためのアーキテクチャ設計
• コンソーシアム内でのデータアクセス制御機能を提供
– 本番適用に向けた安定性やサポート状況
• 成熟していることを示す”Graduated”ステータスのプロジェクト
• コミュニティ内で開発ロードマップが策定されており継続的に開発が進んでいる
• 特定バージョンについてコミュニティによりLong Term Support (LTS)される
– ‘23年3月に新しいLTS版であるv2.5系がリリース
• 複数の事業者がBlockchain as a Service (BaaS)として提供
Graduated
6. 5
© Hitachi, Ltd. 2023. All rights reserved.
サプライチェーン/トレーサビリティ
金融分野
1-3. 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
を活用。航空燃料バッチを
トークン化して流通管理。
8. 7
© Hitachi, Ltd. 2023. All rights reserved.
2-1. Hyperledger Fabricの技術的特徴
• エンタープライズ向けパーミッション型ブロックチェーンプラットフォーム
– あらかじめ許可された参加「組織」でコンソーシアム(ブロックチェーンネットワーク)を形成
• 「組織」 (Organization) をトラストの単位とする
– 電子証明書(X.509)によるアイデンティティ
– スマートコントラクトは「チェーンコード」(chaincode)と呼ばれる
• 主な特徴
– データモデル: ブロックチェーンとステートデータベースを保持
– コンセンサス: Endorse-Order-Validateモデル (性能向上のためv1.0でアーキ大幅改定)
– データアクセス制御: レベルの異なるデータアクセス制御の仕組みを提供
Graduated
9. 8
© Hitachi, Ltd. 2023. All rights reserved.
2-2. データモデル
• データモデルは(Versioned) Key-Value
• 各Peerは2種類の台帳 (Ledger) データを管理
– ブロックチェーン (Blockchain)
• 複数のトランザクション (TX) をブロックとしてまとめ、
そのブロックをつらねたもの
– ワールドステート (World State)
• Key, Valueの最新の値のスナップショット
– 全てのブロックの履歴を最初からたどれば復元可能
• State DB上で管理される
– LevelDB, CouchDBのいずれかを設定で選択可能
https://hyperledger-fabric.readthedocs.io/ja/latest/ledger/ledger.htmlを参考に作成
Ledger
Block
TX TX TX
Block
TX TX TX
Block
TX TX
key=Asset1, value={size:10, color: “red”}, v=0
key=Asset2, value={size:5, color: “blue”}, v=2
key=Asset3, value={size:5, color: “blue”}, v=1
・・・
決定
Blockchain
World State
・・・
10. 9
© Hitachi, Ltd. 2023. All rights reserved.
2-3. Hyperledger Fabricの主要コンポーネント
Organization 1
Peer
Chaincode
(Smart contract)
Organization 2
Peer Chaincode
(Smart contract)
Organization 3
Chaincode
(Smart contract)
Client
Ordering
Service
Orderer
Orderer
Proposal
Endorsement
Endorsement
• エンドースされたTXを受け付
け順序付けし、複数TXを
まとめたブロックを生成
• ブロックをPeerに配布
• TXのリクエストを受け付けスマー
トコントラクトを実行しその結果を
返す (Endorsementと呼ばれる)
• 台帳(BC, ステート)を保持/管理
Peerから呼び出されTXリクエ
ストに応じた処理を実行
(ステートの読み出し/書き込み
はPeerに対して実施)
Ledger
Ledger
TX: Transaction
BC: Blockchain
11. 10
© Hitachi, Ltd. 2023. All rights reserved.
2-4. コンセンサス処理フロー – 1. Endorse
• 3フェーズ
– Endorse
• SCを実行
(エンドースメント)
– Order
• TXの順序を決定
• ブロック生成/配布
– Validate
• TXのエンドースメント
とコンフリクトを検証
し、台帳を更新
Organization 1
Peer Chaincode
(Smart contract)
Organization 2
Peer Chaincode
(Smart contract)
Organization 3
Peer Chaincode
(Smart contract)
Client
Ordering
Service
Orderer
Orderer
Orderer
Proposal
Endorsement
Endorsement
TX: Transaction
SC: Smart contract
12. 11
© Hitachi, Ltd. 2023. All rights reserved.
2-4. コンセンサス処理フロー – 2. Order
• 3フェーズ
– Endorse
• SCを実行
(エンドースメント)
– Order
• TXの順序を決定
• ブロック生成/配布
– Validate
• TXのエンドースメント
とコンフリクトを検証
し、台帳を更新
Organization 1
Peer Chaincode
(Smart contract)
Organization 2
Peer Chaincode
(Smart contract)
Organization 3
Peer Chaincode
(Smart contract)
Client
Ordering
Service
Orderer
Orderer
Orderer
Transaction
Endorsement
Endorsement Block
Block
Block
TX: Transaction
SC: Smart contract
13. 12
© Hitachi, Ltd. 2023. All rights reserved.
2-4. コンセンサス処理フロー – 3. Validate
• 3フェーズ
– Endorse
• SCを実行
(エンドースメント)
– Order
• TXの順序を決定
• ブロック生成/配布
– Validate
• TXのエンドースメント
とコンフリクトを検証
し、台帳を更新
Organization 1
Peer Chaincode
(Smart contract)
Organization 2
Peer Chaincode
(Smart contract)
Organization 3
Peer Chaincode
(Smart contract)
Ordering
Service
Orderer
Orderer
Orderer
Block
Transaction
Transaction
Transaction
Validate
&
Commit
Block
Transaction
Transaction
Transaction
Validate
&
Commit
Block
Transaction
Transaction
Transaction
Validate
&
Commit
Ledger
Ledger
Ledger
TX: Transaction
SC: Smart contract
14. 13
© Hitachi, Ltd. 2023. 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
15. 14
© Hitachi, Ltd. 2023. All rights reserved.
2-6. 非中央集権化に向けた動き
• Fabricでは非中央集権化を促進する機能拡充も実施中
BFT: Byzantine Fault Tolerance
CFT: Crash Fault Tolerance
ざっくり要件: 以下の3観点で単一信頼点(SPOT: Single Point of Trust)がない
アイデンティティ
TX実行システム
管理/ガバナンス
- ブロック生成部(Orderer)の合意形成
アルゴリズムがCFT(Raft)
- 中央管理者が統合運用しがち
参加組織が各々認証局(CA)を用意し
各自アイデンティティを発行する想定
- 適切なエンドースメントポリシー設定要
v3系にてBFTサポート
予定 (現在開発中)
- v2系からチェーンコードライフライクル
管理にSPOTを排除した新モデル導入
設定パラメータ調整が
オフライン ➡
OpsSC(Hyperledger Labsより):
運用ワークフロー全体を
オンチェーン化し効率化
現状機能: 仕込み/将来機能:
[1] Toward Fully-Decentralized System With Hyperledger Fabric, Hyperledger Global Forum, 2022.
[2] Toward Fully-Decentralized System With Hyperledger Fabric, IEICE ComEX, 2023.
16. 15
© Hitachi, Ltd. 2023. All rights reserved.
2-7. 日本語でのFabric関連情報
• コミュニティ内(Fabric Japanese Documentation Working Group)にて
Fabric公式ドキュメントの日本語翻訳活動を推進中
• 翻訳状況: LTS版を対象に既に日本語版ドキュメントが利用可能
– v2.2 (これまでのLTS版): すべてのページの日本語翻訳済
– v2.5 (新LTS版): 正式リリースを受けてこれから随時翻訳・更新
• 日本語版ドキュメントへのアクセス方法 (v2.2の場合)
– https://hyperledger-fabric.readthedocs.io/ja/release-2.2
– または英語版から言語とバージョンを選択
• languages: ja, version: release-2.2
• 宣伝したいこと
– コミュニティ内でのレビューに基づいた精度の高い翻訳となっているのでぜひご活用ください!
– Hyperledger用Discordに専用チャンネルもあるのでお気軽に日本語で問合せください!
(#fabric-japanese)
((*) チャットサービス)
https://discord.com/invite/hyperledger
18. 17
© Hitachi, Ltd. 2023. All rights reserved.
3-1. トークンとは
モノ(現物資産)の所有権、コト(無形資産、サービス)の利用権をデジタル化したもの
• 代替不可能なトークン。ユニークに識別される。
• 例: アート作品、不動産、チケット、etc.
• NBA Top Shot
– NBAのプレイシーンをデジタルトレーディングカード化
• CryptoPunk
– プログラムで生成された24x24のドット絵。
– 1万個のうち同じものはない。
• Bored Ape Yacht Club(BAYC)
– プログラムで生成された10000体の退屈そうな顔をした猿
の肖像画
Fungible Token (FT) Non-Fungible Token (NFT)
• 代替可能なトークン。相互に交換できる。
• 例: 通貨、ゴールド、原油、etc.
• Bitcoin
– 中央銀行や単一の管理者を持たない暗号資産
• USDC
– 米ドルに1対1でペグされたステーブルコイン
• tZERO
– トークン化された証券で資金調達。
Seat A-101 Seat VIP-101
100 Coin 100 Coin
19. 18
© Hitachi, Ltd. 2023. All rights reserved.
3-2. B2Bでの事業機会
• トークンにより、複雑なビジネスプロセスの効率化や新サービスの創生が期待されている。
• 想定ユースケース:サプライチェーンファイナンス、貿易金融、カーボンフットプリント、など
金融機関 Tier1
サプライヤ A
大企業 Tier2
サプライヤ B
移転
ファイナンス申込
信用供与
Token
移転
Token
トークンを活用したサプライチェーンファイナンス
20. 19
© Hitachi, Ltd. 2023. All rights reserved.
3-3. B2Bでトークンを使うときの課題
• B2Bでトークンを使う場合、「責任範囲の明確化」「秘匿性」「トークン仕様の擦り合わせ」が課題。
• 取引企業同士が業務要件に合わせてトークンのデータ項目や機能を擦り合わせる負荷が高い。
監査機関
Token
Token Token
プライバシ
法人Y
法人Z
法人X
課題
• 責任範囲の明確化
• 法的に有効な法人格
• トランザクションのファイナリティ
• コンプライアンス
• 監査
• 秘匿性
• トランザクションのプライバシ
• プライバシ vs トレーサビリティ
• トークン仕様の擦り合わせ
• トークン仕様の分かりやすさ
• 他のアプリとの連携
21. 20
© Hitachi, Ltd. 2023. All rights reserved.
3-4. 解決策:Hyperledger Fabric×トークン
• エンタープライズ向けのガバナンスと秘匿性を備えるHyperledger Fabricでトークンを実装。
• トークン仕様の擦り合わせを効率化するため、トークンの標準仕様(ERC20, ERC721)に準拠。
• 責任範囲の明確化
• 法的に有効な法人格
• トランザクションのファイナリティ
• コンプライアンス
• 監査
• 秘匿性
• トランザクションのプライバシ
• プライバシ vs トレーサビリティ
• トークン仕様の擦り合わせ
• トークン仕様の分かりやすさ
• 他のアプリとの連携
課題 解決策
• エンタープライズ向けの機能
• 組織ベースのアイデンティティモデル
• Endorsement Policy
• Execute-Order-Validate Model
• 秘匿機能
• チャネル
• プライベートデータコレクション
• トークン標準仕様の参照実装
• Fungible Token: ERC20
• NFT(Non-Fungible Token): ERC721
• 汎用プログラミング言語で開発(JS, Go, Java)
× ERC20/ERC721
22. 21
© Hitachi, Ltd. 2023. All rights reserved.
3-5. Hyperledger Fabric トークンスマートコントラクトの主な機能
ERC-20
基本機能
追加機能
• トークンを操作する機能(発行、移転、償還、残高参照、など)を持つ
• ユーザのアイデンティティ(所属組織、属性)でアクセス権限を管理
Mint
(発行)
User1 User2
• BalanceOf(ctx, owner)
• Transfer(ctx, to, value)
• TransferFrom(ctx, from, to, value)
• Approve(ctx, spender, value)
• Allowance(ctx, owner, spender)
• TokenName(ctx)
• Symbol(ctx)
• Decimals(ctx)
• TotalSupply(ctx)
Transfer
(移転)
Burn
(償還)
発行体
残高参照
トータルサプライ
• Mint(ctx, amount)
• Burn(ctx, amount)
• ClientAccountID(ctx)
• ClientAccountBalance(ctx)
23. 22
© Hitachi, Ltd. 2023. All rights reserved.
3-6. Hyperledger Fabric トークン実装
トークンの種類 概要 実装言語 URL
Token-erc-20 Fungible Tokenのスマートコント
ラクト。
Go,
Java,
JavaScript
https://github.com/hyperledger/
fabric-samples/tree/main/token-
erc-20
Token-erc-721 NFT(Non-Fungible Token)
のスマートコントラクト。
Go,
Java,
JavaScript
https://github.com/hyperledger/
fabric-samples/tree/main/token-
erc-721
• トークンの参照実装は、Hyperledgerコミュニティで公開中。
• ドキュメントに従い、Fabricのテストネットワーク構築とトークンの発行・移転をすぐに試せる。
• スマートコントラクトをカスタマイズすることで、様々なトークンに応用可能。
24. 23
© Hitachi, Ltd. 2023. All rights reserved.
3-7. Hyperledger Fabric トークンのデモ
• fabric-samplesのトークンをカスタマイズして、セキュリティトークン(証券トークン)を実装
ユースケース概要
課題
Challenge
- 裏付アセットのあるトークンの発行
- トークンの事務処理(販売、発行、配布、
配当)の負荷
解決策
Solution
- ブロックチェーンでアセットとトークンの所有
権を紐づけて管理
- スマートコントラクトでコンプラチェックや
トークンの発行・配布を自動化
特徴
Features
- アセットとトークンを一元的に管理
効果
Outcome
- トークンの裏付け資産のトラストを確保
- これまで証券化のコストに見合わなかっ
た少額商品のトークン化と流動性向上
投資家
STO Platform
発行体
1) アセット登録
2) 小口
トークン化
セキュリティトークン
4) STO申込
T
T
T
T
T
T
5) STO終了
7) トークン購入代金の支払い
¥
T
6) トークン発行/配布
9) 配当
¥
T
凡例:
情報の流れ
カネの流れ
¥
モノの流れ
8) 事業運用
3) STO開始
トークンの処理フロー
• 発行体がアセットを登録し、そのアセットを裏付けにした
トークンを組成して投資家を募集
27. 26
© Hitachi, Ltd. 2023. All rights reserved.
付録. Hyperledger Fabricを試してみる
• ここではFabricを試す上で役立ちそうな公式ドキュメント/リポジトリ内の情報を紹介
目的 リソース 概要
触ってみる 公式ドキュメントの
テストネットワーク
チュートリアル
サンプルのテスト用ネットワーク(fabric-samples/test-network)を
用いて、Fabricネットワークの起動とTX実行を確認できる
基本チュートリアル
各機能や
概念を知る
公式ドキュメント • チュートリアルの続きでアプリ開発や各機能の使い方提示
• キーコンセプト、アプリ開発者/運用者向けの情報など
fabric-samples 上記でも参照されるFabricの公式サンプル集リポジトリ
より高度な
使い方を
知る
fabric-samples/
test-network-k8s
Kubernetes(K8s)環境版のテストネットワーク実装
(現状はローカルK8s環境で試すことを想定)
fabric-samples/
full-stack-asset-
transfer-guide
Hyperledger Global Forumでのワークショップ内容を
マージしたもの。最新機能や周辺PJも駆使した高度な
使い方(SC開発、アプリ開発、K8s上へのデプロイ)を紹介
28. 27
© Hitachi, Ltd. 2023. All rights reserved.
付録. バージョンごとの機能改善状況
• v2.0
– チェーンコードのライフサイクル管理が非中央集権的に
• v2.2 (これまでのLTS版: 2023年末までメンテナンスされる予定)
• v2.3
– 「システムチャネル」によるOrdererの組織管理を廃止
– Ledgerのスナップショット機能
• 新規追加Peerが最新ステートに追いつく時間を削減
• v2.4
– Fabric GatewayをSDKからpeerに統合
• ピア・チャネル・チェーンコードの状況を把握し、適切なピア等を選びリクエストを送信する機能
– Peerのチャネルからの脱退に対応
• v2.5 (LTS リリース最新版: 2023年3月リリース)
– プライベートデータの削除 (purge) に対応
• v3.x (開発中)
– OrdererのコンセンサスアルゴリズムにByzantine Fault Tolerance (BFT) 対応予定
29. 付録. OpsSC (Operations Smart Contract) for Hyperledger Fabric
• 背景: BCを活用したシステムは、複数組織にまたがって構成され、非中央集権的なTX実行に価値
• ゴール: 組織またぎのシステム運用を非中央集権的に実現
• OSS化: Hyperledger Fabricに必須のBCネットワーク運用に特化した実装を開発、Hyperledger Labs採択[’21/2]
- End-to-Endの組織またぎの運用ワークフローを非中央集権的かつ効率的に実行可能
• 22年度エンハンス: Chaincode運用のK8s対応 (K8s環境サンプル、Chaincode as a Serviceモデルのサポート)
• 今後のエンハンス予定: Channel運用強化 (K8s環境サンプル、BFT Orderer導入時の運用自動化)
運用ワークフローをスマートコントラクト(SC)として定義、
各組織はそのSCに従い自ノード運用
手法1. 単一管理者が運用→運用中央集権化
手法2. 組織毎に自ノード運用→設定差異発生
従来手法 提案手法: OpsSC
peer peer peer
OpsSC
業務SC
OpsSC
組織A 組織B 組織C
OpsSC
2. SCに基づき均一な設定/手順で運用実行
1. 分散運用指示
(BC上で合意形成)
peer
peer
peer
peer peer peer
業務SC
組織A 組織B 組織C
peer
peer
peer
A
単一信頼点
or 別組織へ
アクセス権なし
B C C
A B
設定/手順
差異発生
SC
v3.2
SC
v3.1
管理者
【補足】SC x BC:
業務ロジックを組織間で合意
形成しながら確実に実行
30. 29
© Hitachi, Ltd. 2023. All rights reserved.
補足: コンセンサスモデル
• Fabric v1.0よりEndorse-Order-Validateモデルを採用
– 一部Peerのみがスマートコントラクトを実行することで性能向上
クライアント ピア1 オーダリング
サービス
ピア2
提案要求作成
SC実行
提案要求
SC実行
エンドースメント
エンドースメント
トランザクション作成
ブロック作成
ブロック
検証 検証
ブロック
endorse
order
validate
(SC: スマートコントラクト)