It is already March, and we have just released Next-Gen Corda Beta 2, which you can get by visiting the docs website.
For the Next-Gen Corda beta release, an immense amount of work has been put in by the entire team at R3. It’s been a long journey, we’re pleased with the result, and we hope you like it too.
This is the first public beta release of Next-Gen Corda so take it for a spin, and we are excited to hear what you think, what you liked, and what you didn’t like. We’re inviting you to give Beta 2 a try as we welcome more early adopters to give us feedback on this release.
What’s New In Beta 2?
With Next-Gen Corda, we present new opportunities for reliability, deployment, performance, and scalability with more efficient use of resources with reduced cost.
Individual pieces of the puzzle were built out with each of the past developer previews releases. With the beta release, we will see how we combine these unique pieces. This blog post series will take you through all these puzzle pieces and help you onboard to Next-Gen Corda.
We will start by discussing Next-Gen Corda’s architecture by breaking it up into multiple pieces.
With Next-Gen Corda, we have the concept of “work”. As you can see in Figure 1, the pile of work on the left can be anything — starting a flow, registering to the network, querying the database etc. With Next-Gen Corda, we segregate the work across multiple workers. For, e.g., in Figure 1, I have shown three workers. The DB worker reads and writes to the database on behalf of other workers. The crypto worker is the only worker who can access the private keys to sign the transactions. Each worker is a stateless process. The workers talk to each other via the Kafka message bus. You can achieve a High Availability (HA) scenario by having multiple instances of worker processes running. Figure 1 shows how we can use Kubernetes to scale the workers up and down.
Concept of an Application Network
Let me introduce the concept of an “Application Network”, where the Corda network is now application-centric. Corda’s promise of a permissioned network is achieved by having a network operator who decides what are the rules for joining a network. MGM. Any identity who wishes to join the network must abide by the rules and make a network registering request to MGM. Once approved by MGM, the identity is free to transact with its peers.
Concept of a Corda Package Installer (.CPI) file
Creating an application network in Next-Gen Corda is achieved by uploading a single .CPI file to a Corda cluster. This file contains a CorDapp packaged as a .CPB file with a GroupPolicy.json file.
In Figure 2, we can see we have two application networks, one for CBDC CorDapp and the other for a Settlement CorDapp. CBDC application network is managed by MGM A, and the Settlement application network is managed by MGM B. As you can see, Alice can belong to either of the application networks. Also, the application networks can span multiple Corda clusters.
Concept of Virtual Nodes
Virtual nodes represent the environment required to load a CorDapp from a specific application network for a specific identity. We will see how is this environment created later in the blog.
To perform application-specific work for a particular identity, we will first create a virtual node configuration by associating identities with the .CPI file. The identity can participate in any application network by creating a new virtual node configuration.
The diagram shows that we have two identities, Alice and Bob, part of our Corda cluster. We have two .CPI’s — two CorDapps, each associated with two different application networks. Alice will be able to participate in either network. Alice will create a virtual node configuration associating Alice with the CBDC CorDapp network. This needs to be approved by MGM. Alice will raise a virtual node registration request to MGM. Once approved, you can say a virtual node is ready to be loaded.
When Alice triggers some work from CBDC CorDapp, we can now load Alice’s virtual node for the CBDC network. As you can see in the diagram, we have multiple instances of the workers running; each worker can simultaneously take up the work from Alice and Bob. On the left, you can see a pile of work. Workers are agnostic to what work is being put on the message bus. So one flow worker can pick up the work from Alice for CBDC CorDapp or Bob for Settlement CorDapp.
Since the workers are entirely agnostic of the work on the message bus, even if there is less work for Bob and more work for Alice, it’s okay; the cluster will scale on an aggregate level and is not bound to a specific virtual node.
Now you can say that a Corda cluster represents Corda workers ready to take up any work — work from any identity, work for any network. Hence you can say that a cluster can host multiple application networks, each representing one application, and multiple identities, each identity can be part of multiple networks, and each identity can be mapped to one or multiple application networks i.e one or more CorDapps.
The above diagram shows how everything fits together. It shows a Corda cluster, having two virtual nodes created, each associated with a network and a CorDapp, two application networks, each representing a CorDapp. The diagram also shows the virtual nodes are loaded in a sandboxed environment- an area where the Installer(.CPI file) can exist in isolation, meaning it can’t see any other tenants on the host deployment, and the other tenants can’t see it.
This architecture also supports multi-tenancy, as you can host multiple virtual nodes in a cluster without incurring additional costs.
HTTP REST API
You can interact with the virtual node with exposed HTTP RPC Rest endpoint.
P2P Gateway is used to talk across clusters.
In the next blog post, we will see how to use CorDapp Standard Development Environment (CSDE) and deploy an All-In-One Corda Worker cluster.
Thanks to all the amazing people in the Platform Engineering, QA, Tech Writers, Build and Product Management teams at R3 who made it possible to achieve this milestone!