A Plutus Data object containing proposed parameter changes. The Data object contains a Map with one entry per changed parameter, from the parameter ID to the new value. Unchanged parameters are not included.

The mapping from parameter IDs to parameters can be found in conway.cddl. -- editorconfig-checker-disable-file

Invariant: This map is non-empty, and the keys are stored in ascending order.

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]

Credentials required to unlock a transaction output.

The PubKeyCredential constructor represents the transaction that spends this output and must be signed by the private key. See PubKeyHash.

The ScriptCredential constructor represents the transaction that spends this output must include the validator script and be accepted by the validator. See ScriptHash.

The Value type represents a collection of amounts of different currencies. We can think of Value as a vector space whose dimensions are currencies.

Operations on currencies are usually implemented pointwise. That is, we apply the operation to the quantities for each currency in turn. So when we add two Values the resulting Value has, for each currency, the sum of the quantities of that particular currency in the argument Value. The effect of this is that the currencies in the Value are "independent", and are operated on separately.

Whenever we need to get the quantity of a currency in a Value where there is no explicit quantity of that currency in the Value, then the quantity is taken to be zero.

There is no 'Ord Value' instance since Value is only a partial order, so compare can't do the right thing in some cases.

ByteString representing the currency, hashed with BLAKE2b-224. It is empty for Ada, 28 bytes for MintingPolicyHash. Forms an AssetClass along with TokenName. A Value is a map from CurrencySymbol's to a map from TokenName to an Integer.

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. -- editorconfig-checker-disable-file

ByteString of a name of a token. Shown as hex-encoded bytes. Should be no longer than 32 bytes, empty for Ada. Forms an AssetClass along with a CurrencySymbol.

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. -- editorconfig-checker-disable-file

Make a Value containing only the given quantity of the given currency.

Combine two Value maps with the argument function. Assumes the well-definedness of the two maps.

The CurrencySymbol of the Ada currency.

The TokenName of the Ada currency.

Get the Value minted by the MintValue.

Get the Value burned by the MintValue. All the negative quantities in the MintValue become positive in the resulting Value.

POSIX time is measured as the number of milliseconds since 1970-01-01T00:00:00Z. This is not the same as Haskell's RepIsStuckError POSIXTime :: Type -> Type) (Rep POSIXTime)))

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.

Represents an arbitrary-precision ratio.

The following two invariants are maintained:

1. The denominator is greater than zero.
2. The numerator and denominator are coprime.

Safely constructs a Rational from a numerator and a denominator. Returns Nothing if given a zero denominator.

Makes a Rational from a numerator and a denominator.

Important note

If given a zero denominator, this function will error. If you don't mind a size increase, and care about safety, use ratio instead.

Returns the numerator of its argument.

Note

It is not true in general that numerator <$> ratio x y = x; this will only hold if x and y are coprime. This is due to Rational normalizing the numerator and denominator.

Returns the denominator of its argument. This will always be greater than, or equal to, 1, although the type does not describe this.

Note

It is not true in general that denominator <$> ratio x y = y; this will only hold if x and y are coprime. This is due to Rational normalizing the numerator and denominator.

Converts a GHC Rational, preserving value.

Note: Does not work on-chain.

Converts a Rational to a GHC Rational, preserving value.

Note: Does not work on-chain.

A map associating keys and values backed by BuiltinData.

This implementation has the following characteristics:

• The toBuiltinData and unsafeFromBuiltinData operations are no-op.
• Other operations are slower than PlutusTx.AssocMap.Map, although equality checks on keys can be faster due to equalsData.
• Many operations involve converting the keys and/or values to/from BuiltinData.

Therefore this implementation is likely a better choice than PlutusTx.AssocMap.Map if it is part of a data type defined using asData, and the key and value types have efficient toBuiltinData and unsafeFromBuiltinData operations (e.g., they are primitive types or types defined using asData).

A Map is considered well-defined if it has no duplicate keys. Most operations preserve the definedness of the resulting Map unless otherwise noted. It is important to observe that, in comparison to standard map implementations, this implementation provides slow lookup and update operations because it is based on a list representation.

Unsafely create an Map from a sums of products 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), and therefore be ill-defined. Warning: this requires traversing the list and encoding the keys and values, so it should be avoided in favor of unsafeFromBuiltinList if the input is already in BuiltinData form.

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.