8

At the time the Plutus validator script runs, the transaction is not yet part of the blockchain. But the targeted slot of a transaction is known when a node processes the script. Is it possible to access the target slot inside the validator script?

  • The context of a validator script Plutus.V1.Ledger.Contexts.ScriptContext gives access to the transaction where txInfoValidRange may provide upper/lower bounds of the slot. This, however, requires that a Ledger.Constraints.mustValidateIn constraint has been specified when the transaction was submitted (as done in this example).

  • I understand that it is considered to be bad practice for a Plutus validator script to depend on the state of the whole blockchain or unpredictable input such as the target slot because it limits verification/testing possibilities.

Nevertheless, there might be plenty of good use cases for using the current slot; for example, an oracle might check if its data is expired and does not want to enforce its users to provide an upper limit in the mustValidateIn constraint.

Improve this question

1 Answer 1

Reset to default
9

Accessing any runtime information (including current slot) should not be possible in the validator by design. The reason is that transaction validity needs to be deterministic on construction. The only reason a transaction cannot be executed afterwards would be, if a UTXO was already consumed or the slot is outside of txInfoValidRange (as explained in this Youtube video).

There might be other use cases, but making sure expired oracle data isn't consumed anymore could also be achieved by deactivating an oracle (which would require the oracle contract to support it). And also it is in the best interest of the party creating a transaction to make sure only trustworthy oracle data is consumed.

Improve this answer
2
  • Does this mean that there is no way other than putting the burden on the oracle's users to check for expiration? The users may not even know what's the appropriate update-cycle for the data they want. As an oracle provider, I would know about the reliability of my data source. And I might want to set an expiration date in case my network/blockchain access is broken, etc. Similarly, SSL certificates also have an expiration date because it is a reasonable default: "not doing anything" means automatically invalidated. This is more secure because it removes the "zombies".
    – thebrandre
    Commented May 16, 2021 at 9:12
  • 2
    Users of an oracle should be able to acquire this information about an oracle. After all you really have to trust an oracle, so the provider should be as transparent as possible. The oracle could also provide an expiration Slot in it's Datum and only validate transactions that are valid before that expiration (according to txInfoValidRange). The user then needs to restrict transaction validity to a specific slot range.
    – tobxy123
    Commented May 16, 2021 at 18:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.