Decentralized party with confirmation threshold > 1

App Development
1

Hello team,

For a decentralized party, when setting the partyToParticipantMapping with confirmation threshold > 1, we cannot submit the transaction even through the submission node.
The docs here Decentralization - Canton Network Docs stated that:


Parties with a threshold greater than 1 in the PartyToParticipant mapping cannot submit Ledger API commands. This is because command submissions always go through a single Participant Node and there is no cryptographic link between the party’s submission and the resulting transaction

A bit confused re “there is no cryptographic link between the party’s submission and the resulting transaction”.

Say we have a decentralized party alice::<name_space_c> where name_space_c is computed from local_name_space_a generated on participant1 and local_name_space_b on participant 2 and there’s no partyToKeyMapping with a confirmation threshold of 2.

If participant1 has submission right for alice::<name_space_c>, wondering why can’t the transaction gets signed by local_name_space_a’s private key that sits on participant1 and verified by participant2 that it’s indeed signed by local_name_space_a on participant1 with local_name_space_a’s public key stored on the network?

Wondering if anyone can help to clarify above. Thanks so much in advance.

2

I have chatted with Gemini and seems to provide quite a valid point of view:

  1. name_space_a’s and name_space_b’s keys are not relevant in both ledger command submission and confirmation response. The participant’s own operator key is the one that signs both ledger submission and confirmation. name_space_keys are only used to sign relevant topology transactions.

  2. In our scenario with confirmation threshold = 2 in partyToParticipant mapping, it actually implies that for this decentralised party, we need at least 2 participants’ signature (signing with the PN’s operator keys) for this command to be considered valid

  3. Say if today we allow such commands to pass through the network:
    Participant1 faced a dilemma: “alice wants me to submits this, but the security policy says it requires 2 nodes to sign off on the intent. As a single node, I cannot unilaterally prove to the network that alice actually wants this.”
    Even if Participant1 submitted it, Participant2 faced a dilemma as well: “Did the real alice actually submit this command to P1, or has P1 been hacked/compromised by an insider who is fabricating this transaction to steal Alice’s funds?”
    Because we set the confirmation threshold to 2, the explicit security requirement is that no single participant node should be able to unilaterally move alice’s assets. If P2 blindly co-signs the transaction simply because P1 signed it, then P1 effectively has a threshold of 1. The entire decentralized trust model collapses, and P1 becomes a single point of failure for alice.

    Hence this kind of command is reject locally on PN1 before it even got submitted to the network following below check flow:

    1. Check the Party: P1 looks up alice::<name_space_c> in its local topology cache
    2. Check the Threshold: It sees that Alice’s partyToParticipantMapping has a confirmation threshold of 2.
    3. Check the Submission Type: It recognizes that this is a standard Ledger API command, meaning there is no external cryptographic signature attached from Alice’s private key.

    I think above explanation seems logical and correct, but will be awesome if anyone can help to double confirm the correctness.

    Thanks so much in advance!

3

Hey @Judy_Wu Confusion is understandable because the signing analogy is intuitive but doesn’t map to how Canton’s transaction protocol actually works…

AFIK, Ledger API submission doesn’t just need a cryptographic signature from the submitting party. It needs confirmation responses from every participant hosting a signatory of the transaction.

I’d check as per above a decentralized party with confirmationThreshold = 2 both participant1 and participant2 must send a confirmation response to the mediator for any transaction where alice is a signatory. This requires both participants to independently validate the transaction proposal.

I do suggest checking with LLM at the new better unified Canton Docs: https://docs.canton.network/

also from what I know in custody info too, there’s no mechanism in the current protocol for participant1 to “speak for” participant2’s confirmation, even if it holds a valid signing key.

so…yeah i’d say decentralized parties that need to submit Ledger API commands keep confirmationThreshold = 1. Use threshold > 1 only when you want multi-participant confirmation for receiving/confirming transactions

4

Hey @Judy_Wu

The answer from Gemini is pretty much on point, for local parties and a confirmation threshold > 1, we can’t trust the submitting participant to be the only one authorizing the submission, and so transactions cannot be submitted.

This is not the case for external parties however, where the authorization comes from the external party’s signature, not the submitting node.