Support timed transactions

[ch1bo]

trafficstars

Why

We want to have support for transactions with validity ranges (Figure 3, page 10 in Alonzo spec). This is the only piece of the Alonzo specification which is currently unsupported.

What

The hydra-node should not reject transactions with a lower or upper validity bound set. For that i will need access to a current slot when applying transactions to its ledger.

As the Hydra Head is "isomorphic", having the slot only update when the layer one progresses is fine. i.e. A transaction will be valid on the L2 if it would be valid on the L1.

While a more granular resolution on time (not only on each block) would be possible using wall clock time, this is out of scope for this feature. We will add that later.

How

• Based on the design in ADR20
• Chain layer informs head logic when time progresses by providing a UTCTime + Slot
• Head state stores a current UTCTime + Slot
• Add current time + slot to GetUTxO query response and to the TxValid, TxSeen server outputs.
• Evaluate transactions in Head using current slot

To be discussed

• Convert UTCTime -> Slot or provide UTCTime + Slot from chain layer?

• ~~Dependency: Tracking time is also required to properly implement contestation logic and improves protocol behavior (TBD: timeout of Hydra protocol transitions)~~

• Isn't there more to this? Especially as there is a even a section in the Hydra paper appendix about complications with time (or are we good because we do the "coordinated" protocol)?

• This is only a hydra-node change and does not require any modification of the on-chain protocol..right? Yes

[ch1bo]

Some notes in tracking time

• We may not receive blocks for some time -> dead reckoning required
• Block times are only ~20 secs on mainnet -> we probably want a higher fidelity in "current slot" on our internal ledger
• Ouroboros praos is relying on a global clock anyways -> use NTP as well and just bridge those gaps?

[ch1bo]

As we see user requests & asking about this we decide to prioritize this a bit higher, aiming for doing this within scope of a 1.0.0 hydra-node.

[ch1bo]

Came across this limitation when trying to fix when ReadyToFanout messages are sent out. Our internal notion of slots (or time in general) is lacking and it's not easy to find the right time when the fanoutTx could be posted (e.g. in e2e tests).

If we track progress of time (in slots) on every seen block, we could also replace the Delay on some wall clock time for ShouldPostFanout with a Wait checking whether enough time has passed against the time passed on chain. We still might want to have a greater fidelity on the internal ledger though. (USP?)

[ch1bo]

This has been mentioned as good to have by @Quantumplation. A first version which just uses L1 time would be sufficient for them (which we now have since #483).