Multiparty transaction between multi-domain network topology

Questions
1

“Since different domains have no common notion of ordering on its messages, reconciling atomicity with resilience can become impossible. Thus, Canton allows cross-domain transactions whenever there exists a single domain that all participants in a transaction are connected to.”

(From Canton whitepaper, page no. 11, section: “Multiple domains and global composability”)

I’m having the following questions/thoughts about the above sentence extracted from the Canton Whitepaper. Please help me with my understanding.

  1. How realistic it is to convince (ask) all participant nodes from different domains to join a particular single domain from where the transaction would be initiated?

  2. I would see this as distressing the particular domain by onboarding many participant nodes to achieve transaction atomicity and consensus. At the same time, I’m a little worried that it should not end up becoming the network (domain) centralization/bottleneck.

  3. Are we forcing the party/participant nodes to handle multiple identities and cryptography assets required for joining the multiple domains?

  4. Are we not overhead parties from other domains to adhere to additional governance and rules of the new domain?

  5. In real business, there could be N numbers of other domains that participant nodes have to join to design M numbers of multi-party transactions - isn’t it looking like a costly affair in terms of operational risk?

2

Hi balajimoresyne,

Thanks for your excellent questions. I hope the following answers clarify them:

  1. The key point here is that only the participants involved in the transaction must be connected to a common domain. Participants that do not host any informee party of the transaction need not be connected to the common domain. In a typical deployment, there are many participants connected to a domain, but only a few are actually involved in the transaction. (Unlike in traditional blockchain setups, participants do not need to validate all transactions.) Now, for those participant involved in the transaction, they hopefully have some business incentive to be part of the transaction, and this incentive should be enough to convince them to join a common domain for the particular workflow that needs to be organized. Note that the common domain can be chosen independently for independent business workflows.
  2. Participants can connect to and disconnect from a domain at any time and the topology is therefore dynamic. In practice, however, the connections between a participant and a domain should be long-lived. If a business use case warrants the effort to join a new domain, then this is possible; but hopefully the business use case is not just a one-off for a single transaction, but applies to many transactions over a long period of time. So the onboarding effort for new participants when a new stream of use cases arises should be negligible compared to the load generated by actually executing all the transactions arising from this use case.
    In terms of dynamics, this network effect makes domains with many connected participants more attractive than isolated islands. So there is the risk of excessive centralization and therefore a bottleneck. However, a domain operator has no monopoly on a particular type of transactions. So if the involved participants note that centralization leads to poor service, e.g., due to a bottleneck, they can agree to switch to a different domain with better service.
  3. No. The parties and participants can use the same identities on multiple domains. If the participant wishes, it can register different cryptographic keys with different domains, but this is not necessary.
  4. I have trouble to understand your question. What do you mean with “overhead”? Please clarify.
  5. The participant operator indeed has some overhead when they decide to join a domain; at the very least, they should due their due diligence, as a participant connected to a domain trusts the domain to a certain extent. So a business will do so only if the expected benefits from the new use case exceed those overheads. As said above, for a one-off transaction, this is likely not worth the effort, but it may well be if there are many similar transactions between the same participants. Note that a single participant can host many parties (and thus serve many end users), so even if each end user is part of only a few of those transactions, the participant will be involved in many of them.
3 Likes