POSIXTime vs Slot

[mmontin]

Currently, MonadBlockChain allows for handling time through slots and milliseconds API wise, although there are only Slots internally. This means that currentTime 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 in POSIXTimeRange, and thus can awkwardly overlap with slots. There is some investigation to do there, including the following inquiries:

• why did we do it like this in the first place?
• should we only reason in terms of slots?
• how to handle transaction validity range then?

[carlhammann]

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.

[mmontin]

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?