-
Notifications
You must be signed in to change notification settings - Fork 322
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CIP-???? | On-Chain Parameter Application #934
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
builtinApplyParams
CIP-param-application/README.md
Outdated
We propose the Plutus builtin function `builtinApplyParams`, with the following | ||
type signature: | ||
```hs | ||
builtinApplyParams :: BuiltinByteString -> [BuiltinData] -> ScriptHash |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
|
||
### Cost Model | ||
|
||
TODO |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also tagging @bezirg for his opinion
Also changed the output to be the script CBOR rather than its hash, as suggested by Thomas. This will allow for partial application of the arguments, and subsequently not being limited to performing the whole computation in a single transaction.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The arguments changed to cborHex now allows SOP parameters to be applied.
@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) |
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)