Backwards Compatibility provided by Corda
Let's explore some mechanisms through which Corda preserves backwards compatibility.
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 ...