Closed mmontin closed 1 year ago
So, here's one observation: The Cardano transaction contains a range of slots, and the millisecond times are calculated from the slot number, using protocol parameters. This suggests that we could base cooked on slots completely.
I realise that (milli-) seconds are more intuitive than slots. Since we'll likely have to add a getParams
method to MonadBlockChain
anyway for reasons to do with the upcoming PR that re-introduces an instance for the Contract
monad to cooked, we could use the protocol parameters returned by such a method to write all the convenience functions we like.
It looks like we could base everything on slots indeed, including the validity range of our transactions.
As for having the ability to still support milliseconds, we would have to see if it's useful in practice, because for now, it is very confusing. If we only rely on slots, handling time would be more consistent and would require less helper functions (that currently overflow our MonadBlockChain
) and it would not need access to the parameters. On that note, why would we need them for something else?
Currently,
MonadBlockChain
allows for handling time through slots and milliseconds API wise, although there are only Slots internally. This means thatcurrentTime
will always be either the first ms of a slot, or the last. This is very confusing because jumping by X milliseconds will not bring you at to t + X if t was the current time. In addition, this conflicts with the notion of validity range from transaction that are expressed inPOSIXTimeRange
, and thus can awkwardly overlap with slots. There is some investigation to do there, including the following inquiries: