The ledger era era comes first for type applications; apiEra follows from it.

Serialise an AnyPlutusScript to a TextEnvelope. The text envelope type is determined by the Plutus language version of the script.

Deserialise an AnyPlutusScript from a TextEnvelope. The text envelope type is matched against the Plutus language versions from nonNativeLanguages that the era supports, so new language versions are picked up automatically. The ledger era era comes first for type applications; apiEra follows from it.

A Plutus script in a particular era. Why PlutusRunnable? Mainly for deserialization benefits. The deserialization of this type looks at the major protocol version and the script language to determine if indeed the script is runnable. This is a dramatic improvement over the old api which essentially read a ByteString and hoped for the best. Any failures due to malformed/invalid scripts were caught upon transaction submission or running the script when attempting to predict the necessary execution units.

Where do we get the major protocol version from? In order to access the major protocol version we pass in an era type parameter which can be translated to the major protocol version.

Where do we get the script language from? The serialized version of PlutusRunnable encodes the script language. See `DecCBOR (PlutusRunnable l)` in cardano-ledger for more details.

The constructor carries EraPlutusTxInfo evidence, so a value can only exist for a language and era pairing the ledger supports. That evidence is what makes the conversion to the ledger's own script type total; see plutusScriptInEraToScript.

Evidence that the ledger era era accepts Plutus scripts of lang. The ledger's EraPlutusTxInfo instances are the table; matching gives AlonzoEraScript.

plutusLangInShelleyBasedEra for code that only has the era type. Eras before Alonzo always give Nothing.

With the language known only at the type level, take the singleton from PlutusLanguage:

case plutusLangInEra @era (L.isLanguage @lang) of
  Just (PlutusLangInEra _) -> -- the era runs the language, 'L.EraPlutusTxInfo' is in scope
  Nothing -> -- it does not

When the pairing is static and supported, EraPlutusTxInfo already holds and the proof needs no lookup:

PlutusLangInEra L.isLanguage :: PlutusLangInEra lang era

The runtime side of the table, for code that learns the language late.

Decode a script of a language the era supports. The EraPlutusTxInfo constraint is the proof, so only malformed bytes fail.

The EraPlutusTxInfo evidence in the constructor is the proof the ledger needs, so mkSupportedPlutusScript cannot fail here.

When it comes to using plutus scripts we need to provide the following to the tx:

1. The redeemer pointer map
2. The set of plutus languages in use
3. The set of plutus scripts in use (present in the t)
4. The datum map

This is a Plutus script witness. It possesses: 1. The plutus script or reference input 2. The script redeemer 3. The execution units 4. Potentially a script datum. See the PlutusScriptDatum type family for more details.

Note that Plutus script witnesses do not exist on their own. They must witness something and a redeemer pointer must be constucted to point to the thing being witnessed. See IndexedPlutusScriptWitness for more details.

You can provide the plutus script directly in the transaction or a reference input that points to the script in the UTxO. Using a reference script saves space in your transaction.

Every Plutus script has a purpose that indicates what that script is witnessing.

Construct the datum of a spending-purpose Plutus script witness from a plain HashableScriptData.

A Plutus script witness along the thing it is witnessing and the index of that thing. E.g transaction input, certificate, withdrawal, minting policy, etc. A Plutus script witness only makes sense in the context of what it is witnessing and the index of the thing it is witnessing.

These are all of the "things" a plutus script can witness. We include the relevant type class constraint to avoid boilerplate when creating the PlutusPurpose in the toPlutusScriptPurpose.

To reduce boilerplate, we reuse the PlutusPurpose type from `cardano-ledger`. This type is utilized in constructing the redeemer pointers map, which links the redeemer and execution units with the entity being witnessed. The map is indexed by the redeemer pointer.

A natural question arises: How do Plutus scripts determine which execution units and redeemer are paired with them? The ledger constructs a redeemer pointer for every Plutus script, and this pointer corresponds to the one in the transaction's redeemer pointers map. For more details, refer to collectPlutusScriptsWithContext in `cardano-ledger`.

Classify a ledger redeemer pointer (PlutusPurpose AsIx) into the PlutusScriptPurpose category it belongs to and the index within that category. This is the read direction, the inverse of toPlutusScriptPurpose.

Create a list of indexed plutus script witnesses from anything witnessable that has been witnesseed by a plutus script.

The transaction's redeemer pointer map allows the ledger to connect a redeemer and execution unit pairing to the relevant script. The ledger basically reconstructs the indicies (redeemer pointers) of this map can then look up the relevant execution units/redeemer pairing. NB: the redeemer pointer has been renamed to 'PlutusPurpose AsIndex' in the ledger.