Hyperledger Fabric最新v3.x系での機能強化、変更点にキャッチアップ！

Hyperledger Fabric最新v3.x系での
機能強化、変更点にキャッチアップ！
中村岳
日本オラクル株式会社
2025年7月8日

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

Hyperledger Fabricをベースにエンタープライズ利用向けPaaSとオンプレミスで提供
• 数ステップで構築完了、GUIコンソールで管理・運用も容易
• エンタープライズグレードの耐障害性、堅牢性
• マルチクラウド、ハイブリッドクラウド、
オープンなネットワーク構成が可能
• Oracle独自の付加価値：
• State DBとしてBerkeley DBを利用：パフォーマンスとクエリ利便性向上
• 多機能なREST API：スマートコントラクトの利用を容易に
• 台帳のデータをRDBに複製：大量照会、分析、データ統合
• スマートコントラクトを容易に開発：付属の開発ツールでアセット仕様からコードを自動生成
• 複数ChannelのアトミックトランザクションとXA対応：複数Channelでの更新のアトミックな実行
や、ローカルのDB、MQなどとのグローバルトランザクションをサポート
Oracle Blockchain Platform
東京DCからも
サービス提供中
3

4
はじめに；Hyperledger
Fabricとは

エンタープライズ用途を目的として開発されたブロックチェーン
• Linux Foundation Decentralized Trust（LFDT）傘下のプロジェクト:
• LFDT=Linux財団がホストするオープンなOSSコミュニティ
- Hyperledger Foundationから名称変更（2024年9月）
• 世界で最も成功したOSS=Linuxでの成功実績に基づいた運営
• Fabricをはじめ、複数ブロックチェーン/DLT基盤およびツール等をOSSとして開発
• Hyperledger Fabric : 汎用ビジネス利用のためのブロックチェーン基盤
• メンバー管理サービスを備えたパーミッションドブロックチェーンを実装
• セキュリティ、機密性/プライバシーを強化するための多様な機能
• スマートコントラクトによって業務を自動化
• 大量処理をサポートするためのスケーラブル、プラガブルな設計
• マイニングなどの大規模コンピューターパワー投入は不要＆ファイナリティ有
Hyperledger Fabric
5
5

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

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

Hyperledgerのブロックチェーン
パブリック
公開制のネットワークを
不特定多数で運用
コンソーシアム
複数組織で運用
プライベート
単一組織で運用
パーミッションレス← →パーミッションド
8
8

Hyperledger Fabricのリリースタイムライン
9
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）
リリース頻繁＆派手な機能追加も多め
→成長の時期
リリース間隔が広くなり、変更内容も
運用観点の地味なものが多め
→成熟の時期
v3.0
2024/9/17
2025
v3.1
2025/3/10

10
Hyperledger Fabric
v3.x系の機能強化

v3.0: Byzantine Fault Tolerant (BFT) ordering serviceの導入
“Hyperledger Fabric has utilized a Raft crash fault tolerant (CFT) ordering service since version v1.4. A
Byzantine Fault Tolerant (BFT) ordering service can withstand not only crash failures, but also a subset of
nodes behaving maliciously. Fabric v3.0 is the first release to provide a BFT ordering service based on
the SmartBFT consensus library. Consider using the BFT orderer if true decentralization is required,
where up to and not including a third of the parties running the orderers may not be trusted due to
malicious intent or being compromised.”
Ordering Service？
真の分権？
3分の1？
11

トランザクションフローの中のOrdering Service
12 Copyright © 2025, Oracle and/or its affiliates
From: https://hyperledger-fabric.readthedocs.io/en/latest/txflow.html

13
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生成

Ordering：トランザクションの順序を確定しブロックを生成・配布する
• Endorsementを集め終えたクライアントアプリケーションがTransactionを送付
• 受け取ったOrdering ServiceがTransactionを詰めたBlockを生成、Peerノードに配布
Ordering Service内にもコンセンサスがある：
• Ordering Serviceは1～複数のOrdererノードから成るクラスター
• このクラスターの中で受け取ったTransactionの順序を合意し決定している
Orderingフェーズ
14
Client
App
Orderer
Orderer
Orderer
Client
App
Client
App
Tx1
Tx2
Tx3
Block
Tx1
Tx2
Tx3
Peer
Peer
Peer

【ざっくり】 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にあたる

BFTになるとなにがいいの？
• これまでのOrdering Serviceの主な選択肢はRaftで、CFT（Crash Fault Tolerant）
• Ordering参加者の悪意による改ざんや非応答などによって（悪意をもった者が3分の1未満でも）合意＝トラン
ザクションの成立を妨害可能な攻撃方法が存在する
• ただし、誰が不正をしたのかの責任追及可能性＝Accountabilityは確保されている
• BFT Ordering Serviceはクラスタを構成するOrderer Node数の3分の1未満まで、の留保はつくが悪意による改ざ
んや非応答にも耐性があるため、セキュリティが向上している
• コンソーシアムメンバー自身に悪意があるケース、外部の攻撃者により乗っ取られてしまうケースに対処できる
• 一方、BFTによるセキュリティ向上はスループット／スケーラビリティとトレードオフの関係にある
• Hyperledger Fabricが用いられるコンソーシアム型のユースケースの多くの場合において、コンソーシアム内のメンバー
には一定の信頼があり、不正の牽制につながるAccountabilityがあればBFTでなくCFTで十分、というのはひとつの合
理的な態度とみなしてよいと考える
• RaftとBFT Ordering Serviceを適切に使い分けよう！

v3.0: Ed25519暗号アルゴリズムのサポート
• トランザクションのデジタル署名とその検証に使う暗号アルゴリズムがECDSA規格に加えて、Ed25519規格も利用でき
るようになった
• ECDSAとEd25519はいずれも楕円曲線暗号アルゴリズムだが、Ed25519のほうが後発であり、よりセキュアかつ高速
（らしい…）

v3.1: 性能の最適化 – Chaincode書き込みのバッチ化
• これまで、あるChaincodeの中でState上のKey-Valueを一括で多数書き込む（新規挿入／更新／削除する）処
理は非効率だった
• それぞれのKey-ValueごとにChaincodeとPeerの間で通信が行われるため
• この機能強化により、複数の書き込みをバッチ化し、ChaincodeとPeerの間の通信をひとつにまとめることができるよう
になった
• StartWriteBatch()／FinishWriteBatch()を用いてバッチ化することで、多数のKey-Valueを書き込む処理の効率が
大幅に向上する
• なお、この性能向上はEndorsement Phase（→Chaincodeのシミュレーション実行）にのみ影響し、Commit
Phaseには影響しない
• 参考RFC：https://hyperledger.github.io/fabric-rfcs/text/0011-peer-chaincode-optimization.html
Peer Chaincode
…
Peer Chaincode

v3.1: 性能の最適化 – Chaincode読み取りのバッチ化
• 前述のバッチ化の読み取り版
• それぞれのKey-ValueごとにChaincodeとPeerの間で通信が行われるため、あるChaincodeの中でState上のKey-
Valueを一括で多数読み取る処理は非効率だった
• この機能強化により、複数の読み取りをバッチ化し、ChaincodeとPeerの間の通信をひとつにまとめることができるよう
になった
• GetMultipleStates() ／GetMultiplePrivateData()を用いるとバッチで一括して読み取られ、効率が向上する

v3.0での重要な削除、サポート外となった機能
• System Channelのサポートが削除
• 既にSystem Channelを利用せずにOrdering Serviceを管理できるようになっている
- プライバシー、スケーラビリティ、運用上のメリットがある
• v3.x系に移行する前に、System Channelを削除し、Channel Participation APIを利用するように変更してお
く
• SoloとKafkaのOrdering Serviceのサポートが削除
• v3.x系に移行する前に、 RaftのOrdering Serviceに移行しておく
• 古いChaincode Lifecycle（v1.x系）が削除
• v3.x系に移行する前に、すべてのChaincodeについて新しいLifecycle（v2.x系）を利用するように設定しておく

Thank you !
Any Q&A?

Hyperledger Fabric最新v3.x系での機能強化、変更点にキャッチアップ！

Hyperledger Fabric最新v3.x系での機能強化、変更点にキャッチアップ！

More Related Content

Similar to Hyperledger Fabric最新v3.x系での機能強化、変更点にキャッチアップ！ (20)

More from LFDT Tokyo Meetup (20)

Recently uploaded (12)

Hyperledger Fabric最新v3.x系での機能強化、変更点にキャッチアップ！