Hyperledger Fabric向け非中央集権型システム運用ツール「運用スマートコントラクト(OpsSC)」のご紹介

© Hitachi, Ltd. 2021. All rights reserved.
0
Hyperledger Fabric向け非中央集権型システム運用ツール
「運用スマートコントラクト (OpsSC)」の紹介
日立製作所研究開発グループ
〇佐藤竜也下沢拓

1
サマリ
• 運用スマートコントラクト (OpsSC, Operations Smart Contract) とは
– 背景: ブロックチェーンを活用したシステム (ブロックチェーンシステム) は、
複数組織にまたがって構成され、非中央集権的なトランザクション実行に価値
– ゴール: 組織またぎのシステム運用を非中央集権的に実現
– アイデア: 運用ワークフローをスマートコントラクト (SC) として定義し、
各組織 (の管理者 or エージェント) がそのSCに従って自ノードを運用
– 価値: 組織横断の運用作業を (1) 特定の組織の意思決定に依存することなく
(2) 均一な手順/設定パラメータで (3) 効率的に実施できる
• Hyperledger Fabric v2.x向けのOpsSCを開発 (以降Hyperledger Fabricを単にFabricとも呼ぶ)
– ファーストバージョンとして、Fabricネットワーク管理 (チェーンコード、
チャネル管理) の典型的な運用フローを効率化
– 2021年2月にHyperledger Labsプロジェクトとして承認/登録済
• https://github.com/hyperledger-labs/fabric-opssc

2
1. OpsSCのコンセプト
(ブロックチェーンシステム全般向け)
(*) [1] https://ieeexplore.ieee.org/abstract/document/8328745
[2] https://arxiv.org/abs/1901.11249
[1] Smart-Contract Based System Operations for Permissioned Blockchain, BSC 2018, p.6
[2] Design and Evaluation of Smart-Contract-based System Operations for Permissioned
Blockchain-based Systems, arXiv:1901.11249, p.11, 2019

3
1-1. 背景
• ブロックチェーンの本番適用に向けて運用管理がより重要となる
– 例) SCおよびアプリの更新、台帳データのスナップショット取得
• ブロックチェーンシステムは複数組織(管理ドメイン)にまたがった構成
ネットワーク
SC
組織A
SC
組織C
SC
組織B
合意形成
DC1 DC2 DC3
合意形成
組織A
ノード
組織C
ノード
組織B
ノード
(*) BC: Blockchain, SC: Smart Contract, DC: Data Center
: 他の組織との協調動作が必要な作業
• 問題点: 組織またぎのシステム運用の実行が難しい
例) 同一のSCを同時にデプロイ
各ドメインには
別々の管理者
A B C
管理者

4
1-2. ブロックチェーンシステムのシステム運用に関する問題点
従来の運用管理ツール(例: ジョブ管理サーバ, IaCツール):
- 一般的な(=単一組織に閉じた)運用作業を効率化
一方、組織またぎの運用作業はカバーしない
組織A 組織C
組織B
C
A B
管理者
運用のギャップ発生
(手順、契機、
設定パラメータ)
SC
v3.2
SC
v3.1
方法1:
単一管理者が
全ノード運用
方法2:
各組織の管理者が
自身のノード運用
(*) IaC: Infrastructure as Code
問題点2:
設定差異がシステム正常稼働を妨げる
問題点1:
- その管理者が単一信頼点 (SPOT, Single
Point of Trust) となる
- 権限的に他組織のノードにアクセス不可
ノード
アクセス
権限なし
組織またぎの
運用方法

5
1-3. SCベースのシステム運用方式 (OpsSC)
アイデア: システム運用フローをSCとして定義
- BCレイヤーの合意形成により、クレデンシャルの共有やSPOTなく
管理ドメインまたぎの運用を実現
- SCに基づいて、均一な設定パラメータを用いて均一な手順を実行可能
ネットワーク
組織A 組織C
OpsSC
組織B
OpsSC
OpsSC
0. OpsSCの
TX発行
2. SC上でパラメータ
共有とワークフロー
制御
1. 合意形成
1. 合意形成
3. SCに従って
運用実行
3. SCに従って
運用実行
運用の均一化
(例: SCに基づき統一化
されたスナップショット)
3.
Snapshot()
- Cmds: [“zip /ledger…”…
- Timing: “every 23:55”
…
(*) SC: Smart Contract, TX: Transaction,
SPOT: Single Point of Trust
ノード

6
2. Hyperledger Fabric v2.x向けOpsSC

7
Peer
Chaincode
2-1. Hyperledger Fabric v2.xの概要説明
• Execute-Order-Validateアーキテクチャで複数組織内でのTXを承認
• 一部の組織だけが参加するチャネルごとにチェーンコードおよび台帳を管理
– チャネル: サブネットワーク、チェーンコード: FabricのSC
– これら設定更新時には組織間で足並みをそろえる必要あり (内部的には特殊なTXを発行)
Peer
Chaincode
Client
Ordering Service
(Orderer Nodes)
Peer
Chaincode
CA
(1-1)
Send proposal
(1-2) Execute
(1-3) Endorsement
(2-1) Send endorsed proposal
(2-2) Broadcast block
(3) Validate
Issue key/cert
Org1
Org2
Org3
(*) SC: Smart Contract, TX: Transaction
CA
CA
Client
Client
(3)
(3)
Channel
(1-1)
(1-3) (1-2)

8
2-2. Hyperledger Fabric v2.x向けOpsSCの必要性
• Hyperledger Fabric v2.xの状況
– 個々の運用タスク (例: peer コマンド) は洗練され、SPOTも排除されつつある
(例: v2.0からのNew Chaincode Lifecycle導入)
• 残課題: 個々のタスクを用いたEnd-to-Endの運用ワークフローの効率化
– 各組織が行うべき作業やその際に生じる組織またぎでの調整作業
(例: 情報共有/パラメータ合わせ) が増えた
• Fabric v2.x向けOpsSC: 調整と自動化のケイパビリティを拡充することをめざす
Fabricの各種コマンド
設定パラメータノード
調整自動化 (非中央集権的)
管理者
OpsSCの
対象範囲
例) チェーンコード (=FabricのSC) のデプロイ:
- 各組織は他の組織と全く同一パラメータを用いてチェーンコードの定義を承認する必要あり
- 組織同士でオフラインにてそのソースコードやパラメータを共有/調整する必要あり (典型例)
(*) SPOT: Single Point of Trust

9
補足: 関連動向
• システムチェーンコード [1]
– Peerプロセス内で実行される特別なチェーンコードであり、現在はFabricプラッ
トフォーム上の内部処理や設定情報の共有に使用される
(例: _lifecycle はチェーンコードライフサイクルを管理, CSCCはチャネル設定変更を制御)
– 我々のOpsSCはFabricネットワークを管理するために内部的にこれらのシステム
チェーンコードを利用
• Fabric Interop Working Group [2]
– 目的: Fabricネットワークサービス同士の相互運用性を向上させる
• 稼働中のFabricネットワークに新しい組織を追加(join)するシナリオにフォーカス
– アプローチ: “Consortium Management Chaincode (CMCC)”を用いてjoinリクエスト
のためのアーティファクト (=configtx) を作成
– スコープは少し違うものの、コンセプトは非常に似ている
• 実際、我々の現在のチャネル用OpsSCはCMCCの実装の一部を再利用している
– 我々のOpsSCはCMCCの一形態もしくは応用例と位置付けることもできる
[1] https://hyperledger-fabric.readthedocs.io/en/release-2.2/smartcontract/smartcontract.html#system-chaincode
[2] https://wiki.hyperledger.org/display/fabric/Fabric+Interop+Working+Group

10
2-3. Hyperledger Fabric v2.x向けOpsSCの実装
• OpsSCチェーンコード、OpsSC APIサーバ、OpsSCエージェントの3つで構成
– チェーンコード: 運用ワークフローを管理し、運用命令を含む運用イベントを発行
する機能を提供 (イベントはFabricのChaincode Event機能で実現)
– APIサーバ: 各組織の管理者がOpsSCチェーンコードとやり取りするREST APIを提供
– エージェント: 組織ごとに用意され、運用イベントに従って、その組織の所有する
すべてのノードに対する運用を実行
Peer
Orderer
OpsSC
エージェント
OpsSCチェーンコード
チャネル運用
(channel_ops)
チェーンコード運用
(chaincode_ops)
組織1
組織2
OpsSC
API/ポータル
OpsSC
API/ポータル
組織3
OpsSC
API/ポータル
1. 運用を提案
2. 提案に賛成
Peer
Orderer
OpsSC
エージェント
Peer
Orderer
OpsSC
エージェント
3. 所定の賛成が得られたかチェック
5. イベントに
基づき運用実行
4. イベント発行
5. 運用実行
5. 運用実行
Ph.1: Fabricネットワーク運用に必須となる目的特化のOpsSCを提供
(チェーンコード: SC, チャネル: サブネットワーク、組織構成)

11
2-4-1. チェーンコード(=SC)運用
1. Install
1. Install
1. Install
2. Approve
組織1:
組織2:
組織3: 3. Commit
2. Approve
2. Approve
承認数を
チェック
New Chaincode Lifecycle (Fabric v2.0以降)
• Install, Approve, Commitの3ステップ
– 中央集権的なプロセスが排除された
CCソースコード CC定義
(例: ポリシー)
Peer
エージェント
OpsSC
チェーンコード
チェーン
コード
運用
(chaincode_ops)
組織1
組織2
API/ポータル
API/ポータル
組織3
API/ポータル
1. 提案
2. 提案に投票
Peer
エージェント
チェーンコード用OpsSC
3. CCをDownloadし、
Install, Approve, Commit
3. Download, Install, Approve
3. Download, Install, Approve
Peer
エージェント
提案内容
1. ある組織が提案 (CCソースコードと定義を含む) を作成
2. 他組織がOpsSC上で共有された提案に投票
3. 過半数からの投票が得られたら、各エージェントは
提案に従ってチェーンコードを自動デプロイ
(*) CC: Chaincode
他組織と全く同一のパラメータを用いて
各組織が実行する作業が増加
組織間でチェーンコードとパラメータの共有
や調整する必要あり (典型例)
残課題:
残課題:
• End-to-Endでのチェーンコードデプロイの効率化

12
2-4-2. チャネル(=サブネットワーク、組織構成)運用
1. ブロック取得
3. 署名
組織1:
組織2:
組織3: 4. 更新
3. ConfigUpdateに署名
署名数を
チェック
2. ConfigUpdate生成
他組織と共有
configtx
他組織と共有
• 例: チャネル生成、組織/Ordererの追加
• プロセス: 設定TX (configtx) 生成、各組織
から署名収集、ノードにconfigtxを送信
組織またぎのチャネル更新プロセスチャネル用OpsSC
protobuf->JSON->修正後JSON
->protobuf->抽出されたDelta
他組織とconfigtxを共有する必要あり
残課題:
• 複数組織にまたがるチャネル更新のみを効率化
Orderer
エージェント
OpsSC
チェーンコード
チャネル
運用
(channel_ops)
組織1
組織2
API/ポータル
API/ポータル
組織3
API/ポータル
1. 提案
2. 提案に投票
Peer
エージェント
3. チャネル更新
Peer
エージェント
1. ある組織がHuman-Readableなチャネル更新提案を生成
2. 他の組織がOpsSC上で共有された提案に投票
(内部的にConfig Transaction Libraryを用いてconfigtxに変換)
3. 過半数からの投票が得られたら、エージェントのうち
の一つが提案されたconfigtxを使い自動的にチャネル更新
Peer
Orderer
Orderer
(*) TX: Transaction

13
Org4
Org3
Org2
Org1
2-5. デモ: OpsSCを用いた新規チェーンコード追加＆新規組織追加
[デモ環境]
- Fabricバージョン: v2.3.0
- Fabricネットワーク: fabric-samplesのtest-network (いくつかカスタマイズ済)
- 初期ネットワーク: 3組織 (全組織がCA、Peer、Ordererを持つ)、mychannelチャネル
- OpsSCチェーンコードがops-channelチャネルにデプロイ済
ops-channel
OpsSC chaincode for operating channels (channel_ops)
OpsSC chaincode for operating chaincode (chaincode_ops)
mychannel
fabcar
[シナリオ1.
チェーンコード追加]
Steps:
1. Org1はチェーンコード
fabcarのデプロイ提案
2. 他組織がそれに投票
Result:
提案されたパラメータで
fabcarがmychannel上に
デプロイされる
[Scenario 2. 組織追加]
Steps:
1. Org4はCAを用意し、Peerと
Ordererのための鍵/証明書発行
2. Org1はOrg4のMSPを用いて
Org4の追加を提案
3. Org2と3はそれに投票
(Step2, 3を各チャネルに実行)
4. Org4の各コンポーネントを
起動 (他組織からGenesis blockを
もらう必要あり)
Result:
Org4が全チャネルに追加される
(OpsSCとfabcarも自動デプロイ)
Peer
Orderer
CA
Ops API server
Ops Agent
Peer
Orderer
CA
Ops API server
Ops Agent
Peer
Orderer
CA
Ops API server
Ops Agent
Peer
Orderer
CA
Ops API server
Ops Agent

14
2-5. デモ: OpsSCを用いた新規チェーンコード追加＆新規組織追加
OpsSCのポータル画面

15
おわりに
• 本OpsSCは2021年2月にHyperledger Labsとして承認/登録済
– https://github.com/hyperledger-labs/fabric-opssc
– READMEにて今回紹介したデモと同様のシナリオをコマンドベースで
実行するfabric-samplesベースのサンプル環境を掲載
• 今後のエンハンス予定
– 品質向上
• テスト拡充、Kubernetes環境サンプル、Channel Participation APIサポート、他
– 汎用的な運用サポート (<-> Fabricネットワーク特化運用)
• 任意のコマンドをOpsSCチェーンコード経由で実行
– お気づきの点や要望などいつでもフィードバック頂けるとうれしいです
(Hyperledger Rocket.Chatにも最近チャンネルが用意されました)
• https://chat.hyperledger.org/channel/fabric-opssc

16
Trademarks
• Linux Foundation、Hyperledger、Hyperledger Fabric、Kubernetesは、
The Linux Foundationの商標または登録商標です
• GitHubは、GitHub Inc.の商標または登録商標です
• その他記載の会社名、製品名、サービス名、その他固有名詞は、
それぞれの会社の商標または登録商標です
• 本発表中の文章、図では、TM、🄬マークは表記しておりません

17

Hyperledger Fabric向け非中央集権型システム運用ツール「運用スマートコントラクト(OpsSC)」のご紹介

Recomendados

Recomendados

Mais conteúdo relacionado

Mais de Hyperleger Tokyo Meetup

Mais de Hyperleger Tokyo Meetup (20)

Último

Último (7)

Hyperledger Fabric向け非中央集権型システム運用ツール「運用スマートコントラクト(OpsSC)」のご紹介