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.

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.

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`.

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.