CommandId, workflowId, transactionId, eventId and contractId

Questions
,
1

Hi,

Just want to check if my understanding of those ids are correct.

When command(s) are submitted, a command id and workflow id are provided. However, the command id is only visible to the submitter while workflow id is visible to all parties involved.

A submission can contain multiple commands and each submission is atomic. Each submission has one command id and one workflow id. The submission will result in one transaction id (is this assumption correct?).

Each transaction id can link to multiple event id and each event id links to a state change of a contract (creation of archive). And for all the events in that transaction, it will share the same offset.

So it looks like this…
1 Submission contains (1 workflow id, 1 command id ) → 1 transaction id → many (event id, contract id)

2 Likes
2

Looks basically alright, with a couple of remarks.

  • Events ids apply to any event, including non-consuming exercises.

  • About workflow ids I would add that they are optional identifiers that tie together multiple submissions that logically belong together in a single business process that needs to be divided in multiple submissions (e.g. a proposal/accept pattern).

  • There’s also an application id which is mandatory to send commands because it’s the handle used to read completions for a specific application.

  • About the statement that “the command id is only visible to the submitter”, if you know the application id and you’re properly authorized you can read the completions related to that application id and that includes the command identifier. In practical terms that in most cases that fully overlaps with “the submitter” but I wanted to point out that it’s not necessarily the case.

2 Likes
3

Thanks @stefanobaghino-da. In terms of item 3, does the ledger api or the ledger actually remember the application id and completion offset so that the application can resume without subscribing from a specific offset?

1 Like
4

No, keeping track of the latest observed offset is a client-side responsibility. This allows clients to recover from crashes without adding weight on the participant node.

2 Likes
5

In regards to application id, in a shared ledger, does it require uniqueness? If not, does it affect command dedup? (i.e. does the command dedup check application id?)

1 Like
6

Commands are deduplicated based on the triple (commandId, applicationId, submitters), similarly you get completions for the application id & the submitters you request.
There is no hard constraint on application ids having to be unique but using different application ids for different apps submitting as the same set of parties allows those apps to differentiate between commands they submitted and commands another app submitted as the same parties.

3 Likes