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.
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.
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.
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:
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.
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.
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.