Command Deduplication for Multi-Party Submissions

Questions
1

The documentation for command deduplication states the following:

A command submission is considered a duplicate submission if the ledger server receives the command within the deduplication time of a previous command with the same command ID from the same submitting party.

The documentation for the Commands protobuf is a bit more precise (or at least I hope it’s more precise and not inconsistent) and mentions that the application id is also included.

This identifier should be unique for each new command within an application domain, i.e., the triple (application_id, party, command_id) must be unique.

However, the documentation does not explain how this extends to multi-party submissions with multiple submitters (i.e. parties in actAs). I see two possible implementations:

  1. For the purposes of deduplication, it behaves as if the same command id was used in separate single-party submissions for each party in actAs.
  2. Multi-party submissions don’t interact with single-party submissions. They behave more as if the set of parties was a single completely different party and only interact with other multi-party with the same (unordered) set of parties when it comes to deduplication.

I assume it is probably 1 but I couldn’t find any documentation so asking here :slightly_smiling_face:

4 Likes
2

It’s 2 actually. The deduplication key is the triple (application_id, submitters, command_id), where submitters is the set of submitting parties (act_as + party). I have made a note to improve the documentation.

As a side note, the participant server implementation sorts the submitting parties by name and stores the result as an SQL array. It then uses a simple array equality when checking whether a deduplication key exists.

1 Like
3

@Robert_Autenrieth thanks! I assume the partiicipant also deduplicates before sorting so order and duplicates are both irrelevant and it’s treated as an unordered set?

4

Yes, it’s treated as an unordered set.

That applies to all multi-party related functions - parties in command submissions are normalized as a first step:

  • The legacy party field is added to the actAs field
  • actAs parties are converted to an unordered set (i.e., an instance of scala.collection.immutable.Set)
  • readAs parties are converted to a set, and actAs parties are removed from that set (because actAs implies read access)
1 Like