Corda 5 “The road ahead” — Introducing the building blocks of Corda: API Modularity Part 4

By: Nina Kanti

Developers are a key to the success of our platform and in Corda 5 this is no different. We’ve recently released a preview of the next major version of Corda, Corda 5 Developer Preview. Developer Preview is packed with a bunch of new functionality for developers to try out and give feedback on. The highlights of this release are the new APIs, now interface-based with implementations hosted in separate packages.

Corda 5 Developer Preview, which you can consider an alpha release, allows you to assess our new set of modular APIs and how they might impact your development velocity. In this blog post, we will deep dive into what API modularity means for developers and touch on our motivations behind them.

New to Corda? Have a look through our official Corda Documentation to know more about Corda’s capabilities and key concepts. We do assume in this post you know a bit about the Corda platform

Why make our APIs modular

The new APIs will give you the following advantages:

• Accelerates time to value — These APIs will improve the testability of CorDapps. Developers now have a way to test workflow functionality by mocking services, allowing them to test the business logic in their flows in isolation. Why not try this out yourself by running the flow unit tests with our sample solar system CorDapp built on Developer Preview?
• Ability to bring your own ledger model — Be flexible on your data model which opens the platform up to new use cases, for example, you can use workflows and not the UTXO model, but store your data however fits your system. Corda uses the Corda transaction model (UTXO, atomicity of Corda transactions and checkpoints via DB transactions, contract verification, notarisation). This means that developers will have the ability to provide their own unique solutions for data storage in the future.
• Improves R3’s productivity — Although this is an internal advantage this will increase the maintainability of our APIs and allow our engineering team to fix bugs quicker. Currently, due to the base module being tightly coupled, one alteration can have a ripple effect of changes. Modular APIs will allow our engineering team to maintain and evolve our APIs in a controlled fashion due to the decoupling of components.

Motives

Corda is a permissioned DLT that offers transaction finality guarantees and has embedded privacy features. However, the architectural layers that give Corda these capabilities could have much broader applicability. These layers can be used independently to automate secure communication with participants in a network, and/or give you the ability to coordinate distributed processes between multiple organisations. These capabilities are powerful in their own right!

Last year we performed an experiment to assess how our community has been using Corda, to show how we can help you get to market faster. We called this ‘Project Layer Cake’ and it resulted in defining Corda in layers. Project Layer Cake was a key driving force to make our APIs modular, allowing us to unlock even more value. Watch out for the next blog post to learn more about Layer Cake, where I will go over use cases and common development patterns.

Building blocks

As part of Project Layer Cake, we split Corda into four logical layers where each layer represents a core value of Corda. Developers can now identify which component they require for their use case, and which layer to deep dive into first to learn about these guarantees:

• (P2P) Network — allows data and assets to move securely within a Corda network and communicate with participants. This layer is the foundation of our identity stack, allowing parties to be represented reliably using well-known identity certificates. More on networks in an upcoming blog post
• Flows — Flows automate business processes where data or tasks are coordinated across peers for action, according to a set of procedural rules. Flows can be executed concurrently and reliably on your node, without needing any additional code.
• Ledger — ability to define and store states which are committed via transactions to the vault. The ledger layer offers data consistency and guarantees the ‘what you see is what I see’ (WYSIWIS) promise of Corda.
• Contract — ability to define business logic which must be applied consistently at all nodes to create/ update valid states. These states can be updated without the involvement of all participants using the UTXO model, linking the inputs of future transactions to the outputs of past transactions.

Separation of Concerns

The sketch above showcases what the new APIs look like now in Corda 5. Although you may have the ability to build a workflow engine for intra-organisation workflows (i.e. between departments in the same company) Corda brings little value in these types of use cases. We believe the workflow layer will most likely be used alongside peer-to-peer networking, allowing you to interact with parties in a network securely. You can consider this as our base layer more on common use cases patterns in the next blog post.

Currently, all Corda states depend on our contracts, meaning the contracts layer will typically be used when storing states on the Corda ledger. The new APIs, however, will offer the ability to implement your own pluggable ledger layer where contracts may not be required — a feature we expect to use ourselves. We hope to introduce this pluggable ledger model once the architecture changes are made to make Corda suitable for highly available systems — for more information, view our previous blog. This will be a big undertaking in the 5 series where we hope to re-write the ledger layer to allow for these capabilities.

To leverage this new pluggable ledger approach, you can expect the introduction of a new state type — Consensual States — in the Corda 5 series. In scenarios where you want to negotiate between parties or evolve an agreement, contract verification or backchain verification isn’t necessarily required. Watch out for the introduction of Consensual States, in the Corda 5 series, more on this here.

Conclusion

We want to allow our community to build CorDapps that are fit for purpose where the new APIs play a key role in this. We do aim to release design thinking content and design matrices on best design practices to accelerate your development velocity.

The modular APIs will improve the testability of our platform and allow developers to build CorDapps more effectively. The API changes are motivated by Project Layer Cake, an internal initiative, which set out to think about Corda in layers of value; network, flow, ledger, contract. Thinking of Corda in layers allows developers to analyze which guarantees of Corda they need.

Organisations, especially start-ups, want to build something quickly and easily without having to worry too far about the future. Perhaps your current use case doesn’t require all the layers of Corda or you may not need it yet for your minimal viable product. The platform now allows you to develop incrementally and get geared up for the future. In the first blog post, we spoke about progressive decentralisation. These layers enable incremental development allowing developers to simplify their solutions and build at a much faster rate — lets discuss how in the next blog post

Call to action

• Next on the series, more on Project Layer Cake how it came about and our key takeaways
• In the meantime, make sure to try the new Corda 5 APIs in developer preview and let us know what you think over on Slack or Discord (search for the “corda5” channel).
• Any feedback on the direction you want to give to the product team directly, let us know at [email protected].

Thanks,

Nina