Introduction to Corda5’s CorDapp Packaging Model

The next major release of Corda (v5) will mark a major milestone in the evolution of Corda. The GA release of Corda 5 will be preceded by multiple Developer Preview releases, including different features of Corda 5 to allow developers to have a taste of the brand new version of Corda. It also provides an opportunity to gather feedback from developers before the release of the final product. 

 Corda 5 brings some key architectural changes to simplify and improve various pain points in the previous versions of Corda, such as multi-tenancy, hot-hot HA

Deployments and horizontal scaling. 

One such change is the way we package CorDapps. The new packaging scheme enables Corda5 to have an ‘application first’ approach. The CorDapp packages would contain all information required for running the app,  including which network to join and how to obtain a certificate to join that network. The Corda node becomes a network and identity agnostic Corda hosting environment on which CorDapp packages can be installed.  

New CorDapp Packaging: CPKs, CPBs, CPIs 

To enable the new approach we discussed above, Corda 5 is adopting a new packaging scheme. There are three layers of packaging that are used: the CPK, CPB, and CPI. 

CPK or Corda Package is what individual modules, external dependencies, and third-party libraries are compiled into. Thus instead of a jar file the contract, workflow, and other modules of your CorDapp are now compiled into individual .cpk files. This new way of packaging helps to get rid of dependency clashes between different module artifacts. Thus if you have an external dependency that is dependent on a different version of a particular jar that your project is dependent on, it would not be a problem with the new packaging model. Each Corda Package runs in its own unique sandbox and thus allows multiple versions of a particular class to run at the same time. 

CPB or Corda Package Bundle is a collection of multiple .cpk files amalgamated into a single unit. Essentially a CPB is what we call a CorDapp in Corda 5. All artifacts that form a Cordapp are packaged into a single .cpb file. This allows developers to define a CorDapp as a single unit, which they can unit test, can pass on to QA, and finally deploy to production. It also helps in managing different versions of a CorDapp as it no longer consists of scattered pieces of different artifacts but a single .cpb file. 

As we mentioned earlier a Corda hosting environment (or the Corda node) is now network and identity agnostic. So, where does this information come from? This is where the CPI or the Corda Package Installer comes into the picture. The CPB represents a single Cordapp but it doesn’t have any identity or network information. A CPI is an installation unit on a Corda hosting environment. It links the CorDapp to the network and thus contains all information required such as trust-root and information on how to acquire a certificate to join a network, to onboard a node onto a particular network. The CPI vastly simplifies the process of onboarding a party onto a network. All you need to do is drop a CPI onto a host (node) and it’s all done. The information for onboarding is encapsulated within the CPI. 

Note that the CPI is not part of the Developer Preview, it will be released with the GA release. 

 That’s how the new packaging model of CorDapps would look like in Corda 5. I hope you enjoyed the article, thanks for reading.