Corda Enterpriseリリースノート
Corda Enterprise 4.7のリリース概要
今回のリリースでは、数々の新機能と機能強化が導入されているほか、以前のリリースに存在した既知の問題が解決されます。
これまでのリリースでワイヤやAPIの安定性を約束したのと同様に、Corda 4.7でも同じ保証がされています。
Corda 3.0以上で有効なステートやアプリはCorda 4.7でもお使いいただけます。
Corda Enterprise 4.7における主な新機能と機能強化は以下の通りです:
- アーカイブサービス
- 改善されたノータリーのバックプレッシャー(ETA)メカニズム
- ノード管理とフロー管理用の新しい管理コンソール
- 証明書ローテーション
- Azure ADへのシングルサインオン
- HSM統合サポート
- HSMに秘密アイデンティティ鍵を保存する機能
- HSM API
このページでは、Corda Enterprise 4.7に特有の機能のみを記載しています。 しかし、Corda Enterpriseのお客様は、Cordaオープンソースリリースの一環として、利用可能な全ての機能をご利用いただけます。
Corda 4.7の一環として提供される以下のような新機能、機能強化、修正については、 Cordaオープンソースリリースノートをご覧ください。
新機能と機能強化
アーカイブサービス
アーカイブサービスは、ノード運用者が支出を終えた取引の台帳データをアーカイブできるようにする新しいツールです。 これによってスペースを節約し、ノードデータベースへの負荷を削減できます。
アーカイブサービスの機能には以下があります:
- Cordaコマンドラインインターフェース(CLI)コマンドを使ったアーカイブサービスの利用 これによって、アーカイブが必要なジョブをすばやく確認し、必要なくなったデータをvaultから削除し、vault内のスナップショットをインポート、エクスポート、復元できるようになります。
- アプリケーションエンティティ―マネージャーを使うと、CorDappsが台帳外のデータベースにアクセスできるようになります。
- アーカイブサービスを 共同復元CorDappsと統合すると、壊滅的なシナリオが発生してもデータの復元がスムーズに実行できます。
詳細については アーカイブサービスの説明書セクションをご覧ください。
改善されたノータリーのバックプレッシャー(ETA)メカニズム
ノータリーがトラフィックを扱う方法を最適化するために、ノータリーのバックプレッシャーメカニズム( ETAメカニズムとも呼ばれます)を更新し、ノータリゼーションの申請が突然増えた場合のノータリーのパフォーマンスを改善しました。 この変更によって、ノータリーがノードに提供する取引リトライの概算精度が向上します。
その結果、「トラフィックの重い状態」でもノータリーのバックプレッシャーメカニズムがより高精度かつ俊敏になりました。これによってノードのリトライが削減され、パフォーマンスが最適化され、ノード運用者にとってより良いエンドユーザーエクスペリエンスを提供できます。
ノータリーのバックプレッシャー(ETA)メカニズムとは
設計上、ノータリーはトラフィックの負担が極端に大きくても通常通り作動することができます。 ノータリーのバックプレッシャーメカニズムは、ノータリゼーションの申請キューに対処し、タイムアウトによって発生するノードのリトライ(通常トラフィックの多い時に生じる)が、ノータリーの処理能力に相関して行われる、とすることで、これを可能にしています。 このメカニズムによって、それぞれのノードに対してノータリゼーションの申請に必要な時間及び処理能力が確保され、必要に応じてリトライを行います。 また、不必要なノードのリトライによってノータリゼーションの申請キューが不自然に増えることを防ぎ、ノータリーの効率性も担保します。
ノード管理とフロー管理用の新しい管理コンソール
Corda Enterprise 4.7には2種類の新しい管理コンソールが搭載されています:
- フロー管理コンソールでは、ノードで実行されているフローの状態を確認でき、フローに対していくつかの処理を行えます。 詳細については、 フロー管理コンソールをご覧ください。
- ノード管理コンソールでは、ノードについての情報を確認でき、いくつかの処理を行えます。 詳細については、 ノード管理コンソールをご覧ください。
どちらのコンソールも、CENM Gatewayサービスの一部として動作します。
証明書ローテーション
Corda Enterprise 4.7では、ノードの法的アイデンティティ鍵や証明書を再発行する機能を導入しています。これによって、 Corda Enterprise Network ManagerのNetwork Map上において、新しい証明書を使ってノード(ノータリーノードを含む)を再登録できるようになります。 本機能の詳細については、 R3サポートまでお問い合わせください。
その他の変更と改善
- Azure ADへのシングルサインオン Azure ADとCorda Authサービスで簡単な設定を行うだけで、CordaサービスとAzure AD間でシングルサインオン(SSO)設定が使えるようになりました。 詳しくはこちらをご覧ください.
- HSM統合サポート Corda Enterpriseでは、ユーザーに対して、サポート外のHSMとCorda Enterpriseの統合のサポートを行うようになりました。 今回のリリースには、例として使えるJava実装のサンプルと、展開前に実装をテストできるテストスイートが含まれています。 HSM統合の書き方ガイドについては、 HSMの説明書をご覧ください。
- HSMに秘密アイデンティティ鍵を保存する機能 Corda Enterpriseは、nCipher、FuturexとAzure Key VaultのHSMにおける秘密アイデンティティに関する鍵の保管をサポートするようになりました。nCipherとAzure Key VaultのHSMでは秘密アイデンティティ鍵のネイティブでの利用をサポートし、FuturexのHSMではキーラップモードをサポートします。 これらのHSMにおける秘密アイデンティティ鍵保管の設定については、 HSMの説明書をご覧ください。
- HSM API Corda Enterprise 4.7では、外部のツール開発者がCorda EnterpriseのHSMサポートを拡張するために使える独自のAPIを有するHSMライブラリーが導入されています。
- ノード
initial-registration
がidentity-private-key
キー保管のエイリアス作成を含むようになりました。 詳細については、 ノードフォルダー構造の説明書をご覧ください。 これまでは、cordaclientca
とcordaclienttls
のエイリアスだけがinitial-registration
中に作成され、identity-private-key
は初回のノード実行時に必要に応じて生成されていました。 そのため、Corda Enterprise 4.7では、nodekeystore.jks
の内容は通常のノード実行中に変更されません(証明書ディレクトリを事前に設定したキー保管で埋められるdevMode = true
を除きます)。 - ノータリーの
batchTimeoutMs
設定オプションを調整することでパフォーマンス向上を得られる可能性について解説した説明書を追加しました。ただし、デフォルト設定は変更されていません。
プラットフォームバージョン変更
Corda 4.7のプラットフォームバージョンは8から9に引き上げられています。
プラットフォームバージョンの詳細については、 バージョニングをご覧ください。
修正された問題
- Accountsを使う際に、取引を開始したパーティが受領側のパーティに対して復元を希望する場合に LedgerSyncが差異を出力しない 共同復元の問題を修正しました。
- フローのメタデータ終了時刻がフローのメタデータ開始時刻と異なるタイムゾーンに設定されていた問題を修正しました。
- ホット/コールドのノードフェイルオーバーの場合に、カウンターパーティからのメッセージの受領を待っている間に実行中のフローが新しいホットノードやカウンターパーティのノードで滞る場合がある問題を修正しました。
- ノードの状態のクエリを行う際にいくつかの列挙型をデシリアライズできないためにCorda 4.6 RPCクライアントがCorda 4.7のノードに対して
NodeFlowStatusRpcOps::getFlowStatus
の手法を実行できない問題を修正しました。 - 入力ステートが10以上あった場合に、
StateRef
は<hash>:a
として正しくエンコードされるものの、想定される整数入力によって間違ってデコードされるJPAノータリーの問題を修正しました。
既知の問題
- ノードの状態のクエリを行う際にいくつかの列挙型をデシリアライズできないために、Corda 4.6 RPCクライアントはCorda 4.7のノードに対して
NodeFlowStatusRpcOps::getFlowsMatching
の手法を実行できません。 - 場合によっては、RPCクライアントがノードとの接続に失敗することがあります。 このエラーはスペックの低いマシンを使っている場合に発生しやすいです。
- 法的アイデンティティやTLS鍵について実装されているため、HA Utilitiesツールは使用済みの
freshIdentitiesConfiguration
についての情報を記録しません。 - HA Utilitiesツールは、
NATIVE
モードを使っている場合、マスター鍵が不要だと記載したメッセージを記録しません。 こうしたメッセージは、initial-registration
コマンドを使ってノードを登録している場合に、ノードログにのみ記録されます。 NATIVE
モードでの秘密アイデンティティにはマスター鍵が不要のため鍵は生成されていないにもかかわらず、NATIVE
モードでのHSMの秘密アイデンティティを使ったノード登録中に、HA Utilitiesツールのログに「秘密アイデンティティのキーラップを作成しました」という間違ったログエントリーが含まれます。- 入力や参照のない取引は、出力ステートに異なるノータリーを有することがあります。 その結果、取引を発行しているノードが、そのノータリーとの取引のノータリゼーションを行うことなく、出力ステートに任意のノータリーを設定することがあります。
- Azure KeyVaultのサポートについて、Cordaはまだ、旧式のAzure Java SDKバージョン(1.2.1)に依存しています。 これによって、ノード運用者が
shadedJar
を自身で構築する必要が生じる場合があります。 - 新しいフロー管理コンソールにおいて、ページのリロード後に、フィルターが適用されていた時と同じ結果を表示せず、列のフィルタリング/ソートが間違ってリセットされることがあります。
- 新しいフロー管理コンソールとノード管理コンソールにおいて、ユーザーの名前が短すぎると「パスワードの変更」/「ログアウト」のドロップダウンメニューがすべて見えない場合があります。
- 新しいフロー管理コンソールにおいて、「フローのクエリ」ページ上のカレンダー内の「フローの開始から/まで」のフィールドは2回クリックしないと開けません。
- 共同復元1.1(または1.0)のイニシエーターは、共同復元1.2のレスポンダーによってアーカイブされた取引を復元しようとした場合に失敗することがあります。
- (今回のリリースで導入された)証明書ローテーションを実行するとき、
previousIdentityKeyAliases
のリストにない古い鍵によって署名されたステートを使おうとするとフローにエラーが発生して失敗することがあります。 - 健康診断ツールは常に、現在のディレクトリではなくCordaノードのディレクトリに報告書を保存しようとします。 これはCordaノードのディレクトリへの書き込み権限がないノード運用者にとって問題となる可能性があります。
- Corda HSM Technology Compatibility Kit (TCK)テストのコンソールヘルプと Corda shell CLIのヘルプで、フォーマットが一貫していないところがあります。
samples:attachment-demo:deployNodes
を実行する際、serviceLegalName
ではなくmyLegalName
をノータリゼーションに使うため、runSender
のタスクが添付の送信に失敗します。- カスタムIOU CorDappを移行するために
run-migration-scripts --core-schemas --app-schemas
を実行する際、MS SQLデータベースで動作していると移行スクリプトが失敗します。 H2、PostgreSQLとOracleのデータベースに対しては、移行が問題なく動作します。 - 場合によって、カウンターパーティがダウンしている場合やフローが遮断された場合でもノードがカウンターパーティへの再接続を試み続けることがあります。