Backwards Compatibility provided by Corda

Corda is a very interesting case study from the perspective of backwards compatibility.

In a distributed system, the various nodes of the system might be running different versions of the software. In many cases, the software is deployed incrementally to them and not in a single step. There is an additional challenge in a decentralized system because different organizations now control the various nodes of the systems so that these discrepancies might last longer.

Corda provides a lot of different mechanisms to preserve backwards compatibility in different areas, so let’s explore some of them.

API & ABI backwards compatibility

Corda provides API & ABI backwards compatibility for all the public APIs available to CorDapps. It means that any CorDapp should run in future versions of the platform without any change or re-compilation.

Similar to other applications, CorDapps are expected to evolve, which might involve:

• Changing the structure of data exchanged between nodes
• Changing the structure of data stored in the ledger (e.g., states)

Changing the structure of data exchanged between nodes

The serialization framework provides some support for the evolution of this case.

Example: Adding nullable properties

Nullable properties can be added to a class, and the framework will take care of the associated conversions. A node running an older version of the CorDapp will ignore this new property if data is sent from a node running a newer version of the CorDapp. A node running a newer version of the CorDapp will populate the property with null when receiving data from a node running the older version of the CorDapp.

Example: Removing nullable properties and adding non-nullable properties

Removing nullable properties and adding a non-nullable property is also possible by providing a default value. However, the serialization framework does not allow this form of data loss for data that persisted in the ledger, such as states and commands.

Since states can evolve and the ledger might contain states from many earlier versions of a CorDapp, newer versions of a contract need to contain appropriate logic that can process states from earlier versions of the CorDapp.

The contract logic for handling states from version $v_i$ of the CorDapp can be removed by a subsequent release of the CorDapp only after all unspent states in the ledger are from version $v_j$ of the CorDapp, where $j > i$.