Smart contracts offer a unique way to solve business problems but also present a unique challenge when it comes to managing the rollout of new and updated smart contract based applications. The ‘Accept-Then-Publish’ approach described below is a way to manage this complexity. The motivation for this approach is to allow smart contract application publishers and those managing distributed ledgers to answer the CTO ask below.
As the CTO of a trade association coordinating the exchange of smart contracts across many independent companies I want to be able to roll out new versions of smart contract applications in a controlled way.
Here, controlled is understood to mean coordinated but not synchronized. Coordinated in that it is reasonable to expect that companies will be able to upgrade their internal systems and roll out new software within a wide time window. Not synchronized in that companies need not upgrade at a fixed point in time in a ‘big bang’ way.
Terminology
In this article a smart contract relates to the rules that govern the creation and valid transitions of smart contract instances. These lifecycle events involving smart contract instances are bundled in smart contract transactions. An application that creates and consumes smart contract transactions is a smart contract application. When improvements are made to a smart contract a new smart contract version will be created.
How Are Smart Contract Applications Different ?
In traditional applications messages are exchanged between systems. These messages are regularly text based, contain data specific to the exchange and are used to update a data store before being discarded.
With this setup companies A and B could agree to update the Order message and it would not matter to company C.
With smart contract applications a transaction is shared. This will usually be as a binary serialization which has been digitally signed by one or more parties. Companies receiving smart contract transactions will verify them before recording them on their local ledger.
With smart contracts transactions a reference to the smart contract that governs which lifecycle transitions are valid is embedded inside the transaction itself. A consequence of this is that it is not possible to alter the smart contract version of a transaction once it has been created.
Problem
Assumptions
- Rolling out a new smart contract version will often require accompanying changes to other business processing software.
- The main driver for taking the updated version is that it provides enhanced utility (as opposed to say patching an exploit).
- The rollout should be performed with minimal down time.
- It is possible for the application to support two smart contract versions in parallel.
- Any migration of smart contract instances from earlier versions to more recent versions will be a follow-on exercise and is not considered here.
Accept-Then-Publish
With the Accept-Then-Publish approach each company will upgrade their application to accept transactions based on the new smart contract version but for a period will continue to publish any freshly initiated transactions using the previous smart contract version. Any transition to a smart contract instance based on the new smart contract version will create a transaction also based on the new smart contract version.
This approach is not completely novel and is inspired by the HTTP Accept header used to advise supported media formats. Another inspiration is the TLS handshake used to determine which encryption algorithm to use when establishing a secure communication link. There are aspects of the version determination that are particular to smart contracts:
- The chosen version must work for multiple parties not just two.
- The chosen version may be based on a wider set of companies than those involved in the initial transaction. For example it may be that the transaction will be disclosed to a number of broker companies later in its lifecycle.
- As many distributed ledgers are asynchronous the choice of which smart contract version to use may need to be made while one or more companies are unavailable or offline.
Discovery
To allow companies to share the versions they support there must be a way for companies to discover which smart contract versions other companies accept.
As we are working with a distributed ledger a smart contract, possibly in Daml, would be an obvious choice to achieve the above.
The corollary of notifying partner companies of newly supported versions is notifying them that support for an old version is being withdrawn. This could be achieved in a similar way by notifying partner companies of an end-of-life support date for a particular version.
Which version a company is publishing does not need to be shared, it is the business of the publishing company to make the decision about which version to publish.
Publishing
The choice of which contract version to publish will depend on a number of factors so different strategies could be used:
Message by Message
In the situation where the contract is not intended to be disclosed to any additional companies the most functional version could be automatically selected just prior to contract creation.
Manually
When the company owner determines that all partner companies now support the most functional version they switch to permanently publishing that version. How this is achieved is an implementation detail, it could be via configuration or web service.
Conclusion
Following the Accept-Then-Publish pattern proposed above our hypothetical trade association CTO has a way to ensure the smooth running of his network across smart contract versions.