Layer 2 built-in support

[KtorZ]

Building up on the new V3 syntax:

validator my_validator(arg1: Whatever) {
  spend (datum: Option<Datum>, redeemer: Redeemer, utxo_ref: OutputReference, ctx: Transaction) {
    ...
  }

  mint (redeemer: Redeemer, policy_id: PolicyId, ctx: Transaction) {
    ...
  }

  else(_) { fail }
}

We could imagine augmenting the syntax to support custom purposes; and use that syntax to define Cardano's purposes themselves. The definition for Cardano would be implicitly provided when unspecified, and would be equivalent to:

validator my_validator(arg1: Whatever) for Cardano {
  ...
}

The idea would be to have the validator's purpose names be the (lowercased) variants of a defined type + the else branch:

purpose Cardano = 0 {
  Spend(...)
  Mint(..)
  Publish(..)
  Vote(..)
}

The syntax for defining new purpose should also include ways of specifying the constructor index for the script context corresponding to that purpose (the Cardano ledger currently uses 0).

So for example, if we imagine a layer 2 "Gummiworm" associated with the constructor 1, we could have:

purpose Gummiworm = 1 {
  Swallow(...)
  Scream(..)
  Shout(..)
}

validator my_validator(arg1: Whatever) for Gummiworm {
  swallow(..) { ... }
  scream(..) { .. .} 
  else(..) { ... }
}

Notice that the names of the validator is the same, such that it compiles to a single program (single hash) across all layers.

[Riley-Kilgore]

I think it is worth considering the possibility that Layer 2s will end up not only having a custom ScriptContext shape, but additionally there may be some builtins which are enabled on Layer 2s that are not enabled on the Layer 1.

In this case, it becomes necessary for additional changes outside of the ones described above. To be clear, I am only arguing here in favor of UPLC generation allowing for these builtins. I am not arguing for supporting evaluation of custom builtins, unless maybe the logic for a given builtin is supplied as an Aiken function?).

Not sure what the best approach here is.