I was thinking about the upgrade scenario of a multi signatory contract where one party is the provider of a service. Imagine that a service provider
creates an agreement with other users along the lines of
template UserRole
with
provider : Party
user : Party
where
signatory user, provider
controller user can
RequestToDoStuff : (ContractId RequestForDoneStuff, ContractId WorkProcessOrder)
with
input : Text
workId : Int
do
w <- create WorkProcessOrder with ..
r <- create RequestForDoneStuff with ..
return (w,r)
where WorkProcessOrder
is a contract signed just by the provider
to track the work order that user
witnesses (“don’t worry, I’ll be busy doing this thing”). The provider
might create this contract to track the evolution of the work that user
requests, but to hide the process from them (ex. the process is proprietary, or maybe just private to provider
). The intent being that once they’re finished, they can exercise a choice on RequestForDoneStuff
.
Now the provider
is innovating and has come up with a new process and wants to update this contract. The standard upgrade story is ok, but it can be onerous for the provider
as they have many users and many orders. Supporting two processes, let alone any not upgraded contracts and previous processes, will stifle the innovation that provider
provides. So what does provider
do?
Of course they berate their Daml developers (DA CX engineers, obviously ) who originally wrote RequestToDoStuff
for including the creation of WorkProcessOrder
in the first place. Question, wouldn’t it have been better to leave that create off in the first place and replace it with a trigger? To which that developer mumbles back that Daml’s composable, atomic transactions, less code to maintain, boo triggers…etc. We should obviously think a little bit about the future evolution of our code, but it seems particularly relevant to think about what templates might be upgrade and the ease of doing that.
When I consider this scenario, I think that there’s one weak rule of upgrades that single parties should be allowed to impose on other parties within a multi-signatory setting: A party P
should be able to upgrade a contract from template T1
to T2
if there’s a 1-1 mapping between the choices in T1
to T2
, and for a choice C
, P
can change what contracts CP
witnesses within C
(and nothing else). If CP
witnesses WorkProcessOrder
they still just witness it; they cannot be forced to be an observer or signatory. I call this the weak
version as I am not convinced of any of the stronger versions, so let’s start here. Obviously, this is just a proposal, what do you think?