Documentation

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.

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.

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 Texts to cost integer values (aka CostModelParams, CostModel) See Note [Inlining meanings of builtins].

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.

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

Scripts to the ledger are serialised bytestrings.

Note [Using Flat for serialising/deserialising Script] `plutus-ledger` uses CBOR for data serialisation and `plutus-core` uses Flat. The choice to use Flat was made to have a more efficient (most wins are in uncompressed size) data serialisation format and use less space on-chain.

To make `plutus-ledger` work with scripts serialised with Flat, and keep the CBOR format otherwise, we have defined the serialiseUPLC and deserialiseUPLC functions.

Because Flat is not self-describing and it gets used in the encoding of Programs, data structures that include scripts (for example, transactions) no-longer benefit for CBOR's ability to self-describe it's format.

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

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

Errors that can be thrown when evaluating a Plutus script.

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.

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

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 valid parameter name has to be enumeration, bounded, ordered, and prettyprintable in a "lowerKebab" way.

Each API version should expose such an enumeration as an ADT and create an instance of ParamName out of it.

A Generic wrapper for use with deriving via

Essentially untag the association of param names to values so that CostModelInterface can make use of it.