Corda Enterprise 4.12.5

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

修正された問題

• Corda 4.11およびそれ以前のバージョンでは、ノードがコントラクトを検証する際、それらはすべてCordaノードプロセス内で検証されていました。つまり、カプセル経由でノードプロセスで定義されたカスタムコマンドライン属性（システムプロパティなど）は、コントラクト検証で確認できるということになります。Corda 4.12では、4.12のコントラクトは依然としてCordaノードプロセスで検証されますが、レガシー（つまり、4.11以前）のコントラクトは、新しい外部検証プロセスで検証されるようになりました。この外部検証プロセスは別のプロセスであるため、Cordaノードプロセスで設定されたカスタムコマンドライン属性は受け取りません。これを修正するために、カスタムコマンドライン属性を外部検証プロセスに渡すことができる新しい構成フィールドが定義されました。この新しい構成フィールドはcustom.externalVerifierJvmArgsです。

詳細は、構成フィールドセクションのcustom構成フィールドを参照してください。

Corda Enterprise 4.12.4

Corda Enterprise Edition 4.12.4 は、セキュリティアップデートに対応するための依存関係のアップグレードに焦点を当てたCorda Enterprise Edition のパッチリリースです。

修正された問題

• Log4jに存在する、ログファイルに過剰なメッセージが書き込まれる可能性がある欠陥を回避するため、Log4jのバージョンが2.23.1から2.23.0にダウングレードされました。修正されたLog4jが利用可能になった時点で、このバージョンはより新しいバージョンに更新される予定です。

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

以下の表は、4.12.3と4.12.4Enterprise Editions間の依存バージョン変更をまとめたものです。

Corda Enterprise 4.12.3

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

修正された問題

• CorDappのビルドがエラー java.lang.NoSuchFieldError: id_ml_dsa_44 を発生してビルドに失敗することがある問題が修正されました。この問題は、Bouncy Castleライブラリにおけるバージョン不一致によって発生していました。Bouncy Castleの新しいLTSバージョンがこのフィールドを導入し、Bouncy Castleの依存関係で指定されたバージョン範囲によってこれが選択されていました。この問題は、現在、Corda内でBouncy Castleの依存関係を特定のバージョンに固定することで解決されています。
• ClassNotFoundエラーによりトランザクション検証が失敗することがなくなりました。これは、外部検証器内のレガシーなトランザクションからコマンドをデシリアライズする際に発生していました。デシリアライゼーション時に使用されるクラスローダーにCorDappが含まれておらず、不足しているクラスが自動的に構築できなかったために発生することがありました。この問題が解決されたのは、デシリアライゼーション時にCorDappクラスが利用可能になったためです。さらに、不足しているクラスの自動構築機能は、外部検証者では無効化されました。
• トランザクションリカバリをサポートするためにCordaバージョン4.11で導入された「in-flight transaction」という状態を持つトランザクションは、Ledger Graph CorDappがトランザクショングラフを構築する際に含まれなくなりました。CorDappは現在、in-flightの状態を持つすべてのトランザクションを無視します。
• Notaryの健全性チェッククライアントツールは、現在、問題なく起動します。
• 検証ファイルが空白行を含んでいる場合でも、提供された再検証ファイルを使用するTransaction Validator Utility (TVU) が、検出されたトランザクションの数を正確に報告するようになりました。

Corda Enterprise 4.12.2

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

Transaction Validator Utility（TVU）の更新

次のセクションでは、Transaction Validator Utility（TVU）とCorda 4.12ノードの実行に関する更新された要件について説明します。 以前のドキュメントを明確化し、強化しています。 現在のパッチリリースドキュメントは、以下の内容を反映して更新されています。

• レガシーコントラクトディレクトリ：ネットワーク上のすべてのノードがバージョン4.12のノードである場合、TVUを実行する際、または4.12ノードを実行する際に、レガシーコントラクトディレクトリは不要になりました。
• 4.12 環境要件：TVU は 4.12 環境（データベースを除く）で実行する必要があります。具体的には、cordappsディレクトリには 4.12 互換の CorDapps のみを含める必要があります。下記「Transaction Validator Utility」内の 1.を参照してください。
• レガシーコントラクトディレクトリの目的：レガシーコントラクトディレクトリは、4.12 ノードでレガシーコントラクトを含むトランザクションを構築できるようにするためにのみ必要です。これは、4.12ノードと4.12以前のノードが混在するネットワークでのみ適用されます。
• レガシーJARsディレクトリ：TVUとノードの両方を実行する場合は、legacy-jarsディレクトリを含める必要があります。詳細は、下記「Corda 4.12 ノード」内の4.を参照してください。

Transaction Validator Utility

TVUの目的は、レガシー・トランザクションの検証時に4.12ノードが実行する処理を模倣し、検出されたエラーを報告することです。

1. TVUは、4.12ノードのディレクトリで実行する必要があり、検証対象の4.11データベース（または4.11にアップグレードしたデータベース）を使用します。CorDappsディレクトリには4.12 CorDappsが含まれていることを確認し、必要に応じて、legacy-jarsディレクトリに4.12以前の依存関係を含めます。これは、台帳上の既存コントラクトの添付ファイルで必要となる場合です（下記「Corda 4.12 ノード」内の4.を参照）。legacy-contractsディレクトリは必須ではありません。

Corda 4.12 ノード

2. ネットワークに4.12ノードと4.12以前のノードが混在している場合、各4.12ノードには、4.12以前のコントラクトCorDappsを含むlegacy-contractsディレクトリが必要です。これにより、4.12ノードは4.12以前のコントラクトを含むトランザクションを構築できるようになり、4.12以前のノードとの相互運用が可能になります。このシナリオでは、legacy-jarsディレクトリも必要になる場合があります。下記4.を参照してください。
3. ネットワークがアップグレードされた4.12ノードのみで構成されている場合、legacy-contractsディレクトリは必要ありません。4.12ノードは、レガシーコントラクトのないトランザクションを作成します。ネットワークに4.12以前のノードがないため、legacy-contractsディレクトリがなくとも問題ありません。このシナリオでは、台帳にはすでに4.12以前のトランザクションが含まれているため、legacy-jarsディレクトリが必要になる場合があります。
4. 4.12以前のトランザクションは、検出された時点で外部検証プロセスで検証されます。このプロセスは、デフォルトではCorda 4.11以前に同梱されていたサードパーティライブラリをすべて含んでおらず、また、driversディレクトリをクラスパス上に持っていません。もし、台帳添付のコントラクトが、そのようなサードパーティライブラリや、Corda 4.11以前のdriversディレクトリ内のコンテンツに依存している場合、必要なJARファイルをノードディレクトリ内のlegacy-jarsというディレクトリに配置することができます。このディレクトリ内のJARはすべて、外部検証者のクラスパスに追加されます。TVUは、このような問題の特定と解決の検証をサポートします。

修正された問題

• 外部検証者がlegacy-contractsフォルダを使用する必要はなくなりました。外部検証者は、4.12より前のトランザクションを検証し、コントラクトの添付ファイルを取得する際にデータベースのみを使用します。
• 「複数の主体に送信」および「複数の主体から受信」の操作の周辺に、オープンなテレメトリースパンが追加されました。
• 以前は、トランザクションビルダーで、不足している依存関係を追加しようとした際に、検証の試行に失敗するとログに記録されていました。 現在は、不足している依存関係を決定する際に失敗した場合は、その試行はログに記録されなくなりました。
• このリリースには、AMQP シリアライゼーションのパフォーマンス改善が含まれています。
• テスト用にドライバ DSL を使用する際、X.500 名の Organization (O) フィールド値は同じで、Organization Unit (OU) 値が異なる2つのノードを作成できるようになりました。
• テスト目的で一連のmock networksを作成する際に、メモリリークが発生しなくました。
• 最小プラットフォームバージョンが140（すなわち、4.12）の場合、トランザクションビルダーがレガシーアタッチメントをトランザクションに添付しなくなりました。
• 期待されるサブジェクト名が実際のサブジェクト名と一致せず、Floatが切断された場合、警告が記録されます。
• TVUは、デシリアライズテストの一部として出力statesをデシリアライズする際に、CorDappsクラスローダーを含めるようになりました。さらに、TVUは、ノードと同じadd-opensオプションのセットも含めるようになりました。
• TVUは、トランザクションの検証時にJDK17アタッチメントをデータベースに書き込まなくなりました。
• TVUのメモリリークが解消されました。
• TVUからのヌルポインタ例外（一部の親パスを解決する場合）が解消されました。
• TVUは、別の例外のJSON表現を出力する際に例外を発生させなくなりました。
• TVUは、ノードと同じ方法で構成ファイルを解析するようになりました。
• 新しいlegacy-jarsディレクトリが導入され、以前のバージョンのCordaとの下位互換性が向上しました。詳細は、上記の説明およびアップグレードガイドを参照してください。
• R3が提供するCorDappsのコントラクトJAR署名キーのローテーションは、このパッチリリースに含まれています。

既知の問題

• Finance Contracts CorDappが誤ってCorda Enterprise 4.12ノードJARに組み込まれたため、さまざまなテストに問題が生じ、これらのコントラクトをトランザクションで使用するすべての人に影響が及ぶ可能性がありました。Finance CorDappを使用している場合は、R3は、できればバージョン4.12の稼働前に、このパッチリリースにアップグレードすることを強くお勧めします。

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

以下の表は、4.12.1と4.12.2Enterprise Editions間の依存バージョン変更をまとめたものです。

Corda Enterprise 4.12.1

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

アップグレードの推奨

Corda Enterprise 4.11以前のバージョンから4.12へのアップグレードに関する注意点については、4.12のリリースノートをご参照ください。

修正された問題

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

Corda Enterprise Edition 4.12リリースノート

Corda Enterprise Edition 4.12リリースでは、JavaとKotlinのバージョンアップと、それに伴うアップグレードサポートが導入されました。JavaとKotlinのアップグレードをサポートする機能以外には、大きな新機能は導入されていません。このリリースでは、Java は Java 8 から Java 17 にアップグレードされ、Kotlin は 1.2.71 から Kotlin 1.9.20 にアップグレードされました。

CorDapp(s)とノードが4.12に正常にアップグレードされると、同じネットワーク上で、4.12と4.11（またはそれ以前）の台帳上の既存のトランザクションを含むノードをシームレスに相互運用することができます。

既存のバックチェーンから旧コントラクトも扱う必要があるために、新しいJavaとKotlinのバージョンをサポートすることがこのCordaバージョンの大きな特徴です。また、JavaとKotlinのアップグレードは、CorDapp開発者にとっても意味があります。

なお、他の変更を加えずにCorda JARを単純に置き換えることはできません。

アップグレード推奨

開発者またはノードオペレータとして、できるだけ早くCordaの最新リリースバージョンにアップグレードする必要があります。最新のCorda Enterpriseリリースノートはこのページにあります。最新のアップグレードガイドはCorda Enterprise Edition 4.11から4.12へのアップグレードガイドを参照してください。

このガイドの手順は、Corda 4.11から4.12への直接アップグレードにのみ有効です。バージョン4.10以下のノードがある場合は、最初に4.11にアップグレードする必要があります。そのためには、該当するリリースのアップグレードドキュメントを参照してください。

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

Corda 4.11 はプラットフォームバージョン140を使用しています。

プラットフォームバージョンに関する詳細は、Versioningを参照してください。

新機能、改善点、制限事項

JavaとKotlinのアップグレード

Corda 4.12ではJava 17とKotlin 1.9.20が必要です。すなわち、Corda 4.12と互換性を持たせるために、4.11以前で書かれたレガシーなCorDappsをJava 17とKotlin 1.9.20で動作するように再コンパイルする必要があります。これらのアップグレードはCordaのサポート性とセキュリティを強化します。

Corda SDKのJava 17互換リリース

ベースとなるCordaパッケージには、いくつかのSDKとライブラリが含まれています。これらのSDKとライブラリはJava 17とKotlin 1.9.20と互換性があります

Transaction Validator Utility

Corda 4.12では、Corda 4.12へのアップグレード時にマイグレーション後のエラーを回避するために、データベースにコミットされたトランザクションを検証するツールであるTransaction Validator Utility (TVU)が導入されました。詳細はTransaction Validator Utility を参照してください。

署名制約を使用したCorDappsのみサポート

Corda 4.12では署名制約を使用したCorDappsのみがサポートされています。ハッシュ制約はサポートされていません。

署名制約の使用は、CorDappのアップグレードプロセスを容易にするため、Cordaの以前のリリースで推奨されてきました。ハッシュ制約を使用している4.11のCorDappsがある場合は、4.12にアップグレードする前に4.11の署名制約に移行する必要があります。

Corda4.11と4.12のCorDappsは同じキーセットで署名する必要がある

Java 17とKotlin 1.9.20用に4.12のCorDappsを再コンパイルした際には、4.11のCorDappで使われたのと同じキーセットを使って署名する必要があります。

明示的なコントラクトのアップグレードはサポートされない

Corda 4.12では、明示的なコントラクトのアップグレードはサポートされていません。

toLedgerTransaction.verifyが旧トランザクションで動作しない

CorDappsを見直して、以下のような呼び出しをしていないかチェックしてください。

• SignedTransaction.toLedgerTransaction().verify()
• WireTransaction.toLedgerTransaction().verify()
• TransactionBuilder.toLedgerTransaction().verify()

上記の呼び出しを行うCorDappsは旧トランザクションでは動作しません。これらのCorDappsを互換性のあるものにするには、SignedTransaction.verify()に変更してください。

CordaノードエクスプローラがJava 17に対応していない

ノードエクスプローラはJava 17を使用するように変換されておらず、リリースパックでは提供されていません。ノードエクスプローラを使いたい場合、現在の唯一の選択肢は4.11ノードエクスプローラを使用し、4.12ノードに接続することです。

サンプル Kotlin と Java のサポート

以下の2つのパブリックリポジトリで様々なCorDappのサンプルを提供しています（ブランチ: release/4.12）：

• サンプル Kotlin リポジトリ
• サンプルJavaリポジトリ

ほとんどのサンプルはJava 17、Kotlin 1.9.20、Gradle 7.6.4に変換されています。

サンプルはCorda Open Sourceで動作するように作られています。サンプルをCorda Enterpriseで動作するように変換するには、最低でもエンタープライズアーティファクトがインストールされているリポジトリを指定する必要があります。また、ENT（com.r3）のアーティファクトグループ名はOS（net.corda）と異なる必要があります。たとえば、net.corda:corda-node-driver:4.12（Corda OS）はcom.r3.corda:corda-node-driver:4.12（Corda ENT）に置き替えてください。

以下の依存関係はサンプルで使用されており、Corda OSからCorda Enterpriseに切り替えることができます：

• corda
• corda-confidential-identities
• corda-core-test-utils
• corda-finance-workflows
• corda-jackson
• corda-node
• corda-node-api
• corda-node-driver
• corda-rpc
• corda-shell
• corda-test-utils
• corda-testserver-impl

以下のサンプルはJava 17とKotlin 1.9.20に変換され、テストされています：

KotlinとJavaのCorDappテンプレート

以下のKotlinとJavaのCorDappテンプレートはJava 17、Kotlin 1.9.20、Gradle 7.6.4に変換されました。これらはCorda Community EditionとCorda Open Source Edition (branch: release/4.12) で動作するように書かれています：

• Kotlin CorDappテンプレート
• Java CorDappテンプレート

オプションのゲートウェイプラグインリリースパックはない

オプションのゲートウェイプラグインリリースパックには、CENMゲートウェイサービスで使用されるフローおよびノード管理プラグインが含まれています。これらのプラグインはGUIベースのフローおよびノード管理機能を提供します。CENM はまだ Java 17 を使用するように変換されていないため、これらのプラグインは 4.12 リリースには含まれていません。CENM とプラグインの変換後、将来のリリースで追加される予定です。もしフローおよびノード管理機能を使いたいのであれば，4.11optional-gateway-pluginsリリースパックからプラグインを入手して，CENM ゲートウェイサービスで使うことができます．

内部APIやリフレクティブアクセスを使うCorDapp

CorDappが内部APIやリフレクティブアクセスを使っている場合、コマンドラインで明示的にモジュールを開く必要がある可能性があります。Cordaを起動する時に、1つ以上の-add-opensオプションを追加することで、これを行うことができます。

修正された問題

ノード起動時にフローが再開された場合の Thread.contextClassLoader の設定

以前は、ノード起動時にフローが再開された場合、スレッドコンテキストクラスローダーが設定されず、CorDappクラスのClassNotFound問題を引き起こす可能性がありました。これは現在修正されています。

既知の問題

ロギングレベルがTRACEのとき、余分なスタックトレースを出力する

コマンドラインオプション--logging-level=TRACEによってトレースに設定されたログレベルでノードを開始すると、ArtemisのバグによりLog4jからいくつかのUnable to format stack trace出力が表示されます。これらは無視でき、ノードの操作には影響しません。これらは、org.apache.activemq.artemis.core.paging.cursor.impl.PageCursorProviderImplロガーからのトレース出力を削除するカスタムlog4j.xmlによって削除することができます。

Log4jの起動時のWarning

デフォルトのLog4jでノードを起動すると、次のメッセージが表示されます:main WARN The use of package scanning to locate plugins is deprecated and will be removed in a future release.これは単なるWarningであり、安全に無視できます。現在、代替手段を調査中です。

notaryhealthcheck-clientが起動しない

Corda 4.12のnotaryhealthcheck-clientが起動に失敗します。これは将来のパッチリリースで修正される予定です。代替手段として、Corda 4.11リリースで提供されているnotaryhealthcheck-clientを使用することができます。

deployNodes実行時のBouncy Castleからの断続的なWarning

GradleタスクのdeployNodesを実行すると、以下のような警告メッセージが表示されることがあります：

exception in disposal thread: org/bouncycastle/util/dispose/DisposalDaemon$3

これは現在使用しているBouncy CastleのLTSバージョンからの警告メッセージであり、ユーザーへの影響はありません。ネイティブコードによる参照の廃棄に関連して引き起こされます。将来のパッチリリースで修正される予定です。

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

以下の表は、4.11と4.12 Enterprise Editionの間の依存関係のバージョン変更の一覧です：