Scripts to the ledger are serialised bytestrings.

A Plutus script ready to be evaluated on-chain, via evaluateScriptRestricting.

Get a SerialisedScript from a ScriptForEvaluation. O(1).

Get a ScriptNamedDeBruijn from a ScriptForEvaluation. O(1).

Turns a program which was compiled using the 'PlutusTx' toolchain into a binary format that is understood by the network and can be stored on-chain.

Turns a program's AST (most likely manually constructed) into a binary format that is understood by the network and can be stored on-chain.

The deserialization from a serialised script into a ScriptForEvaluation, ready to be evaluated on-chain. Called inside phase-1 validation (i.e., deserialisation error is a phase-1 error).

Deserialises a SerialisedScript back into an AST. Does *not* do ledger-language-version-specific checks like for allowable builtins.

An error that occurred during script deserialization.

A script with named de-bruijn indices.

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 LedgerPlutusVersion since 1. The builtins allowed (during decoding) differ, and 2. The Plutus language versions allowed differ.

Evaluate a fully-applied term using the CEK machine. Useful for mimicking the behaviour of the on-chain evaluator.

A simple toggle indicating whether or not we should accumulate logs during script execution.

The type of the executed script's accumulated log output: a list of Text.

It will be an empty list if the VerboseMode is set to Quiet.

Errors that can be thrown when evaluating a Plutus script.

This represents the major component of the Cardano protocol version. The ledger can only supply the major component of the protocol version, not the minor component, and Plutus should only need to care about the major component anyway. This relies on careful understanding between us and the ledger as to what this means.

The Plutus ledger language. These are entirely different script languages from the ledger's perspective, which on our side are interpreted in very similar ways.

It is a simple enumerated datatype (there is no major and minor components as in protocol version) and the ordering of constructors is essential for deriving Enum,Ord,Bounded.

IMPORTANT: this is different from the Plutus Core language version, Version

The version of Plutus Core used by this program.

The intention is to convey different levels of backwards compatibility for existing scripts: - Major version changes are backwards-incompatible - Minor version changes are backwards-compatible - Patch version changes should be entirely invisible (and we will likely not use this level)

The version used should be changed only when the language itself changes. For example, adding a new kind of term to the language would require a minor version bump; removing a kind of term would require a major version bump.

Similarly, changing the semantics of the language will require a version bump, typically a major one. This is the main reason why the version is actually tracked in the AST: we can have two language versions with identical ASTs but different semantics, so we need to track the version explicitly.

Compatibility is about compatibility for specific scripts, not about e.g. tools which consume scripts. Adding a new kind of term does not change how existing scripts behave, but does change what tools would need to do to process scripts.

A map indicating which builtin functions were introduced in which MajorProtocolVersion.

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

Which builtin functions are available in the given given PlutusLedgerLanguage and MajorProtocolVersion?

See Note [New builtins/language versions and protocol versions]

Query the protocol version that a specific Plutus ledger language was first introduced in.

Which Plutus language versions are available in the given MajorProtocolVersion?

See Note [New builtins/language versions and protocol versions]

Counts CPU units in picoseconds: maximum value for SatInt is 2^63 ps, or appproximately 106 days.

Counts size in machine words.

An optimized version of fromIntegral . unSatInt.

A raw representation of the ledger's cost model parameters.

The associated keys/names to the parameter values are arbitrarily set by the plutus team; the ledger does not hold any such names.

See Note [Cost model parameters]

Untags the plutus version from the typed cost model parameters and returns their raw textual form (internally used by CostModelInterface).

A parameter name for different plutus versions.

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

A valid parameter name has to be enumeration, bounded, ordered, and prettyprintable to a "lower-Kebab" string.

A Generic wrapper for use with deriving via

A fatal error when trying to create a cost given some plain costmodel parameters.

A non-fatal warning when trying to create a cost given some plain costmodel 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 being recomputed on every evaluation.

Different protocol versions may require different bundles of machine parameters, which allows us for example to tweak the shape of the costing function of a builtin, so that the builtin costs less. Currently this means that we have to create multiple DefaultMachineParameters per language version, which we put into a cache (represented by an association list) in order to avoid costly recomputation of machine parameters.

In order to get the appropriate DefaultMachineParameters at validation time we look it up in the cache using a semantics variant as a key. We compute the semantics variant from the protocol version using the stored function. Note that the semantics variant depends on the language version too, but the latter is known statically (because each language version has its own evaluation context), hence there's no reason to require it to be provided at runtime.

To say it differently, there's a matrix of semantics variants indexed by (LL, PV) pairs and we cache its particular row corresponding to the statically given LL in an EvaluationContext.

The reason why we associate a DefaultMachineParameters with a semantics variant rather than a protocol version are

1. generally there are far more protocol versions than semantics variants supported by a specific language version, so we save on pointless duplication of bundles of machine parameters
2. builtins don't know anything about protocol versions, only semantics variants. It is therefore more semantically precise to associate bundles of machine parameters with semantics variants than with protocol versions

Create an EvaluationContext given all builtin semantics variants supported by the provided language version.

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

IMPORTANT: the toSemVar argument computes the semantics variant for each MajorProtocolVersion and it must only return semantics variants from the semVars list, as well as cover ANY MajorProtocolVersion, including those that do not exist yet (i.e. toSemVar must never fail).

IMPORTANT: The evaluation context of every Plutus version must be recreated upon a protocol update with the updated cost model parameters.

Shared helper for the evaluation functions: evaluateScriptCounting and evaluateScriptRestricting,

Given a ScriptForEvaluation:

1) applies the term to a list of Data arguments (e.g. Datum, Redeemer, ScriptContext) 2) checks that the applied-term is well-scoped 3) returns the applied-term

An opaque type representing Plutus Core ByteStrings.

A generic "data" type.

The main constructor Constr represents a datatype value in sum-of-products form: Constr i args represents a use of the ith constructor along with its arguments.

The other constructors are various primitives.