Milestone 11.2

This is a bugfix release which changes UntrustworthyData.Validator to implement Serializable so that checkpoints with unwrap lambdas are valid.

Milestone 12.1

One of our busiest releases, lots of changes that take us closer to API stability (for more detailed information about what has changed, see https://docs.corda.r3cev.com/changelog.html). In this release we focused mainly on making developers' lives easier. Taking into account feedback from numerous training courses and meet-ups, we decided to add CollectSignaturesFlow which factors out a lot of code which CorDapp developers needed to write to get their transactions signed.

The improvement is up to 150 fewer lines of code in each flow! To have your transaction signed by different parties, you need only now call a subflow which collects the parties' signatures for you.

Additionally we introduced classpath scanning to wire-up flows automatically. Writing CorDapps has been made simpler by removing boiler-plate code that was previously required when registering flows. Writing services such as oracles has also been simplified.

We made substantial RPC performance improvements (please note that this is separate to node performance, we are focusing on that area in future milestones):

• 15-30k requests per second for a single client/server RPC connection.
  • 1Kb requests, 1Kb responses, server and client on same machine, parallelism 8, measured on a Dell XPS 17(i7-6700HQ, 16Gb RAM)
• The framework is now multithreaded on both client and server side.
• All remaining bottlenecks are in the messaging layer.

Security of the key management service has been improved by removing support for extracting private keys, in order that it can support use of a hardware security module (HSM) for key storage. Instead it exposes functionality for signing data (typically transactions). The service now also supports multiple signature schemes (not just EdDSA).

We've added the beginnings of flow versioning. Nodes now reject flow requests if the initiating side is not using the same flow version. In a future milestone release will add the ability to support backwards compatibility.

As with the previous few releases we have continued work extending identity support. There are major changes to the Party class as part of confidential identities, and how parties and keys are stored in transaction state objects.

Added new Byzantine fault tolerant (BFT) decentralised notary demo, based on the BFT-SMaRT protocol

We continued to work on tools that enable diagnostics on the node. The newest addition to Corda Shell is flow watch command which lets the administrator see all flows currently running with result or error information as well as who is the flow initiator.

We have also started work on the strategic wire format (not integrated).

Milestone 13.0

Following our first public beta in M12, this release continues the work on API stability and user friendliness. Apart from bug fixes and code refactoring, there are also significant improvements in the Vault Query and the Identity Service. More specifically:

The long awaited new Vault Query service makes its debut in this release and provides advanced vault query capabilities using criteria specifications (see QueryCriteria), sorting, and pagination. Criteria specifications enable selective filtering with and/or composition using multiple operator primitives on standard attributes stored in Corda internal vault tables (eg. vault_states, vault_fungible_states, vault_linear_states), and also on custom contract state schemas defined by CorDapp developers when modelling new contract types. Custom queries are specifiable using a simple but sophisticated builder DSL (see QueryCriteriaUtils). The new Vault Query service is usable by flows and by RPC clients alike via two simple API functions: queryBy() and trackBy(). The former provides point-in-time snapshot queries whilst the later supplements the snapshot with dynamic streaming of updates.

We have written a comprehensive Hello, World! tutorial, showing developers how to build a CorDapp from start to finish. The tutorial shows how the core elements of a CorDapp - states, contracts and flows - fit together to allow your node to handle new business processes. It also explains how you can use our contract and flow testing frameworks to massively reduce CorDapp development time.

Certificate checks have been enabled for much of the identity service. These are part of the confidential (anonymous) identities work, and ensure that parties are actually who they claim to be by checking their certificate path back to the network trust root (certificate authority).

To deal with anonymized keys, we've also implemented a deterministic key derivation function that combines logic from the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) protocol and the BIP32 hardened parent-private-key -> child-private-key scheme. This function currently supports the following algorithms: ECDSA secp256K1, ECDSA secpR1 (NIST P-256) and EdDSA ed25519. We are now very close to fully supporting anonymous identities so as to increase privacy even against validating notaries.

We have further tightened the set of objects which Corda will attempt to serialise from the stack during flow checkpointing. As flows are arbitrary code in which it is convenient to do many things, we ended up pulling in a lot of objects that didn't make sense to put in a checkpoint, such as Thread and Connection. To minimize serialization cost and increase security by not allowing certain classes to be serialized, we now support class blacklisting that will return an IllegalStateException if such a class is encountered during a checkpoint. Blacklisting supports superclass and superinterface inheritance and always precedes @ CordaSerializable annotation checking.

We've also started working on improving user experience when searching, by adding a new RPC to support fuzzy matching of X.500 names.

Milestone 11.1

• Corda now requires JDK 8u131 or above in order to run. Our Kotlin now also compiles to JDK8 bytecode, and so you'll need to update your CorDapp projects to do the same. E.g. by adding this to build.gradle:

tasks.withType(org.jetbrains.kotlin.gradle.tasks.KotlinCompile).all {
    kotlinOptions {
        languageVersion = "1.1"
        apiVersion = "1.1"
        jvmTarget = "1.8"
    }
}

or by adjusting Settings/Build,Execution,Deployment/Compiler/KotlinCompiler in IntelliJ:

Language Version: 1.1
API Version: 1.1
Target JVM Version: 1.8

• We have increased the maximum message size that we can send to Corda over RPC from 100 KB to 10 MB.

• The Corda node now disables any use of ObjectInputStream to prevent Java deserialisation within flows. This is a security fix, and prevents the node from deserialising arbitrary objects.

• We've introduced the concept of platform version which is a single integer value which increments by 1 if a release changes any of the public APIs of the entire Corda platform. This includes the node's public APIs, the messaging protocol, serialisation, etc. The node exposes the platform version it's on and we envision CorDapps will use this to be able to run on older versions of the platform to the one they were compiled against. Platform version borrows heavily from Android's API Level.

• We have revamped the DemoBench user interface. DemoBench will now also be installed as "Corda DemoBench" for both Windows and MacOSX. The original version was installed as just "DemoBench", and so will not be overwritten automatically by the new version.

API changes:

• Added extension function Database.transaction to replace databaseTransaction, which is now deprecated.

• Starting a flow no longer enables progress tracking by default. To enable it, you must now invoke your flow using one of the new CordaRPCOps.startTrackedFlow functions. FlowHandle is now an interface, and its progress: Observable field has been moved to the FlowProgressHandle child interface. Hence developers no longer need to invoke notUsed on their flows' unwanted progress-tracking observables.

• Moved generateSpend and generateExit functions into OnLedgerAsset from the vault and AbstractConserveAmount clauses respectively.

• Added CompositeSignature and CompositeSignatureData as part of enabling java.security classes to work with composite keys and signatures.

• CompositeKey now implements java.security.PublicKey interface, so that keys can be used on standard classes such as Certificate.

  • There is no longer a need to transform single keys into composite - composite extension was removed, it is impossible to create CompositeKey with only one leaf.

  • Constructor of CompositeKey class is now private. Use CompositeKey.Builder to create a composite key. Keys emitted by the builder are normalised so that it's impossible to create a composite key with only one node. (Long chains of single nodes are shortened.)

  • Use extension function PublicKeys.keys to access all keys belonging to an instance of PublicKey. For a CompositeKey, this is equivalent to CompositeKey.leafKeys.

  • Introduced containsAny, isFulfilledBy, keys extension functions on PublicKey - CompositeKey type checking is done there.

Milestone 9.2

• Correct web server ports for IRS demo.
• Correct which corda-webserver JAR is published to Maven.
• Database tables are not dropped during node startup.