Corda Enterprise 4.10.6

Corda Enterprise Edition 4.10.6 は、問題の解決に焦点を当てた Corda Enterprise Edition のパッチリリースです。

修正された問題

• DriverDSLを使用してTest Nodeをデプロイした際、NoSuchMethodErrorという例外が発生することなく、Nodeが正常に起動するようになりました。
• DriverDSLを使用してテストを行う際、X.500名のOフィールド値が同一かつOU値が異なる2つのNodeを作成できるようになりました。
• テストのために一連のmock networksを作成する際に、メモリリークが発生しなくなりました。
• トランザクションリカバリをサポートするためにCordaバージョン4.11で導入された「in-flight transaction」という状態を持つトランザクションは、Ledger Graph CorDappがトランザクショングラフを構築する際に含まれなくなりました。CorDappは現在、in-flightの状態を持つすべてのトランザクションを無視します。

新機能、機能強化、および制限事項

• R3が提供するCorDappsのContract JAR signing keyのローテーションが、このパッチリリースに含まれています。
• Docker imageは現在、Java 8 build 432をベースとしています。
• OpenTelemetry のスパンが 「send to multiple parties」 と 「receive from multiple parties」 の操作に追加されました。

サードパーティコンポーネントのアップグレード

次の表は、4.10.5と4.10.6間の依存関係バージョンの変更点を示しています。

Corda Enterprise 4.10.5

Corda Enterprise Edition 4.10.5 は、問題の解決に焦点を当てた Corda Enterprise Edition のパッチリリースです。

修正された問題

• これまでReceiveTransactionFlowは、ResolveTransactionFlowの実行前に、トランザクション上のnetwork parametersが存在することを確認していました。これは、特定のシナリオで問題を引き起こす可能性がありました。例えば、移行されたネットワークの新しいNodeにトップレベルのトランザクションを送信する場合、古いnetwork parametersは新しいNodeには存在しないためです。 この問題は現在修正されています。
• あるコードパスでのパーティ特定において、wellKnownPartyFromAnonymousは、X.500名の特定を試みる際に、network parametersからNotaryを考慮していませんでした。このシナリオは、新しく移行されたネットワークに新しいNodeを導入する際、新しいNodeのnetwork mapに古いNotaryが含まれていないために発生する可能性がありました。 この問題は現在修正されています。現在、チェック時にnetwork parametersからNotaryが考慮されます。

Corda Enterprise 4.10.4

Corda Enterprise Edition 4.10.4は問題の解決に焦点を当てたCorda Enterpriseのパッチリリースです。

修正された問題

• デフォルトの log4j2.xml ファイルで、diagnostic-*または checkpoints_agent-* で始まるログファイルの DefaultRolloverStrategy ポリシーの Delete アクションが間違っていました。このため、誤ったファイル名と比較されていました。この問題は修正され、ファイルがポリシーに従って削除されるようになりました。
• TLS 秘密鍵の保存に HSM を使用した場合の TLS 接続に関する問題が解決されました。
• 以前は、実際には接続されていないにもかかわらず、ノードがピアとの有効な接続を誤って認識するという稀なエラーシナリオが発生することがありました。この問題は通常、ピアノードが切断/接続しているときに発生します。この問題は現在解決されています。

サードパーティコンポーネントのアップグレード

• Jetty のバージョンが 9.4.51.v20230217 から 9.4.53.v20231009 にアップグレードされました。
• Apache Tomcat のノード管理プラグインのバージョンが 9.0.82 から 9.0.83 にアップグレードされました。

Corda Enterprise 4.10.3

Corda Enterprise Edition 4.10.3 は、問題の解決に重点を置いた Corda Enterprise Edition のパッチ リリースです。

修正された問題

• SSLハンドシェイクの失敗に関連する警告レベルの一部のログメッセージは、以前のパッチリリースでのSSL証明書処理の改善の一環として誤って導入され、トラフィックロードバランサーの接続テストおよびシステム監視の一部としてログに頻繁に表示されていました。これらのログメッセージは、ログの「ノイズ」を減らすために消されています。
• Vault クエリは、可能な限り、合計状態数に対する追加の SQL クエリを回避するように最適化されています。
• 以前は、コンテナーのクエリ結果の状態の順序が、同じトランザクションに属している場合に正しくないことがありました。この問題は解決されました。
• ノードスレッド名を改善して、ロギングとデバッグをより明確にしました。
• 新しいノードで SSL ハンドシェイクを実行する際の遅延が、他のノードとの既存の接続に影響しなくなりました。
• 以前は、外部 ID が複数のキーにマッピングされている場合に、 externalIdsに対するクエリに対して誤った値が返されていた問題が解決されました。Page.totalStatesAvailableexternalIds
• 外部IDが複数のキーにマップされている場合に、externalIdsに対するクエリでPage.totalStatesAvailableに不正な値が返される問題が解決されました。

Corda Enterprise 4.10.2

Corda Enterprise Edition 4.10.2は、Corda Enterprise Editionの問題解決に焦点を当てたパッチリリースです。

修正された問題

• フロー・チェックポイント・ダンプには、フローの状態、特にhospitalizedか否かを示すstatusフィールドが含まれるようになりました。
• Artemisサーバーのデバッグログが追加されました。
• ノード構成値 cryptoServiceTimeout のデフォルト値が 1 秒から 10 秒に増加しました。
• ピアツーピア接続のトランスポート層接続の切断からの回復中に、Artemisメッセージブローカーのバグに対する回避策は、接続の最初の切断中にのみ取られていました。これにより、ノードが再起動されるまで、2つのピア間の接続を再確立できないというまれな障害が発生しました。これが接続が失われるたびに実行されるようになったため、ピアツーピア接続は、オペレーターの介入なしに常に再確立されるようになりました。
• 以前は、ノードが Luna HSM で 2 つの異なるスロットを使用するように構成されていた場合 (たとえば、ノード ID に 1 つのスロットを使用し、コンフィデンシャル ID に別のスロットを使用)、これは失敗しました。この問題は解決されました。

※ただし、この修正の結果、使用しているLunaクライアントがバージョン10.4.0以降であることを確認する必要があります。

• Luna HSM で FIPS モードがアクティブになっている場合、ファームウェアのバージョン 7.7.1 では、メカニズム AES/CBC/PKCS5Padding でラップ機能を使用できません。これにより、"ラップ" モードの使用時にコンフィデンシャル ID でフロー エラーが発生しました。

FIPS モードでのラッピングを可能にする新しいメカニズム (AES/KWP/NoPadding) が有効になりました。この新しいメカニズムに切り替えるために、新しいブーリアン型構成パラメーターusekwp が Luna HSM 構成ファイルに追加されました。このパラメーターを true に設定すると、新しいメカニズムが使用されます。false の場合、またはパラメーターが構成ファイルに存在しない場合は、既存のメカニズムが使用されます。

• MockNetwork の.startNodes()と.stopNodes()の両方のドキュメントを更新し、ノードの再起動がサポートされていないことを示しました。
• 以前は、コンフィデンシャル ID ID と Securosys PrimusX HSM を使用するように構成されている場合、Corda が新しいコンフィデンシャル ID のラップされたキー ペアの生成に失敗する可能性がありました。これにより、一時的なキーペアがリークし、HSM のリソースが消費されました。この問題は、次の場合に発生していました。
• Securosys HSM がマスタークローンクラスタで構成されている
• マスター HSM に障害が発生し、Corda がクローン HSM を使用するためにフェイルオーバーした
• 機密 ID を使用してトランザクションを作成しようとしました

この問題は解決されました。ラップされたキーペアを生成する場合、一時キーペアは HSM に保持されないため、リークすることはありません。

この更新プログラムを適用すると、PrimusX JCEをバージョン2.3.4以降にアップグレードする必要があります。

このアップデートでは、HSMファームウェアのバージョンをアップグレードする必要はありませんが、当然のことながらファームウェアを最新の状態に保つことをお勧めします。現在、最新のファームウェアバージョンは2.8.50です。

• コントラクト検証中にデータベーストランザクションの進行中に、問題によってコントラクト検証ステータスが正しくない場合に、キャッシュ削除の修正が適用されました。
• Cordaは、開発者が統合テストを書くのに役立つNodeDriverを提供する。NodeDriverを使うことで、開発者はローカルにノードを立ち上げてフローを実行し、状態の更新を検査することができます。以前は、テストを含むビルド・パイプラインが失敗する問題がありました。これは、Notaryが開始するのに1分（デフォルトのタイムアウト値）以上かかることがあったからです。

この問題を解決するために、NodeDriver に新しいパラメータ notaryHandleTimeout が追加されました。このパラメータは、ノータリが開始された後、ノータリ・ハンドルが戻ってくるまでの待ち時間（分）を指定します。

• Notaryワーカーがシャットダウンされると、メッセージ ID のクリーンアップが最初のシャットダウン アクティビティではなく、最後のシャットダウン アクティビティとして実行されるようになりました。これにより、Notaryワーカーが公証人クラスターの一部であり、シャットダウン中にクライアントトラフィックを受信しているように見える状況が回避されます。
• 以前は、ノードが非常に多数のフローを呼び出していたため、削除されていないクライアント ID のキャッシュがかなりのヒープ領域を占有していました。占有するスペースがエントリごとに 170 バイト削減されるソリューションが実装されました。たとえば、1 万個の未削除のクライアント ID が占めるヒープ領域は、以前よりも 170,000,000 バイト少なくなっています。 ーーー
• 新規または再始動されたピア・ノードがオンラインになり、あるノードに初めて接続すると、接続先のノード上の他のピアからのメッセージ処理が大幅に遅くなる可能性があります。これで、オンラインになる新しいピアは、接続先のノードで専用スレッドを取得し、受信側ノード上の既存のピアツーピア接続のメッセージ処理を遅らせません。
• 以前は、新しいノード構成オプションであるcryptoServiceFlowRetryCountが導入されていました。cryptoServiceFlowRetryCountの絶対値は、フローを再試行する回数（N）を決定するようになりました。この修正により、代わりにN+1回の再試行が実行される問題が解決されました。
• インバウンド接続のデフォルトのSSLハンドシェイクタイムアウトが60秒に増加しました。SSLハンドシェイク中に証明書失効リスト（CRL）のダウンロードに時間がかかったり、到達できなかったりした場合、crlCheckSoftFailが有効になっていれば、この60秒がノードに接続を確立するのに十分な時間を与えます。
• 以前は、チェックポイントをロードする際に記録されるログメッセージは、プロセスの最後にロードされたチェックポイントの総数を記録するだけものでした。

現在、次のログが追加されています。

1. チェックポイント: ロードされる 30 種類のチェックポイント (実行可能フローと一時停止フロー) のログが追加されました。ログ・メッセージには、すべてのチェックポイントがロードされるまで、30秒ごとにロードされたチェックポイントの数が表示されます。
2. 終了したフロー: ログメッセージに、終了したフローの数が表示されるようになりました。

Ex.）

[INFO ] 2023-02-03T17:00:12,767Z [main] statemachine.MultiThreadedStateMachineManager. - Loading checkPoints flows {} [INFO ] 2023-02-03T17:00:12,903Z [main] statemachine.MultiThreadedStateMachineManager. - Number of runnable flows: 0. Number of paused flows: 0 {} [INFO ] 2023-02-03T17:00:12,911Z [main] statemachine.MultiThreadedStateMachineManager. - Started loading finished flows {} [INFO ] 2023-02-03T17:00:28,437Z [main] statemachine.MultiThreadedStateMachineManager. - Loaded 9001 finished flows {} [INFO ] 2023-02-03T17:00:43,606Z [main] statemachine.MultiThreadedStateMachineManager. - Loaded 24001 finished flows {} [INFO ] 2023-02-03T17:00:46,650Z [main] statemachine.MultiThreadedStateMachineManager. - Number of finished flows : 27485 {}

• 証明書失効リスト (CRL) のダウンロード時に読み取りタイムアウトが導入されたことで、証明書失効チェックが改善されました。デフォルトのCRL接続タイムアウトも、Cordaノードに合うように調整されています。CRL のキャッシュが 30 秒から 5 分に増加しました。
• AppleシリコンMacからパフォーマンステストスイートを使用する場合の互換性が向上しました。

Corda Enterprise 4.10.1

Corda Enterprise Edition 4.10.1 は、問題の解決に重点を置いた Corda Enterprise Edition のパッチ リリースです。

修正された問題

このリリースには、次の修正が含まれています。

• 削除されたパーティをデータ保管庫に格納しようとすると、StackOverflowExceptionがスローされる問題が解消されました。

Corda Enterprise 4.10

Corda Enterprise Edition 4.10には、いくつかの新機能、拡張機能、および修正が含まれています。

プラットフォームのバージョン変更

Corda 4.10 はプラットフォームバージョン 12 を使用します。

プラットフォームのバージョンの詳細については、「バージョニング」を参照してください。

新機能と機能強化

新しいサービスライフサイクルイベント

起動時に、ノードはステートマシンを起動する直前に新しいサービスライフサイクルイベントBEFORE_STATE_MACHINE_STARTを発行します。ノードは、イベントのすべての受信者が処理を完了するまで、ステートマシンを起動しません。

ノードのヘルスチェックのためのクイックRPC

ノードによって提供される一部のRPCは、標準のRPCスレッドプールをバイパスし、ノードがRPCリクエストのバックログの処理でビジー状態にある場合でも比較的迅速に戻るという点で「高速」になりました。影響を受けるRPCはcurrentNodeTime()とgetProtocolVersion()です。

ピアノードが永続的にブロックされない

以前は、TLS ハンドシェイクの問題が原因で障害が発生したためにノードがピア ノードへの AMQP 接続を開くことに失敗した場合、ノードを再起動しない限り、それ以上の接続試行が試行されないように、ピアが永続的にブロックされる可能性がありました。この更新により、ピアノードは永続的にブロックされなくなりましたが、接続はより長い間隔を使用して再試行されます。

新しい暗号化サービス構成オプションの導入

新しいノード構成オプション cryptoServiceFlowRetryCountが導入されました。

以前は、CryptoServiceExceptionに苦しんだフローは、処理のためにflow hospitalに入っていました。フローは最大 2 回再試行され、それでも失敗した場合は、フローを呼び出したコードに例外が伝達され、フローは失敗しました。

cryptoServiceFlowRetryCount を使用して、暗号化サービスのタイムアウトが原因で CryptoServiceExceptionがスローされた場合の上記の既定のアクションをオーバーライドできるようになりました。その他の原因は、この更新プログラムによる影響を受けません。

cryptoServiceFlowRetryCount の絶対値によって、フローが再試行される回数が決まります。値の符号によって、すべての再試行が使い果たされたときに何が起こるかが決まります。

• 負の値を指定すると、CryptoServiceException が呼び出し元のコードに伝達され、フローは失敗します。これは Corda 4.10 より前のバージョンではデフォルトの振る舞いでした。
• 正の値を指定すると、フローは次のいずれかになるまで一時停止したフロー病院に保持されます。
• ノードが再起動されます
• ノード・オペレーターが手動でフローを再始動する
• ノードオペレーターが手動でフローを強制終了します

JMX経由で公開されるノードステータス

ノードは、現在何をしているかを示すステータスを JMX (net.corda.Node.Status) 経由で公開するようになりました。このステータスは、ノードがJMXを介して情報/メトリックを公開するように構成されている場合にのみ使用できます。

Java シリアライゼーションがファイアウォールで無効になりました

Javaシリアライゼーションは、リモートコード実行を実行するために悪意を持ってアクセスされた場合の攻撃に対する軽減策として、Cordaファイアウォールコンポーネントで無効になりました。

Postgres のサポート

Postgres 13.8 に対応しました。

フローで OpenTelemetry スパンを生成できるようになりました

OpenTelemetry トレース シグナルが、ノード間のフローでサポートされるようになりました。詳細については、「OpenTelemetry」を参照してください。

ノード診断の改善

このリリースには、改善されたノード診断が含まれています。

• ログ・ファイルへのスレッド・ダンプは 5 分ごとに行われます。
• ステートマシンのスレッドプールがブロックされているかどうかを判断するための定期的なチェックがあり、ブロックされている場合は警告が生成されます。
• ログメッセージは、他のフロー上でフローを開始するノードと、受信ノード の両方で出力されるようになりました。これにより、送信側イニシエートセッションはメッセージIDに、受信側イニシエートセッションはメッセージIDに結びつけられる。これにより、ノード間のログの診断が容易になります。

修正された問題

このリリースには、次の修正が含まれています。

• Artemisからの警告メッセージは、ノードからSSHクライアントを切断するときに標準出力に書き込まれなくなりました。ただし、警告はノードのログファイルに書き込まれます。
• inMemory トークン選択を有効にしてトークン SDK を使用する場合の Corda ノードのメモリ使用量が改善されました。
• Cordaは、外部データソース(リモートRDBMSなど)からユーザーの資格情報と権限を取得できます。このデータベースの資格情報は、node.confファイル で構成されます。以前は、ノードが実行されると、Cordaはこのデータベースのパスワードをログファイルに記録していました。この問題は解決され、パスワードはログファイルに書き込まれなくなりました。
• 以前は、アーカイブ・サービス・コマンドは、エラーまたは問題が発生しない限り、ログ・ファイルにメッセージを書き込みませんでした。更新は、コマンドが正常に実行されたときにもメッセージが書き込まれることを意味します。詳細については、「アーカイブ サービスのコマンドライン インターフェイス(CLI)」を参照してください。
• 以前は、トランザクションキャッシュのメモリリークは、処理中のエントリの重みが過小評価されているために発生していました。処理中のエントリの重みが過小評価されるのを防ぐための改善が行われ、より正確に推定されるようになったため、キャッシュされたエンティティの合計サイズが大幅に減少しました。
• フロードレインモードでは、データベースにまだコミットされていない P2P インフライトメッセージが確認されなくなりました。以前は、フロードレインモードでは、すべての処理中のメッセージが重複として認識されていました。
• 以前は、アタッチメント・クラス・ローダがキャッシュから追い出された場合、アタッチメント・クラス・ローダが早く閉じられすぎていました。現在では、アタッチメント・クラス・ローダーのクローズは、（BasicVerifierから）アタッチメント・クラス・ローダーを参照しているすべてのSerializationContextがスコープ外に出るまで遅延されます。
• 高負荷時にデータベーストランザクションがロールバックされ、フローステートマシンのスレッドがフロー処理を停止することがあり、その結果、特定の状況下でノードのロックアップが発生していましたが改善しました。

データベーススキーマの変更

4.9 と 4.10 の間でデータベースの変更はありません。

サードパーティ製コンポーネントのアップグレード

次の表に、4.9.5 Enterprise Edition と 4.10 Enterprise Edition 間の依存関係バージョンの変更を示します。