From 3aacb2f57f031a9ef1520edfd5a36724836a070e Mon Sep 17 00:00:00 2001 From: keyanmaskoot Date: Mon, 4 Nov 2024 20:45:23 +0100 Subject: [PATCH 1/7] feat: add CIP docs for `builtinApplyParams` --- CIP-param-application/README.md | 83 +++++++++++++++++++++++++++++++++ 1 file changed, 83 insertions(+) create mode 100644 CIP-param-application/README.md diff --git a/CIP-param-application/README.md b/CIP-param-application/README.md new file mode 100644 index 0000000000..429689a553 --- /dev/null +++ b/CIP-param-application/README.md @@ -0,0 +1,83 @@ +--- +CIP: ???? +Title: On-Chain Parameter Application +Status: Proposed +Category: Plutus +Authors: + - Keyan M. +Implementors: [] +Discussions: + - https://github.com/cardano-foundation/CIPs/pull/999/ +Created: 2024-11-04 +License: CC-BY-4.0 +--- + +## Abstract +We propose a new Plutus builtin function `builtinApplyParams` with the +signature `BuiltinByteString -> [BuiltinData] -> ScriptHash` in order to enable +simple and low cost on-chain check for validating instances of unapplied +scripts. + +## Motivation: why is this CIP necessary? +Complex contracts tend to depend on multiple scripts, and in some cases, +validation from scripts with some unknown parameters are required. + +As a simple example, assume a minting script which needs to validate that the +destination of its token is a a parameterized spending that is uniquely +instantiated for a user. + +The current solution involves wrapping the spending script with an inner lambda, +expecting the parameters as hashed values to ensure their constant lengths, and +expect each parameter to be provided via the redeemer. This approach allows +slicing unapplied CBOR of the applied script at specific indexes in order to +validate the presence of the expected hash. + +This, however, is a costly and relatively complex approach. + +With our proposed builtin function, the minting script of the example above can +be provided with the unapplied script (either directly or indirectly), and have +arbitrary values applied to it as parameters. + +## Specification + +### Function Definition + +we propose the Plutus builtin function `builtinApplyParams`, with the following +type signature: +```hs +builtinApplyParams :: BuiltinByteString -> [BuiltinData] -> ScriptHash +``` + +Where the first argument is the unapplied script's CBOR, and +the `BuiltinData` list is all the parameters that are to be applied in order. +Finally the result will be hash of the applied script. + + +### Cost Model + +TODO + + +## Rationale: how does this CIP achieve its goals? + +With a builtin function, we'll get cheap and simple on-chain parameter +validation. Consequently, this will enable easier implementation of advanced +contracts with enhanced guarantees. + +### Alternatives + +Please see example above under the [motivation section](#motivation-why-is-this-cip-necessary). + +## Path to Active + +### Acceptance Criteria +- [] Fully implemented in Cardano. + +### Implementation Plan +- [] Passes all requirements of both Plutus and Ledger teams as agreed to improve Plutus script efficiency and usability. + +## Copyright +This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). + +[CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode +[Apache-2.0]: http://www.apache.org/licenses/LICENSE-2.0 From b1a1be8dac4e661b6c2c01e44f1ee82062703262 Mon Sep 17 00:00:00 2001 From: keyanmaskoot Date: Mon, 4 Nov 2024 21:35:17 +0100 Subject: [PATCH 2/7] docs: elaborate current solution and benefits --- CIP-param-application/README.md | 59 ++++++++++++++++++++++++--------- 1 file changed, 44 insertions(+), 15 deletions(-) diff --git a/CIP-param-application/README.md b/CIP-param-application/README.md index 429689a553..b7e9ad1d7a 100644 --- a/CIP-param-application/README.md +++ b/CIP-param-application/README.md @@ -23,18 +23,11 @@ Complex contracts tend to depend on multiple scripts, and in some cases, validation from scripts with some unknown parameters are required. As a simple example, assume a minting script which needs to validate that the -destination of its token is a a parameterized spending that is uniquely +destination of its token is a parameterized spending script that is uniquely instantiated for a user. -The current solution involves wrapping the spending script with an inner lambda, -expecting the parameters as hashed values to ensure their constant lengths, and -expect each parameter to be provided via the redeemer. This approach allows -slicing unapplied CBOR of the applied script at specific indexes in order to -validate the presence of the expected hash. - -This, however, is a costly and relatively complex approach. - -With our proposed builtin function, the minting script of the example above can +The [current solution](#alternatives), is costly and relatively complex. With +our proposed builtin function, the minting script of the example above can be provided with the unapplied script (either directly or indirectly), and have arbitrary values applied to it as parameters. @@ -42,7 +35,7 @@ arbitrary values applied to it as parameters. ### Function Definition -we propose the Plutus builtin function `builtinApplyParams`, with the following +We propose the Plutus builtin function `builtinApplyParams`, with the following type signature: ```hs builtinApplyParams :: BuiltinByteString -> [BuiltinData] -> ScriptHash @@ -60,13 +53,49 @@ TODO ## Rationale: how does this CIP achieve its goals? -With a builtin function, we'll get cheap and simple on-chain parameter -validation. Consequently, this will enable easier implementation of advanced -contracts with enhanced guarantees. +Using the [provided example](#motivation-why-is-this-cip-necessary), the minting +script can have access to the unapplied script: +* Either by direct inclusion as a parameter (which can lead to a large script size) +* Or providing a UTxO as a parameter that houses the unapplied script so that + the minting script can read it without becoming excessively large + +Furthermore, arbitrary parameters can be provided via the redeemer which can be +used to generate an instance's script hash. + +In short, we'll get: +* Easier and cheaper parameter verification on-chain +* A more automation friendly build for such architectures +* Less error prone builds ### Alternatives -Please see example above under the [motivation section](#motivation-why-is-this-cip-necessary). +Continuing to use the [example above](#motivation-why-is-this-cip-necessary), implementing +such a validation on-chain would involve a few key steps. + +First, the whole target contract has to be wrapped within an outer function +which the parameters will be applied to it. This leads to single occurances of +the parameters throughout the script's CBOR. + +Secondly, each parameter will be required to have fixed lengths in order to +allow validation of the bytes surrounding parameters. This can be achieved by +assuming these parameters are all hashes, and that their corresponding values +will be provided via the redeemer. + +Next, in order to validate a given script is an instance of a known script, +first few bytes of an instance must be provided (up until where the parameter is +placed). With this "prefix" at hand, the instance's CBOR can be constructed +on-chain as such: +```hs +let appliedCBOR = + prefix <> param0 <> paramHeader <> param1 <> paramHeader <> param2 <> postfix +``` + +Where `postfix` is similar to `prefix`, but for the rest of the script until its +end. Note that `paramHeader` can be reused based on the presumption that all +parameters are of equal lengths. + +Finally, this `appliedCBOR` can be hashed to attain its corresponding script +credential. ## Path to Active From ce04c5a03364dc9061f79290e81e916551b45c73 Mon Sep 17 00:00:00 2001 From: keyanmaskoot Date: Mon, 4 Nov 2024 21:42:41 +0100 Subject: [PATCH 3/7] fix: minor improvements --- CIP-param-application/README.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/CIP-param-application/README.md b/CIP-param-application/README.md index b7e9ad1d7a..9036049779 100644 --- a/CIP-param-application/README.md +++ b/CIP-param-application/README.md @@ -64,13 +64,12 @@ used to generate an instance's script hash. In short, we'll get: * Easier and cheaper parameter verification on-chain -* A more automation friendly build for such architectures +* A more automation-friendly build for such architectures * Less error prone builds ### Alternatives -Continuing to use the [example above](#motivation-why-is-this-cip-necessary), implementing -such a validation on-chain would involve a few key steps. +Implementing such a validation on-chain would involve a few steps. First, the whole target contract has to be wrapped within an outer function which the parameters will be applied to it. This leads to single occurances of @@ -82,7 +81,7 @@ assuming these parameters are all hashes, and that their corresponding values will be provided via the redeemer. Next, in order to validate a given script is an instance of a known script, -first few bytes of an instance must be provided (up until where the parameter is +first bytes of an instance must be provided (up until where the parameters are placed). With this "prefix" at hand, the instance's CBOR can be constructed on-chain as such: ```hs From 93ae9323f08ce5b7f99803c1041d6d649a6b3b4a Mon Sep 17 00:00:00 2001 From: keyanmaskoot Date: Mon, 4 Nov 2024 21:48:57 +0100 Subject: [PATCH 4/7] fix: minor improvement --- CIP-param-application/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-param-application/README.md b/CIP-param-application/README.md index 9036049779..071ec80f12 100644 --- a/CIP-param-application/README.md +++ b/CIP-param-application/README.md @@ -72,7 +72,7 @@ In short, we'll get: Implementing such a validation on-chain would involve a few steps. First, the whole target contract has to be wrapped within an outer function -which the parameters will be applied to it. This leads to single occurances of +which the parameters will be applied to. This leads to single occurances of the parameters throughout the script's CBOR. Secondly, each parameter will be required to have fixed lengths in order to From fcca291e7f635fd700ae2e158f57dae62a2d0562 Mon Sep 17 00:00:00 2001 From: keyanmaskoot Date: Mon, 4 Nov 2024 21:53:34 +0100 Subject: [PATCH 5/7] fix: minor improvement --- CIP-param-application/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-param-application/README.md b/CIP-param-application/README.md index 071ec80f12..53217b4187 100644 --- a/CIP-param-application/README.md +++ b/CIP-param-application/README.md @@ -43,7 +43,7 @@ builtinApplyParams :: BuiltinByteString -> [BuiltinData] -> ScriptHash Where the first argument is the unapplied script's CBOR, and the `BuiltinData` list is all the parameters that are to be applied in order. -Finally the result will be hash of the applied script. +Finally, output will be the hash of the applied script. ### Cost Model From 2d8950eef799761cfb8d1c261a32d0aa78821ae8 Mon Sep 17 00:00:00 2001 From: keyanmaskoot Date: Wed, 6 Nov 2024 23:46:19 +0100 Subject: [PATCH 6/7] docs: add Phil and Microproofs as authors --- CIP-param-application/README.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/CIP-param-application/README.md b/CIP-param-application/README.md index 53217b4187..1f58d897b1 100644 --- a/CIP-param-application/README.md +++ b/CIP-param-application/README.md @@ -4,11 +4,13 @@ Title: On-Chain Parameter Application Status: Proposed Category: Plutus Authors: + - Philip DiSarro - Keyan M. + - Microproofs Implementors: [] Discussions: - - https://github.com/cardano-foundation/CIPs/pull/999/ -Created: 2024-11-04 + - https://github.com/cardano-foundation/CIPs/pull/934/ +Created: 2024-11-06 License: CC-BY-4.0 --- From 09ace8016a6a0c425a554cbb855c842fa6a07fdf Mon Sep 17 00:00:00 2001 From: keyanmaskoot Date: Tue, 12 Nov 2024 20:57:27 +0100 Subject: [PATCH 7/7] docs: change type signature to leave room for SOP 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. --- CIP-param-application/README.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/CIP-param-application/README.md b/CIP-param-application/README.md index 1f58d897b1..c59bbd357e 100644 --- a/CIP-param-application/README.md +++ b/CIP-param-application/README.md @@ -16,9 +16,9 @@ License: CC-BY-4.0 ## Abstract We propose a new Plutus builtin function `builtinApplyParams` with the -signature `BuiltinByteString -> [BuiltinData] -> ScriptHash` in order to enable -simple and low cost on-chain check for validating instances of unapplied -scripts. +signature `BuiltinByteString -> [BuiltinByteString] -> BuiltinByteString` in +order to enable simple and low cost on-chain check for validating instances of +unapplied scripts. ## Motivation: why is this CIP necessary? Complex contracts tend to depend on multiple scripts, and in some cases, @@ -40,12 +40,13 @@ arbitrary values applied to it as parameters. We propose the Plutus builtin function `builtinApplyParams`, with the following type signature: ```hs -builtinApplyParams :: BuiltinByteString -> [BuiltinData] -> ScriptHash +builtinApplyParams :: BuiltinByteString -> [BuiltinByteString] -> BuiltinByteString ``` Where the first argument is the unapplied script's CBOR, and -the `BuiltinData` list is all the parameters that are to be applied in order. -Finally, output will be the hash of the applied script. +the `BuiltinByteString` list is CBOR bytes of all the parameters that are to be +applied in order. Finally, output will be the fully/partially applied script +CBOR. ### Cost Model