再注目されているHyperledgerをテーマに、Linux Foundationが「Hyperledger Tokyo Meetup」をオンライン開催【後編】

こんにちは、吉田です。今回は前回に引き続き、5月12日(水)にオンライン開催された「Hyperledger Tokyo Meetup」について、その内容を紹介していきます。

「Hyperledger Tokyo Meetup」とは

「Hyperledger Tokyo Meetup」は、Hyperledgerプロジェクトとは非公式の関係ですが、Hyperledgerに関連する企業の技術者やブロックチェーンテクノロジーに情熱を注ぐメンバーで構成されている集まりで、Hyperledgerに関する話題で熱く盛り上がっているコミュニティです。

ここでは、本Meetupの2本目と3本目の講演について、概要を紹介します。

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

アクセンチュアのセウェカリ シタル氏に続いて登壇したのは、日立製作所の佐藤竜也氏で、「Hyperledger Fabric向け非中央集権型システム運用ツール『運用スマートコントラクト(OpsSC)』のご紹介」というタイトルで講演されました。

ブロックチェーンの本番適用に向けて、SC(Smart Contract)及びアプリケーションの更新や台帳データのスナップショット取得などの運用管理が重要となってきます。本番適用で想定されるブロックチェーンを活用したシステムでは、複数組織(管理ドメイン)に跨って構成されることが一般的であり、同一のSCを同時に複数の組織にデプロイするなど、組織またぎのシステム運用の実行が困難なケースが存在します。従来のジョブ管理ツールなどの運用管理ツールでは、単一組織に閉じた場合の運用作業は効率化できますが、組織またぎの運用作業はカバーできません。

そこで、単一管理者が全ノードを運用する方法が考えられますが、その場合、その管理者が単一信頼点(SPOT：Single Point of Trust)になるだけだけでなく、権限的な視点でも他組織のノードにアクセスできないことが想定されるため、この方法では実現できません。次に各組織の管理者が自組織のノードを運用する方法が考えられますが、この方法では各組織でのバージョン違いなど、運用のギャップが発生する可能性があり、システムの正常稼働を妨げる恐れがあります。

そこで、システム運用フローをSCとして定義するというアイデアに辿りつきました。この方法なら、BCレイヤの合意形成により、クレデンシャルの共有やSPOTがなく、管理ドメイン跨ぎの運用が実現でき、SCに基づいて設定パラメータを用いて均一な手順が実行可能になります。具体的には、OpsSCのトランザクションを発行すると各組織のOpsSC間で合意が形成され、SC上でパラメータ共有とワークフローが制御され、SCに従って運用が実行されるため、運用の均一化が実現できるようになります。

Hyperledger Fabric v2.xでは、個々の運用タスクが洗練され、SPOTも排除されつつありますが、まだ個々のタスクを用いたEnd-to-Endの運用ワークフローの効率化が課題として残っていました。例えば、チェーンコード(FabricのSC)をデプロイする場合、各組織はほかの組織と同じパラメータを用いてチェーンコードの定義を承認する必要があります。また、組織同士がオフラインでソースコードやパラメータを共有したり、調整したりする必要があります。

Hyperledger Fabric v2.x向けのOpsSCは運用ワークフローを管理し、運用命令を含む運用イベントを発行する機能を提供する「チェーンコード」、各組織の管理者がOpsSCチェーンコードとやり取りするREST APIを提供する「APIサーバ」、組織ごとに用意され運用イベントに従ってその組織の所有するすべてのノードに運用を実行する「エージェント」で構成されます。

Hyperledger Fabric v2.x向けOpsSCの実装

チェーンコードの運用面で考えると、Fabric v2.0以降のNew Chaincode Lifecycleでは、Install、Approve、Commitの3ステップの中で中央集権的なプロセスが排除され、他組織と全く同一のパラメータを用いて各組織が実行する作業が増えたり、組織間でチェーンコードとパラメータの共有や調整をする必要がありましたが、OpsSCを活用することで、End-to-Endでチェーンコードデプロイの効率化が実現できます。ある組織がチェーンコードを提案し、他の組織がOpsSC上で共有された提案に投票し、過半数の投票を得られたら、各エージェントは提案に従ってチェーンコードを自動デプロイすることになります。

また、チャネル運用という視点では、チェネル生成や組織/Ordererの追加など組織またぎのチャネル更新プロセスでは、設定トランザクションを生成し、各組織からの署名収集、各ノードに設定トランザクションを送信する必要があり、他の組織と設定トランザクションを共有する必要があります。これにOpsSCを適用することで、複数組織にまたがるチャネル更新のみを効率化できます。(1)ある組織がHuman-Readableなチェネル更新提案を生成します。(2)ほかの組織がOpsSC上で共有された提案に投票します。(3)過半数からの投票が得られたらエージェントのひとつが提案された設定トランザクションを用いて自動的にチャネルを更新します。

このOpsSCは2021年2月に「Hyperledger Labs」として承認され、登録されました。今後は、テストを拡充し、Kubernetes環境のサンプルの作成など品質向上を図っていくこと、任意のコマンドをOpsSCチェーンコード経由で実行できるように汎用的な運用サポートを図っていくとのことです。

Hyperledger Cactus V0.4
リリースの概要と今後の開発方針

最後に、富士通研究所の竹内琢磨氏が「Hyperledger Cactus V0.4 リリースの概要と今後の開発方針」というタイトルで講演されました。

ブロックチェーンビジネスも集中から分散へ移行しており、単一の業界では閉じずに複数事業者を連携するサービスのニーズが増加すると予想されています。例えば、電力サービスと決済サービスの場合、それぞれの市場が存在しますが、既存の決済とトークンを組み合わせて新規サービスを創りたいといったようなケースが考えられ、各々の市場の形を崩さない形で、安全につなぐ技術が必要になるでしょう。今後は、このように異なるブロックチェーン同士の連携技術がビジネスの鍵となる可能性があります。

しかしながら、ブロックチェーンごとに取引API仕様や取引確定タイミングなど様々な相違点があるため、多種多様なブロックチェーンへの拡張は困難です。これに対応するには、異なるブロックチェーン間の差分を吸収する処理が必要になります。また、連携先のブロックチェーンが属するネットワークは異なるため、開発者は個々のSDKに合わせた設定を行う必要があり、対応が煩雑になります。そこで、これを解決するために、ファイアウォール対応の統一的な抽象化命令機能である「Hyperledger Cactus」が開発されました。

Hyperledger Cactusは、異なるブロックチェーンで管理されるデジタル資産同士の取引をAPI呼び出しで実行可能にする統合基盤で、異なるブロックチェーン間での取引が確定するタイミングなどの差分を吸収し、必要な資産移転を実行します。このプロジェクトは2020年5月に始動し、Accenture社と富士通の2社が発起人となり、現在この2社以外の開発者を含めて30名程度がコミットしています。

Hyperledger Cactusには、ブロックチェーン統合サービスの実体となる「Cactus Node Server」と、アプリケーションのロジックを担当する「Business Logic Plugin(BLP)」、各種ブロックチェーンへの「取引発行」「ブロック監視」等の操作をする「Validator Server」の3つで構成されています。

Hyperledger Cactus v0.4では、以下の6種類のブロックチェーンに対応した「Validator Server」を提供しています。

1. Hyperledger Fabric:IBM等が開発する許可型ブロックチェーン
2. Hyperledger Sawtooth:Intel等が開発する許可型または許可不要型のブロックチェーン
3. Go-Ethereum:GoベースのEthereumクライアント
4. Hyperledger Besu:JavaベースのEthereumクライアント
5. Quorun:Ethereumベースの許可型ブロックチェーン
6. Corda:金融機関が主導して開発されたブロックチェーン

また、Business Logic Plugin(BLP)では、以下の3種類のサンプルロジックを提供しています。

1. Car-trade:Ethereum-Fabric連携の自動車所有権のトレードアプリ
2. Electricity-trade:Sawtooth-Ethereum連携の電力自動決済アプリ
3. Supply-chain-app:Fabric-Besu-Quorum 連携のサプライチェーンアプリ

Hyperledger Cactusのアーキテクチャ

Cactus Node Serverでは、異なるブロックチェーンの資産移転に関する基本機能を開発しました。

• Verifier:同期型リクエスト及び非同期型リクエスト対応機能
• Verifier Factory:異なるValidator対応するためのVerifier初期化機能

今後は、すべてのブロックチェーン基盤へのValidator Serverの対応を進め、SDKの強化を行い、2021年夏～秋頃に「Hyperledger Cactus V1 Release Candidate」をリリースし、2021年冬から2022年春までには「Hyperledger Cactus V1」リリースを目指し、開発を進めていく予定だそうです。

全体的に質疑も活発に行われていましたし、盛り上がったMeetupであったように思います。このように熱く盛り上がったHyperledgerを今後もフォローしていきたいと思います。

最後に、Hyperledger関連で興味深い発表(*2)があったたので、紹介します。Linux Foundationの傘下にあるLinux Foundation Public Health(LFPH)イニシアティブは6月8日、新型コロナのワクチン接種を証明するグローバルネットワーク「Global COVID Certificate Network(GCCN)」の立ち上げを発表しました。

【参照リリース】Introducing the Global COVID Certificate Network (GCCN)
https://www.lfph.io/2021/06/08/gccn/