The engineering team at R3 have been hard at work (in their homes) building a bundle of things in our summer release to improve your quality of Corda life. While they are putting the finished touches on this Q3 release, you can get your hands on it with the beta. Please contact our support team for access (email@example.com). This quarter our focus has been in three areas:
- Flow management
- Membership & network improvements
- Improvements for developers
Corda, uniquely among blockchains, has the ability to orchestrate workflows between companies. We recognize that managing these workflows can be difficult and puts an undue burden on developers to solve for this in their code. As such we have put more emphasis on the management of workflows that are in process. Our flow management improvements include:
- The ability to query, filter and inspect flow checkpoints via shell/RPC. The growth of long-lived production deployments had introduced the need for production-grade tools to manage running flows. With this feature we are giving administrators the ability to remotely retrieve rich information on a running flow, such as start time, the step reached, and the parameters passed to invoke it of in-process flows and manage their execution. This builds on earlier ‘flow hospital’ work and begins work on looking at flow management, not just fixing of flows with known errors. Users can query flows and obtain information from a number of filtering criteria such as progress step or CorDapp.
- Retry flows without restarting the node. Node operators can now retry hospitalised flows via RPC, rather than having to restart the node to trigger retries. In addition, node operators can mark problematic flows as “do not restart”, preventing them from being retried automatically when the node is restarted.
- Allows the use of a unique ID to prevent duplicate flow starts. The RPC Client has been updated to allow clients to deduplicate flow invocations, to ensure a given flow is not executed on the ledger twice. This also increases resiliency through allowing a client to take appropriate action should a flow fail to start.
Membership and network improvements
Our production use cases are revealing a need to help the CorDapp operators better manage their network of participants. Whether in a private network or a larger zone, such as the Corda Network, operators need to identify their users and manage them leveraging meta-data they establish about those participants. We are releasing initial capabilities in this area.
- Support for membership representation. BNOs are a term we use for business networks who deploy the CorDapps and manage the user base for them. To help this key entity better manage their users, we are introducing a new primitive on Corda that allows developers represent membership attestations, membership lists and ultimately Business Network abstractions. This release introduces tooling to manage the lifecycle of a membership attestation and showcases best practices to manage memberships, drive entitlements and set granular privacy and permissions within your business network.
- Increased support for larger networks. In response to the increase of observed network sizes (measured in terms of participants) we have increased the distribution performance of the network map list to ensure a faster turnaround even when the network passes the several thousands nodes.
- Removal of need for flag days when adding notaries. It is no longer necessary to shut down and restart a node after accepting the updated network parameters whenever a new Notary is added to a network’s whitelist, thus triggering a flag day.
We are focused on improving the overall developer experience to ensure Corda maintains it status as an easy to use platform for developers. In this release we have a number of improvements that will help developers build more resilient applications.
- Detection of un-restorable checkpoints. During development flows are now automatically serialised then deserialised whenever they reach a checkpoint. This enables automatic detection of flow code that creates checkpoints that cannot be deserialised. This feature can, and should, be disabled in the node configuration when in production.
- Register custom serializers. Custom serialisers can now be used when serialising types as part of a flow framework checkpoint. Most classes will not need a custom serialiser. This exists for classes that throw exceptions during checkpoint serialisation. Implement the new CheckpointCustomSerializer interface to create a custom checkpoint serialiser.
More in the box
In addition to the major areas of our focus we have included a number of improvements you can benefit from. These include:
- Monitoring of ledger statistics. We are releasing a new utility CorDapp that captures statistics related to the Corda ledger, allowing for efficient access via flows and JMX metrics.
- The metrics exposed by LedgerGraph include: size of transaction chain, attachment count and whether all the outputs of a transaction chain have been consumed. This utility will help operators anticipate when transaction chains are too long and should be reissued among other possible uses.
- In-place upgrades. We want to better assist customers moving from Corda open source to our Enterprise distribution. Our first step toward this is ensuring the schemas for open source and Enterprise are in sync allowing for a so called in place upgrade that does not require a larger migration of an instance.
- Metering improvements. To support operators who wish to retrieve Corda Enterprise metering data via the flow framework from a central collector node, we are releasing a standalone client for the metering collection CorDapp. The client can be used out of the box to retrieve metering data in JSON format from one or more nodes in a business network. No direct access to node shells is needed. If any node fails to respond, the client facilitates subsequent attempts to collect missing data.
- Store TLS keys in HSM. TLS keys are used in Enterprise by the firewall to ensure secure connections to other Corda servers. While we have had the ability for this storage to date it has been limited. From this release we’ll now enable storage of TLS keys in an HSM for any configuration.
While we are still hard at work finishing the third quarter release, we want to hear what you need in the future as our roadmap and priorities are based on our users input. If you have any input as to what you would like to see please email us at firstname.lastname@example.org.