Hi
I assume the participant nodes wont change in such situations, how does one go about migrating a domain from one underlying ledger to another?
thanks
Hi
I assume the participant nodes wont change in such situations, how does one go about migrating a domain from one underlying ledger to another?
thanks
Hi Vivek,
There’s no direct support for migrating the domain data from one infrastructure to another. However, as all relevant Daml data rests at the participants anyway, you can simply transfer the Daml contracts from the old Canton domain to the new one, using Canton’s preview feature for multi-domain support. In detail:
Dold
.Dnew
.Dnew
.participantX.transfer.execute(stakeholder, contract-id, Dold, Dnew)
Dold
.Then you can dismantle the old domain Dold
if you wish.
Step 4 must be currently run for each active contract once. So this probably does not scale to huge sets of active contracts. But this is merely an engineering issue; the fundamental idea can be made to scale (provided there is enough demand to warrant the engineering effort).
Hello Vivek and thank you for your question.
In addition to the answer by Andreas there is another way to look at the scenario in question:
Your intuition that the participant nodes don’t have to change is good although I see two ways to approach this based on two slightly different scenarios documented in the Operational Processes section of the canton manual:
Best regards,
– Oliver
Hi, I have a related “Canton newbye” follow-up question: contracts migration is needed because a contract pertains to a domain.
According to my understanding of the white paper, though, a contract does not really “reside” in a domain (which is essentially messaging infrastructure) but is rather associated to one: what is this association used for?
If you want to dive into composability, please have a look at the corresponding tutorial: Composability — Canton 1.0.0-SNAPSHOT [0J documentation
You are right that the contract does not reside on the domain. Rather, the domain is the currently agreed synchronisation point of the stakeholders. Effectively, when deciding about a valid state, we need to establish an order of attempted changes, and that’s done by having the domain order the encrypted messages such that every participant receives the transactions in the same order.
The agreement that a certain domain is responsible for the ordering is a temporary one and can be changed by a transfer.
Cheers,
Ratko
Thanks @Ratko_Veprek! I’ll go through the tutorial (and possibly come back with more questions).