In PPP Larz explains that there's a limit to how long a contract can remain on chain, what is that limit and how do I go about extending it?
1
-
Can you point to the source where Lars says this?– FermatCommented Jul 2, 2022 at 18:10
Add a comment
|
1 Answer
Just a guess, but you might be referring to the POSIX time <-> slot conversion, where Lars noted in week 3 (see notes here), that - if you require a definite upper bound for a slot interval - you should not place that upper bound too far into the future, because slot lengths could potentially change in the future, and cause your script to behave unexpectedly.
If so, I'm not sure if this is still important in the context of using txInfoValidRange in smart contracts though, since it seems to have changed from SlotRange to POSIXTimeRange (https://github.com/input-output-hk/plutus/blob/65fa7ce05a810947f565ac59b4d4e35b3cd5d1b3/plutus-ledger-api/src/PlutusLedgerApi/V1/Contexts.hs#L109 since this commit) - and so you probably don't need to care about this any longer.
In any case this is not related to how long your contract stays on chain, but only how one needs to consider working with time & slot length in certain scenarios.
-
Yeah it's changed a bit can i specify this to be something like 100 years from now? Commented Jul 2, 2022 at 22:05
-
1In general if you're working with the POSIXTime: It's in milliseconds since 1970-01-01T00:00:00Z. So in 100 years it'll be around ~4812480000000. I think in general you can safely work with this in your scripts (but don't trust me on this :p). However for the "txInfoValidRange" value: It's not set directly by you in posix time, but converted from slots under the hood and set by whoever created the transaction in the first place. I think it can also take any value up to infinity (open interval) - so yes, it can also be a valid tx in 100 years.– seanCommented Jul 3, 2022 at 8:31