Automatic transfers to different domains - how is the domain chosen?

Questions
1

I’m following the composability example here.

My question is when the painter accepts the paint offer, how does his participant node know that the IOU domain is the suitable domain to use (ie all parties to the PaintOffer.Accept transaction are hosted by participant nodes connected to the IOU domain)?

My understanding is that each domain topology manager knows the parties hosted by a given participant, and that this information is shared to the participant nodes. So I am guessing that this information also includes the associated domain? That way the painter’s participant node would be able to ascertain the domain to use. Is that right or is something else going on?

I understand that there are criteria for choosing a domain, but these seem more about choosing a domain when more than one is available. My question is how is that list of potential domains identified in the first place? Thanks!

2

Hey!
When we say that a party Alice is hosted on a participant P1, this is not the end of the story. What we should say is that “Alice is hosted on a P1 on domain D1”: this is because every topology transaction is for a given domain. In terms of topology transactions:

  • ParticipantState: indicates that a participant is hosted on a domain
  • PartyToParticipant: indicates which party is hosted by which participant
    The two combined gives the relation that I mentioned above.

You have the same story for the vetted packages: they are communicated by topology transactions and as such are per domain.

You usually don’t notice this “per domain story” because if you enable a party on a participant P, then will try to host (i.e., submit the corresponding PartyToParticipant topology transaction) to each domain it is connected to and to each domain it connects to in the future.

To answer your question, a domain is suitable for submission if:

  • The required packages are vetted.
  • The topology is correct: all informees of the transaction need to be hosted on the domain and the parties which need to confirm have at least confirmation rights.

I hope this helps.

Raf

3

Thanks @Rafael_Guglielmetti that helps. So referring back to the painter example, the painter’s participant node can use the combination of ParticipantState and PartyToParticipant transactions to determine the domain to use?

I read though that the use of automatic domain selection is not recommended - is that correct? If it is then how should the submitting participant determine the domain to be used? Does it have to be told via some off chain communication that occurs between all the participants involved in the transaction?

4

So referring back to the painter example, the painter’s participant node can use the combination of ParticipantState and PartyToParticipant transactions to determine the domain to use?

Yes, correct: the ParticipantState is about participant->domain while PartyToParticipant is about party->participant (on the corresponding domain). So somehow, the two give you party->participant->domain.

I read though that the use of automatic domain selection is not recommended - is that correct?

Where did you read that ?
In general, it is worth keeping in mind that multi-domain on 2.x is not production ready (and so the domain selection is not neither). I think the heuristics in the automatic domain selection are not too bad for now. They will be improved as part of the 3.0 release. If you don’t want to rely on that, the submitting participant can submit a domain during submission. Note that in that case, the domain must be admissible (package vetting and topology); if that’s not the case, then submission will fail.

Hope this helps.

Raf

5

I think it was an internal doc actually, have shared with you offline. Maybe that is out of date.