Corda Enterprise 4.11.5

Corda Enterprise Edition 4.11.5 は、問題の解決に焦点を当てた 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をベースとしています。

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

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

Corda Enterprise 4.11.4

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

修正された問題

• 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.11.3

Corda Enterprise Edition 4.11.2は、Corda Enterprise Editionの問題解決にフォーカスしたパッチリリースです。

修正された問題

4.11以前のノードからアップグレードする場合、データベースに新スタイルの機密ID（証明書のないID）が含まれていると、データベースのアップグレードに失敗する問題を修正しました。

Corda Enterprise Edition 4.11.2

Corda Enterprise Edition 4.11.2は、Corda Enterprise Editionの問題解決にフォーカスしたパッチリリースです。

修正された問題

• デフォルトの log4j2.xml ファイルで、diagnostic-*または checkpoints_agent-* で始まるログファイルの DefaultRolloverStrategy ポリシーの Delete アクションが間違っていました。このため、誤ったファイル名と比較されていました。この問題は修正され、ファイルがポリシーに従って削除されるようになりました。
• TLS 秘密鍵の保存に HSM を使用した場合の TLS 接続に関する問題が解決されました。
• RPCのgetFlowsMatchingV2拡張操作のリグレッションが修正され、以前のCordaリリースと互換性がなくなりました。この問題はCordaフロー管理GUIで発生し、以前のCordaリリースのフロー・ステータスを表示できませんでした。この修正により、4.11.1または4.11を使用してRPCクライアントを作成した場合は、4.11.2を使用してクライアントを再構築する必要があります。
• 以前は、実際には接続されていないにもかかわらず、ノードがピアとの有効な接続を誤って認識するという稀なエラーシナリオが発生することがありました。この問題は通常、ピアノードが切断/接続しているときに発生します。この問題は現在解決されています。

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

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

Corda Enterprise Edition 4.11.1

Corda Enterprise Edition 4.11.1は、Corda Enterprise Editionの問題解決にフォーカスしたパッチリリースです。

修正された問題

4.11と4.11以前のノード間で、新しいデータ型：TRANSACTION_RECOVERYのトランザクションを送信/フェッチする際の相互運用性を修正しました.

Corda Enterprise Edition 4.11

Corda Enterprise Edition 4.11 には、いくつかの新機能、改善点、および修正が含まれています。

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

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

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

新機能と改善点

JDK Azul および Oracle JDK アップグレード

Corda は現在、JDK Azul 8u382 および Oracle JDK 8u381 をサポートしています。

Ledger Recovery

Corda 4.11 リリースの一環として、Ledger Recoveryが導入されました。これは、標準化された Corda ネットワークの運用バックアップおよびリカバリプロセスを補完します。

詳細については、Ledger Recovery を参照してください。

Two Phase Finality

Two Phase Finality プロトコル（FinalityFlow および ReceiveFinalityFlow サブフロー）が追加され、Finality を使用する CorDapps の耐障害性と回復性を向上させました。既存の CorDapps では、この新しい改良されたプロトコルを利用するための変更は必要ありません。

詳細については、Two Phase Finalityを参照してください。

Finality Recovery Tooling

イニシエータおよびレシーバーの両方が Finality Flow のリカバリを行うための RPC 拡張操作（FlowRPCOps インターフェースへの追加）が追加されました。また、ノードシェルコマンドを使用してオペレーションチームが Finality Flow リカバリを実行できるようになりました。

詳細については、Finality Flow Recovery を参照してください。

Ledger Recovery flow

新しいLedger Recoveryフロー（LedgerRecoveryFlow）は、ノードが自身の台帳に存在しない、かつ当事者（イニシエータまたはレシーバー）であったピアリカバリノードからトランザクションを識別および回復できるようにします。

詳細については、Ledger Recovery flow parameters を参照してください。

コンフィデンシャルアイデンティティのキーペアジェネレータ

新しいサービスが追加され、トランザクションで CI（機密性のあるアイデンティティ）を使用する際に事前に CI キーを生成します。これらの事前生成された CI は、バックアップリカバリの目的で後で使用されます。

追加のネットワークパラメータ

次のネットワークパラメータと関連するノード構成パラメータが追加されました：

• confidentialIdentityMinimumBackupInterval
• recoveryMaximumBackupInterval

これらのネットワークパラメータには CENM 1.6 以降が必要です。

詳細については、Available Network Parameters を参照してください。

配布レコードのクリーンアップ

新しいメンテナンスジョブ DistributionRecordCleanupTaskが追加されました。これにより、recoveryMaximumBackupInterval ネットワークパラメータよりも古いledger recovery配布レコードが削除されます。

ネットワークパラメータ recoveryMaximumBackupInterval が定義されていない場合、node パラメータ enterpriseConfiguration.ledgerRecoveryConfiguration.recoveryMaximumBackupInterval が定義されていれば、その代わりに使用されます。

どちらのパラメータも定義されていない場合、配布レコードのメンテナンスジョブは無効になります。

詳細については、Ledger Recovery distribution record cleanup を参照してください。

二重支払い例外処理の改善

Two Phase Finality は、FinalityFlow の初期化時に重複支払いが検出された場合、未確認のトランザクションを DBTransaction テーブルから自動的に削除します。

さらに、新しいオプションの ReceiveFinalityFlow handlePropagatedNotaryError コンストラクタパラメータが trueに設定されている場合（デフォルト：false）、二重支払いエラー（NotaryError.Conflict）が 2PF イニシエータに伝播します。これにより、イニシエータは関連する未確認のトランザクションを自身の DBTransaction テーブルから自動的に削除できます。

CorDapp が Corda 4.11 にコンパイルされている場合（つまり、その対象プラットフォームバージョンが 13 である場合）、デフォルトで二重支払い処理が有効になります。詳細については、Versioning を参照してください。

AMQPデータのデシリアライズ性能向上

このリリースでは、AMQPデータのデシリアライズのパフォーマンスが向上しており、LedgerGraph、Archiving、および他のCorDappsのパフォーマンスが向上する可能性があります。

Vaultクエリページの読み込み中に変更を検出する

Vault.Pageに新しいプロパティpreviousPageAnchorが追加されました。これは、Vaultクエリのページが読み込まれている間にVaultが変更されたかどうかを検出するために使用されます。このシナリオを検出することが重要な場合、プロパティを使用してクエリを再開することができます。

このプロパティの使用例は、Vault Queriesで確認できます。

依存関係のアップグレード

以下の依存関係がアップグレードされ、重大なセキュリティの脆弱性に対処しています。

Hibernateが5.4.32.Finalから5.6.14.Finalにアップグレードされました。

H2が1.4.197から2.2.214にアップグレードされました。

H2データベースは、既知の脆弱性に対処するために、バージョン2.2.224にアップグレードされました。H2はサポートされていない本番データベースであり、開発およびテスト目的でのみ使用する必要があります。H2バージョン1.4.197（Cordaの以前のバージョンで使用されていたバージョン）と、4.11で実装された新しいH2バージョン2.2.224の違いに関する詳細は、H2ドキュメントを参照してください。最も重要な違いは次のとおりです。

• エンティティの命名 H2バージョン2.2.224は、データベース内のテーブルと列の命名に関する厳格なルールを実装しています。SQLのキーワードの使用はもはや許可されていません。CorDappスキーマがテーブルまたは列に予約された名前を使用している場合、CorDappのフローはテーブルと対話しようとしたときに失敗し、関連するSQL例外が発生します。

この問題の解決策は、問題のあるテーブルまたは列の名前を予約されていない名前に変更することです。この名前変更プロセスは、CorDappの移行スクリプトとCorDappコード内のJPAエンティティ定義で実装する必要があります。

• 後方互換性

H2バージョン2.xは、古いバージョンと後方互換性がありません。H2データベースURLにMODE=LEGACYを追加することで、限られた後方互換性を実現できます。詳細については、H2 FeaturesページのLEGACY Compatibility Modeセクションを参照してください。

H2 2.xは、古いH2バージョンで作成されたデータベースファイルを読み取ることができません。古いデータベースをアップグレードするための推奨されるアプローチは、データをエクスポートしてそれを新しいバージョン2.xデータベースに再インポートすることです。このプロセスの詳細については、H2 Migration to 2.0ページに記載されています。

Liquibaseが3.6.3から4.20.0にアップグレードされました。

• API

このLiquibaseのバージョンには、前のバージョンとはわずかに異なるAPIがあります。Liquibaseを使用した独自のデータベースマイグレーションコードを実装しているCorDappsは、新しいAPIに合わせて更新する必要があります。

• ログ このLiquibaseのバージョンでは、すべてのINFOレベルのログがSTDERRに向けられ、STDOUTはSQLクエリのログに使用されます。Liquibaseを使用した独自のデータベースマイグレーションコードを実装しているユーティリティは、カスタムロガーを確立してLiquibaseの情報ログをキャプチャできます。Liquibase APIは、カスタムロガーを統合するために使用できるクラスを提供しています。

vault_stateテーブルに追加された消費トランザクションID

Stateがトランザクションによって消費されると、Cordaはvault_stateテーブルのconsuming_tx_id列に消費トランザクションのIDを追加します。Cordaは新しいトランザクションのためにのみこのデータベース列を更新します。すでに台帳に存在する消費されたStateに対しては、consuming_tx_idの値はnullです。

パフォーマンス向上のためのノード構成変更

フローの待ち時間を短縮し、スループットを向上させるために、ノード構成の以下のデフォルト値が変更されました。

• enterpriseConfiguration.tuning.brokerConnectionTtlCheckIntervalMsは20から1ミリ秒に変更されました。
• enterpriseConfiguration.tuning.journalBufferTimeoutは3333333ナノ秒から1000000ナノ秒に変更されました。
• notary.extraConfig.batchTimeoutMsは200から1に変更されました。

DJVMの削除

DJVMのベータ機能が削除されました。DJVMの削除の結果、DriverParametersクラスからdjvmBootstrapSourceおよびdjvmCordaSourceの2つのコンストラクタパラメータが削除されました。DriverParametersを使用するクライアントコードは、再コンパイルが必要です。

追加の署名検証

recordTransactions()関数は、公開ServiceHub APIを使用する場合に、より厳格な署名検証を実行します。詳細については、DBTransactionStorageを参照してください。

解消された問題

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

• PostgreSQL 9.6および10.10は、PostgreSQL自体によってサポートされなくなったため、サポートマトリックスから削除されました。
• log4j2.xmlは、ロールオーバー戦略の構成で診断およびチェックポイントログ用の正しいファイルを削除します。
• 前のパッチリリースでは、SSL証明書の処理を強化する一環として、失敗したSSLハンドシェイクに関連する特定のログメッセージが意図せず追加されました。これらのメッセージは、トラフィックロードバランサーやシステムモニタリングの接続性テスト中にログに頻繁に表示されました。ログのノイズを減少させるために、これらの特定のログメッセージを無効にしました。

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

すべてのデータベーステーブルの詳細な説明については、データベーステーブルを参照してください。

以下のデータベース変更が適用されました：

• vault_stateテーブルには、新しいconsuming_tx_id列が追加されました。この新しい列は、次のマイグレーションスクリプトで追加されました：vault-schema.changelog-v14.xml。
• Two Phase Finalityは、メインのDbTransactionテーブル内に追加のデータフィールドを導入しました。

@Column(name = "signatures")
val signatures: ByteArray?

Two Phase Finality は、回復メタデータの配布レコードを格納するための新しいデータベーステーブルを2つ導入します:

@Entity
@Table(name = "${NODE_DATABASE_PREFIX}sender_distr_recs")
data class DBSenderDistributionRecord(
        @EmbeddedId
        var compositeKey: PersistentKey,

        /** states to record: NONE, ALL_VISIBLE, ONLY_RELEVANT */
        @Column(name = "sender_states_to_record", nullable = false)
        var senderStatesToRecord: StatesToRecord,

        /** states to record: NONE, ALL_VISIBLE, ONLY_RELEVANT */
        @Column(name = "receiver_states_to_record", nullable = false)
        var receiverStatesToRecord: StatesToRecord
)

@Entity
@Table(name = "${NODE_DATABASE_PREFIX}receiver_distr_recs")
data class DBReceiverDistributionRecord(
        @EmbeddedId
        var compositeKey: PersistentKey,

        /** Encrypted recovery information for sole use by Sender **/
        @Lob
        @Column(name = "distribution_list", nullable = false)
        val distributionList: ByteArray,

        /** states to record: NONE, ALL_VISIBLE, ONLY_RELEVANT */
        @Column(name = "receiver_states_to_record", nullable = false)
        val receiverStatesToRecord: StatesToRecord
)

上記のテーブルは同じ永続的な複合キータイプを使用します:

@Embeddable
@Immutable
data class PersistentKey(
        @Column(name = "transaction_id", length = 144, nullable = false)
        var txId: String,

        @Column(name = "peer_party_id", nullable = false)
        var peerPartyId: Long,

        @Column(name = "timestamp", nullable = false)
        var timestamp: Instant,

        @Column(name = "timestamp_discriminator", nullable = false)
        var timestampDiscriminator: Int
)

配布リストのプライバシー情報（暗号キーを含む）を保持するための2つの追加のテーブルがあります:

@Entity
@Table(name = "${NODE_DATABASE_PREFIX}recovery_party_info")
data class DBRecoveryPartyInfo(
        @Id
        /** CordaX500Name hashCode() **/
        @Column(name = "party_id", nullable = false)
        var partyId: Long,

        /** CordaX500Name of party **/
        @Column(name = "party_name", nullable = false)
        val partyName: String
)

@Entity
@Table(name = "${NODE_DATABASE_PREFIX}aes_encryption_keys")
class EncryptionKeyRecord(
        @Id
        @Type(type = "uuid-char")
        @Column(name = "key_id", nullable = false)
        val keyId: UUID,

        @Column(name = "key_material", nullable = false)
        val keyMaterial: ByteArray
)

Ledger RecoveryのためのConfidential Identityの事前生成により、node_our_key_pairsテーブル内に4つの新しいフィールドが導入されます:

@Entity
@Table(name = "${NODE_DATABASE_PREFIX}our_key_pairs")
class PersistentKey(

      <.... existing fields not shown .... >

      @Enumerated(EnumType.ORDINAL)
      @Column(name = "key_type", nullable = false)
      var keyType: KeyType = CI,

      @Column(name = "crypto_config_hash", length = MAX_HASH_HEX_SIZE, nullable = true)
      var cryptoConfigHash: String? = null,

      @Enumerated(EnumType.ORDINAL)
      @Column(name = "status", nullable = false)
      var status: Status = CREATED,

      @Column(name = "generate_tm", nullable = false)
      var insertionDate: Instant = Instant.now()
)

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

以下の表は、4.10.3と4.11 Enterprise Editionsの間での依存関係のバージョン変更をリストアップしています:

Log4jパッチ

2021年12月のLog4jの脆弱性に対処するすべてのパッチはこちらをクリックしてください。