By Charlie Crean, Staff Software Engineer at R3
Next-Gen Corda introduces a fresh network model designed to enhance privacy, control, and operational efficiency. This comes in the form of application networks, which have been designed to make creating, managing, and participating in Corda networks simpler and more efficient. In this article, we’ll explore the practical features of application networks and how they empower you to easily set up and manage your own networks.
Getting to Know Application Networks
Before we delve into the features, let’s take a closer look at what an application network is exactly. Simply put, an application network is a permissioned network of virtual nodes that all agree to the same set of network terms, and are all running one or more compatible applications. Admission to the network is managed by an entity (or entities) known as the network operator. The rules determining whether a party can join the network are defined by the network operator, and can range anywhere from allowing anyone to join unchallenged, to performing a full Know Your Customer (KYC) process on each member.
These networks can span one or more Corda clusters and consist of a network manager (also known as the Membership Group Manager (MGM), which we will cover shortly) and one or more network participants. This network manager is operated by the previously mentioned network operator entity. A single Corda cluster can host multiple virtual nodes in the same or different application networks.
Each application network is self contained in terms of network visibility. Parties who have been permitted to join network A, for example, do not have visibility over parties who have been granted access to network B (and vice versa). Though parties may choose to run multiple virtual nodes and join multiple different application networks (as shown for Alice in the above diagram), which would allow them the option of interoperability between these networks.
Application networks aim to enhance the network models from previous Corda iterations by allowing management through tooling native to a Corda cluster (accessible via REST APIs), by moving away from the use of bespoke software in the CENM stack, and by allowing the network operator to select the certificate authorities to serve as the network trust root(s). The privacy provided by application networks also means that only parties approved to join a network have visibility over that network – meaning it’s not visible to a party running on the same or different cluster unless they get approval for that specific application network.
In regulated markets, customers have stringent privacy and governance requirements. These requirements often differ between different applications. As a result, the majority of CorDapps have been launched as private business networks. Application networks embrace this reality by reducing the scope of each network to a single bundle of applications, all governed by the same rules.
As network scope is reduced to a select number of applications, network rules are limited to a much more reduced set of participants. In previous Corda network models, all network participants shared the same network rules regardless of which CorDapps they were running. Application-scoped networks allow a more fine-grained control over network properties such as the available notaries, and maximum transaction sizes.
Let’s now explore the key features of application networks.
Embrace Industry Standards
Bringing industry-standard Public Key Infrastructure (PKI) and tapping into third-party Certificate Authorities (CAs) adds an extra layer of security and trust to your application network. The network operator can select a specific set of CAs as trust roots for the TLS PKI of the network and require all participants to get certificates issues from one of those in order to transact successfully within the network. This means solid encryption, secure identity management, and a simpler authentication process for all participants across your network. The result? A more resilient and reliable network infrastructure that aligns with established security best practices.
But that’s not all – managing your network becomes a breeze with the power of REST APIs. The magic of REST APIs lies in their user-friendly approach. They offer clear-cut instructions, making the administration of your network a walk in the park. What’s even better, they seamlessly integrate with your current tools and systems, adding a touch of automation to smooth your operations.
Explore Multiple Network Models
Corda’s application networks offer multiple network models tailored to different stages of development and testing. Currently, two models are available, but the overall structure of the network models allows for pluggability meaning as Corda evolves, the network models can evolve with it without a major restructure.
Here’s an overview of the existing models:
Static networks: Ideal for local testing, with predetermined virtual nodes, operating within a single cluster.
Dynamic networks: Suited for real-world scenarios, including production networks, cross-cluster testing, and adaptable scenarios with varying member counts.
Notably, dynamic networks feature the MGM, a central component for dynamic participant registration, data distribution across clusters, and advanced network management. While these are the current models, there is the potential for additional models in the future.
Static networks are named as such because the network participant list is predetermined. This is allows networks to be created without an MGM. The lack of an MGM limits the network feature set but allows for quicker network setup which is why this model is only for testing purposes.
While these are the two network models currently available, we have plans to extend this in the future to cover a wide array of business needs. The pluggable nature of the network models will allow us to meet specific needs easier than ever before.
Below you can find out about some of the extra capabilities available in dynamic networks.
Meet the MGM
Within an application network, the Membership Group Manager (MGM) assumes the crucial role of network administration. By operating as a virtual node with network administration permissions within a Corda cluster, the MGM significantly reduces the operational overhead associated with network creation and management compared to previous Corda iterations. Importantly, integrating an MGM into any Corda cluster is streamlined and resource-efficient, as it requires no additional infrastructure.
An application network can contain a single MGM which is responsible for onboarding virtual nodes to the network, distribution of network data, and managing the network. The party responsible for network management can use Corda’s REST API to act as the MGM and administer the network.
Onboard with Ease
As application networks function as private, permissioned networks, the challenge lies in striking a balance between robustly securing network access and data while maintaining a seamless onboarding experience. To tackle this, let’s have a look at the network onboarding process.
Network onboarding offers flexibility and enables seamless integration into business-specific workflows external to Corda which must be executed before allowing permission to join a network. On the side of the network operator, this gives a fine-grained level of control over which virtual nodes are approved to join a network. And on the applying virtual node’s side, all the information required to join a network comes as part of the installed CPI so network onboarding can be requested via a simple REST API.
One facet of this functionality is the automatic handling of onboarding requests. When a virtual node initiates the onboarding process and successfully passes automated validations, it swiftly gains entry to the application network.
Moreover, this feature includes the ability to pause registrations for manual review. This empowers administrators to assess registration requests, establishing a tailored onboarding workflow. Through the network manager REST API, pending registrations can be queried, allowing for personalised attestations (for example, KYC checks or verification of subscription fees). Once the personalised workflow has completed, these paused registrations can be approved or declined through the REST API.
Certain networks may require strict onboarding validation for registering parties, but wish to fast-track a selected number of entities into the network (for example, if the entities are already known and trusted). For these entities, a further layer of expedited onboarding is achievable through token issuance. These tokens grant parties the advantage of bypassing manual reviews, expediting the process while retaining the option to halt specific registrations which do not include a registration token.
This comprehensive suite of options transforms network onboarding into a dynamic and adaptable process, accommodating a spectrum of needs and scenarios.
The suspension feature presents a tool for managing network dynamics within an application network. By suspending virtual nodes, their ability to engage in transactions with other network participants is temporarily halted. Suspended virtual nodes become undiscoverable in the network participant list, preventing other parties from accessing their information. This blockage applies not only at the CorDapp API level but also at the peer-to-peer layer on both ends of an attempt at communication. If either party involved is suspended, messages are dropped, effectively preventing interactions involving suspended parties.
Suspended parties do not receive any network updates during the period of time in which they are suspended. Similarly, non-suspended network parties receive no updates about about suspended members.
This functionality grants administrators control over network interactions. When the timing is optimal, the network manager can elect to reactivate the suspended virtual node, promptly restoring its full network functionality. Unlike more definitive actions such as certificate revocation, this approach provides a flexible solution for temporarily taking parties offline within the application network.
Wrapping It Up
And that’s a wrap — a friendly introduction to the world of Next-Gen Corda’s application networks. We’ve taken a stroll through some neat features that redefine how Corda networks work. From the MGM to the smooth network onboarding, network suspensions, and the integration of industry-standard PKI and third-party CAs.
But wait, there’s more to explore! While we’ve scratched the surface of what application networks can do, there’s a lot more to uncover. So, for all the curious minds out there, it’s time to dive into Corda’s documentation, join community chats, and gear up to learn about all the ins and outs of application networks in Next-Gen Corda.
Thank you for taking the time to delve into the world of Corda’s application networks with us. I hope this blog serves as inspiration to start playing with application networks, and exploring their possibilities. We wish you all the best as you embark on this exciting adventure.
Ready to Dive In?
Excited to get hands-on with Corda’s application networks? There’s a world of exploration waiting for you! To take your journey to the next level, check out the official announcement of Next-Gen Corda’s release.
For a deeper dive into the application network vision, this early blog post unveils the grand plan behind it all. Or you can check out a blog post by our CTO, Richard Brown, which provides some background on why we moved from global networks to application-scoped networks.
Feeling adventurous and want to start building your own network? Look no further than the step-by-step documentation that walks you through creating your very own application network.
So what are you waiting for? Your journey into the world of Corda’s application networks awaits. Dive in and explore!