PS/SLの佐々木です。
2024年9月にHyperledger FabricのメジャーアップデートがありVersion3がリリースされました。
今回はリリースノートからHyperledger Fabric V3で新しくどのような機能か登場したのか紹介したいと思います。
Hyperlerger Fabric V3 新機能紹介
1. Byzantine Fault Tolerant (BFT) Ordering Service
概要
- BFTとは？
- BFTは、単なるクラッシュ障害（Crash Fault Tolerance, CFT）に留まらず、一部のノードが悪意を持った行動をしてもシステム全体が正常に機能することを保証する仕組みです。
- 悪意あるノードやハッキングによる障害に強い信頼性を提供します。
- 背景
- Fabric v1.4.1 以降、Raft ベースの CFT が主流。
- Fabric v3 で初めて SmartBFT ライブラリを用いた BFT コンセンサスが導入される。
- 分散システムにおける真の非中央集権性を実現するために設計されている。
- 利用条件
- Channel Capability V3_0 を有効にする必要があります。
従来の CFT (Crash Fault Tolerance) Ordering Service
- 実装: Fabric v1.4.1 以降、Raft プロトコルが採用されており、これは CFT（クラッシュ障害耐性）のみを提供。
- 動作原理:
- ノードがクラッシュ（停止）した場合でも耐性あり。
- ただし、悪意ある行動（データ改ざんや不正なリーダー選出）には耐えられない。
- 制約: Raft は分散ノード間の信頼性が前提であり、ノード運営者が「信頼できる」ことを前提としている。
新しい BFT Ordering Service
- 実装: SmartBFT ライブラリを活用。
- 動作原理:
- 最大でノードの 1/3 未満が悪意ある行動をしてもシステムが正常に動作。
- 各ノードが異なる主体によって運営されている場合でも、完全な分散と信頼性を実現可能。
利点
- 開発者視点
- 高い耐障害性: システムが最大でノードの 1/3 未満の悪意ある行動や障害に耐えられる。
- 柔軟性: 信頼できない運営者（ノード間の異種運営）を含むシステムを構築可能。
- 実験的試行: テストネットワークで簡単に試すことができ、初期設定もチュートリアルが整備されている。
- ユーザー視点
- データの安全性: ネットワーク上の悪意あるノードや妨害行動がシステム全体の整合性を崩さない。
- 信頼性の向上: ノード運営者が分散化され、特定の主体に依存しない。
比較まとめ
| 特徴 | CFT (Raft) | BFT (SmartBFT) |
|---|---|---|
| 耐障害性 | クラッシュ障害に耐える | クラッシュ＋悪意あるノードの行動にも耐える |
| 運営ノード間の信頼性 | 信頼が前提 | 信頼が不要、最大1/3までの不正行為を許容 |
| 適用ユースケース | 信頼された環境（例: 同一企業内） | 信頼できない環境（例: 複数企業間の連携） |
2. Ed25519 暗号アルゴリズムのサポート
概要
- Ed25519とは？
- Ed25519 は、従来の楕円曲線暗号（ECDSA）よりも高速かつ安全なデジタル署名アルゴリズム。
- Fabric の MSP（Membership Service Provider）機能で、署名や検証に利用可能になりました。
- 利用条件
- Channel Capability V3_0 を有効にする必要があります。
従来の ECDSA（楕円曲線デジタル署名アルゴリズム）
- 性能:
- トランザクション署名と検証で利用。
- パフォーマンスは十分だが、Ed25519 と比較すると若干の処理遅延がある。
- セキュリティ:
- 楕円曲線暗号は安全だが、Ed25519 と比べると一部の最新攻撃に対する耐性がやや劣る可能性が指摘されている。
新しい Ed25519
- 性能:
- ECDSA に比べて署名・検証が高速。
- トランザクション処理のスループット向上が期待できる。
- セキュリティ:
- より新しいアルゴリズムであり、高度な攻撃に対しても強い耐性を持つ。
- 鍵サイズが短く、署名もコンパクト。
利点
- 開発者視点
- 高速性: 署名や検証が効率化され、大規模なトランザクション処理においてパフォーマンス向上。
- セキュリティ向上: より強力な署名アルゴリズムで、攻撃に対する耐性が強化。
- ユーザー視点
- トランザクション処理速度の向上: Ed25519 を採用することで取引の処理速度が改善され、ユーザー体験が向上。
- 長期的なセキュリティ対応: 将来の暗号技術的脅威に対する準備。
比較まとめ
| 特徴 | ECDSA | Ed25519 |
|---|---|---|
| 署名・検証速度 | 標準的 | 高速 |
| 鍵サイズ | やや大きい | 小さい |
| セキュリティ | 十分安全 | 最新の脅威に対するより強い耐性 |
| 適用場面 | 既存システムとの互換性を重視 | パフォーマンスと将来的なセキュリティを重視 |
3. 追加の改善点
全ての承認済みチェーンコードのクエリ
- 新コマンド:
peer lifecycle chaincode queryapproved - チャネル名を指定するだけで、そのチャネルに承認された全チェーンコードを取得可能。
利点
- 開発者視点: 承認済みチェーンコードの管理が簡素化され、ネットワークのデバッグや監視がしやすくなる。
- ユーザー視点: 安全なチェーンコード管理による運用の信頼性向上。
変更点
peer.gossip.pvtData.transientstoreMaxBlockRetentionのデフォルト値変更- 変更点: 保持ブロック数が 1000 → 20000 に増加。
- 目的: 未コミットのプライベートデータをトランジェントストアに長期間保持し、コミット遅延に対する耐性を向上。
- Proposal のタイムスタンプ検証
- 新機能:
TimeWindowCheckフィルターが追加され、提案リクエストのタイムスタンプをピア時間と比較して検証。 - 目的: 不正確なタイムスタンプの提案が承認されるリスクを軽減。
- 新機能:
peer.deliveryclient.blockGossipEnabledのデフォルト値が false に変更- 背景: Gossip を介したブロック配信が非推奨に。将来的に削除される可能性があり、デフォルトで無効化。
- 推奨設定: ピアはオーダリングサービスノードから直接ブロックを受信する構成を採用。
削除機能
- システムチャネルのサポート削除
- 概要: システムチャネルが削除され、チャンネル作成は Channel Participation API 経由に移行。
- 利点: プライバシー、スケーラビリティ、運用性の向上。
- Solo および Kafka コンセンサスの削除
- 概要: Solo はテスト用として設計されており、Kafka は Raft の導入以降非推奨だった。Fabric v3.0 では完全に削除。
- 対応: Raft への移行が必要。
- レガシーチェーンコードライフサイクルの削除
- 概要: Fabric v1.x のチェーンコードライフサイクルは削除され、v2.x の新しいライフサイクルに統一。
- 対応: 全チェーンコードを再デプロイし、チャネルアプリケーション機能を V2_0 または V2_5 に設定する必要あり。
非推奨機能
- Gossip によるブロック配信
- 非推奨理由: Gossip は複雑さと非効率性のため、オーダリングサービスノードから直接ブロックを受け取る構成が推奨される。
- 今後の変更: 将来のリリースで削除される可能性が高い。
まとめ
Hyperledger Fabric v3 の新機能は、分散型ネットワークの安全性、性能、柔軟性を向上させるために設計されています。
- BFT オーダリングサービスは、より信頼性の高い分散システムを構築したい組織にとって理想的な選択肢です。
- Ed25519 のサポートは、高速かつ安全な取引処理を可能にします。
