Corda Enterprise Network Manager 1.4 リリースノート

Published in

Corda japan

12 min readOct 1, 2020

____________________________________________________
＜お知らせ＞
SBI R3 Japanブログは、MediumからSBI R3 Japanのポータルサイトに引っ越ししました。引っ越し先で、mediumの過去記事も閲覧可能です。今までとは異なる新しいコンテンツも発信してまいりますので、お気に入り登録をぜひお願いします！

Corda Portal

Corda実装解説からブロックチェーンビジネス構築までCordaに関する様々なノウハウを発信しています。

cordajapan.net

____________________________________________________

Corda Enterprise Network Managerの新しいバージョンである1.4がリリースされました。
リリースノートの翻訳文を一部掲載いたします。

原文はこちらよりご確認ください。

日本語全文はこちらよりご確認ください。

Corda Enterprise Network Manager 1.4

CENM 1.4では、CENMエラーコンディションのナレッジベース、多数のネットワークマップサービスのパフォーマンス強化、SMR（Signable Material Retriever）サービスに代わる新しいSigning Serviceプラグイン機能EKS、CloudHSM、AWS PostgreSQLを使用したAWSネイティブネットワーク展開の拡張サポートなどの新機能と機能強化が導入されています。

このリリースは下位互換性がありますが、Corda Enterprise Network Managerの以前のバージョンからこのリリースにアップグレードすることをお勧めします。

アップグレードに関する重要な注意事項

CENM 1.3 から CENM 1.4 へのアップグレードには、以下の操作が必要です。

Signing Serviceに関する設定のマニュアル更新

署名データのプラグインを処理するために、CENM 1.4以前に使用されていたSMR(Signable Material Retriever)サービスは、Signing Service内のプラグインロードロジックに置き換えられました。その結果、CENM 1.4へのアップグレード時には、すべてのユーザーは既存のSigning Serviceの設定を更新する必要があります。詳細については、CENMアップグレードガイドを参照してください。

Zoneサービス・データベースの移行

CENM 1.3 から CENM 1.4 にアップグレードする場合、データベース構成で runMigration = true を設定する必要があります。詳細については、CENMアップグレードガイドを参照してください。Zone Service データベーススキーマが更新されたことで、この作業が必要となりました。

その他改善点については、以下を参照してください。

新機能と機能強化

CENMエラーコンディション・ナレッジベース

Corda 4.5 および Corda Enterprise 4.5 で導入された Corda ノード用のエラー処理ロジックが、CENM 1.4にも導入されました。

その結果、CENM の例外は CENM のエラーコードとして扱われるようになり、各例外に対してエラーコードが生成されるようになりました。設定の解析/検証エラーに関連するエラーコードの初期セットは、新しいCENMエラーコードのドキュメントページに記載されています。これは、将来のリリースで更に拡張される予定です。

ネットワークマップサービスのパフォーマンス向上

CENM 1.4では、ネットワーク内に多数のアクティブな参加者が存在する場合にも、安定した運用を確保するために、ネットワークマップサービスのパフォーマンスを向上させています。

データベース項目のうち、シリアライズする項目を減らすことで、ネットワークマップから、新しく加入したノードへのレスポンスに関して、パフォーマンスと信頼性の向上をもたらします。これにより、以前のCENMバージョンで潜在的に発生する可能性のあったデッドロックを回避することが可能です。このデッドロックは、複数の新規ノード登録が同時に実行された場合に発生する可能性がありました。

パフォーマンスは、以下の変更の組み合わせによって強化されています。

新しいオプションのタイムアウト・パラメータを使用して、ネットワーク・マップで定義された署名プロセス内で使用される各サービスへの通信に対して、個別にSigningサービスのタイムアウトを設定できるようになりました。また、timeout パラメータを使用して、Identity Manager および Revocation サービスとネットワークマップサービス間の通信のタイムアウトを設定することもできます。タイムアウトパラメータの値は、ゾーンサービス用のＤＢに含まれる socket_config テーブルおよび signer_config テーブルに追加されたtimeout 列に保存されます。 (ゾーンサービスデータベースのCENM 1.3 からの移行に関する詳細については、『CENM アップグレードガイド』を参照してください)
新しい API エンドポイントである GET network-map/node-infos を使用すると、ネットワーク内のすべてのノードの署名付き NodeInfo オブジェクトのリストを一度に取得することができます。
Network Map API レスポンスに追加されたヘッダにより、レスポンスが、よりHTTP の標準的な使用法に準拠するようになりました。
新しいヘッダ X-Corda-Server-Version が、すべての Network Map API 応答 (コード 5xx の内部エラー応答を除く) に追加され、Network Map のバージョンと利用可能な呼び出しを示します。既定値は 2 です。
新しいヘッダ X-Corda-Platform-Version が Platform-version に置き換わりました。古いヘッダ名は引き続きサポートされます。
新しいヘッダ X-Corda-Client-Version が Client-version に置き換わります。古いヘッダ名は引き続きサポートされます。

SMR（Signable Material Retriever）サービスに代わる新しいSigning Serviceのプラグイン機能

SMR(Signable Material Retriever)サービスは、署名データのプラグインを処理する目的でCENM 1.2に導入されました。CENM 1.4では、従来のSMRをSigning Serviceの一部として機能するプラグインロードロジックに置き換えました。このロードロジックは、Identity ManagerサービスとNetwork Mapサービスから署名可能なデータをフェッチし、新しいプラグイン（指定されている場合）またはデフォルトのSigningサービス処理ロジックに送信します。

その結果、SMRサービスを完全に削除し、CENMサービスの数を減らし、デフォルトのSMRプラグインで作成されたRPCサーバーとストレージを維持する必要がなくなりました。

上記の変更に伴う一連の新機能と変更点については、以下に説明します。詳細については、Signingサービスのドキュメントを参照してください。

設定の変更

serviceLocationAlias から serviceLocation へのリプレース

Signing Serviceの設定方法が変更され、各署名タスクが serviceLocationAlias の代わりに serviceLocation プロパティを使用しなければならないようになりました。新しいプロパティを使用して、CA以外の署名タスク(ネットワークマップ、ネットワークパラメータ)に対して、複数のロケーション(サブゾーンごとに1つ)を定義することができます。serviceLocationAliasプロパティは、CENM 1.4では使用できません（使用すると設定エラーが発生します）。

プラグインベースまたはデフォルトの署名を設定するオプションの追加

各署名タスクは pluginJar と pluginClass からなる plugin と呼ばれる新しいプロパティを持っています。pluginプロパティが設定されている場合、Signing Serviceはプラグインを使用してデータに署名を行います。設定されていない場合、Signing Serviceはデフォルトの署名メカニズムを使用します。プラグイン・プロパティが使用されている場合、デフォルトのSigningサービス・キーは使用されないため、signedKeyAlias は存在してはいけません。CA タイプの署名タスク(CSR や CRL)同士では同じプラグインプロパティを設定する必要があります。同様に、非CAタイプの署名タスク（(ネットワークマップやネットワークパラメータ)同士でも同じである必要があります。例えば、CAタイプの署名についてはプラグインを用いつつ、非ＣＡタイプの署名にはデフォルト署名を適用することができます。CA と非 CA の両方の署名タスクがプラグインを使用する場合、signingKeys プロパティを設定してはいけません。

非同期署名

非同期署名はプラグインAPI内の新機能で、Signing Serviceプラグインの使用時に署名を遅延させることができます。

下記のように機能します。

Signing Serviceは、署名要求のステータス変更をポーリングします。プラグインから返されたステータスがPENDINGの場合、Signing Serviceはポーリングを続けます。リクエストのステータス変更が返されるための最大設定タイムアウトはありません — Signingサービスは、ステータスがCOMPLETEDまたはFAILEDになるまでポーリングを続けます。
返されたステータスがFAILEDの場合、リクエストは停止されます。
ステータスがCOMPLETEDの場合、リクエストは完了とマークされ、署名は、それぞれのCENMサービス (Identity Managerサービスまたはネットワークマップサービス)に保存されます。

非同期署名の導入に伴い、以下の変更が行われました。

APIの変更。Signing Serviceがプラグインから署名ステータスを問い合わせることができるように、CAと非CAプラグイン用の新しい関数が追加されました。プラグインからの返答（ステータス）が PENDING となっているにもかかわらず、requestId (トラッキング ID) が含まれなかった場合、署名サービスからのポーリングは停止し、リクエストは破棄されます。
シェル署名。シェル経由で署名が行われた場合、非同期トラッキングのIDとステータスがコンソールに出力されるようになりました。さらに、各署名タスクに新しいシェルメニュー項目が追加され、非同期署名リクエストのステータスを追跡できるようになりました。
RPC機能の変更。RPC経由で署名が行われた際に、非同期署名のトラッキングIDとステータスを返すという複雑なタスクを可能にするために、リクエストの変更や、RPC経由で各リクエストのステータスを問い合わせるために使用される4つの新しいRPCリクエストの追加など、RPC機能に多くの変更が加えられました。詳細はSigning Serviceのドキュメントを参照してください。

コードの変更

共通のSignerー共通モジュールがあり、Signerクラスを抽象化し、各Signerに2つの実装を追加しています — 1つはデフォルトロジック用、もう1つはプラグインロジック用です。
SigningServicePluginLoader。このクラスは、設定から定義されたプラグインをロードするために使用します。Java URLClassLoaderと、コンストラクタの引数として与えられる親ClassLoaderを使用します。

CAプラグインの例

CENM 1.4にはCAプラグインのサンプルが同梱されており、ユーザーが独自のプラグインを作成する際に必要なすべての情報を提供しています。詳細は Signing Service のドキュメントを参照してください。

AWSへの実装

ーAWS EKS、CloudHSM、PostgreSQLを利用した標準実装方法の提供ー

Kubernetes & Helmを利用した標準実装を提供しました。以下のコンポーネント使ったAWS環境へのサポートを拡大しています。

CENM 1.4でサポートされている実装シナリオは以下の3つになります。

AWSで外部PostgreSQLを利用
AzureにPostgreSQLをクラスタでデプロイ
AzureにPostgreSQLを外部接続

一方、以下のシナリオはサポートしません。

AWSにPostgreSQLをクラスタでデプロイ

CENM のデプロイのセクションを参照してください。

Corda 4.6リリースノート

Corda Enterprise4.6 リリース

リンク先の『Corda Guide』ではCordaに関する

・よくあるご質問
・技術ドキュメント
・インフォメーションやリリースノート

も掲載しています。
ぜひご参照ください。

最後までご覧いただき、ありがとうございます。
ご不明点などございましたら、弊社までお気軽にお問い合わせください

Facebook： https://www.facebook.com/R3DLTJapan
Twitter： https://twitter.com/R3Sbi
HP： https://sbir3japan.co.jp/product.html
お問い合わせ：info-srj@sbir3japan.co.jp