Offsets, commands, transaction and events, oh my!

[Luciano]

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:

CommandId, workflowId, transactionId, eventId and contractId

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 …

[bernhard]

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.

[Luciano]

Thanks for taking the time to reply … but 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)?