🗒️Corda Enterprise 4.12 リリースノート

💡

こちらの記事はCorda Enterprise 4.12の英文リリースノートを翻訳したものとなります。原文はこちらをご参照ください。

⚠️

ノードを Corda 4.12 にアップグレードする際、Transaction Validator Utilityをノードデータベースに対して実行し、古いノードのトランザクションが 4.12 ノードと互換性があるかを確認することが極めて重要です。また、互換性を確保するため、アップグレードしない予定の古いノードであっても、アップグレード済みのノードとやり取りする可能性がある場合は、同様に TVU を実行する必要があります。詳細については、「Transaction Validator Utility」を参照してください。

Corda Enterprise Edition 4.12.8

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

アップグレード推奨事項

重要：ノードをCorda 4.12にアップグレードする際は、Transaction Validator Utilityを古いノードのデータベースで実行し、古いノードのトランザクションが4.12ノードと互換性があることを確認することが非常に重要です。
トランザクションの互換性を確保するには、アップグレードされていない古いノードでもTransaction Validator Utilityを実行する必要があります。これらのノードはアップグレードされたノードと相互作用する可能性があるためです。
詳細については、Transaction Validator Utilityを参照してください。

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

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

修正された問題

Transaction BuilderがNoClassDefFoundErrorでドット付きの欠落クラス名を無視していた問題を修正しました。このクラスのクラス名は、ドットまたはスラッシュのいずれかを使用して処理できるようになりました。
多数の依存関係がアップグレードされました。以下のサードパーティコンポーネントのアップグレードを参照してください。
TransactionBuilderによる欠落クラス検索時のアタッチメント処理の問題を修正しました。これは現在以下のように行われます：

アタッチメントの検索優先順位：TransactionBuilderはまずインストールされたCorDappsを検索し、必要な場合のみデータベースにフォールバックします。JDK 17互換のアタッチメントのみが考慮されます。レガシーCorDappsはデータベースフォールバックを使用しません。
決定論的選択：アタッチメントのタイプに応じて、アタッチメントはバージョン（降順）、ID（昇順）、または挿入日（降順）でソートされ、ノード間で一貫した予測可能なアタッチメント解決が保証されます。詳細については、アタッチメントの解決方法を参照してください。

4.12.6および4.12.7で使用されていたquasar 0.9.1_r3でリグレッションが発見されました。これは解決されました。以前に4.12.6または4.12.7へのアップグレードを検討していた場合は、代わりにquasar 0.9.2_r3を使用する4.12.8にアップグレードしてください。
ノータリーヘルスチェックコントラクトCorDappが、R3プロダクションキーで署名されるようになりました。以前はR3開発者キーで署名されていました。

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

この表は、Corda Enterprise Edition 4.12.8の依存関係バージョンの更新を示しています。バージョンが変更されていない依存関係は省略されています。

依存関係	4.12.8 Enterprise
co.paralleluniverse:quasar-core	0.9.2_r3
com.github.docker-java:docker-java	3.6.0
com.github.docker-java:docker-java-transport-httpclient5	3.6.0
org.bouncycastle:*	2.73.9
com.nimbusds:oauth2-oidc-sdk	8.36.2
com.nimbusds:nimbus-jose-jwt	10.0.2
org.apache.zookeeper:zookeeper	3.9.4

Corda Enterprise Edition 4.12.7

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

アップグレード推奨事項

重要：ノードをCorda 4.12にアップグレードする際は、Transaction Validator Utilityを古いノードのデータベースで実行し、古いノードのトランザクションが4.12ノードと互換性があることを確認することが非常に重要です。
トランザクションの互換性を確保するには、アップグレードされていない古いノードでもTransaction Validator Utilityを実行する必要があります。これらのノードはアップグレードされたノードと相互作用する可能性があるためです。
詳細については、Transaction Validator Utilityを参照してください。

修正された問題

Corda Network BuilderがDockerおよびAzure環境でCLI経由でCordaネットワークを正しくデプロイするようになりました。
脆弱性のため、Nettyが4.1.127.Finalにアップグレードされました。

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

以下の表は、4.12.6と4.12.7 Enterprise Edition間の依存関係バージョンの変更を示しています。バージョンが変更されていない依存関係は省略されています。

依存関係	名前	4.12.6 Enterprise	4.12.7 Enterprise
io.netty:*	Netty	4.1.122.Final	4.1.127.Final

Corda Enterprise Edition 4.12.6

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

アップグレード推奨事項

重要：ノードをCorda 4.12にアップグレードする際は、Transaction Validator Utilityを古いノードのデータベースで実行し、古いノードのトランザクションが4.12ノードと互換性があることを確認することが非常に重要です。
トランザクションの互換性を確保するには、アップグレードされていない古いノードでもTransaction Validator Utilityを実行する必要があります。これらのノードはアップグレードされたノードと相互作用する可能性があるためです。
詳細については、Transaction Validator Utilityを参照してください。

修正された問題

極めてまれに、メッセージがArtemisでスタックする可能性がありました。この問題はArtemisチームに報告されています。回避策として、Cordaは現在これが発生したことを自動的に検出し、メッセージを再送信します。
以前は、欠落クラスを検索する際に間違ったレガシーアタッチメントが選択されていました。現在、欠落クラスのレガシーアタッチメントJARはlegacy-contractsフォルダにも存在する必要があります。詳細：以前は、欠落クラスを含むアタッチメントをアタッチメントストレージテーブルで検索していました。実行された唯一のチェックは、このアタッチメントがcordappsフォルダにもないことを確認することでした。cordappsフォルダになければ、レガシーアタッチメントであると想定されていました。しかし、これはデータベースに複数のJDK17アタッチメント（同じCorDappの異なるバージョン）が存在し、最新のものだけがcordappsフォルダにある可能性があるという事実を無視しています。現在、アタッチメントテーブルがチェックされますが、legacy-contractsフォルダの内容に対してフィルタリングされます。
newrelic-api.jarはcorda.jar内にバンドルされなくなりました。New Relicの機能は変更されていません：New Relicライブラリがクラスパスに存在し、適切に設定されていれば、メトリクスは以前と同様に報告されます。
以前は、フローrecoverAllFinalityFlowsが非アクティブなフローをアクティブとして扱っていませんでした。この動作は修正されました。

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

以下の表は、4.12.5と4.12.6 Enterprise Edition間の依存関係バージョンの変更を示しています。バージョンが変更されていない依存関係は省略されています。

依存関係	名前	4.12.5 Enterprise	4.12.6 Enterprise
org.apache.activemq:*	Artemis	2.36.0	2.42.0
commons-beanutils:commons-beanutils	beanutils	1.9.4	1.11.0
org.apache.curator:*	Curator	5.6.0	5.9.0
com.github.docker-java:docker-java	docker Java	3.2.5	3.5.3
org.apache.logging.log4j:*	Log4j	2.23.0	2.24.3
io.netty:*	Netty	4.1.115.Final	4.1.122.Final
co.paralleluniverse:quasar	Quasar	0.9.0_r3	0.9.1_r3
org.apache.shiro:*	Shiro	1.10.0	1.13.0

Corda Enterprise Edition 4.12.5

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

アップグレード推奨事項

重要：ノードをCorda 4.12にアップグレードする際は、Transaction Validator Utilityを古いノードのデータベースで実行し、古いノードのトランザクションが4.12ノードと互換性があることを確認することが非常に重要です。
トランザクションの互換性を確保するには、アップグレードされていない古いノードでもTransaction Validator Utilityを実行する必要があります。これらのノードはアップグレードされたノードと相互作用する可能性があるためです。
詳細については、Transaction Validator Utilityを参照してください。

修正された問題

Corda 4.11以前では、ノードがコントラクトを検証する際、すべてCordaノードプロセス内で検証されていました。これは、カプセル経由でノードプロセスに定義されたカスタムコマンドライン属性（例：システムプロパティ）がコントラクト検証で参照可能であることを意味していました。Corda 4.12では、4.12コントラクトは依然としてCordaノードプロセスで検証されますが、レガシー（4.11以前）コントラクトは新しい外部検証プロセスで検証されるようになりました。この外部検証は別のプロセスであるため、Cordaノードプロセスに設定されたカスタムコマンドライン属性を受け取りません。これを解決するために、外部検証プロセスにカスタムコマンドライン属性を渡すことを可能にする新しい設定フィールドが定義されました。この新しい設定フィールドはcustom.externalVerifierJvmArgsです。詳細については、設定フィールドのcustom設定フィールドを参照してください。

Corda Enterprise Edition 4.12.4

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

アップグレード推奨事項

重要：ノードをCorda 4.12にアップグレードする際は、Transaction Validator Utilityを古いノードのデータベースで実行し、古いノードのトランザクションが4.12ノードと互換性があることを確認することが非常に重要です。
トランザクションの互換性を確保するには、アップグレードされていない古いノードでもTransaction Validator Utilityを実行する必要があります。これらのノードはアップグレードされたノードと相互作用する可能性があるためです。
詳細については、Transaction Validator Utilityを参照してください。

修正された問題

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

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

以下の表は、4.12.3と4.12.4 Enterprise Edition間の依存関係バージョンの変更を示しています：

依存関係	名前	バージョン 4.12.3 Enterprise	バージョン 4.12.4 Enterprise
io.netty:netty-buffer<br>io.netty:netty-codec<br>io.netty:netty-common<br>io.netty:netty-handler<br>io.netty:netty-resolver<br>io.netty:netty-transport*	Netty	4.1.109.Final	4.1.115.Final
org.apache.logging.log4j:*	Apache	2.23.1	2.23.0

Corda Enterprise Edition 4.12.3

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

アップグレード推奨事項

重要：ノードをCorda 4.12にアップグレードする際は、Transaction Validator Utilityを古いノードのデータベースで実行し、古いノードのトランザクションが4.12ノードと互換性があることを確認することが非常に重要です。
トランザクションの互換性を確保するには、アップグレードされていない古いノードでもTransaction Validator Utilityを実行する必要があります。これらのノードはアップグレードされたノードと相互作用する可能性があるためです。
詳細については、Transaction Validator Utilityを参照してください。

修正された問題

CorDappビルドがエラーjava.lang.NoSuchFieldError: id_ml_dsa_44でビルドに失敗する可能性がある問題を修正しました。この問題は、Bouncy Castleライブラリのバージョン不一致から発生しました。Bouncy Castleの新しいLTSバージョンでこのフィールドが導入され、Bouncy Castle依存関係で指定されたバージョン範囲によってピックアップされていました。この問題は、Corda内でBouncy Castle依存関係を特定のバージョンにロックすることで解決されました。
外部検証でレガシートランザクションからコマンドをデシリアライズする際に、ClassNotFoundエラーが発生してトランザクション検証が失敗する問題が発生しなくなりました。これは、デシリアライズ中に使用されるクラスローダーにCorDappsが含まれず、欠落クラスを自動構築できなかったために発生することがありました。動作した場合でも、それはCordaが欠落クラスを構築できたからに過ぎませんでした。この問題は、デシリアライズ中にCorDappクラスが利用可能であることを保証することで解決されました。さらに、外部検証の欠落クラス自動構築機能が無効化されました。
トランザクション回復をサポートするためにCordaバージョン4.11で導入されたフライト中トランザクション状態を持つトランザクションは、Ledger Graph CorDappがトランザクショングラフを構築する際に含まれなくなりました。代わりに、CorDappはフライト中ステータスを持つトランザクションを無視するようになりました。
ノータリーヘルスチェッククライアントツールが問題なく起動するようになりました。
Transaction Validator Utility（TVU）は、提供された再検証ファイルに空白行が含まれている場合でも、発見されたトランザクションの数を正確に報告するようになりました。

Corda Enterprise Edition 4.12.2

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

アップグレード推奨事項

重要：ノードをCorda 4.12にアップグレードする際は、Transaction Validator Utilityを古いノードのデータベースで実行し、古いノードのトランザクションが4.12ノードと互換性があることを確認することが非常に重要です。
トランザクションの互換性を確保するには、アップグレードされていない古いノードでもTransaction Validator Utilityを実行する必要があります。これらのノードはアップグレードされたノードと相互作用する可能性があるためです。
詳細については、Transaction Validator Utilityを参照してください。

Transaction Validator Utilityの更新

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

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

TVUの目的は、4.12ノードがレガシートランザクションを検証する際の動作を模倣し、発見されたエラーを報告することです。

TVUは4.12ノードディレクトリで実行する必要があります。検証対象の4.11データベース（または4.11にアップグレードされたデータベース）を使用します。CorDappsディレクトリには4.12 CorDappsが含まれていることを確認し、台帳上の既存のコントラクトアタッチメントで必要とされる4.12以前の依存関係がある場合はlegacy-jarsディレクトリに含めてください（以下のポイント4を参照）。legacy-contractsディレクトリは不要です。
ネットワークに4.12ノードと4.12以前のノードが混在している場合、各4.12ノードには4.12以前のコントラクトCorDappsを含むlegacy-contractsディレクトリが必要です。これにより、4.12ノードが4.12以前のコントラクトを含むトランザクションを構築でき、4.12以前のノードとの相互運用が可能になります。このシナリオでは、legacy-jarsディレクトリも必要になる場合があります - 以下のポイント4を参照してください。
ネットワークがアップグレードされた4.12ノードのみで構成されている場合、legacy-contractsディレクトリは不要です。4.12ノードはレガシーコントラクトなしでトランザクションを作成しますが、ネットワークに4.12以前のノードがないため問題ありません。このシナリオでは、台帳にすでに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名が同じOrganisation（O）フィールド値を持ち、異なるOrganisation Unit（OU）値を持つ2つのノードを作成できるようになりました。
テスト目的で一連のモックネットワークを作成する際のメモリリークがなくなりました。
最小プラットフォームバージョンが140（つまり4.12）の場合、トランザクションビルダーはレガシーアタッチメントをトランザクションに添付しなくなりました。
予期されるサブジェクト名と実際のサブジェクト名が一致せず、Floatが切断された場合、警告がログに記録されます。
TVUは、デシリアライゼーションテストの一部として出力状態をデシリアライズする際にCorDappsクラスローダーを含むようになりました。さらに、TVUはノードと同じadd-opensオプションのセットも含むようになりました。
TVUは、トランザクションを検証する際にJDK17アタッチメントをデータベースに書き込まなくなりました。
TVUのメモリリークが解決されました。
TVU（一部の親パスを解決する際）のnullポインタ例外が解決されました。
TVUは、別の例外のJSON表現を出力する際に例外を発生させなくなりました。
TVUは、ノードと同じ方法で設定ファイルを解析するようになりました。
以前のバージョンのCordaとの後方互換性を向上させるために、新しいlegacy-jarsディレクトリが導入されました。詳細については上記の説明とアップグレードガイドを参照してください。
R3提供のCorDappsのコントラクトJAR署名キーローテーションがこのパッチリリースに含まれています。

既知の問題

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

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

以下の表は、4.12.1と4.12.2 Enterprise Edition間の依存関係バージョンの変更を示しています：

依存関係	名前	バージョン 4.12.1 Enterprise	バージョン 4.12.2 Enterprise
org.eclipse.jetty:*	Jetty	12.0.7	12.0.14
commons-io:commons-io	commons IO	2.7	2.17.0
org.apache.commons:commons-configuration2	commonsConfiguration2	2.10.1	2.11.0
org.apache.sshd:sshd-common	sshd	2.12.1	2.13.2
org.apache.zookeeper:*	Zookeeper	3.8.3	3.8.4

Corda Enterprise Edition 4.12.1

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

アップグレード推奨事項

重要：ノードをCorda 4.12にアップグレードする際は、Transaction Validator Utilityを古いノードのデータベースで実行し、古いノードのトランザクションが4.12ノードと互換性があることを確認することが非常に重要です。
トランザクションの互換性を確保するには、アップグレードされていない古いノードでもTransaction Validator Utilityを実行する必要があります。これらのノードはアップグレードされたノードと相互作用する可能性があるためです。
詳細については、Transaction Validator Utilityを参照してください。

修正された問題

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

Corda Enterprise Edition 4.12

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

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

新しいJavaおよびKotlinバージョンのサポートは主要な機能です。既存のバックチェーンからのレガシーコントラクトも処理する必要があるためです。アップグレードされたJavaおよびKotlinバージョンは、CorDapp開発者にも影響を与えます。他の変更を導入せずにCorda JARを単純に置き換えることはできません。

アップグレード推奨事項

重要：ノードをCorda 4.12にアップグレードする際は、Transaction Validator Utilityを古いノードのデータベースで実行し、古いノードのトランザクションが4.12ノードと互換性があることを確認することが非常に重要です。
トランザクションの互換性を確保するには、アップグレードされていない古いノードでもTransaction Validator Utilityを実行する必要があります。これらのノードはアップグレードされたノードと相互作用する可能性があるためです。
詳細については、Transaction Validator Utilityを参照してください。

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

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

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

新機能、機能強化、制限事項

JavaおよびKotlinのアップグレード

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

Java 17互換のCorda SDKリリース

基本CordaパッケージにはいくつかのSDKとライブラリが含まれています。これらのSDKとライブラリはJava 17およびKotlin 1.9.20と互換性があります：

SDK/ライブラリ	Java 17互換リリース
corda-shell	4.12
r3-libs	1.4
confidential-identities	1.2
accounts	1.1
token-sdk	1.3
reissue-cordapp	1.1
archiving	1.2
ledger-graph	1.3
r3-tools	4.12

Collaborative Recoveryの削除

Collaborative Recoveryソリューションと関連するCorDapps（LedgerSyncおよびLedgerRecover）は非推奨となり、Corda 4.12で削除されました。Corda Enterprise Edition 4.11リリースノートで説明されているように、バージョン4.11で導入された新しいリカバリツールを使用することをお勧めします。

Transaction Validator Utility

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

シグネチャ制約とAlwaysAcceptAttachmentConstraintのみのサポート

Corda 4.12では、シグネチャ制約とAlwaysAcceptAttachmentConstraintを使用するCorDappsのみがサポートされています。ハッシュ制約はサポートされていません。シグネチャ制約の使用は、CorDappアップグレードプロセスを容易にするため、Cordaの以前のリリースで推奨されていました。ハッシュ制約を使用する4.11 CorDappsがある場合は、4.12にアップグレードする前に4.11でシグネチャ制約に移行する必要があります。AlwaysAcceptAttachmentConstraintを使用する4.11 CorDappsがある場合、それらのCorDappsは4.12でAlwaysAcceptAttachmentConstraintを引き続き使用できます。

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

4.12 CorDappsをJava 17とKotlin 1.9.20用に再コンパイルした後、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）：

Samples Kotlinリポジトリ
Samples 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に変換およびテストされています：

CorDappタイプ	CorDapp
Accounts	obligation-accounts
	sharestatewithaccount
	supplychain
	worldcupticketbooking
Advanced	duediligence-cordapp
	negotiation-cordapp
	obligation-cordapp
	superyacht-cordapp
	syndicated-lending
Basic	cordapp-example
	flow-database-access
	flow-http-access
	opentelemetry-cordapp-example
	ping-pong
	tutorial-applestamp
	tutorial-jarsigning
	tutorial-networkbootrstrapper
Features	attachment-blacklist
	attachment-sendfile
	confidentialIdentity-whistleblower
	contractsdk-recordplayers
	cordaService-autopayroll
	customlogging-yocordapp
	customquery-carinsurance
	dockerform-yocordapp
	encumbrance-avatar
	multioutput-transaction
	notarychange-iou
	observableStates-tradereporting
	oracle-primenumber
	postgres-cordapp
	queryableState-carinsurance
	referenceStates-sanctionsBody
	schedulableState-heartbeat
	state-reissuance
Tokens	bikemarket
	dollartohousetoken
	fungiblehousetoken
	stockpaydividend
	tokentofriend

KotlinおよびJava CorDappテンプレート

以下のKotlinおよびJava CorDappテンプレートは、Java 17、Kotlin 1.9.20、Gradle 7.6.4に変換されています。これらはCorda Open Source Edition向けに書かれています（ブランチ：release/4.12）：

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

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

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

内部APIまたはリフレクティブアクセスを使用するCorDapp

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

CENM互換性

CENMリリースノートに記載されている例外を除き、このバージョンのCordaは現在リリースされているすべてのバージョンのCENMと互換性があります。

修正された問題

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

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

既知の問題

ログレベルがTRACEの場合の追加スタックトレース出力

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

Log4jからの起動時警告

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

notaryhealthcheck-clientの起動失敗

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

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

GradleタスクdeployNodesを実行すると、次の警告メッセージが表示される場合があります：

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

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

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

以下の表は、4.11と4.12 Enterprise Edition間の依存関係バージョンの変更を示しています：

依存関係	名前	バージョン 4.11 Enterprise	バージョン 4.12 Enterprise
com.google.guava:guava	Guava	28.0-jre	33.1.0-jre
co.paralleluniverse:quasar-core	Quasar	0.7.16_r3	0.9.0_r3
org.bouncycastle	Bouncy Castle	jdk18on:1.75	lts8on:2.73.6
pro com.guardsquare:proguard-gradle	ProGuard	6.1.1	7.3.1
org.yaml:snakeyaml	SnakeYAML	1.33	2.2
com.github.ben-manes.caffeine:caffeine	Caffeine	2.9.3	3.1.8
io.netty:netty-tcnative-boringssl-static	TC Native	2.0.48.Final	2.0.65.Final
org.apache.commons:commons-configuration2	Commons Configuration2	2.10.0	2.10.1
co.paralleluniverse:capsule	Capsule	1.0.3	1.0.4_r3
org.ow2.asm:asm	ASM	7.1	9.5
org.apache.activemq:*	Artemis	2.19.1	2.32.0
com.fasterxml.jackson.*	Jackson XML	2.13.5	2.17.0
org.eclipse.jetty.ee10:jetty-ee10-*	Jetty	9.4.53.v20231009	12.0.7
org.glassfish.jersey.*	Jersey	2.25	3.1.6
javax.validation:validation-api	Validation	-	2.0.1.Final
org.slf4j:* Simpe	Log4J	1.7.30	2.0.12
org.apache.logging.log4j:*	Log4j	2.17.1	2.23.1
com.squareup.okhttp3:okhttp	OK HTTP	3.14.9	4.12.0
io.netty:*	Netty	4.1.77.Final	4.1.109.Final
org.apache.commons:commons-fileupload2-jakarta	File Upload	1.4	2.0.0-M1
com.esotericsoftware:kryo	Kryo	4.0.2	5.5.0
org.mockito:mockito-core	Mockito	2.28.2	5.5.0
org.mockito.kotlin:mockito-kotlin	Mockito for Kotlin	1.6.0	5.2.1
org.jetbrains.dokka:dokka-gradle-plugin	Dokka for Gradle	0.10.1	1.8.20
net.i2p.crypto:eddsa	EddSA	0.3.0	-
com.zaxxer:HikariCP	Hikari	3.3.1	5.1.0
org.iq80.snappy:snappy	Snappy	0.4	0.5
commons-io:commons-io	Commons I/O	2.6	2.7
org.javassist:javassist	Java Assist	3.27.0-GA	3.29.2-GA
org.jooq:joor	Joor	-	0.9.15
org.apache.curator:*	Apache Curator	5.1.0	5.6.0
org.apache.zookeeper:zookeeper	Apache Zookeeper	-	3.8.3
org.apache.commons:commons-dbcp2	Apache Commons	-	2.12.0

⏱️

Last updated: 2026/1/9 by 齊藤