Discover Corda Enterprise 4.3 and the Power of Accounts
We are happy to announce the release of Corda Enterprise 4.3. This latest version of Corda Enterprise builds on the capabilities introduced in Corda 4.3 and brings new functionality that meets the specific demands of enterprise deployments.
Corda Enterprise 4.3 continues our focus on the themes important to our customers and for putting Corda Enterprise into production: operational capabilities, security and resilience. We have also introduced a new capability that underpins a flexible pricing model for Corda Enterprise. We will discuss the new Corda Enterprise pricing model in a separate blog post.
Building on open source
Corda Enterprise builds on the open source distribution of Corda. This maintains our promise that a network can operate with a mix of Corda Enterprise and Corda nodes, and contracts can be deployed to either distribution without modification. Corda Enterprise users benefit from the enterprise grade capabilities of the latest version, as well as core features delivered in open source.
In Corda 4.3 we introduced accounts, a major new capability that we anticipate will help expand the use cases for Corda. Corda Enterprise brings support and maintenance to this capability. Customers such as Finastra, with Fusion LenderComm, are already embracing the potential of accounts:
2019 has been a great year as more and more Corda Enterprise nodes go into production, with great applications like HQLAx now up and running, supporting live transactions. With this momentum, we have seen new requirements related to operating nodes in enterprise data centers.
We have introduced the ability to gain insight into the operational state of a node, with node health check capabilities. In 4.0 we laid the groundwork by enabling the collection of information about the node to help the R3 support team to provide better service to our customers. Corda Enterprise now provides insights to the node operator on key indicators of whether a node is healthy and performing transactions as it should. The node health survey allows the node operator to verify the node is configured properly by checking it can reach the necessary local components (the bridge and float) and that the configuration files are in proper order (for the node and the Corda Firewall). It can also check that nodes can reach other necessary components on the network (such as the Network Map and the Identity Manager).
In Enterprise 4.3 we have increased our focus on the notary, targeting operations and performance.
We recognize that customers operating notaries have a varied set of preferred databases. Our new Java Persistence API (JPA) expands the set of databases that can be used, giving you the flexibility to use any supported database with the notary, which will support performance increases as networks grow. The JPA interface expands support in this release by adding CockroachDB and Oracle 12c RAC to be used as the notary database.
We have also increased performance of the notary by selecting CockroachDB to replace Percona as our preferred database. The challenge with the notary is it contains a simple data set that grows over time leading to long lookup times. We evaluated a number of technologies to address this while looking to satisfy all three demands we have for a notary database — High Availability (HA), ease of configuration and, of course, performance. Cockroach has great characteristics to support HA and performance that matches our use case well. The notary needs to be highly available to ensure business continuity in the network. CockroachDB helps greatly with this, for example, making it easier to add or remove nodes from the cluster. We are deprecating Percona in this release to give customers time to migrate to CockroachDB.
We continue to make progressive improvements on security, with a focus on HSMs. We’ve added Securosys and Azure Key Vault support for the Notary signing keys. We will continue to round out support for all key types across the platform in the supported HSMs. TLS keys that are used for the connection between a standalone Artemis MQ instance and the node can now be stored in the HSM. We’ve also made general improvements to our HSM integration ensuring any failure to connect to the HSM, or an HSM failure, is handled properly with retries and eventual failure of the flows giving control at the transaction level.
With Enterprise 4.3 we are introducing a new pricing model. We will have a separate posting on pricing to explain how you can benefit from a flexible pricing mechanism that grows with you. The new pricing model is usage based, in line with modern pricing we have become familiar with.
In order to support this pricing, we’ve introduced a new capability — metering. Metering is used for tracking activity related to Corda Enterprise’s pricing model, but it can be used by you to track your own usage across your network. Metering records the activity of signing a transaction locally in the node. This activity is a central event in Corda, or any blockchain, as it represents a definitive moment when you’ve agreed to a state transition that will be recorded on the ledger.
In order to help our customers, we also capture the command that is signed in the transaction. This gives more insight into what activity has occurred on the node. It allows CorDapp publishers to capture detailed information they can use for various purposes, including their own billing. With insight into the command signed you can create custom billing models where the price could, as an example, vary based on the activity. We are excited not only to provide our customers with a new flexible pricing model for Enterprise, but also to empower you to build out your own pricing models leveraging our platform capabilities.
All of this was designed to ensure it respects privacy. Information is captured locally in the node only. It is not automatically reported back to R3 or the CorDapp publishers. The node operator can run a flow to query for this information and then must manually send this information to the CorDapp publisher. In a future release we will automate this process, while still ensuring the node operator has opted in to provide information in a transparent manner.