🗒️Corda 4.6 リリースノート

Cordaの新しいバージョンである4.6（Open Source版）がリリースされました。

リリースノートの翻訳文を掲載いたします。

2020/10/09全訳版公開しました！

リリースノート序文

Corda 4.6 リリースノートへようこそ。

このリリースでは、新機能と既存の主要機能および運用上の改善がされました。また、主要領域の

問題も併せて修正されています。

ビジネスネットワークメンバーシップの改善

Corda 4.6 では、ビジネスネットワークの参加者をシステム内で表現する機能（Business Network Membership）が追加されました。以下の動画では、Corda の新しいコアコンセプトであるMembership（メンバーシップ）について説明し、このコンセプトをCorda機能として実現するための方法を紹介しています。

Databaseスキーマ管理方法の統一

Corda Open Sourceと Corda Enterprise でのDatabseスキーマ管理の方法を統一しました。

すべてのスキーマ管理オプションを設定ファイル(node.conf)から起動オプションに移動しました(設定ミスを減らし、オプションの変更がより簡単になるようにするためです)。
Node起動の際に、Databaseスキーマを作成/アップグレードする機能を削除しました。代わりにスキーマ作成/移行用の起動オプションを導入し、Nodeのインストール/アップグレード作業の一部として実行するようにしました。
Corda と Corda Enterprise の間でDatabaseの設定方法、セットアップ方法、そして動作方法を統一しました。
4.0以前のバージョンのCordaからの更新時の自動スキーマ移行を削除しました。
CorDapps用のLiquibaseスキーママイグレーション/記述スクリプトを導入することで、Corda Open SourceでカスタムCorDappスキーマをLiquibaseマイグレーションにパッケージ化できるようになりました。

Flow管理の機能と改善

Corda 4.6 では、Flowの重複開始を防ぐために一意の ID を使用する機能が提供されています。これは、Flowを開始する際に、RPCクライアントが一意の識別子を引数として渡すことで実現します。

この改善により、以下のことが可能になります。

Corda NodeへのRPC接続が切断された場合などにFlowが正しく開始されたことを確認できます。
IDが重複したFlowの開始を防止する - 同じ識別子でFlowを2回開始しようとしても、1回だけ実行します。
実行中のFlowの進行状況トラッカーを再取得できます。
完了したFlowの結果を再取得できます。

概要は以下の動画にまとめられています。

※Corda Enterpriseにはこの機能に加えて、Flowデータをクエリする機能やFlowを一時停止および

再試行する機能が実装されています。

以下の動画で、RPC を介したFlowクエリ、Flowの一時停止、Flowの再試行の概要を説明しています。

※Corda Enterpriseにはこの機能に加えて、Flowデータをクエリする機能やFlowを一時停止および

再試行する機能が実装されています。

以下の動画で、RPC を使用したFlowの問い合わせ、Flowの一時停止、Flowの再試行について解説しています。

開発に関する機能改善

開発者にとって使いやすいプラットフォームとしての Corda の地位を維持するために、開発者の体験を全体的に改善することに焦点を当てています。このリリースでは、開発者がより安定したアプリケーション構築をするのに役立つように、いくつかの改善が行われています。

復帰不能なCheckPointが自動検出されるようになりました。開発中、FlowはCheckPointに到達するたびに自動的にシリアル化され、その後デシリアライズされるようになりました。これにより、デシリアライズできないCheckPointを作成するFlowコードを自動的に検出できるようになりました。
CordappのCheckPoint作成時に使用できるカスタムシリアライザを登録できるようになりました。FlowフレームワークのCheckPointの一部として型をシリアライズする際に、カスタムシリアライザを使用できるようになりました。ほとんどのクラスではカスタムシリアライザは必要ありません。この機能は、CheckPointでのシリアライズ中に例外を投げるクラスに対応するために存在します。新しい CheckpointCustomSerializer インターフェイスを実装して、カスタムチェックポイントシリアライザーを作成できます。

運用の改善

Corda 4.6では、Flow State Machineをより安定させるために一連の改良が導入されています。
新しいFlowSessionのクローズAPIは、FlowSessionを確実に終了させてリソースを解放するサポートを追加しました。

他にも多数の機能が実装されました。このリリースノート全体をご一読いただき、このリリースの新機能や拡張機能がどのようにご活用いただけるかをご理解いただければと思います。

新機能と機能強化

ビジネスネットワークメンバーシップの改善

ビジネスネットワークを作成・管理するためのビジネスネットワークメンバーシップ拡張機能を使用すると、あなた（Node オペレータ）は、共通のCorDappsと共有のビジネスコンテキストのセットに基づいて論理的なネットワークを定義・作成することができます。ビジネスネットワークの外部にいるCorda Nodeからは、そのビジネスネットワークのメンバーを認識できなくなります。

この拡張機能を使用すると、一連のワークフローを使用して、ネットワークへのメンバーの追加、

メンバーの削除、およびパーミッションの管理を行うことができます。

Databseスキーマ管理方法の統一

Corda Open Sourceと Corda Enterprise でDatabaseスキーマ管理を行う方法を統一しました。

Nodeの設定ファイル(node.conf)に記載する方法から起動オプションで指定する方法に変更しました。 (設定ミスを減らし、オプションの変更がより簡単になるようにするためです)。
Node起動の際に、Databaseスキーマを作成/アップグレードする機能を削除しました。代わりにスキーマ作成/移行用の起動オプションを導入し、Nodeのインストール/アップグレード作業の一部として実行するようにしました。
Corda と Corda Enterprise の間でDatabaseの設定方法、セットアップ方法、そして動作方法を統一しました。
4.0以前のバージョンのCordaからの更新時の自動スキーマ移行を削除しました。
CorDapps用のLiquibaseスキーママイグレーション/記述スクリプトを導入することで、Corda Open SourceでカスタムCorDappスキーマをLiquibaseマイグレーションにパッケージ化できるようになりました。

スキーマの移行/作成が通常のNode実行モードから切り離され、別の起動オプションを使用する必要があります。4.6以前の設定ファイル(node.conf)にあったスキーマの移行に関連するすべてのオプションは使用不可になったため、Corda 4.6 で使用するとエラーが発生になります。

さらなる重要な変更点は以下の通りです。

CorDappsのためのスキーマ管理

Corda 4.6 は、Corda Enterprise と同様に Liquibase を介した CorDappsスキーマの移行をサポート

しています。

各 CorDapps は、必要なスキーマを作成/移行するために Liquibase スクリプトを使って移行リソースを提供する必要があります。
移行スクリプトを持たない古い Corda オープンソースの CorDapps は、Corda Enterprise の Enterprise migration ドキュメントで説明されているのと同じ方法で移行する必要があります。
NodeはHibernateを使って、H2をdevモードで使用してアプリスキーマを自動的に管理することができます。これを有効にするためには、起動オプションとして、--allow-hibernate-to-manage-app-schema を設定する必要があります。

スキーマの作成

Corda 4.6 では、Corda Nodeは通常の実行モードではスキーマを動作中に変更/作成できなくなりました。代わりに、run-migration-scripts という新しい起動オプションを使って、スキーマの設定や変更をあらかじめ適用する必要があります。この起動オプションはスキーマを作成/変更して終了します。

コア・スキーマとアプリ・スキーマへの分割

Corda Nodeは、Node自体が動作するために必要なコア・スキーマのセットを持っています。さらに、CorDappsは、カスタムStateをVaultに保存するために、追加のマップされたスキーマを定義することができます。

Corda 4.6までは、Node/スキーマの移行は両方の組み合わせを使用し、ハードコードされたリストとヒューリスティックを使用して、必要なスキーマの作成/移行をすべて実行して、どちらがどちらであるかを判断していました（例えば、コア・スキーマとアプリ・スキーマでは、CheckPointがデータベースに存在している間に実行できるかどうかの要件が異なるため）。

Corda 4.6の変更によって、run-migration-scripts起動オプションは、--core-schemasと--app-schemasの2つの新しいパラメータを取ります。これらのパラメータのうち少なくとも1つが存在していなければならず、それぞれの要求されたスキーマセットに対してマイグレーションスクリプトを実行します。

CheckPoint(CordaのFlowが他のノードとの間で未完了のFlowを保持している場合など、FlowCheckPointをノードが保持している状態)が存在している場合、コア・スキーマの移行はできません。アプリ・スキーマに関してはCheckPointが存在していても、--update-app-schema-with-checkpoints フラグを使用して強制的に移行させることが可能です。

テスト

自動化されたテスト（MockNetwork、NodeBasedTest、Node Driver テストのように）は、必要な

スキーマを自動的に設定することができます。

MockNetworkを使ったテストの場合、MockNode はAbstractNode のフィールドをオーバーライドして、その場でスキーマのマイグレーションを実行できるようにします（コマンドラインからは利用できません）。Liquibase を実行するかどうか、Hibernate を使ってアプリのスキーマを作成するかどうかを制御するために、余分なコンストラクタのパラメータを取ります。既存のテストとの互換性を保つために、どちらもデフォルトでは true になっています。
Node Driverを使ったテストの場合、インプロセスNodeはMockNode と同様のメカニズムを使用します。永続データベースを使用するアウトオブプロセスNodeは、起動前にデータベースをセットアップする必要があります（実際のNodeと同様）。そのため、この場合、DriverDSL はNodeを実行する前にスキーマ移行ステップを実行します。インメモリデータベースを使用するアウトオブプロセスNodeは特に厄介なケースで、Nodeが起動する前にセットアップできる永続データベースがないためです。したがって、Node自体はH2インメモリJDBC URLをチェックすることができ、それが検出された場合は必要なマイグレーションを実行します。
NodeBasedTestを使ったテストの場合は、NodeDriverと同じインプロセスNodeを使用します。

ブートストラップ

Network Bootstrapperは、ブートストラップ・プロセスの一部として、コア・スキーマの移行を実行します。

Cordformationには、以下のようにbuild.gradleのNodeセクションに追加できる追加パラメータがあります。

runSchemaMigration = true

これにより、コードフォームのセットアップの最後のステップとしてスキーマの完全移行が実行され、Nodeの実行準備が完了します。

設定ファイル（node.config）のフィールド変更

以下のフィールドは、設定ファイル(node.conf)のデータベース・セクションから削除されました。これらのフィールドが見つかるとNodeが起動時に例外をスローするため、設定ファイル(node.conf)から削除する必要があります。

transactionIsolationLevel: これはNodeでハードコードされるようになりました。
initialiseSchema: 上記のとおり、スキーマはNode起動時に初期化できなくなりました。
initialiseAppSchema: 上記のとおり、スキーマはNode起動時に初期化できなくなりました。

スキーマ管理ドキュメントをご覧いただきまして、CorDapp のパッケージングプロセスにどのような調整が必要かをご確認いただければと思います。

V4.0 以前の Corda バージョンからのスキーマの移行

Corda 4.6 では、4.0 より古いバージョンの Corda から移行する際に、Databaseの変更履歴を後付けするサポートが削除されました。そのため、Corda 4.6 に移行する前に、前のバージョンの 4.x に移行する必要があります - 例えば、3.3 から 4.5 に移行した後、4.5 から 4.6 に移行する場合などです。

Flow重複開始防止機能と、開始済Flowの状態を取得する機能

CordaのRPCクライアントでは、各Flowを一意のクライアントIDで起動できるようになりました。

この方法でFlowを開始することには、以下のような利点があります。

同じクライアントIDでFlowが複数回呼び出された場合、それらは重複しているとみなされます。最初の呼び出しの後に続くすべての呼び出しは、単に最初の呼び出しの結果を返します。
実行中のFlowは、クライアントIDを使用して再アタッチできます。これにより、そのFlowハンドルを再取得することができます。
完了したFlowの結果は、Flowが完了した後でも、クライアントIDを使用して確認することができます。

また、以下のようなことも可能になります。

既に開始したFlowに対して、確実な再接続ができます。
Flowの結果や例外を実行後いつでも再利用することができます。

詳細については、「クライアントが提供する一意のIDでFlowを開始する方法」を参照してください。

FlowSessionをクローズするための新しいAPI

Corda 4.6 では新しいFlowSessionのクローズ API が導入されています。これにより、FlowSessionを確実に終了させてリソースを解放することができます。

詳細は「API：Flows」をご覧ください。

Notaryリストのホットロード

Notaryリストをホットロードできるようになりました。すなわちnotariesネットワークパラメータを更新しても、Nodeをシャットダウンして再起動する必要はありません。

詳細については、「ネットワークマップ」の「ホットロード」をご覧ください。

DockerformのホストからコンテナへのSSHポートマッピング

Dockerコンテナを作成する際に、ホスト上のSSHポートをコンテナ上の同じポートにマッピングできるようになりました。詳細については、「ローカルにノードを作成する」の「オプション設定」を参照してください。

CorDapp CheckPoint用のカスタムシリアライザの登録機能

CorDappsの開発者は、FlowフレームワークのCheckPointの一部として問題の型をシリアライズする際に使用される、特定の型のカスタムシリアライザを作成することができるようになりました。

これは高度な機能であり、CheckPointのシリアライズ中に例外を投げる特定の型のために特別に設計されていることに注意してください。大多数のクラスでは、カスタムシリアライザは必要ありません。

新しいCheckpointCustomSerializerインターフェースを実装することで、カスタムチェックポイントシリアライザーを作成できます。

詳細については、「CorDapps CheckPoint用のプラグ可能なシリアライザ」を参照してください。

復帰不能なCheckPointを自動検出

CheckPointに到達すると、Flowは自動的にシリアル化された後、デシリアライズされるようになりました。これにより、デシリアライズできないCheckPointを作成するFlowコードを効率よく検出できるようになりました。これは、開発者やネットワークオペレータがCorDappsを開発する際に、復帰不能なCheckPointを検出できるようになるため、適切に再試行できないFlowを書くリスクを減らすことができます。

この機能は、開発者が共通で直面する以下のような問題に対応しています。

Kryo（Cordaが使用しているCheckPointシリアライズライブラリ）で正しくシリアライズ/デシリアライズできないオブジェクトを作成したり、データ構造を活用したりすること。
べき等性がない、または動作を重複排除しないFlow（外部システムへの呼び出しなど）を書くこと。

この機能は、エラーが発生しなくても、CheckPointからFlowをリロードする方法を提供します。その結果、開発者は、Flow全体に復帰可能なエラーを注入する方法を必要とせずに、Flowが正しく動作することをより確信できるようになります。

この機能は本番環境では使用すべきではありません。設定ファイル(node.conf)ではデフォルトで無効になっています。

reloadCheckpointAfterSuspend = false

詳しくは、「修復不可能なCheckPointの自動検出」を参照してください。

その他の変更点・改善

Corda 4.6では、FlowStateMachineをより強固なものにするための改良を導入しました。
Corda 4.6 以降、DemoBench のサポートは廃止されました。
Accounts SDK の新しいマイナーバージョンであるバージョン 1.0.2 をリリースしました。このバージョンには、Corda 4.6との互換性を高めるデータベースの改良が含まれています。Corda 4.6 で Accounts SDK を使用する場合は、Accounts SDK V 1.0.2 を使用する必要があります。
Tokens SDK の新しいマイナーバージョン - バージョン 1.2.1 をリリースしました。このバージョンには、Corda 4.6との互換性を高めるためのデータベースの改良が含まれています。Corda 4.6でTokens SDKを使用する場合は、Tokens SDK V 1.2.1を使用する必要があります。
ドライバDSLを使用して新しいドライバを起動する場合、Notary Nodeは、startNodesInProcessドライバプロパティに関係なく、ドライバを実行するのと同じJVMプロセス内のスレッドとしてデフォルトで起動します(startNodesInProcessがfalseの場合は新しいプロセスとして起動しません)。この設定はオーバーライドすることができます。テストがNotaryと対話し、Notaryが新しいプロセスとして実行されることを期待する場合、startInProcessをfalseに設定しなければならないことに注意してください。
Corda 4.6 では、CorDapp の minimumPlatformVersion がNodeのプラットフォームバージョンよりも高い場合、CorDapp はロードされず、Nodeは起動に失敗します。これは、Corda 4.5 の場合、このような条件ではNodeが起動し、CorDapp をロードできなかったことがログに記録されていましたが、Corda 4.5 の場合と比べて動作が変更されました。

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

Corda 4.6 のプラットフォームバージョンが 7 から 8 に更新されました。

プラットフォームのバージョンの詳細については、バージョン管理をご覧ください。

アップグレードに関する重要な注意事項

Corda 4.6 で行ったデータベーススキーマの統一に関する運用上の改善は、以前のバージョンから Corda 4.6 にアップグレードする際に、いくつかの手順を必要とします。これらの変更点に

ついての詳細は、以下のページをご覧ください。

アップグレードパスごとに必要な手順の簡単なチェックリストを以下に示します。

既存のノードを Corda 4.5 (またはそれ以前の 4.x バージョン) からバージョン 4.6 にアップグレードする

設定ファイル(node.conf)のデータベースセクションから、transactionIsolationLevel、initialiseSchema、またはinitialiseAppSchemaのエントリを削除します。
run-migration-scripts モードでNodeを実行して、不足しているコア・スキーマの変更を更新します。
CorDapps に Liquibase リソースを追加します。Corda 4.6 では、カスタムスキーマを導入する CorDapps には、スキーマを前もって作成できる Liquibase のマイグレーションスクリプトが必要です。リソースにマイグレーションスクリプトがない既存のCorDappsに対しては、外部の移行用 .jar ファイルとして追加することができます。
既存のスキーマの変更ログを更新します。Corda .jar ファイルをアップグレードし、CorDapp に Liquibase スクリプトを追加した後、アプリからのカスタムスキーマはデータベースに存在しますが、Liquibase changelog テーブルの changelog エントリが欠落しています (changeLogエントリはLiquibaseによって自動生成されるものの為)。このため、Nodeを起動するときに問題が発生します。また、すでに存在するテーブルを再作成できないため、run-migration-scripts を実行するときにも問題が発生します。新しい起動オプションsync-app-schemas を実行することで、CorDappsの既存のマップされたスキーマの changelog エントリが作成されます。実行例：java -jar corda.jar sync-app-schemas重要：起動オプションsync-app-schemasを実行する前に、新しい CorDappsやスキーマエンティティを追加したバージョンをインストールしないでください。CorDappsで見つかったマップされたスキーマは、一致するDatabaseエンティティを作成しようとせずに変更ログに追加されます。重要：スキーマがマップされた CorDappsがインストールされている間にNodeを Corda 4.6 にアップグレードする場合、Nodeを再起動したり、アプリのスキーマの更新を実行したりする前に、スキーマを同期させなければなりません。したがって、Nodeをアップグレードしている間、またはアップグレード後であってもアプリスキーマを同期する前に、新しいスキーマまたは変更されたスキーマを持つ CorDappsをインストールしたり、更新したりしてはいけません。

Corda 3.x または Corda Enterprise 3.x からバージョン 4.6 にアップグレードする

初期ノード登録コマンドを実行する際の注意点

Corda 4.6では、Databaseの移行はデフォルトで初期Node登録時に実行されます。

これを防ぐには、--initial-registration コマンドと一緒に --skip-schema-creation フラグを使用してください。

初期登録コマンドについては、「ノードのコマンドラインオプション」と「互換ゾーンへの参加」で説明しています。

問題の修正

Flowドレインモードが有効な場合に、RPC startFlowが既存のクライアントIDFlowに再アタッチできない問題を修正しました。
CorDappクラスが使用されている場合に、クラスローダがクラスを見つけられない問題を修正しました。
FlowSessionCloseTest.flowが、適切に処理された重複したクローズでない限り、クローズしたセッションにアクセスできなかった問題を修正しました。
再起動時にsenderUUIDが設定されていないためにRetryFlowMockTestが失敗し、早期終了セッションメッセージが受信Flowをハングアップさせない問題を修正しました。
ExceptionsErrorCodeFunctionsTestがタイムアウトにより失敗する問題を修正しました。
Liquibaseスキーマを使用しないカスタムCorDappsで実行されたログで、期待されていたerror_code="5"エラーが発生していた問題を修正しました。
KillされたクライアントIDFlowと他のステータスを持つFlowとの間で一貫性のない動作をする問題が修正されました。
ネットワーク・パラメータのパスが設定可能になり、ネットワーク・パラメータ・ファイルがNode構成で指定した場所に保存されるようになりました。
証明書でロギングが検出されていたが、問題が印刷されていなかった問題を修正しました。
Flowフレイキーテストを受信したときにセッション終了メッセージがハングしない問題を修正しました。
Flow名の代わりに、MembershipAuthorisationException メッセージに StateAndRef< MembershipState> が含まれていた問題が修正されました。
ModifyGroupFlow の説明で必須の Notaryパラメータが欠落していた問題を修正しました。
互換性のないデータベーススキーマエラーのためにNodeの起動に失敗するCorDapps Demoの問題を修正しました。
ClassGraph() フィルタ関数に渡されたクラスパス要素からオプションの file:prefix が取り除かれ、フィルタ関数が要素を認識しなくなる問題を修正しました。
StateMachineManager.startデータベーストランザクションがまだ開始されていない場合にFlowの実行が開始される問題を修正しました。
バージョンアップしたでR3 Toolsが正常に動作しない問題を解決するために、Jackson 2.9.7に戻しました。
Paths.get("") が現在の作業ディレクトリの代わりに null を返す問題を修正しました。

Created by: Kazuto Tateyama

Last edited by: Kazuto Tateyama

Updated: 2020/10/09

・・・・・・・・・・・・・・・・・・・・・・・・・・

Twitter： SBI R3 Japan(@r3sbi)

HP： https://sbir3japan.co.jp/