Documentation

Scripts to the ledger are serialised bytestrings.

The plutus language version as seen from the ledger's side. Note: the ordering of constructors matters for deriving Ord

This represents the Cardano protocol version, with its major and minor components. This relies on careful understanding between us and the ledger as to what this means.

A map indicating which builtin functions were introduced in which ProtocolVersion. Each builtin function should appear at most once.

This *must* be updated when new builtins are added. See Note [New builtins and protocol versions]

Which builtin functions are available in the given ProtocolVersion?

See Note [New builtins and protocol versions]

A variant of Script with a specialized decoder.

This decoder decodes the names directly into NamedDeBruijns rather than DeBruijns. This is needed because the CEK machine expects NameDeBruijns, but there are obviously no names in the serialized form of a Script. Rather than traversing the term and inserting fake names after deserializing, this lets us do at the same time as deserializing.

Check if a Script is "valid" according to a protocol version. At the moment this means "deserialises correctly", which in particular implies that it is (almost certainly) an encoded script and the script does not mention any builtins unavailable in the given protocol version.

Note: Parameterized over the ledger-plutus-version since the builtins allowed (during decoding) differs.

Errors that can be thrown when evaluating a Plutus script.

The type of log output: just a list of Text.

A simple toggle indicating whether or not we should produce logs.

Shared helper for the evaluation functions, deserializes the SerializedScript , applies it to its arguments, puts fakenamedebruijns, and scope-checks it.

Which unlifting mode should we use in the given ProtocolVersion so as to correctly construct the machine's parameters

An opaque type that contains all the static parameters that the evaluator needs to evaluate a script. This is so that they can be computed once and cached, rather than recomputed on every evaluation.

There are two sets of parameters: one is with immediate unlifting and the other one is with deferred unlifting. We have to keep both of them, because depending on the language version either one has to be used or the other. We also compile them separately due to all the inlining and optimization that need to happen for things to be efficient.

Build the EvaluationContext.

The input is a Map of strings to cost integer values (aka CostModelParams, CostModel) See Note [Inlining meanings of builtins].

Comparably expensive to mkEvaluationContext, so it should only be used sparingly.

Evaluates a script, with a cost model and a budget that restricts how many resources it can use according to the cost model. Also returns the budget that was actually used.

Can be used to calculate budgets for scripts, but even in this case you must give a limit to guard against scripts that run for a long time or loop.

Note: Parameterized over the ledger-plutus-version since the builtins allowed (during decoding) differs.

Evaluates a script, returning the minimum budget that the script would need to evaluate successfully. This will take as long as the script takes, if you need to limit the execution time of the script also, you can use evaluateScriptRestricting, which also returns the used budget.

Note: Parameterized over the ledger-plutus-version since the builtins allowed (during decoding) differs.