Input-Output Hong Kong or IOHK previously explained Ouroboros’ time-handling on Cardano, plus the vitality of determinism. Now, in its blog, the second part presents Plutus, Marlowe, and Hydra addressing timekeeping on Cardano, plus use cases.
Sharing the update, IOHK tweeted:
The second part of time handling on Cardano is now out.
— Input Output (@InputOutputHK) December 8, 2022
Here’s more about specific use cases: how Plutus, Marlowe, and Hydra address timekeeping on #Cardano.https://t.co/jJX43PA79Y
Plutus Scripts
The creator-defined transaction validity range’s access is available to Plutus scripts. When these validity ranges are set, the creator can decide upon their validity. The result is constraints imposed upon the inclusion of transactions into slots, making it easy to define on-chain ‘contracts.’
If the script fails to assume that the validation time is within range, it wouldn’t pass phase 1 prior to script execution (ensuring determinism).
POSIXTime expresses the validity interval limits in real-time, whereas consensus converts to real-time from slots.
In the actual design of Alonzo, the well-known uses of time are covered by validity range. At the same time, it also harmonizes well with the time-to-live (TTL).
Time Applications in Cardano Ecosystem
Hydra
The Hydra protocol is time-dependent in computing and enforcing the contestation deadline. Via the UTCTime, the Hydra Head state machine records the time passage. UTCTime (off-chain) is used to thwart the imposed slot-to-time conversion limitations.
With a tick granularity of around 20s, via using the time measure, Hydra reacts to the contestation deadline’s protocol-specific crossing.
It’s vital that Hydra Head’s local time is knitted to Ouroboros-handled on-chain time. Hydra, an isomorphic protocol, aspires to process layer 2’s (L2) ‘timed transactions.’ But for this, comprehending precision and the process of discretizing time on a layer 2 ledger is a must.
Time-handling complexities can better be solved with fitting solutions offered by layer 2.
Marlowe
A domain-specific language involving time, Marlowe writes standard financial and transactional contracts.
Marlowe’s financial contracts also include ACTUS standard contracts, viz. loans, swaps, options, and derivatives). Marlowe also supports auctions, token swaps, and games contracts.
The incumbent Marlowe mechanisms go well with its semantics, offering Plutus-inherited locality and determinism to its transactions.
Perfectly in-sync with Cardano’s validity intervals, Marlowe’s contract time lies in the timeouts and deadlines constraining its evolutionary execution. A loan contract requires a timeout logic; to execute varied logic for penalty imposition in a loan default (missed payment), set future payment schedule, etc.
Solutions
It may well be possible for Cardano to offer accurate time-specific data in transaction validation. These might include the block producer (minting) timestamp, or with milliseconds precision the actual timestamp in UTC.
But this just might hinder prospective determinism. In it, a user fails to ascertain the instance of a transaction applying to the ledger for sure or not. Simply because it depends upon the exact timestamp selected by the block producer for block creation.
Even beyond the validity interval, to the transaction bodies, various assertion types may also be possibly added. But a use case is a must for all assertion types.
Conclusion
L2 networks like Hydra do have a potential to offer higher accuracy since the ‘slot length’ is shorter. Their validity range is also short, whereas the transaction finality latency is low. But Hydra’s incumbent implementation does not offer that level of flexibility as of now.
Remember, in the space of decentralized blockchain, time isn’t an easy phenomenon to decipher. The above-discussed states that on-chain time on Cardano is en route, that too with constraints and improvements on horizon.
On-chain time tends to address system constraints, it also ensures stake pool operators’ and end-users’ security with enough usability.
