Corda Enterprise release notes
Corda Enterprise 4.5.1
Corda Enterprise 4.5.1 is a patch release of Corda Enterprise that introduces fixes to known issues in Corda Enterprise 4.5.
As a node operator, you should upgrade to the latest released version of Corda if the fixed issues listed below are relevant to your work.
- Fixed an issue where the Classloader failed to find a Command class when Optional generic was used on Type definition.
- The Configuraton Obfuscator tool has been fixed to work for HSM configuration files.
- Fixed an issue where retrying session inits could fail due to database connectivity.
- The H2 version has been reverted to 1.4.197 to avoid a dependency issue introduced after the previous upgrade.
- The CPU usage of the
NodeMeteringBackgroundprocess has been decreased.
- A security update to prevent AMQP header spoofing has been applied.
- Fixed an issue where passing two sessions with the same counterparty to the
CollectSignaturesFlowled to both counterparties’ flows having to wait infinitely for messages from the other party.
- A previously unhandled exception in
FlowStateMachineImpl.run().initialiseFlow()is now handled correctly.
- Fixed an issue where Corda Firewall did not start if its main configuration and its HSM configuration were obfuscated.
- Fixed an issue where a TLS handshake timeout led to blacklisting endpoint.
- Added support to the spent state audit command for specifying state references in the form
txId(outputIdx)in addition to the existing
Corda Enterprise 4.5 release overview
This release extends the Corda Enterprise 4.4 release with further performance, resilience, and operational improvements.
Corda Enterprise 4.5 supports Linux for production deployments, with Windows and macOS support for development and demonstration purposes only. See the Corda Enterprise platform support matrix for more information.
Corda Enterprise 4.5 is operationally compatible with Corda (open source) 4.x and 3.x, and Corda Enterprise 4.4, 4.3, 4.2, 4.1, 4.0, and 3.x. See the Corda (open source) release notes for more information.
New features and enhancements
As part of Corda Enterprise 4.5 we have introduced significant performance enhancements. Our main focus was to improve latency across multiple areas of the platform.
We have reduced the latency of
CollectSignaturesFlow. This was achieved by parallelising various areas of the platform, such as backchain resolution, collection of signatures, and broadcast of finalised transaction to peers. Note that no CorDapp changes are required to benefit from these changes.
We have introduced
new flow framework APIs (
sendAllMap), which can be used to send messages to multiple counterparties with improved performance. Previously, a flow was able to send messages to multiple counterparties by using the
send API once for each counterparty. These new APIs can now be used to achieve the same with better performance, which comes from a smaller number of suspensions and checkpoints.
We have introduced compression of messages exchanged between nodes during flows which can improve performance in terms of both latency and throughput. The performance improvement gained depends upon environmental factors, such as network configuration or hardware specification. This option is enabled by default but can be disabled if desired via the
node configuration option.
Corda Enterprise images on DockerHub
Official Corda Enterprise Docker images are now available directly on DockerHub.
Furthermore, we have updated our
local development task to make use of the new Docker images and to default to using PostgreSQL as the chosen node database.
Further Hardware Security Module (HSM) support
Corda Enterprise 4.5 introduces the ability to use AWS CloudHSM to secure the cryptographic keys used by a node. Legal identity, TLS Firewall and Confidential Identity keys can now all be stored in an AWS HSM.
See the platform support matrix documentation section for more information.
Collaborative Recovery CorDapps for disaster recovery
Corda Enterprise 4.5 introduces a new suite of utility CorDapps that can help you safely, and privately reconcile and recover ledger data lost in a disaster scenario.
LedgerSync CorDapp can be used to routinely check the ledger for data inconsistencies between nodes, without compromising security. In the rare event that an inconsistency is discovered, the CorDapp
LedgerRecover can be deployed in either Automatic recovery or Manual recovery mode (for more serious data loss) to securely recover the missing data from nodes across the network.
See the Collaborative Recovery documentation section for more information.
LedgerSync CorDapp as a stand alone tool
LedgerSync CorDapp is part of the Collaborative Recovery CorDapps, however it can be run as a standalone tool as well.
It safely and privately highlights the differences between the common ledger data held by two nodes in the same Business Network. A peer running the CorDapp can be alerted to missing transactions. This procedure is called Reconciliation.
The CorDapp is designed to diagnose ledger inconsistencies caused by either of the following two events:
- A disaster affecting a node’s relational datastore.
- More rarely, a hardware or connectivity fault.
LedgerSync can be run either on demand or on a regular basis. The app contacts all peers of the initiating node that are on the same business network, and produces a report detailing all transactions relevant to both the node and the target peers, held in the initiating node’s ledger (transactions are considered relevant to a node if it was involved as either state participant or owner). If
LedgerSync finds that the initiating tool is missing any relevant transaction, it flags the discrepancy to the operator, who can then proceed to recover the missing data.
LedgerSync is designed to be compliant with the Corda privacy model. It does not share any transaction information with network peers that shouldn’t already have access to it.
documentation section for more information.
HA Notary readback queue
Each Notary worker now has a readback queue. This queue collects recently-spent states, then double-checks that they have correctly been recorded as spent in the Notary database. If this mechanism detects an inconsistency, an error is recorded in the worker’s log file, and a JMX metric for unpersisted DB records is updated.
See the database monitoring agent documentation section for more information.
Notary double-spend tool
A double-spend occurs when a state that the notary has marked as spent is used as input to a new transaction. Notaries will reject transactions that attempt double-spends.
Corda Enterprise 4.5 introduces the
Spent State Audit Tool - a new command-line tool that enables notary operators to obtain a list of transactions that attempted to double-spend a state. The information provided by the tool can be used to undertake root cause analysis on a double-spend attempt that has occurred on the network.
Please consult the
Spent State Audit Tool
documentation section for more information.
The Metering Collector CorDapps have been extended to request a summary of Corda Enterprise usage from one or more other participants on the network via the flow framework. This feature is designed to support Business Network Operators (BNOs) and comes with strong built-in privacy controls to ensure that each user has to opt in to sharing their information.
Corda Enterprise nodes now maintain an audit trail of RPC usage. Whenever a user attempts to perform an RPC call, the information will be recorded by the node in an off-ledger database table. The information can be downloaded locally in CSV or JSON format by an authorised user via a dedicated RPC operation.
See the RPC Audit Collection Tool documentation section for more information.
Our documentation on monitoring has been revamped and now includes improved guidance for node operators.
Furthermore, Corda Enterprise nodes expose additional metrics. The list of all metrics exposed by the node is available here.
We have also provided a list of common node monitoring scenarios.
Corda Enterprise Configuration Obfuscator
We have unified the
configuration obfuscation tools for Corda Enterprise and the Corda Enterprise Network Manager under a single
.jar file. The new tool provides the same level of functionality of its predecessors.
The following libraries have been updated:
Improved Tokens SDK along with new documentation and training
The Tokens SDK has been extended to provide a consistent API for use in both Java and Kotlin.
The documentation has been relocated to the main Corda and Corda Enterprise documentation site, and a comprehensive training module for developers added to the Corda training site. Read the documentation. Explore the training module.
- All database columns containing datestamps have been standardised to use UTC (the time zone used was previously inconsistent).
- The HSM name used in the HA Utilities
--float-hsm-namecommand-line parameters should now exactly match
cryptoServiceName, as described here.
Platform version change
The platform version of Corda Enterprise 4.5 has been bumped up from 6 to 7 due to the addition of the new flow framework APIs
sendAllMap, which can be used to send messages to multiple counterparties with improved performance.
For more information about platform versions, see Versioning.
- Fixed an issue where the implementation of
QueryCriteriaUtilswas the same as
- We have fixed an issue where CorDapp custom serialisers were not supported in
MockNetwork, causing unit tests of flows to fail without using
- We have fixed an issue where serialising a
FlowExternalOperation, which had maintained a reference to a
FlowLogic, could throw an
IndexOutOfBoundsExceptionerror when constructing a
- We have fixed an issue where
ServiceHub.signInitialTransaction()threw undeclared checked exceptions (
- We have standardised all node database timestamps to use the UTC time zone.
- We have fixed issues with the existing checkpoint iterator serialisers related to null handling and the use of
equalswhen restoring the iterator position.
- We have fixed an issue where Corda failed to deserialise Enums with custom
toString()methods into the DJVM sandbox.
- We have fixed an issue where Corda’s internal
core, which is supposed to be private, was both public and mutable.
- We have fixed an issue with failing session init messages when the state machine replayed them from the Artemis queue in order to retry flows that had not yet persisted their first checkpoint, due to problems with database connectivity.
- We have fixed an issue where the
com.r3.corda.enterprise.settlementperftestcordapp.flows.SwapStockForCashFlowTestfailed for Oracle 11 due to failed migration.
- We have fixed an issue where
Level.FATALlogs did not include the original log message after updating them to extract more information from the stack traces.
- We have fixed an issue where a race condition would occur when a flow hung while waiting for the ledger to commit a transaction with hash even when that transaction was present in the database.
- We have fixed an issue where no CRL check was done when using embedded Artemis, which could cause nodes to continue to be involved in transactions after they had been blacklisted.
- We have fixed an issue with inconsistent error messages on starting components if HSM was not available.
- We have fixed an issue where a Vault Query using
LinearStateQueryCriteria(linearId = emptyList())would translate into an illegal SQL statement on PostgreSQL and would throw an exception.
- We have added a custom serialiser (
IteratorSerializer) that can fix broken iterators in order to resolve an issue with a
- We have fixed an issue with failing
VaultObserverExceptionTesttests on Oracle.
- We have fixed an issue where the “Registering as a new participant with a Corda network” message during node registration using the node shell was not centred.
- We have fixed an issue with licensing for the Collaborative Recovery CorDapps.
- We have removed stack trace for
level.WARNlogs while running
- We have fixed an issue where an unhandled exception was thrown when a user attempted to start the
InitiateManualRecoveryFlowflow from the node when the recovery had already been initialised.
- We have fixed an issue where an unhandled exception was thrown when
isRequesterhad a wrong value while running
- We have fixed an issue where Corda Enterprise did not provide information about the flow when a non-started manual
LedgerRecoverwas requested by the node.
- We have ensured that the documentation about
LedgerRecoverclearly explains that
TimeStampsfor recovered transactions are changed compared to the original transactions.
- We have fixed an issue where the
ExportTransactionsFlowflow could get stuck while
- We have fixed an issue where manual
LedgerRecoverdid not work for PostgreSQL 10.
- We have added a primary key to the
NODE_PROPERTIEStable in order to prevent duplicate inserts.
- We have fixed an issue where the Corda Firewall load was stuck when the connection between the Firewall Load Testing tool and Corda Firewall was disrupted.
- We have fixed a production environment issue occurring where notaries became unresponsive after a Java upgrade to Zulu 22.214.171.124.
- We have fixed an issue where the Corda Health Survey tool ignored HTTP 301 and 404 response codes when resolving network information.
- We have fixed an issue where the Corda Health Survey tool did not perform HTTP / HTTPS network map redirections.
- We have fixed an issue with a flaky test where
net.corda.coretests.transactions.AttachmentsClassLoaderTests.attachmentwas still available in verify after forced garbage collection.
- We have moved the
backchainFetchBatchSizeoption, used for bulk backchain resolution, into the correct Corda Enterprise-specific tuning section of the Node configuration (this section contains options that should be changed only in consultation with R3).
- We have fixed an issue where sensitive information was exposed as plain text in logs and the shell terminal when using the Database Management Tool.