Hosting multiple party to Canton Participant Node

Hi There,

I was looking at the Canton network setup, where we have a participant node that helps to participate in a network, create/update the transactions, and talk to the Canton domain for ledger sync and consensus on behalf of the party/entity hosted on it. So there are some following questions where I was struggling to understand the behavior:

  1. The Canton Participant node can host multiple parties/entities on it then how is its data being created/shared and stored in DB? and how it reads the data for the particular entity?

  2. How does the Canton participant node manage the Public/Private key pair (which acts as a cryptographic identity for a party) for every party hosted on it?

  3. In a multi-party hosted environment, how the transactions are processed by the participant node when there are multiple clients interacting with it?

  4. How efficiently it is possible to migrate the ledger of a party from one participant node to another?

  5. Can you help with the documentation of the pre-defined DB schema used in persisting the ledger in the Participant node?


Hi @balajimore ,

Canton nodes can host multiple parties, and parties can be hosted on multiple Canton nodes. At the Canton protocol level, the “views” of the transaction are encrypted and distributed per participant node, not per party. The participant stores its views of the transaction in the local participant database and annotates and indexes them so that it can serve the APIs which allow for querying by templateId and party. So the short answer to 1. is that it uses SQL indices to filter data appropriately.

In line with the above, it’s participants, not parties that have a cryptographic identity on the ledger. When you see a party id like alice:abc123, the abc123 part is the fingerprint of the namespace root key of the namespace abc123. Via delegation chains, that namespace root key can allow other keys to read or write data for that party. So lets say via such a delegation chain participant P is allowed to read and write for party alice:abc123 at offset O, and the there is a transaction involving alice:abc123. The submitting node Q (as well as everyone else) knows that P hosts alice:abc123 so it’ll encrypt the party’s views so that P can read them using P’s decryption key. P then sends a confirmation signed by P’s signing key.

I’m not sure what you are asking specifically in 3. Canton Enterprise nodes are fully multi-threaded. They’ll process transactions for multiple clients in parallel in a first come first serve fashion.

You can migrate parties from one node to another as per this piece of documentation.

We don’t currently document the participant node’s internal DB schema, but if you are interested in it, you can find it here, including version to version migrations.

1 Like