- Cardano is working on bringing an effective solution to the on-chain time handling based on validity range and slot range.
- Here’s how smart contract and scalability solutions like Plutus, Marlowe, and Hydra can handle this effectively.
The Cardano blockchain recently published detailed reports regarding the time handling done by the Ouroboros consensus protocol. The protocol propagates minted blocks to all the nodes in the system, in a timely manner. As a result, time requires the construction of a globally acceptable representation for consensus.
In the latest blog post, Cardano’s parent group Input Output Global (IOHK) explains how the Plutus scripts can do time handling in an effective manner. The Plutus scripts will get access to the transaction validity range as defined by its creator.
The creator gets the flexibility to define the validity range such that any transaction will be valid from slot X to slot Y. It will leave either one or both the bounds undefined. But it also brings the constraints of including a transaction in a particular slot. The official announcement notes:
The script can assume that the actual time of validation is in this range. Otherwise, the transaction will fail in phase 1 before script execution. This ensures determinism since the script will always see the same piece of information (the validity range) regardless of when the script is validated, so the behavior will be the same.
The limits of validity interval happen in real-time (POSIXTime), instead of slots. Besides, the conversion of slots to real-time happens via a consensus. Cardano explains that using real-time instead of slots is important since slot lengths can change at a hardfork. Thus, assumptions based on slots are more or less unreliable.
Use Cases of Time Handling in Hydra and Marlowe
To compute and enforce its contestation deadline, the Hydra protocol is dependent on the safety mechanism. Using UTCTime, the Hydra Head state machine tracks the passage of time. However, the final tick comes from the chain based on the slot number observed from blocks produced by the chain.
By using the UTCTime, Hydra addresses the limitations inherent in the slot-to-time conversion imposed by the validity window. The announcement notes:
One cannot convert a slot too far in the future, which means that it is simpler to use UTCTime off-chain and only do conversions when submitting/receiving transactions to or from the chain. This implies that the tick’s granularity is roughly 20s, as this is the expected frequency at which blocks are produced.
As a result, Hydra can react to the protocol-relevant crossing of the contestation deadline.
On the other hand, Marlowe is a domain-specific language responsible for writing financial and transactional contracts. It also supports non-financial contract types such as token swaps, auctions, and even games. Cardano’s existing mechanism of time-handling dovetail effectively with Marlowe’s semantics. It offers Marlowe transactions with locality combined with the determinism inherited from Plutus.
Cardano Notes: In Marlowe, the contract’s time typically appears in the deadlines and timeouts that constrain how the execution of the contract evolves, and this works perfectly with Cardano’s validity intervals. The timeout logic is needed in a loan contract, for example, to handle the situation where a loan payment is missed: then different logic needs to be executed in order to impose a penalty, adjust the schedule of future payments, etc.
The Solution
During transaction validation, Cardano is looking to provide more accurate time-related data which includes the timestamp from the block producer at which the block was minted. It can also show the actual timestamp in UTC with the precision of milliseconds.
Subscribe to our daily newsletter!
No spam, no lies, only insights. You can unsubscribe at any time.
But this would break protective determinism on protocols that no longer include this feature. Another option would be adding various assertion kinds to transaction bodies beyond the validity interval. Although possible, it would be difficult to implement.
Ultimately, Layer-2 networks like Hydra can provide ultimate accuracy via a shorter validity range and a shorter slot range. This would happen alongside the decreased latency in transactions finality.
