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.

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.

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.

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.

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

An optimized version of fromIntegral . unSatInt.

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

Build the EvaluationContext.

The input is a list of cost model parameters (which are integer values) passed from the ledger.

IMPORTANT: the cost model parameters MUST appear in the correct order, matching the names in ParamName. If the parameters are supplied in the wrong order then script cost calculations will be incorrect.

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

The enumeration of all possible cost model parameter names for this language version.

IMPORTANT: The order of appearance of the data constructors here matters. DO NOT REORDER. See Note [Quotation marks in cost model parameter constructors] See Note [Cost model parameters from the ledger's point of view]

An Interval of POSIXTimes.

An address may contain two credentials, the payment credential and optionally a StakingCredential.

The hash of a public key. This is frequently used to identify the public key, rather than the key itself. Hashed with BLAKE2b-224. 28 bytes.

This is a simple type without any validation, use with caution. You may want to add checks for its invariants. See the Shelley ledger specification.

A transaction ID, i.e. the hash of a transaction. Hashed with BLAKE2b-256. 32 byte.

This is a simple type without any validation, use with caution. You may want to add checks for its invariants. See the Shelley ledger specification.

A pending transaction. This is the view as seen by validator scripts, so some details are stripped out.

A transaction output, consisting of a target address, a value, optionally a datum/datum hash, and optionally a reference script.

A reference to a transaction output. This is a pair of a transaction ID (TxId), and an index indicating which of the outputs of that transaction we are referring to.

The datum attached to an output: either nothing; a datum hash; or the datum itself (an "inline datum").

An interval of as.

The interval may be either closed or open at either end, meaning that the endpoints may or may not be included in the interval.

The interval can also be unbounded on either side.

The Eq instance gives equality of the intervals, not structural equality. There is no Enum in order to handle non-inclusive endpoints. For this reason, it may not be safe to use Intervals with non-inclusive endpoints on types whose Enum instances have partial methods.

An Interval that covers every slot. In math. notation [-∞,+∞]

from a is an Interval that includes all values that are greater than or equal to a. In math. notation: [a,+∞]

to a is an Interval that includes all values that are smaller than or equal to a. In math. notation: [-∞,a]

Construct a lower bound from a value. The resulting bound includes all values that are equal or greater than the input value.

Construct an upper bound from a value. The resulting bound includes all values that are equal or smaller than the input value.

Construct a strict lower bound from a value. The resulting bound includes all values that are (strictly) greater than the input value.

Construct a strict upper bound from a value. The resulting bound includes all values that are (strictly) smaller than the input value.

A Map of key-value pairs. A Map is considered well-defined if there are no key collisions, meaning that each value is uniquely identified by a key.

Use safeFromList to create well-defined Maps from arbitrary lists of pairs.

If cost minimisation is required, then you can use unsafeFromList but you must be certain that the list you are converting to a Map abides by the well-definedness condition.

Most operations on Maps are definedness-preserving, meaning that for the resulting Map to be well-defined then the input Map(s) have to also be well-defined. This is not checked explicitly unless mentioned in the documentation.

Take care when using fromBuiltinData and unsafeFromBuiltinData, as neither function performs deduplication of the input collection and may create invalid Maps!

Unsafely create a Map from a list of pairs. This should _only_ be applied to lists which have been checked to not contain duplicate keys, otherwise the resulting Map will contain conflicting entries (two entries sharing the same key). As usual, the "keys" are considered to be the first element of the pair.

Type representing the BLAKE2b-224 hash of a script. 28 bytes.

This is a simple type without any validation, use with caution. You may want to add checks for its invariants. See the Shelley ledger specification.

Type representing the BLAKE2b-256 hash of a redeemer. 32 bytes.

This is a simple type without any validation, use with caution. You may want to add checks for its invariants. See the Shelley ledger specification.

Type representing the BLAKE2b-256 hash of a datum. 32 bytes.

This is a simple type without any validation, use with caution. You may want to add checks for its invariants. See the Shelley ledger specification.

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.

A type corresponding to the Plutus Core builtin equivalent of Data.

The point of this type is to be an opaque equivalent of Data, so as to ensure that it is only used in ways that the compiler can handle.

As such, you should use this type in your on-chain code, and in any data structures that you want to be representable on-chain.

For off-chain usage, there are conversion functions builtinDataToData and dataToBuiltinData, but note that these will not work on-chain.