Contract Upgrades & Constraints in V3
With Blockchain and smart contracts being such uncharted territory, it’s inevitable that at some point we’ll find our contracts contain bugs (remember the DAO or Parity Wallet hack, anyone?). Or perhaps we didn’t capture all the functional or business requirements, or the regulatory landscape changed.
As such, we’ll need to look to our old friend, the upgrade.
I want to spend most of this post talking about the new upgrade functionality in Corda V3, but it’s almost obligatory to first talk about how Bitcoin and Ethereum carry out upgrades.
Bitcoin being purely a distributed ledger for recording balances with very primitive smart contract functionality, the protocol is decided entirely by the core code that everyone runs. As and when the development team release upgrades, users of Bitcoin vote on the code change by either updating to the new version or not. If enough users update, that becomes the new accepted network. Upgrading this way is perhaps, in theory, the simplest method in the blockchain world as everyone is fundamentally running the same software. In practice, it’s one of the hardest.
Ethereum with its ‘Smarter’ contracts is somewhat closer to Corda. Once a smart contract is deployed on the Ethereum blockchain, it is final and cannot change — essentially enforcing the idea that “code is law”. Typical workarounds for this make use of a versioning system, whereby another contract sits in front of the actual contract containing the business logic and is used to forward requests to the correct version of the contract.
Now, if you’re reading this, you’re probably familiar with states and contracts in Corda and how how Corda uses contracts to separate the rules of how a state can change over time from its definition. I would probably take a punt you also know Corda states only evolve (or to be more precise, consumed/created) once verification has taken place within a transaction. Right?
For many reasons, multiple implementations of a contract with the same method signature and enclosing class can exist at any one time. For example, on finding a bug within the current implementation of a cash contract in a two-party network with Alice and Bob. Alice wishes to upgrade to a fixed version immediately while Bob must first run through a series of internal testing procedures which could take days; we now have two versions on the network (Thanks, Bob!).
In contrast to other blockchains, Corda has two built-in capabilities to allow for easy contract upgrades, by leveraging the ‘contract constraints’ functionality. If ‘contract constraints’ are a new concept to you, think of them as a means to constrain which implementations of a contract from the universe of contract implementations can be used. The upgrade routes are termed explicit and implicit.