CIP-???? | On-Chain Parameter Application

[keyan-m]

We propose a new builtin Plutus function, builtinApplyParams, to reduce the costs and complexity of instantiating parameterized scripts on-chain.

A sample use-case for performing this computation on-chain would be enabling validation by a minting policy for the destinations of its tokens, ensuring that only instances of a specific script can be the recipients.

Without this builtin, apart from development complexities, script instances need to be limited to hashed parameters that must be resolved via the redeemer in each transaction, and therefore bloat the chain with duplicate data.

---

(latest version in branch)

[rphair]

thanks @keyan-m - I've tagged for Triage to put it on the agenda for our next CIP meeting (https://hackmd.io/@cip-editors/100). @MicroProofs I hope you will also be with us this time to help introduce it & likewise @colll78 if you can make it.

[colll78]

This proposed solution solves:

#354
#385

[perturbing]

Why do you return a ScriptHash and not a BuiltinByteString? Besides this ScriptHash not being a plutus type, would it not be nice to return the applied CBOR, so that one can apply parameters over multiple transactions.

[perturbing]

I wonder what the impact here would be, since this suggested built-in is effectively running the plutus machinery inside an already running instance of it.

My intuition tells me that this is okay, since the complexity of this calculation is always bound by the complexity of any possible other script. But looking forward to more insight from @kwxm :)

[perturbing]

Also tagging @bezirg for his opinion

[colll78]

The arguments changed to cborHex now allows SOP parameters to be applied.

[rphair]

@kwxm we decided the last CIP meeting 2 days ago to wait as per #934 (comment) until you had gone over this to confirm feasibility & desirability of this change... once that's done we would confirm this as a candidate & assign a CIP number. (cc @keyan-m @bezirg @perturbing)

[colll78]

@kwxm we decided the last CIP meeting 2 days ago to wait as per #934 (comment) until you had gone over this to confirm feasibility & desirability of this change... once that's done we would confirm this as a candidate & assign a CIP number. (cc @keyan-m @bezirg @perturbing)

Costing should just be the sum of:

1. the setup cost for the CEK machine with the script we want to apply arguments to
2. the cost of one apply
3. overhead?

I think the above can be fully ignored though, and the costing process can be identical the process used to bench any other external functional call (ie. validateSignature). Just run large amounts of tests to see the impact the input size has on CPU/MEM and determine a function that accurately models that data as closely as possible.