Corda 5.2.2

Corda 5.2.2 は、Corda の回復力向上に焦点を当てた Corda のパッチリリースです。このページでは、Corda 5.2.2 リリースにおける主な変更点を以下に示します。

アップグレード推奨

Corda 5.2.2 パッチリリースにはバグ修正が含まれ、また、Kafka エラーに対する Corda クラスターの回復力も向上しています。また、Corda の自己報告型健全性メカニズムの改善も含まれています。したがって、5.2.1 から 5.2.2 への移行はローリングアップグレードで実行できます。必要なのは、Helm チャートのアップグレードコマンドを使用してワーカーソフトウェアのバージョンを 5.2.2 に更新することだけです。その後、ワーカーをレプリカ数ゼロまでスケールダウンし、その後必要あレプリカ数までスケールアップして新しいイメージを適用することができます。

5.1から直接5.2.2にアップグレードすることはできません。5.1のユーザーは、5.2のアップグレードプロセスを使用してバージョン5.2にアップグレードし、その後、5.2.1のアップグレード手順を使用してバージョン5.2.1にアップグレードする必要があります。その後、5.2.2 のアップグレード手順に従ってください。 Corda クラスターのアップグレードに関する情報は、以下を参照してください。

• 5.1 から 5.2 へのアップグレード。
• 5.2 から 5.2.1 へのアップグレード。
• 5.2.1 から 5.2.2 へのアップグレード。

機能強化

最大メッセージサイズの検証

Cordaは、Kafkaメッセージバスに送信されるメッセージのペイロードサイズに上限を設けています。この制限は、corda.messagingセクションのmaxAllowedMessageSizeフィールドを介して構成せれます。

ユーザーデータが最大許容メッセージサイズを超えないように、以下の領域に検証メカニズムが導入されています。

フロー開始リクエスト

フロー開始リクエストは、maxAllowedMessageSizeの最大50%に制限されています。この制限は、システム内の後続のペイロードにおけるフィールドの重複を考慮したものです。クライアントがこのサイズを超えるフローを開始しようとすると、エラーが返され、フローは開始されません。

外部メッセージングAPI

外部メッセージングAPIは、すでにCorda 5.2に存在しており、Kafkaトピックに直接メッセージを送信することができます。フローがmaxAllowedMessageSizeを超えるメッセージを送信しようとすると、フロー内でCordaRuntimeExceptionがスローされます。

フローの結果

ClientStartableFlow API によって返されたフローの結果は、フローのステータス更新の一部としてメッセージバスに直接送信されます。結果が maxAllowedMessageSize を超えないように、検証が実装されています。この検証に失敗すると、フローは失敗とマークされます。

修正された問題

• Kafka 接続の中断に対する回復力が向上しました。
• コンシューマーグループのリバランシング中のエラー処理が改善されました。CommitFailedExceptionエラーは、ワーカーを再起動せずに回復できるようになりました。
• ProducerFencedExceptionによりフェンスされたプロデューサーの回復方法が改善されました。
• 不健全な状態のワーカーが、ワーカーの/isHealthyRESTエンドポイントを介して健全であると報告する可能性がある問題が解決されました。
• フローワーカーのトピックパーティションが、フローのサブセットに対する一時的なエラーの再試行によってブロックされることがある問題を解決しました。

Corda 5.2.1

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

アップグレード推奨

Corda 5.2.1パッチ・リリースにはバグ修正が含まれており、単一のクラスタ・ネットワーク上でディザスタリカバリの操作を実行する機能が導入されています。これをサポートするために、データベーススキーマとKafkaトピック設定がアップデートされました。そのため、Corda5.2.1への移行は、Helmチャートのupgradeコマンドでワーカーのソフトウェアバージョンを更新するだけではなく、独自のアップグレード手順があります。

また、Corda5.1 からCorda5.2.1 に直接アップグレードすることはできません。Corda5.1のユーザーはまずCorda5.2のアップグレード手順を使ってCorda5.2にアップグレードし、その後Corda5.2.1のアップグレード手順を使ってCorda5.2.1にアップグレードする必要があります。Cordaクラスタのアップグレードについては、以下のページを参照してください：

• 5.1から5.2へのアップグレード
• 5.2から5.2.1へのアップグレード

機能強化

このセクションでは、Corda5.2.1で強化された機能について説明します。

新しいCorda CLIupgradeコマンド

Corda CLIツールに新しいupgradeコマンドが追加されました。このコマンドを使用して、Corda5.2からCorda5.2.1へのプラットフォーム・アップグレード・プロセスの一部としてデータを移行することができます。

Corda CLIのupgradeコマンドの詳細については、アップグレードのページを参照してください。

修正された問題

このセクションでは、Corda5.2.1で解決された問題について説明します。

• Kafka上の管理データが失われたり、同期が取れなくなった場合、データベースから自動的に復元されますが、このプロセスが正しく動作しない問題が修正されました。
• REST workerとState Manager間の統合が修正され、異なるstate typeが同じスキーマ内に保存されないように設定できるようになりました。その結果、アップグレード後に以前の flow status レコードにアクセスできなくなる可能性があります。

既知の問題と制限事項

このセクションでは、Corda5.2.1 に引き続き存在する既知の問題について説明します。

• 設定を変更すると、database workerの内部でリコンシリエーション（データベースとKafkaのデータの不一致を調整するプロセス）が中断される可能性があります。podは理論上、いくつかのエラー条件下で再起動することができ、再起動後はCordaは正常に動作し続けます。

Corda 5.2

このページではCorda 5.2リリースの主な変更点を紹介します：

• 機能強化
• 修正された問題
• 既知の問題と制限

Cordaクラスタを5.1から5.2にアップグレードする方法については、5.1からのアップグレードを参照してください。

機能強化

このセクションでは5.2で強化された機能について説明します。強化された点は以下の通りです：

• パフォーマンス
• デプロイメント
• アプリケーション・ネットワーク
• REST API
• レッジャー
• コンフィギュレーション
• セキュリティ
• CorDapp開発

パフォーマンス

低レイテンシーを維持しながら、TPS（transactions per second：1秒あたりのトランザクション数）が向上している。

デプロイメント

データベース設定

全てのデータベース接続の詳細を一度設定し、デプロイ時にidで参照する必要があります。どのステートタイプにどのデータベースを使用するかを指定したり、より細かいアクセス制御を設定したりできるようになりました。

詳細については、デプロイメントセクションのPostgreSQLセクションを参照してください。

データベースの持ち込み

クラスタ管理者が、Cordaによって管理されるデータベースを使用するのではなく、仮想ノード用のPostgreSQLデータベースの作成とその後の更新を管理できるように、bring-your-own-database (BYOD)機能が導入されました。

詳細はBringing Your Own Databaseを参照してください。

データベース検索パス

データベースURLでsearch_pathパラメータを指定できなくなりました。手動でユーザーを作成する場合は、スキーマのsearch_pathを指定する必要があります。詳細については、手動によるデータベースのブートストラップとBringing Your Own Databaseを参照してください。

Istio との統合

Cordaワーカー間の通信をセキュアにするために、Istioサービスメッシュと統合できるようになりました。

デプロイの設定の詳細については、Istio Integrationを参照してください。

アプリケーションネットワーク

MGMエンドポイントの変更とMGMの再登録

MGM のメンバーが提供するコンテキスト（例えば、プラットフォームのアップグレード後、MGM のエンドポイント情報の変更後、または MGM による以前の登録の試みが失敗した場合など）を更新するために、MGM を再登録することが可能になりました。

詳細については、MGM の再登録を参照してください。

REST API

フローステータス

GET flow/{holdingIdentityShortHash}エンドポイントが更新され、オプションのパラメータとしてフローステータスを受け取れるようになりました。これにより、返されるフローを特定のステータスのものに絞り込むことができます。

詳細については、REST APIリファレンスを参照してください。

RBAC ユーザーのパスワード

RBACユーザーのパスワードを変更できるようになりました。以下の新しいエンドポイントが追加されました：

• /api/v5_2/user/{loginName}/selfpassword;
• /api/v5_2/user/{loginName}/otheruserpassword. 詳細については、REST APIリファレンスを参照してください。

レッジャー

トランザクション・プライバシーの強化

ネットワーク内のすべての仮想ノードが、UTXOレッジャー上のトランザクションの発行に遡り、入力によってリンクされたすべての前任者を確認し、検証する必要がなくなり、トランザクションのプライバシーを高めるネットワーク運用が可能になりました。その代わり、取引内容の可視性は公証人に提供されなければなりません。

詳細については、取引プライバシーの強化を参照してください。

レッジャーリペア

何らかの予期せぬエラーにより、公証人がトランザクションを公証したにもかかわらず、トランザクションの最終処理に関与したメンバーが公証されたトランザクションを保存していないというシナリオを解決するために、レッジャーリペア機能が導入されました。このようなシナリオでは、メンバーが消費済みステートを繰り返し使用しようとし、そのフローが公証の失敗で常に失敗する可能性があります。

レッジャーリペア機能は、公証された可能性のあるトランザクションがないか各メンバーのデータ保管庫をチェックし、そのようなトランザクションがあれば公証人に送信して、以前に見られたかどうかをチェックし、トランザクションが公証されていればメンバーのデータ保管庫を更新する。デフォルトでは、Cordaは10分ごとに元帳修復プロセスを実行する。このスケジュールされたチェックは、クラスター内のすべての仮想ノードに対して実行されます。また、新しい com.r3.corda.notary.plugin.common.repair.NotarizedTransactionRepairFlow を使用して、特定の仮想ノードに対して手動でチェックを実行することもできます。

詳細はLedger Repairをご参照ください。

コンフィギュレーション

P2Pセッションのハートビートメッセージ

coda.p2p.linkManager設定セクションに、セッション・ハートビート・メッセージを有効にするかどうかを指定する新しい設定heartbeatEnabledが追加されました。ハートビートを無効にすると、クラスタのメッセージオーバーヘッドを減らすことができます。特に、異なるクラスタに存在する他の多くの仮想ノードと通信する多くの仮想ノードをホストするクラスタでは、ハートビートを無効にすると、クラスタのメッセージオーバーヘッドを減らすことができます。しかし、リンクマネージャプロセスが利用できなくなった場合のフェイルオーバーが遅くなる可能性もあります。そのため、ハートビートはデフォルトで有効になっています。

詳細については、coda.p2p.linkManagerを参照してください。

メディエータ設定

coda.messagingの設定セクションに、マルチソースメディエータの設定が追加されました：

• subscription.mediator.pollTimeout
• subscription.mediator.poolSize
• subscription.mediator.minPoolRecordCount

Mediatorはフローを処理するためのサブスクリプションです。

詳細については、corda.messagingを参照してください。

RBACパスワード

新しいパスワードの最大文字数を指定するための新しい設定lengthLimitがcoda.rbac設定セクションに追加されました。

詳細については、coda.rbacを参照してください。

セキュリティ

ラッピングキーのローテーション

以下の種類のラッピングキー（他のキーを静止時に暗号化するために使用されるキー）をローテーションできるようになりました：

• マスター
• 仮想ノード

以下の新しいREST APIメソッドが追加されました：

• api/v5_2/wrappingkey/rotation/{tenantid}のPOSTメソッド
• api/v5_2/wrappingkey/rotation/{tenantid}のGETメソッド

詳細については、ラッピングキーの管理 を参照してください。

CorDappの開発

CordaランタイムGradleプラグイン

ランタイムGradleプラグインを含むCorDappテンプレート（以前はCSDEとして知られていた）は、Corda 5.2と互換性があります。

詳細はCorDappテンプレートを参照してください。

コントラクト・テスト

Contract TestingフレームワークがCorda 5.2に対応しました。

詳細はツールセクションのContract Testing Frameworkを参照してください。

フローセッション固有のタイムアウト

クライアントは、フローメッセージAPIでフローセッション固有のタイムアウトを指定できるようになりました。クライアントがタイムアウト値を提供しない場合、Cordaは以前のリリースと同様にcorda.flow設定セクションの値を使用します。

ウェブソケット

フロー・ステータスの更新を取得するためのウェブ・ソケット・インターフェイスは利用できなくなりました。

ボールト名クエリによる順序付け

ORDER BY句を持つ保管庫名付きクエリを登録できるようになりました。この句では、データベース列と状態の JSON 表現を使用できます。

データ保管庫名付きクエリの NULL パラメータ

データ保管庫名付きクエリで NULL パラメータを指定できるようになりました。

送受信トランザクション・フロー

以下のメソッドが UtxoLedgerService に追加されました：

• sendTransaction - UtxoSignedTransaction トランザクションを取引相手に送信します。
• receiveTransaction - カウンターパーティーのセッションから検証済みトランザクションを受信し、それを保管庫に永続化します。

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

永続化 API の冪等性

persist() API は、失敗シナリオにおけるリクエストの冪等性を有効にするために、（フローのコンテキスト内で）一意な決定論的重複排除 ID を要求するようになった。IDは関数呼び出し時に決定論的でなければならず、128文字を超えてはならない。

トークン選択APIの冪等性

tryClaim() APIは、失敗シナリオでリクエストの冪等性を有効にするために、一意な（フローのコンテキスト内で）決定論的重複排除IDを要求するようになった。IDは関数呼び出し時に決定論的でなければならず、128文字を超えてはならない。

修正された問題

このセクションでは、5.2で解決された問題について説明します。これらの問題は、以下の領域で発生しました：

• デプロイメント

デプロイメント

トークン選択シャーディングとIngress

トークン選択ワーカーでシャーディングを有効にすると、REST および P2P Gateway ワーカーで有効になっている Ingress に干渉する可能性がありました。その結果、Ingressリソースのステータスが繰り返し更新され、REST APIやP2P Gatewayへの接続が失われました。

既知の問題と制限

Vaultで暗号データベースのパスワードが変更される（Corda Enterpriseのみ）

暗号データベースのクラスタレベルのパスワードが変更されても、Vaultから再読み込みされない。

ノータリの選択

公証人仮想ノード選択ロジック（NotaryVirtualNodeSelectorServiceImpl）には、保留中および一時停止中のメンバーが含まれます。

フローサービスの例外

ラムダ式が使用されると、フロー・サービスが例外をスローする場合があります。この問題は、ASMライブラリのバグが原因です。