Corda 5: The Road Ahead Part 1

Following CordaCon we are excited to announce R3 is working on the next major platform version — Corda 5 — and that the first public milestone — Corda 5 Developer Preview — is available today!

You can check out the CordaCon sessions about it following this link. Our developer relations team is planning several posts to take you through the details of this preview and the practical changes in it — you should check those out too.

With this blog series however, we (the product team) wanted to share some of the thinking that went into the upcoming new features as well as the high level direction we are going towards with this new series. You’ll be able to “keep us right” and give us your feedback either by engaging with these posts or the upcoming previews we are planning leading up to the first GA release next year.

The road ahead* is still long and we want to take you with us on the journey.

I’ll kick off this series with a two part post on the “whys” of Corda 5 that led to some of the new features. Then we’ll share more information about our approach to modular APIs, network and the re-architecture of the node for availability and scalability.

*this is a throwback to an old post of ours leading up to Corda 1.0 here.

Why a new platform version?

Corda 4 has been in the market since February 2019 and over these 2.5 years has been powering a wide range of incredible solutions, allowing developers to re-architect trust in regulated multi-party enterprise use cases in ways that was simply not possible before.

While we introduced a lot of features and made the platform more robust — the architecture we were building on remained unchanged since the inception of Corda in October 2017.

A lot has changed in 4 years and in order to ensure the platform would address what we think our customers need today and in the future we needed to go back to the drawing board on certain aspects of it.

Below I want to share a few of the observations that got us started in this journey & what we took away from it.

1- App networks are the best go to market for distributed applications

We have seen the emergence and success of the concept of business networks — purpose built permissioned applications and (often) technical networks. We learned from those operating them that the ability to offer an end to end experience to participants of a context specific network ( for example, imagine the value chain of a letter of credit) greatly speeds up the go to market of solutions, aligns permissioning with those that have the context for it & offers a variety of operating & commercial models.

Take away: We designed Corda 5 to optimise the development, distribution and lifecycle management of applications — we call this being “application centric” — it really boils down to putting ourselves in your shoes (developer/software vendor) and starting from there with everything we do. We also want to greatly simplify & broaden the appeal of operating a network ($$$ → $). Finally we want to do it without compromising the interoperability potential that made a large network on Corda so compelling.

2- Build the new critical system infrastructure

In the past few years we have seen the interest & maturity of use cases grow among large financial market infrastructure providers, payments providers, and central banks. For Corda to enable you to go after the new generation of critical system infrastructure we need an extremely strong and ongoing investment on the non-functionals of the platform.

Take away: The primary objective we set out to achieve with the new series is to find an architecture that would allow us to reach the high availability demands of critical services as well as a cost effective way to scale (horizontally) to deal with bursty and high regime throughputs. The ambition is to have a scalable, highly available distributed system that can power an entire country’s money supply or the biggest international payment networks in the world.

3- Bootstrapping a networked application is incredibly hard but speed and lower costs can help

We have seen how improvements on key platform metrics such as CorDapps time to market & CorDapps (total) operating cost can become incredibly important when combined with the high bar of networked applications. It is often the case that “build it and they will come” is not appropriate if your application requires a significant portion of the participants of the value chain to be onboard first. We have seen successful examples of customers iteratively building their participants’ pipeline & their application and finding creative ways to speed up the GTM (through SaaS) to reach the critical mass.

Take away: Corda 5 is designed to be faster to develop on, cheaper to test for production grade applications — so that rapid prototyping can help you pipeline building, and a simpler path to production can help you convert your prospects in live participants.

4- Progressive decentralisation: When re-architecting trust, there is no one size fits all & you don’t built for the end state first

We have seen the early success among our ecosystem and across the industry of progressive decentralisation — that is applications designed for distributed systems but prioritising rapid GTM versus distribution at first and progressively distributing operations as the network grows.

Take away: While we spent a bit of time wrestling with this concept internally (specifically for Corda) — we arrived at the conclusion that a progression towards a distributed end state is often the safer and easier way to test the market fit of a solution (particularly with a challenging GTM as described (3)). In Corda 5 we want to make these hybrid models possible, with a more flexible architecture that allows you to move between different operating models (progressively reaching your end state).

In conclusion — we took these and other observations and turned them into the following 3 objectives for the 5 series:

1. Faster and cheaper application development cycle
   (so that you can quickly prove the value of your solution & rapidly promote it to production).
2. Lower cost of operations for a larger array of operating models
   (not just for “a” node operator, for an application operator, for a variety of operating models).
3. A new architecture to be HA and horizontally scalable from the ground up
   (to power the next-gen critical system that will support any app in our ecosystem).

This is what we set out to do in 2020. Join me in the next blog post to know how we plan to meet those objectives!

Call to actions before you leave:

• Any feedback on the direction you want to give to the product team directly, let us know at [email protected].

Thanks! Gabe