CIP-???? | Parameterised Reference Scripts

[micahkendall]

Allow a parameterised script on-chain to mint proof that a script is generated by it, and also for that minted output to be used as a reference script.

---- New Details ----

Currently there are two main script types on Cardano- Validators and Mint Scripts.
Validators decide whether an output can be spent from an address, and Mint Scripts decide whether a new output can be created from an address.

A Parameterised Reference Script would be similar to Mint Scripts, as it follows the same general form of producing a new output which has undergone a layer of validation. However, the output wouldn't be a representation of value or some arbitrary tokenized asset, but would be a reference to a spendable Validator or Mint Script (Or, potentially another parameterised script- but this is a more complex case).

This output would contain a reference to the script it was generated from. It would also contain the args used to generate it.

An example use case for this is NFTs. If I want to make a validator which has a special case for NFTs, it is currently a complex project and there would be some sort of oracle, verification or trust process required.
A short example of why NFTs in particular would be good to verify is contracts which require uniqueness: it is simple to lock some asset with a token, allowing the owner to encapsulate that value and transfer it using the token. A secure contract would always guarantee the uniqueness of the key, which depends on the fact whether a token is actually an NFT. However, the idea is more general than NFTs, they are just a good explanatory case.

With Parameterised Reference Scripts, I consider this example from https://github.com/input-output-hk/plutus-pioneer-program/blob/main/code/week05/src/Week05/NFT.hs

{-# INLINABLE mkPolicy #-}
mkPolicy :: TxOutRef -> TokenName -> () -> ScriptContext -> Bool
mkPolicy oref tn () ctx = traceIfFalse "UTxO not consumed"   hasUTxO           &&
                          traceIfFalse "wrong amount minted" checkMintedAmount
  where
    info :: TxInfo
    info = scriptContextTxInfo ctx

    hasUTxO :: Bool
    hasUTxO = any (\i -> txInInfoOutRef i == oref) $ txInfoInputs info

    checkMintedAmount :: Bool
    checkMintedAmount = case flattenValue (txInfoMint info) of
        [(_, tn', amt)] -> tn' == tn && amt == 1
        _               -> False

It is technically trivial to verify some generated contract (...simply run the producing parameterised function with that input again) by applying the TxOutRef to the parameterised version. It is clearly useful to be able to do this efficiently from a Plutus script (any on-chain smart contract)- but it is currently not practically feasible to do this. This reasoning justifies a CIP which makes this use case practical if not possible.

My initial spec would be as follows:
A parameterised script may be used to mint an output corresponding to any other kind of script. This output must encode two values: "fromScriptHash", and "args". "fromScriptHash" is the hash of the parameterised script. "args" is the plutus data values which are fed into the parameterised contract to produce the output scripts.
This output will always be spent to the hash of the produced script. If the parameterised script is stored as a reference script, then the output will also be spendable as a reference script (where the source is resolved by taking the args stored at the output, jumping back to the parameterised script, and generating the source by providing the args.) Otherwise, without the use of a reference script, the script can be provided per-use.

One way I imagine this CIP being used:

You have already submitted a transaction with the minting policy above, to mint an NFT.
The main-net is upgraded through a hard-fork, implementing this CIP.
I (or someone) provide a pair of contracts, one where a key may be generated for any token which a ‘parameterisation proof’ is provided as a reference input corresponding to the policy above by hash. The key’s token name is the hash of the NFT asset class (full policy+name bytestring). This also validates the spend of the NFT, along with other assets you may wish to lock, towards the locking contract, with a datum corresponding to the key. The locking contract allows you to retrieve all values which are locked by a datum corresponding to the key, provided you burn that key.
You build a TX, minting the key to your wallet, to build a bundle of an NFT and various other assets, which is sent to the locking contract.
You sell the key on some marketplace, and some other user unlocks the assets when desired by invoking the locking contract.

How was this workflow actually improved by this CIP?
There is less trust in the NFT process required. It is much easier to agree on formats for proof of uniqueness through parameterization.
Entirely verified on chain.

Open for dialogue about more specific details of this proposal if anyone has anything to say.

[KtorZ]

This proposal was introduced in the triage phase in today's editor meeting (number 57); I couldn't quite understand the motivation behind it, nor what the specification is really proposing. This may be due to the fact that the PR is still a draft and thus, not yet finished.

It might help to be less generic in the motivation and provide a concrete example of a problem that this proposal comes to address. I'll encourage you to rework the proposal for more clarity.

There's also no Path to Active section, so it isn't clear what will be the steps to implement this proposal.

Note

I have the feeling that you may be interested in writing a CPS as outlined in #366 to describe the problem, before describing the solution.

[micahkendall]

By taking techniques which guarantee uniqueness, and generalising them to accept Plutus functions (think minting policy provided as a parameter), you can replace standards with code. Think ERC721 but as a wrapping function. Compliance in this way changes from an auditing to an on-chain process.

[micahkendall]

By taking techniques which guarantee uniqueness, and generalising them to accept Plutus functions (think minting policy provided as a parameter), you can replace standards with code. Think ERC721 but as a wrapping function. Compliance in this way changes from an auditing to an on-chain process.

Additionally, you could write a wrapper for a function which outputs a price feed, then enforce that the output from that policy matches a standard for the structure of that price feed. This could be applied to oracle standardisation.