Corda: Corda's behaviors on implicit upgraded states

Question

Does Corda enforce that implicit upgraded states aren't downgraded?

https://github.com/corda/corda/pull/4741/commits - this removed the downgrade rule enforcement - I think any ideas why this was removed?

Answer 1

You can downgrade states to older versions of a contract, yes.

We made some attempts to fix this in Corda 4 but had to back off. It's one reason why C4 took a bit longer than we'd hoped.

The problem is related to rolling upgrades. During a rolling upgrade of an app, some nodes will be using old versions of the app and some nodes will be on the new version. When an upgraded flow takes a state of V1 from the vault it will presumably fill out a new field or do something different to produce a V2 state. The transaction creating the V2 state will use the V2 smart contract and get sent to a node that's still on V1. Now this is OK because the new smart contract logic will be attached to the transaction, sent to the peer over the p2p network and executed if it's whitelisted (or in future, run inside a sandbox). But that's only true for the contract logic, not the flows, which are allowed to do much more. So the older node will then take the V2 state from the vault, and construct a transaction that attaches and uses V1 of the app because that's what it's got installed.

What this means is that during the upgrade period where both V1 and V2 of an app are live simultaneously, data might be repeatedly upgraded and downgraded until the upgrade is complete. It's inherent in the nature of passing bits of data around between different parties who can upgrade at different times. Therefore we can't protect the user from downgrades because we don't know when the upgrade is considered to be complete.

In future we might make another attempt at tackling this problem. For now, downgrade protection can be implemented at the app level by using sentinel fields.