When to drop ReqTx and other Network events

[ffakenz]

Context

Opening discussion based on comments on PR to fix ISSUE

Summary

We don't like the approach of a TTL for NetworkEvents, especially because transactions already carry an expiry date so it is in principle possible to know whether a transaction has passed or not. Obviously, this demands to support time in our L2 ledger, but I think it kills two birds and one stone. Furthermore, we do now have a notion of time in the head logic coming from the chain layer; so it is possible (albeit imperfect) to stream that time down into the ledger L2 and before re-enqueuing a transaction we can simply ask the ledger whether a transaction is expired based on its validity interval upper bound. If it isn't, then we drop it.

This also assumes that clients do set a TTL, without which the transaction is infinitely re-enqueued. At a later stage, we can imagine keeping track of past UTxO (now spent) in some kind of data structure, e.g. a bloom filter to remain constant in size, to provide a probabilistic answer to the question: should we re-enqueue that transaction? If any of its inputs was seen in the past, there's no point re-enqueuing it as it will never be valid.

Now that we have the Tick, clients can submit transactions with bounds. And perhaps we could track consumed UTxO in order to detect an "impossible" transaction,

[ch1bo]

The rationale in the summary and linked comment makes sense to me. I also think that adding a TTL should not be necessary, but we should leverage the ledger.

Idea: Improve the Ledger tx interface by adding another case to ValidationResult = Valid | Invalid | InvalidForever where implementations should use InvalidForever when a transaction will never be valid (anymore).

The cases for InvalidForever are already listed above, but let's summarize:

1. The tx validity upper bound is in the past (time is monotonic)
2. One of the inputs has already been spent (need to keep track of past inputs)

That way, the used ledger decides when / how long to re-enqueue transaction (requests).

[ch1bo]

An alternative could be to not bother and require the application to re-submit transactions when they are not included in a snapshot within an application-specific time. That behavior would mirror the one of a cardano-node more closely as there is no guarantee of inclusion of a transaction even when submitted to peer nodes.

[ghost]

that's actually what the initial TTL proposal was kind of hinting at. Of course, the TTL was hard coded but it seemed much simpler than fiddle with upper bounds, time translation, and other niceties. Perhaps it could be as simple as one of:

• adding a TTL flag to the hydra-node
• adding a TTL flag on the newTx command from client

[ch1bo]

My point here is rather: The client should do the bookkeeping whether another NewTx request is required if the transaction is in principle TxValid but never shows up in a SnapshotConfirmed.

No TTL, no logic in the hydra-node.

This also matches the UX you currently get from the cardano-node and might be good enough?

[ghost]

Ah I see what you mean. That's even simpler so I would be tempted to favor that solution :)

[ffakenz]

I like the idea to follow the same approach as the cardano-node.