We shipped Corda 4 yesterday… here are some key new features we think make it a big deal…

Kat has all the details here, and the release notes, upgrade notes and changelog provide all the detail.

In this post, I highlight three specific new features, all unique to Corda, and explain why I think they are important. They are:

Reference States

“Only confirm this transaction if the reference data used to construct it is up to date”

Corda enables parties who wish to transact to do so safe in the knowledge that “what I see is what you see.” If my node tells me you owe me some money, then I know for sure that yours says the same thing.

It’s why we spend so much time on things like consensus, determinacy, contract verification, and so forth. But agreeing on a single fact is only half the story. Sometimes you need to agree on some underlying data too.

To see why, imagine we had modelled an insurance policy using a blockchain and you’ve opened a claim.

We get to a point where I’m ready to settle the claim and so maybe I create a transaction that uses Corda Settler to initiate a payment to you over some existing payment rail, and simultaneously update the claim to mark that it had been paid.

I sign it and send it to you as a courtesy to let you know the money will soon arrive in you bank account and that the claim is now settled.

Except… during the claim process, you changed bank! The reference data I hold about where to send payments to my customers is out of date.

And so, even after going to all this trouble to reduce error and inconsistency, we still have a payment that has gone AWOL! And note: this could also happen even if the payment was on-ledger: perhaps you’d cycled your key.

The solution to this problem is a simple idea. What if I could tell Corda: “here is the transaction I want to execute and here also is the reference data I used to prepare it; please only confirm the transaction if the reference data is up to date.”

In the example above, imagine you had an “account details” state on the ledger. It is effectively a notice from you to the world saying: “if you need to pay me, here’s how.” And if you ever change your bank details, you would update it.

So now, with Corda 4, by referencing it in a transaction, I can be sure that if you had updated your details I’d find out before finalising my payment to you.

We would have removed yet another source of error and inconsistency.

We think this idea — “only process this transaction if the following data is up to date” — is going to be huge. You can read more about it here.

Network Parameters in Transactions

“What were the network’s rules when this transaction from the past was confirmed?”

Now… this one sounds technical and, well, a bit boring. But it is also key to the massive expansion of Corda Network.

Recall: Corda’s vision is big.

We think we can go way beyond the idea of lots of standalone single-purpose blockchain networks. Sure: if you have specific regulatory, geographical or business needs to tightly control who is on your network or govern how it runs then Corda will work just fine and we are seeing lots of these networks springing up.

But, for many groups of users we see, they are tantalised by the possibility of states created in one context being reused in another, for assets to flow around the ‘internet’ of Corda nodes in unanticipated ways, and be recombined and split in ways limited only by the imagination of developers who haven’t even started writing any code yet.

And to enable that vision in reality we need a few pieces of plumbing.

For example, a network like Corda Network is going to be around for a long time. So it is going to go through upgrades: new notary pools will be added, old ones will be retired; new platform features will become standard, old ones will be deprecated; new crypto suites will be added that everybody is expected to understand, and so on.

So this raises a question: if you join the network in a few years’ time, how are you supposed to know if a transaction from the past was valid or not? What were the generally accepted rules back then? How are you supposed to know?

Bitcoin, for example, solves this by hardcoding the answer in the software. But many of these ‘network parameters’, as we call them, can legitimately be different for different precursor networks or segregated ‘sub zones’ of Corda Network. Hard-coding them in the software would be too cumbersome.

So, in Corda, starting in version 4.0, we include a reference to the network’s prevailing parameters in every transaction. That way, when your node is reviewing a transaction from the past for validity, it knows precisely which version of the network parameters were in force at the time.

This sounds minor but it is the key to unlocking a bunch of adoption and migration scenarios for large-scale shared networks like Corda Network.

Signature Constraints

“How do I upgrade my app?”

This one is the biggie. It’s also the reason Corda 4 has proved so difficult to get right… It turned out to be a bit harder to get it working than we first realised.

But the wait has been worth it because this new feature, and supporting infrastructure from Corda’s serialisation framework, unlocks some extraordinary capabilities.

Here’s the problem to be solved:

You and a group of peers have deployed a blockchain application to automate some part of your business relationship. Let’s assume the app was written by a software vendor you contracted for this purpose.

So you all install Corda 4 (or Corda Enterprise 4 — they’re fully interoperable), install the app, go live and start transacting. Excellent!

Except… what happens when it’s time to upgrade the application?

If you don’t plan for this up-front, you can end up in pickles such as the DAO hack or other “code is law” problems. But implementing app upgrade functionality inside a distributed application by hand is hard and error prone.

It’s why we shipped, in Corda 3, a somewhat brute-force way to enable application upgrades: you could opt in to let the operator of the zone ‘whitelist’ updates to applications. But that was just a short-term measure… it was centralised and clunky. But it did work.

In Corda 4, we go a massive step further. We allow those adopting an application to opt in to a ‘social’ system of application upgrades. With Corda 4, you can express conditions like: “any newer version of the app signed by the following party (perhaps a business network operator) or n-of-m of the following parties can be used to spend this state.”

This doesn’t sound like a big change but when, you combine it with Corda’s serialisation framework, it opens the door to something unprecedented in blockchain systems: rolling upgrades of apps.

To see why this is important, think about the logistics of getting all participants in a business network to upgrade their app. The idea that everybody needs to upgrade on the same day seems a bit fanciful.

But with signature constraints, that have the effect of decentralising upgrade logic by giving individual node operators a degree of freedom over which version of an app to use, and the Corda serialisation engine, that allows data structures to evolve in forwards- and backwards-compatible ways, Corda 4.0 opens the possibility of different members of a business network upgrading their apps to different schedules and yet continuing to have everything work!

These features are advanced, and I suspect we’ll learn a lot about how to use them in real life in the coming months, so watch this space.

In the meantime, do take the time to get your head around how signature constraints and the Corda serialiser work. Your first experiences of them will probably be head-scratching pain when you wonder why something has stopped working..! But do persist… . what we’re introducing with Corda 4.0 is ground-breaking… nobody else has anything remotely like this. Invest a bit of time understanding how they work — and why they’re there — and it will repay itself many times over.

And there’s more…

This is just the tip of the iceberg so do read the release notes; there is a lot in this release!