February 21, 2019
1800+ commits, many new features, compatibility with Corda 3, and all done in the time it takes to gestate a baby sea lion (11 months for those not of a zoological persuasion).
Corda 3 has done sterling service since we delivered it last year, finding a home as the foundation part of many exciting projects, embraced by both enterprises and the open source community, and truly enabling the growth of DLT and blockchain toward more mature products.
Now we’re delivering Corda 4 with multiple features that enable you to accelerate your vision of delivering rock solid DLT applications, and go to production with what you need to enable long term stability and confidence.
We’ve done significant work on backwards compatibility testing in this release, including testing apps written by our users, so you should be able to upgrade with confidence. However, please do read the release notes to learn what you need to know.
Corda 4 introduces reference states. These allow smart contracts to read data from the ledger without simultaneously updating it. They’re useful not only for any kind of reference data such as rates, healthcare codes, geographical information etc, but for anywhere you might have used a SELECT JOIN statement. Reference states significantly simplify app design and improve Corda’s scalability, by avoiding contention on hot states that are being widely used.
Signature constraints enable smooth rolling upgrades over huge datasets, by allowing states to define what contract logic governs them with much greater flexibility than previous versions of Corda. States can express these restrictions socially, as in “any contract JAR signed by a threshold of these keys is suitable”, rather than just by hash or via zone whitelist rules, as in previous releases. This is a fundamental part of the Corda security and upgrade story, reducing attack vectors and giving greater control to app developers.
Corda 4 finishes off the wire stability story started with Corda 3 with the rollout of AMQP serialisation across the whole communication stack. We have now fully removed usage of Kryo from the RPC stack. The new class carpenter functionality will auto-generate and load classes that match the embedded message schemas received from the node, enabling dashboards, format converters and other generic tools to be created without the need to embed every CorDapp within your client app. Finally, we’ve added SSL support for the RPC connections, something a number of you have been asking for.
Network parameters in transactions. States on Corda are designed to be long lived and valid until consumed no matter how far in the future that is! We recognise however that, over time, whilst historic states remain in stasis the surrounding infrastructure will not. It is thus important we have some mechanism by which to interrogate a state for historic validity as the network existed at the time it was signed.
To meet this requirement transactions created by a Corda 4 (and beyond) node will have the currently valid signed network parameters file attached and signed over. This also means new signatures must be working against the current globally accepted parameters. The notary signing a transaction will check that it does indeed reference the current in-force network parameters. This will mean that new transactions that are valid only under old (and superseded) network parameters cannot be confirmed.
It is a fundamentally important aspect of Corda (and all blockchain based platforms) that all nodes processing a transaction agree on its validity. Corda transactions are defined using JVM bytecode, meaning the execution of that code must be fully deterministic for this to occur. Because this isn’t a requirement of existing JVMs, they do not provide this functionality, thus Corda 4.0 introduces a standalone Deterministic JVM. Whilst it isn’t yet integrated with the rest of the platform it will eventually become a part of the node and enforce deterministic and secure execution of smart contract code.
Currently it is released as an evaluation version. We want to give developers the ability to start trying it out and get used to developing deterministic code under the set of constraints that we envision will be placed on contract code in the future. There are some instructions on how to get started with the DJVM command-line tool, which allows you to run code in a deterministic sandbox and inspect the byte code transformations that the DJVM applies to your code. Read more in “Deterministic JVM”.
Corda 4 introduces state pointers, a feature that combines with reference states to make it easier to refer to the latest version of something on the ledger. Configurable flow responders allow sophisticated users of CorDapps to customise their execution by subclassing and overriding flows. For example an institution could customise a shared flow from an industry-wide app to make it send a PDF report to a specific set of users inside the company. Some backwards compatible, opt-in API changes give improved security for applications. Applications can now use the Java Persistence Architecture to access the node’s database engine, building on the JDBC/SQL support in prior releases. Target versioning allows the platform to enable and disable backwards compatibility codepaths depending on whether an app declares it needs them or not, allowing us to be more forgiving of bugs or old behaviour in apps.
For node operators, an official Docker image is now provided for those who want to run a container based infrastructure. It’s also used by the new network builder tool which gives a graphical way to build test Corda networks locally and in the cloud. We’ve open sourced the LiquiBase database upgrades feature from Corda Enterprise 3 to make upgrades and migrations easier. Notary back pressure helps avoid overload, enabling nodes to run as fast as the notary can handle without triggering failures. Some types of network parameter flag days are now auto accepted by the node when the change is simply additive, and thus nobody would conceivably disagree. Logged errors now all have unique error codes that can be discussed on StackOverflow. We’ve totally revamped our command line handling to be far more robust, helpful, consistent and visually attractive. Finally, we’ve added a new command to pre-validate configuration files.
Upgrading a distributed system whilst it’s live is a notoriously difficult engineering problem, that has led to many outages over the history of the IT industry. Doing such upgrades on a long lived blockchain where different apps, developers, node versions and attackers all co-exist simultaneously is tougher still. We’ve expended great effort during the Corda 4 development process to craft solutions that solve or catch many problems of inter-version upgrades (e.g. accidental forwards-compatibility bugs), whilst also blocking attacks. Anyone’s who’s followed this process closely via our mailing lists will see it hasn’t been a smooth journey… this is a vastly complex area and we’re only just beginning to scratch the surface of it.
In future we plan to provide a comprehensive versioning and upgrades guide, that will show you how to build apps that can be smoothly migrated across versions without any interruptions to service. We’re proud to be shipping the first stages of a comprehensive solution to this in Corda 4.
You’ll be delighted to learn we’ve added some new jokes.
Share this post
Stay up to date on the latest news and articles related to Corda.