Skip to content
Discussions/App Development/Offsets, commands, transaction and events, oh my!Forum ↗

Offsets, commands, transaction and events, oh my!

App Development3 posts318 views1 likesLast activity Feb 2023
LU
LucianoOP
Feb 2023

Are the below statements about the relationships between identifiers correct?

  • Offset <=> Transaction
  • Transaction => Command (but Command does not imply transaction, as it could be rejected)
  • From the above two statements, Offset => Command
  • Transaction <=> Events

If true, then why do we need to have separate identifiers for offsets and transactions?

Somewhat related:

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 …
BE
bernhard
Feb 2023

Transactions and transactionIds are part of the shared ledger. Transactions are (partially) ordered, but transactionIds are not.

Commands, offsets and eventIds are participant-local, ie are different from participant to participant.

Commands are essentially a correlationId between API request and completion, which are either transactions or rejections.

Offsets are a local totally ordered index into all the orderable things which includes both transactions and rejections. They are primarily useful for features like command deduplications. They are like “block height” on blockchains, but because there are no blocks and there is privacy, they are local to participants.

EventIds are like the “index” in a block on a blockchain. As with offsets, because there is privacy, the index is different from view to view so is participant local.

LU
Luciano
Feb 2023

Thanks for taking the time to reply … but :face_with_spiral_eyes: let me try to unpack this; there are a couple of things here like ordering, locality and the relationship to public blockchains to which I can’t see the direct relevance to. Let’s start with the relationship between the different types of IDs [edit], and talk about the abstract/global ledger [end edit]:

Luciano:

Offset <=> Transaction

bernhard:

Offsets are a … ordered index into all the orderable things which includes both transactions and rejections.

So I would take this as: Transaction => Offset, i.e. there is a unique offset for each transaction, but not necessarily a unique transaction for each offset (because it could be a rejection instead). Right?

Luciano:

Transaction => Command (but Command does not imply transaction, as it could be rejected)

bernhard:

Commands are essentially a correlationId between API request and completion, which are either transactions or rejections.

So my statement is correct here, right?

Luciano:

From the above two statements, Offset => Command

This statement still follows from the first and second. But can I go further and say that there exists a unique offset for each command and vice-versa, i.e. Offset <=> Command Id?

Luciano:

Transaction <=> Events

bernhard:

[Offsets] are like “block height” on blockchains … EventIds are like the “index” in a block on a blockchain

So here you’re stating a relationship between offsets and events, rather than transactions and events? Does the later still hold? i.e. if I give you a transaction, you can tell me which events correspond to it, and vice-versa? (I’m sorry but the blockchain analogy is somewhat lost on me - I’m not that familiar with how they work).

Finally, going back to your points about ordering, the difference between an offset and command ID is that the former has ordering guarantees, whereas the other doesn’t (it’s up to the user to enforce these)?

← Back to Discussions