Corda Enterprise release notes (Japanese)
Corda Enterprise Edition 4.7のリリース概要

今回のリリースでは、数々の新機能と機能強化が導入されているほか、以前のリリースに存在した既知の問題が解決されます。
これまでのリリースでAPIの後方互換性を約束したのと同様に、Corda 4.7でも同じ保証がされています。
Corda 3.0以上で有効なStateやCordappはCorda 4.7でもお使いいただけます。
Corda Enterprise Edition 4.7における主な新機能と機能強化は以下の通りです:
- アーカイブサービス
- 改善されたノータリーのバックプレッシャーメカニズム
- ノード管理とフロー管理用の新しい管理コンソール
- 証明書ローテーション
- Azure ADへのシングルサインオン
- HSM統合サポート
- HSMに秘密アイデンティティ鍵を保存する機能
- HSM API
このページでは、Corda Enterprise Edition 4.7に特有の機能のみを記載しています。しかし、Corda Enterpriseのお客様は、Cordaオープンソースリリースの一部としてご利用いただける機能をすべて活用できます。
Corda 4.7の一環として提供される以下のような新機能、機能強化、修正については、Cordaオープンソースリリースノートをご覧ください。
- 保証されたステートのリプレイスメントを伴うステートの再発行を行うことで、取引のバックチェーンを断ち切る機能
- ビジネスネットワークメンバーシップバージョン1.1
- 新しいマルチRPCクライアントを通じてCordaノードとやり取りをする機能
- 参照アプリケーション:
新機能と機能強化

アーカイブサービス

アーカイブサービスは、Node運用者がアウトプットStateを伴わないTransactionの台帳データをアーカイブできるようにする新しいツールです。これによってディスクスペースを節約し、Nodeデータベースへの負荷を削減できます。
アーカイブサービスの機能には以下があります:
- Cordaコマンドラインインターフェース(CLI)コマンドを使ったアーカイブサービスの利用これによって、アーカイブが必要なジョブをすばやく確認し、必要なくなったデータをvaultから削除し、vaultの中身のスナップショットをインポート、エクスポート、復元できるようになります。
- アプリケーションエンティティ―マネージャーを使うと、CorDappsが台帳外のデータベースにアクセスできるようになります。
- アーカイブサービスをCollaborative Recovery CorDappsと統合すると、壊滅的なシナリオが発生してもデータの復元がスムーズに実行できます。
詳細についてはアーカイブサービスの説明をご覧ください。
改善されたNotaryのバックプレッシャーメカニズム

Notaryがトラフィックを扱う方法を最適化するために、Notaryのバックプレッシャーメカニズム(バックプレッシャーメカニズムとも呼ばれます)を更新し、Notaryへの署名リクエストが突然増えた場合のNotaryのパフォーマンスを改善しました。この変更によって、Notaryがタイムアウトする可能性に関する予見精度が向上します。
つまり、「トラフィックの重い状態」でも高精度かつクイックに動作可能なバックプレッシャーメカニズムを実現したことになります。これによってNodeのリトライが削減され、パフォーマンスが最適化され、Node運用者にとってより良いエンドユーザーエクスペリエンスを提供できます。
Notaryのバックプレッシャーカニズムとは
設計上、Notaryはトラフィックの負担が極端に大きくても通常通り作動できるようになりました。Notaryのバックプレッシャーメカニズムは、Notaryへの署名リクエストキューを処理し、タイムアウト(大抵はハイトラフィック時)が原因で発生するノードのリトライがNotaryの容量の関数になるよう実現することでこれを可能にしています。このメカニズムによって、必要に応じてそれぞれのNodeが行うノータリゼーションの申請およびリトライにかかる時間や処理能力を確保しています。また、不必要なNodeのリトライによってノータリゼーションの申請キューが不自然に増えることを防ぎ、Notaryの効率性も担保します。
Node管理とフロー管理用の新しい管理コンソール

Corda Enterprise Edition 4.7には2種類の新しい管理コンソールが搭載されています:
- Flow管理コンソールでは、ノードで実行されているflowの状態を確認でき、flowに対していくつかの処理を行えます。詳細については、Flow管理コンソールをご覧ください。
- ノード管理コンソールでは、ノードについての情報を確認でき、いくつかの処理を行えます。詳細については、ノード管理コンソールをご覧ください。
どちらのコンソールも、CENM Gatewayサービスの一部として動作します。
証明書ローテーション

Corda Enterprise Edition 4.7では、ノード鍵(Legal Identity)とその証明書をローテーションする機能を導入しています。これによって、Corda Enterprise Network ManagerのNetwork Map上において、新しい証明書を使ってNode(Notary Nodeを含む)を再登録できるようになります。本機能の詳細については、R3サポートまでお問い合わせください。
その他の変更と改善

- Azure ADを使ったシングルサインオンAzure ADとCorda Authサービスで簡単な設定を行うだけで、CordaサービスとAzure AD間でシングルサインオン(SSO)設定を運用できるようになりました。
- HSM統合サポートCorda Enterpriseでは、サポートされていないHSMとCorda Enterpriseインスタンスのユーザーによる統合をサポートするようになりました。今回のリリースには、例として使えるJava実装のサンプルと、展開前に実装をテストできるテストスイートが含まれています。HSM統合の書き方ガイドについてはHSMに関する項をご覧ください。
- HSMにConfidential Identity鍵を保存する機能Corda Enterpriseは、nCipher、FuturexとAzure Key VaultのHSMにおけるConfidential Identityに関する鍵の保管をサポートするようになりました。nCipherとAzure Key VaultのHSMではConfidential Identity鍵のネイティブでの利用をサポートし、FuturexのHSMではキーラップモードをサポートします。これらのHSMにおけるConfidential Identity鍵保管の設定については、HSMに関する項をご覧ください。
- HSM APICorda Enterprise Edition 4.7では、外部のツール開発者がCorda EnterpriseのHSMサポートを拡張するために使える独自のAPIを有するHSMライブラリーが導入されています。
- ネットワークへの初期登録(
initial-registration
)時に、Nodeはidentity-private-key
のエイリアス作成を行うようになりました。詳細については、Nodeのフォルダ構成の項をご覧ください。これまでは、cordaclientca
とcordaclienttls
のエイリアスだけがinitial-registration
中に作成され、identity-private-key
は初回のNode実行時に必要に応じて生成されていました。そのため、Corda Enterprise Edition 4.7では、nodekeystore.jks
の内容は通常のNode実行中に変更されません(証明書ディレクトリを事前に設定したキー保管で埋められるdevMode = true
を除きます)。 - Notaryの
batchTimeoutMs
設定オプションを調整することでパフォーマンス向上を得られる可能性について解説を追加しました。ただし、デフォルト設定は変更されていません。
プラットフォームバージョン変更

Corda 4.7のプラットフォームバージョンは8から9に引き上げられています。
プラットフォームバージョンの詳細については、バージョニングをご覧ください。
修正された問題

- Accountsを使う際に、Transactionを開始したPartyが受領側のPartyに対して復元を希望する場合にLedgerSyncが差異を出力しないCollaborative Recoveryの問題を修正しました。
- Flowに含まれるメタデータである終了時刻と開始時刻の間で、異なるタイムゾーンを設定できる問題を修正しました。
- ホット/コールドのNodeフェイルオーバーの場合に、カウンターパーティからのメッセージの受領を待っている間に継続的なフローが新しいホットNodeやカウンターパーティのNodeで滞る場合がある問題を修正しました。
- NodeがStateの検索を行う際にいくつかの列挙型をデシリアライズできないためにCorda 4.6 RPCクライアントがCorda 4.7のNodeに対して
NodeFlowStatusRpcOps::getFlowStatus
を実行できない問題を修正しました。 - 入力Stateが10以上あった場合に、
StateRef
は<hash>:a
として正しくエンコードされるものの、想定される整数入力によって間違ってデコードされるJPA Notaryの問題を修正しました。 - Floatが同じBridgeからの2つの接続の試行を同時に処理し、結果としてバインディングの例外が発生する問題を修正しました。
既知の問題

- Nodeの状態のクエリを行う際にいくつかの列挙型をデシリアライズできないために、Corda 4.6 RPCクライアントはCorda 4.7のNodeに対して
NodeFlowStatusRpcOps::getFlowsMatching
を実行できません。 - 場合によっては、RPCクライアントがNodeとの接続に失敗することがあります。このエラーはスペックの低いマシンを使っている場合に発生しやすいです。
- HA UtilitiesツールがLegal IdentitiesやTLS鍵を念頭に実装されているため、
freshIdentitiesConfiguration
についての情報を記録しません。 - HA Utilitiesツールは、
NATIVE
モードを使っている場合、マスター鍵が不要だと記載したメッセージを記録しません。こうしたメッセージは、initial-registration
コマンドを使ってNodeを登録している場合に、Nodeログにのみ記録されます。 NATIVE
モードでのConfidential Identityにはマスター鍵が不要のため鍵は生成されていないにもかかわらず、NATIVE
モードでのHSMのConfidential Identityを使ったNode登録中に、HA Utilitiesツールのログに「Confidential Identityのキーラップを作成しました」という間違ったログエントリーが含まれます。- 入力や参照のないTransactionは、出力Stateについて異なるNotaryを有することがあります。その結果、Transactionを発行しているNodeが、そのNotaryとのTransactionのノータリゼーションを行うことなく、出力Stateに任意のNotaryを設定することがあります。
- Azure Key Vaultのサポートについて、Cordaはまだ、古くなったAzure Java SDKバージョン(1.2.1)に依存しています。これによって、Node運用者が
shadedJar
を自身で構築する必要が生じる場合があります。 - 新しいフロー管理コンソールにおいて、ページのリロード後に、フィルターが適用されていた時と同じ結果を表示せず、列のフィルタリング/ソートが間違ってリセットされることがあります。
- 新しいフロー管理コンソールとNode管理コンソールにおいて、ユーザーの名前が短すぎると「パスワードの変更」/「ログアウト」のドロップダウンメニューがすべて見えない場合があります。
- 新しいフロー管理コンソールにおいて、「フローのクエリ」ページ上のカレンダー内の「フローの開始から/まで」のフィールドは2回クリックしないと開けません。
- Collaborative Recovery1.1(または1.0)のイニシエーターは、Collaborative Recovery1.2のレスポンダーによってアーカイブされたTransactionを復元しようとした場合に失敗することがあります。
- (今回のリリースで導入された)証明書ローテーションを実行するとき、
previousIdentityKeyAliases
のリストにない古い鍵によって署名されたStateを使おうとするとフローにエラーが発生して失敗することがあります。 - Health Check Toolは常に、現在のディレクトリではなくCorda Nodeのディレクトリに報告書を保存しようとします。Corda Nodeのディレクトリへの書き込み権限がないNode運用者にとって問題となる可能性があります。
- Corda HSM Technology Compatibility Kit (TCK)テストのコンソールヘルプとCorda shell CLIのヘルプで、フォーマットが一貫していないところがあります。
samples:attachment-demo:deployNodes
を実行する際、serviceLegalName
ではなくmyLegalName
をノータリゼーションに使うため、runSender
のタスクが添付の送信に失敗します。- カスタムIOU CorDappを移行するために
run-migration-scripts --core-schemas --app-schemas
を実行する際、MS SQLデータベースで動作していると移行スクリプトが失敗します。H2、PostgreSQLとOracleのデータベースに対しては、移行が問題なく動作します。 - 場合によって、カウンターパーティがダウンしている場合やフローが遮断された場合でもNodeがカウンターパーティへの再接続を試み続けることがあります。
Was this page helpful?
Thanks for your feedback!
Chat with us
Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.
Propose documentation improvements directly
Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.
We're sorry this page wasn't helpful. Let us know how we can make it better!
Chat with us
Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.
Create an issue
Create a new GitHub issue in this repository - submit technical feedback, draw attention to a potential documentation bug, or share ideas for improvement and general feedback.
Propose documentation improvements directly
Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.