Hello, we are currently using the upgrade tool and are looking into a multi-node upgrade. One of my colleagues mentioned that there could be contracts that exist across different nodes, with one party from each being a signatory, for example. Is this possible? My understanding was that all parties to be signatures on a contract need to exist on the node that the contract lives on. Would there have to be a copy of the contract on each ledger? Or would the contract have to be sharded across the different nodes? Or is it in fact possible to have a contract with signatories as party::1234 and party:5678?
Hi, Austin.
Yes! Absolutely. If two parties are signatories on the same contract, and those two parties are hosted on different participant nodes, then the contract will be stored in the Private Contract Store of both participants. In fact, both participant nodes would have been involved in validating the transaction that generated that contract.
Our training materials do a good job of exploring those details of the Daml platform.
Hi Wally,
Thanks for the response! I guess where my confusion comes in is what the contract would look like on one node, for example. If the contract was hosted with my one signatory as Party::1234, would my party from the other node (Party::5678) have to have a “copy” party on the first node? Something like Party_Node2::1234? Or can contracts access parties from different nodes without needed to have a “copy party”.
Also a follow up that introduced this discussion would be then that since both nodes had to validate the transaction, if we were to do an upgrade on one node with that contract would it also get upgraded on the other node?
Great followup questions, @austin.hodges!
No, it does not work like that.
Consider this topology:
Participant1, hostingAlice::1234.Participant5, hostingBob::5678.
Daml enables the definition of workflows that result in contracts which have been signed by both Alice::1234 and Bob::5678. For that workflow to complete, both Participant1 and Participant5 will need to coordinate that workflow through a common synchronizer.
- The synchronizer will take care of distributing the proposed transaction.
- Both participant nodes will need to validate the proposed transaction.
- The participants will be signaled when all the participants have agreed about the transaction’s validity.
- Each participant will then store its own copy of the contract(s) resulting from the transaction.
After the transaction completes, the result will be:
Participant1, hostingAlice::1234.Contract1, signed byAlice::1234,Bob::5678
Participant5, hostingBob::5678.Contract1, signed byAlice::1234,Bob::5678
Even though there is a contract on Participant1 with Bob::5678 as a signatory, Bob::5678 will not be able to query the Ledger API of Participant1. Is that part of your question?
It’s similar to the fact that you have email stored in your email account that has the To: field populated with other email addresses. (Admittedly, the analogy is not perfect since email is not sent From: more than one sender. 
)
Oh ok, I see. My confusion came from the participant node being able to have parties on contracts that were hosted on other nodes. It makes sense, but since I have always worked on just one node in the past I wasn’t familiar with the ability to have parties on contracts that exist on other nodes. Bob being able to query the ledger API of participant1 wasn’t a part of my question, but that is helpful insight. Another follow up to that then would be how do we get bobs party on participant1? I’m assuming that since bob can’t query the Ledger API of P1 then his party doesn’t actually exist on P1, so how are we able to set the Party data type as a value that doesn’t exist? Or that is all handled by the domain sync since it can see all “variables” for all participants that exist within?
You can ask Bob for his Daml party by email or Slack. It’s not a secret like an API key. It is more like an email address.
Or you can query your participant node. It will give you a list of parties – both local and non-local.
Ah ok, so you can input it like text. Gotcha, I was hung up on the functionality in Navigator where you select it from a dropdown. Thank you for the quick response!
1 Like
Canton Getting Started, but with Docker would be a good way to play with this on your workstation. In fact, the step 4 which says, “In Navigator, log in as the bank and issue an Iou:Iou to Alice.” you actually have to copy-and-paste the Daml id for Alice into Navigator. That is because Navigator only displays local parties in its drop-down box.
Great, thank you so much!