Corda 5.2 Release Notes

This page lists the key changes in the 5.2 release of Corda and contains the following:

• Enhancements
• Fixed Issues
• Known Issues and Limitations

For information about upgrading a Corda cluster from 5.1 to 5.2, see Upgrading from 5.1.

Enhancements

This section describes the enhancements made in 5.2. These were made in the following areas:

• Performance
• Deployment
• Application Networks
• REST API
• Ledger
• Configuration
• Security
• CorDapp Development

Performance

The number of TPS (transactions per second) has been improved while maintaining low latency.

Deployment

Database Configuration

All database connection details must now be configured once and referenced by id during deployment. It is now possible to specify which database is used for which state type and also configure finer-grained access control.

For more information, see the PostgreSQL section of the Deployment section.

Bring Your Own Database

A bring-your-own-database (BYOD) feature has been introduced to enable Cluster Administrators to manage the creation and any subsequent updates of PostgreSQL databases for virtual nodes, rather than using a database managed by Corda.

For more information, see Bringing Your Own Database.

Database Search Path

Database URLs can no longer specify the search_path parameter. If you manually create users, you must specify their search_path for their schema. For more information, see Manual Database Bootstrapping and Bringing Your Own Database.

Istio Integration

It is now possible to integrate with Istio service mesh to secure communication between Corda workers.

For more information about configuring your deployment, see Istio Integration.

Application Networks

Changing the MGM Endpoint and Re-registering the MGM

It is now possible to re-register an MGM to update the MGM’s member-provided context; for example, after a platform upgrade, after changes to the MGM’s endpoint information, or if a previous attempt by the MGM to register failed.

For more information, see Re-register an MGM.

REST API

Flow Status

The GET flow/{holdingIdentityShortHash} endpoint has been updated to take a flow status as an optional parameter. This enables you to filter the flows returned to those of a particular status.

For more information, see the REST API Reference.

RBAC User Password

It is now possible to change the password of RBAC users. The following new endpoints have been added:

• /api/v5_2/user/{loginName}/selfpassword;
• /api/v5_2/user/{loginName}/otheruserpassword.

For more information, see the REST API Reference.

Ledger

Transaction Privacy Enhancements

It is now possible to operate a network that increases the privacy of transactions by no longer requiring every virtual node in a network to see and verify all predecessors, linked by inputs, back to issuance of a transaction on the UTXO ledger. In exchange, visibility of transaction content must be given to the notary.

For more information, see Transaction Privacy Enhancements.

Ledger Repair

Ledger repair functionality has been introduced to resolve scenarios where, due to some unexpected error, a notary notarizes a transaction but the members involved in finalizing the transaction do not store the notarized transaction. Such a scenario may result in the members repeatedly attempting to spend consumed states and their flows constantly failing with notarization failures.

The ledger repair functionality checks each member’s vault for transactions that might have been notarized, sends any such transactions to the notary to check whether they were previously seen, and updates the member’s vault if the transactions were notarized. By default, Corda runs the ledger repair process every ten minutes. This scheduled check runs for all virtual nodes in the cluster. You can also run a check manually for a particular virtual node using the new com.r3.corda.notary.plugin.common.repair.NotarizedTransactionRepairFlow flow.

For more information, see Ledger Repair.

Configuration

P2P Session Heartbeat Messages

A new setting heartbeatEnabled has been added to the corda.p2p.linkManager configuration section to specify if session heartbeat messages are enabled. Disabling heartbeats can lead to lower message overhead for a cluster, particularly for clusters that host many virtual nodes that communicate with many other virtual nodes residing in different clusters. However, it can also lead to slower failover if link manager processes become unavailable. As a result, heartbeats are enabled by default.

For more information, see corda.p2p.linkManager.

Mediator Configuration

The following new settings have been added to the corda.messaging configuration section for the multi-source mediator:

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

The mediator is the subscription used to process flows.

For more information see corda.messaging.

RBAC Password

A new setting lengthLimit has been added to the corda.rbac configuration section to specify the maximum number of characters of new passwords.

For more information, see corda.rbac.

Security

Wrapping Key Rotation

It is now possible to rotate the following types of wrapping keys A key used to encrypt other keys at rest. :

• master
• virtual node

The following new REST API methods have been added:

• POST method of the /api/v5_2/wrappingkey/rotation/{tenantid}
• GET method of the /api/v5_2/wrappingkey/rotation/{tenantid}

For more information see, Managing Wrapping Keys.

CorDapp Development

Corda Runtime Gradle Plugin

The CorDapp template, including the runtime Gradle plugin, (formerly known as the CSDE) is now compatible with Corda 5.2.

For more information, see CorDapp Template.

Contract Testing

The Contract Testing framework is now available for Corda 5.2.

For more information, see Contract Testing Framework in the Tools section.

Flow Session-Specific Timeout

The client can now specify a flow session-specific timeout on the Flow Message API. If the client does not provide a timeout value, Corda uses the value in the corda.flow configuration section, as in previous releases.

Web Socket

The web socket interface for retrieving flow status updates is no longer available.

Order By Vault-Named Queries

It is now possible to register vault-named queries with an ORDER BY clause. This clause can use the database columns and the JSON representation of the states.

Vault-Named Queries Null Parameters

It is now possible to specify null parameters in vault-named queries.

Send/Receive Transaction Flows

The following methods have been added to UtxoLedgerService:

• sendTransaction — sends a UtxoSignedTransaction transaction to counterparties.
• receiveTransaction — receives a verified transaction from a counterparty session and persists it to the vault.

For more information, see the Javadocs.

Persistence API Idempotency

The persist() API now requires a unique (within the context of a flow) deterministic deduplication ID to enable request idempotence in failure scenarios. The ID must be deterministic at the time of the function call and can not be more than 128 characters.

Token Selection API Idempotency

The tryClaim() API now requires a unique (within the context of a flow) deterministic deduplication ID to enable request idempotence in failure scenarios. The ID must be deterministic at the time of the function call and can not be more than 128 characters.

Fixed Issues

This section describes the issues resolved in 5.2. These occurred in the following areas:

• Deployment

Deployment

Token Selection Sharding and Ingress

Enabling sharding for the token selection worker could interfere with Ingress enabled for the REST and P2P Gateway workers. This resulted in repeated updates to the status of the Ingress resources causing a loss in connectivity to the REST API or P2P Gateway.

Known Issues and Limitations

Crypto Database Password Changed in Vault

The crypto database cluster-level password is not re-read from Vault if it changes.

Notary Selection

The notary virtual node selection logic (NotaryVirtualNodeSelectorServiceImpl) includes pending and suspended members.

Flow Service Exception

In some instances, the flow service throws an exception if a lambda expression is used. This issue is caused by a bug in the ASM library.