From 4083db6a557c3afa75402a9bdc866534901a7bb2 Mon Sep 17 00:00:00 2001 From: zygomeb Date: Tue, 23 Aug 2022 04:00:28 +0200 Subject: [PATCH 1/6] 0069 first version --- CIP-0069/README.md | 87 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 87 insertions(+) create mode 100644 CIP-0069/README.md diff --git a/CIP-0069/README.md b/CIP-0069/README.md new file mode 100644 index 000000000..e864b39b5 --- /dev/null +++ b/CIP-0069/README.md @@ -0,0 +1,87 @@ +--- +CIP: 0069 +Title: Script Signature Unification +Authors: Maksymilian 'zygomeb' Brodowicz +Status: Draft +Type: Standards Track +Created: 2022-08-23 +License: CC-BY-4.0 +--- + +## Simple Summary / Abstract + +This CIP unifies the arguments given to all types of Plutus scripts currently available (spending, certifying, rewarding, minting) by removing the argument of a datum. + +For a while now every builder, myself included have struggled with the mutual dependency issue (two validators that need to know each other's hash) when designing dapps and it is widely considered a substantial barrier to safe protocols and one that limits our design space considerably. + +The exact change would be to have every validator take as argument the redeemer and then the script context. Datums, only relevant to locking validators would be able to be provided by either looking them up in the ScriptContext or by extending the `Spending` constructor of `TxInfo` to carry `(TxOutRef, Datum)`. + +If this CIP were to be accepted and implemented, we'd be able to resolve a mutual dependency by merging two scripts into one, that can act as both say minting and spending depending on the purpose given. + +## Motivation / History + +As it stands the scripts being made on cardano often suffer this problem, and the tokens usually are made to be able to be minted at any time. This leads to further checks being made on the frontend and further fragilitiy of the systems we create. + +Use Case 1: Minting validator checks datum given to spending validator. The spending validator requires the token be present as witness of the datum's correctness. + +Use Case 2 (taken from Optim's Liquidity Bonds): Unique NFT is minted to give a unique identifier to a loan, that then gets reused by Bond Tokens. The spending validators require that NFT be present. + +Use Case 3 (taken from Minswap's Dex V1): NFT is minted for the same reason as above. It allows a minting policy to later mint LP tokens with that unique id token name. + +We see a similar pattern repeating over and over again, as I bid you, the developer reading this to provide witness. By allowing the multi-purpose policies (spending and any other) we increase the security of Cardano by giving us more confidence and allowing to design protocols that have their design driven by cardano's features, not limited by cardano's language. + +## Specification + +### Removing the datum argument + +All the sctipt purposes have a form of `Redeemer -> ScriptContext -> ()` except the `Spending` one. +It has form of `Datum -> Redeemer -> ScriptContext -> ()`. This is enforced by the cardano node. + +We make it conform to the general pattern by having it also have a 'signature' of `Redeemer -> ScriptContext -> ()` + +### (Optional) Providing the Datum in ScriptPurpose + +The datatype in question defined as + +``` +data ScriptPurpose + = Minting CurrencySymbol + | Spending TxOutRef + | Rewarding StakingCredential + | Certifying DCert +``` + +to be redefined to + +``` +data ScriptPurpose + = Minting CurrencySymbol + | Spending TxOutRef Datum + | Rewarding StakingCredential + | Certifying DCert +``` + +which will allow a script to easily match on its purpose and pick the datum out as it would do so normally. + +If this change is to not be added, the Datum can be picked out of `ScriptConext`. Adding unnecessary boilerplate and clock cycles. + +Cardano node would naturally verify that the correct `Datum` is given, as it does currently. + +## Rationale + +Unifying of the script signature is a very elegant solution to the problem, streamlining the experience of developing on cardano. +Given that accessing the datum is almost always made by a spending script, it makes sense to intdoduce that argument back to the `ScriptPurpose` that now plays a more important role. +It begs the question if it should be added as an argument to all validators, to further emphasize that fact. + +## Backwards compatibility + +This change is not backwards compatible; it must be introduced in a new Plutus language version. +Node code must be modified. + +## Path to Active + +The appropriate changes need to be made to the node code and a new language major version be introduced. + +## Copyright + +This CIP is licensed under Apache-2.0 \ No newline at end of file From 11d6a3eddbee07ea2727968e0d14b2d6d7ef4363 Mon Sep 17 00:00:00 2001 From: zygomeb Date: Tue, 25 Oct 2022 13:08:27 +0200 Subject: [PATCH 2/6] incorporate typo and language fixes, remove optional section --- CIP-0069/README.md | 38 +++++--------------------------------- 1 file changed, 5 insertions(+), 33 deletions(-) diff --git a/CIP-0069/README.md b/CIP-0069/README.md index e864b39b5..f42f92ef6 100644 --- a/CIP-0069/README.md +++ b/CIP-0069/README.md @@ -28,49 +28,21 @@ Use Case 2 (taken from Optim's Liquidity Bonds): Unique NFT is minted to give a Use Case 3 (taken from Minswap's Dex V1): NFT is minted for the same reason as above. It allows a minting policy to later mint LP tokens with that unique id token name. -We see a similar pattern repeating over and over again, as I bid you, the developer reading this to provide witness. By allowing the multi-purpose policies (spending and any other) we increase the security of Cardano by giving us more confidence and allowing to design protocols that have their design driven by cardano's features, not limited by cardano's language. +We see a similar pattern repeating over and over again as witnessed by dapp developers and auditors alike. By allowing the multi-purpose policies (spending and any other) we increase the security of Cardano by giving us more confidence and allowing to design protocols that have their architecture driven by Cardano's features, not limited by Cardano's language. ## Specification ### Removing the datum argument -All the sctipt purposes have a form of `Redeemer -> ScriptContext -> ()` except the `Spending` one. -It has form of `Datum -> Redeemer -> ScriptContext -> ()`. This is enforced by the cardano node. +All the sctipt purposes have a form of `Redeemer -> ScriptContext -> exists a. a` except the `Spending` one. +It has form of `Datum -> Redeemer -> ScriptContext -> exists a. a`. This is enforced by the Cardano node. -We make it conform to the general pattern by having it also have a 'signature' of `Redeemer -> ScriptContext -> ()` - -### (Optional) Providing the Datum in ScriptPurpose - -The datatype in question defined as - -``` -data ScriptPurpose - = Minting CurrencySymbol - | Spending TxOutRef - | Rewarding StakingCredential - | Certifying DCert -``` - -to be redefined to - -``` -data ScriptPurpose - = Minting CurrencySymbol - | Spending TxOutRef Datum - | Rewarding StakingCredential - | Certifying DCert -``` - -which will allow a script to easily match on its purpose and pick the datum out as it would do so normally. - -If this change is to not be added, the Datum can be picked out of `ScriptConext`. Adding unnecessary boilerplate and clock cycles. - -Cardano node would naturally verify that the correct `Datum` is given, as it does currently. +We make it conform to the general pattern by having it also have a type of `Redeemer -> ScriptContext -> ()` ## Rationale Unifying of the script signature is a very elegant solution to the problem, streamlining the experience of developing on cardano. -Given that accessing the datum is almost always made by a spending script, it makes sense to intdoduce that argument back to the `ScriptPurpose` that now plays a more important role. +Given that accessing the datum is almost always made by a spending script, it makes sense to introduce that argument back to the `ScriptPurpose` that now plays a more important role. It begs the question if it should be added as an argument to all validators, to further emphasize that fact. ## Backwards compatibility From 63f983306f3945fc2ec896c46bbf10133e3f338f Mon Sep 17 00:00:00 2001 From: zygomeb Date: Tue, 25 Oct 2022 13:24:00 +0200 Subject: [PATCH 3/6] incorporare discussion changes, some typos --- CIP-0069/README.md | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/CIP-0069/README.md b/CIP-0069/README.md index f42f92ef6..ca91be43c 100644 --- a/CIP-0069/README.md +++ b/CIP-0069/README.md @@ -16,11 +16,9 @@ For a while now every builder, myself included have struggled with the mutual de The exact change would be to have every validator take as argument the redeemer and then the script context. Datums, only relevant to locking validators would be able to be provided by either looking them up in the ScriptContext or by extending the `Spending` constructor of `TxInfo` to carry `(TxOutRef, Datum)`. -If this CIP were to be accepted and implemented, we'd be able to resolve a mutual dependency by merging two scripts into one, that can act as both say minting and spending depending on the purpose given. - ## Motivation / History -As it stands the scripts being made on cardano often suffer this problem, and the tokens usually are made to be able to be minted at any time. This leads to further checks being made on the frontend and further fragilitiy of the systems we create. +As it stands the scripts being made on cardano often suffer this problem, and the tokens usually are made to be able to be minted at any time. This leads to further checks being made on the frontend and further fragilitiy of the systems we create. When a mutual dependency arises we are forced to choose which script gets to statically know what's the hash of the other, and which has to be provided 'during runtime'. Use Case 1: Minting validator checks datum given to spending validator. The spending validator requires the token be present as witness of the datum's correctness. @@ -28,16 +26,24 @@ Use Case 2 (taken from Optim's Liquidity Bonds): Unique NFT is minted to give a Use Case 3 (taken from Minswap's Dex V1): NFT is minted for the same reason as above. It allows a minting policy to later mint LP tokens with that unique id token name. -We see a similar pattern repeating over and over again as witnessed by dapp developers and auditors alike. By allowing the multi-purpose policies (spending and any other) we increase the security of Cardano by giving us more confidence and allowing to design protocols that have their architecture driven by Cardano's features, not limited by Cardano's language. +We see a similar pattern repeating over and over again as witnessed by dapp developers and auditors alike. By allowing the multi-purpose policies (spending and any other) we increase the security of Cardano by giving us more confidence and allowing to design protocols that have their architecture driven by Cardano's features, not limited by Cardano's language. + +This primarily manifests in the ability to use a single validator for both minting and spending but the proposed solution makes it possible to use one validator for any and all purposes at once. ## Specification ### Removing the datum argument -All the sctipt purposes have a form of `Redeemer -> ScriptContext -> exists a. a` except the `Spending` one. -It has form of `Datum -> Redeemer -> ScriptContext -> exists a. a`. This is enforced by the Cardano node. +All the script purposes have a form of `Redeemer -> ScriptContext -> exists a. a` except the `Spending` one. +It has the following form: `Datum -> Redeemer -> ScriptContext -> exists a. a`. This is enforced by the Cardano ledger. + +We modify the general signature to be `ScriptArgs -> ScriptContext -> exists a. a`. -We make it conform to the general pattern by having it also have a type of `Redeemer -> ScriptContext -> ()` +```hs +data ScriptArgs = + RedeemerOnly Redeemer + | RedeemerAndDatum Redeemer Datum +``` ## Rationale From 6ba04f12fc2a70627dcad1b5d235e709bb682f5c Mon Sep 17 00:00:00 2001 From: zygomeb <87449555+zygomeb@users.noreply.github.com> Date: Thu, 24 Nov 2022 23:22:20 +0100 Subject: [PATCH 4/6] Update CIP-0069/README.md Co-authored-by: Matthias Benkort <5680256+KtorZ@users.noreply.github.com> --- CIP-0069/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-0069/README.md b/CIP-0069/README.md index ca91be43c..bbca056ef 100644 --- a/CIP-0069/README.md +++ b/CIP-0069/README.md @@ -1,5 +1,5 @@ --- -CIP: 0069 +CIP: 69 Title: Script Signature Unification Authors: Maksymilian 'zygomeb' Brodowicz Status: Draft From eda40156dd389c9d8dd43e8a56de7936303cba11 Mon Sep 17 00:00:00 2001 From: zygomeb <87449555+zygomeb@users.noreply.github.com> Date: Thu, 24 Nov 2022 23:22:28 +0100 Subject: [PATCH 5/6] Update CIP-0069/README.md Co-authored-by: Matthias Benkort <5680256+KtorZ@users.noreply.github.com> --- CIP-0069/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-0069/README.md b/CIP-0069/README.md index bbca056ef..3e2b6a9c7 100644 --- a/CIP-0069/README.md +++ b/CIP-0069/README.md @@ -2,7 +2,7 @@ CIP: 69 Title: Script Signature Unification Authors: Maksymilian 'zygomeb' Brodowicz -Status: Draft +Status: Proposed Type: Standards Track Created: 2022-08-23 License: CC-BY-4.0 From a6af7bbc501e936acd334730f6a37f28e9c6237d Mon Sep 17 00:00:00 2001 From: KtorZ Date: Tue, 6 Jun 2023 16:11:27 +0200 Subject: [PATCH 6/6] Update CIP-0069 to comply with latest CIP-0001 --- CIP-0069/README.md | 44 +++++++++++++++++++++++++++----------------- 1 file changed, 27 insertions(+), 17 deletions(-) diff --git a/CIP-0069/README.md b/CIP-0069/README.md index 3e2b6a9c7..aaf4df638 100644 --- a/CIP-0069/README.md +++ b/CIP-0069/README.md @@ -1,30 +1,34 @@ --- CIP: 69 -Title: Script Signature Unification -Authors: Maksymilian 'zygomeb' Brodowicz +Title: Script Signature Unification +Category: Plutus +Authors: + - Maksymilian 'zygomeb' Brodowicz +Implementors: N/A Status: Proposed -Type: Standards Track +Discussions: + - https://github.com/cardano-foundation/CIPs/pull/321 Created: 2022-08-23 License: CC-BY-4.0 --- -## Simple Summary / Abstract +## Abstract This CIP unifies the arguments given to all types of Plutus scripts currently available (spending, certifying, rewarding, minting) by removing the argument of a datum. -For a while now every builder, myself included have struggled with the mutual dependency issue (two validators that need to know each other's hash) when designing dapps and it is widely considered a substantial barrier to safe protocols and one that limits our design space considerably. +For a while now every builder, myself included have struggled with the mutual dependency issue (two validators that need to know each other's hash) when designing dapps and it is widely considered a substantial barrier to safe protocols and one that limits our design space considerably. -The exact change would be to have every validator take as argument the redeemer and then the script context. Datums, only relevant to locking validators would be able to be provided by either looking them up in the ScriptContext or by extending the `Spending` constructor of `TxInfo` to carry `(TxOutRef, Datum)`. +The exact change would be to have every validator take as argument the redeemer and then the script context. Datums, only relevant to locking validators would be able to be provided by either looking them up in the ScriptContext or by extending the `Spending` constructor of `TxInfo` to carry `(TxOutRef, Datum)`. -## Motivation / History +## Motivation: why is this CIP necessary? As it stands the scripts being made on cardano often suffer this problem, and the tokens usually are made to be able to be minted at any time. This leads to further checks being made on the frontend and further fragilitiy of the systems we create. When a mutual dependency arises we are forced to choose which script gets to statically know what's the hash of the other, and which has to be provided 'during runtime'. -Use Case 1: Minting validator checks datum given to spending validator. The spending validator requires the token be present as witness of the datum's correctness. +- Use Case 1: Minting validator checks datum given to spending validator. The spending validator requires the token be present as witness of the datum's correctness. -Use Case 2 (taken from Optim's Liquidity Bonds): Unique NFT is minted to give a unique identifier to a loan, that then gets reused by Bond Tokens. The spending validators require that NFT be present. +- Use Case 2 (taken from Optim's Liquidity Bonds): Unique NFT is minted to give a unique identifier to a loan, that then gets reused by Bond Tokens. The spending validators require that NFT be present. -Use Case 3 (taken from Minswap's Dex V1): NFT is minted for the same reason as above. It allows a minting policy to later mint LP tokens with that unique id token name. +- Use Case 3 (taken from Minswap's Dex V1): NFT is minted for the same reason as above. It allows a minting policy to later mint LP tokens with that unique id token name. We see a similar pattern repeating over and over again as witnessed by dapp developers and auditors alike. By allowing the multi-purpose policies (spending and any other) we increase the security of Cardano by giving us more confidence and allowing to design protocols that have their architecture driven by Cardano's features, not limited by Cardano's language. @@ -34,10 +38,10 @@ This primarily manifests in the ability to use a single validator for both minti ### Removing the datum argument -All the script purposes have a form of `Redeemer -> ScriptContext -> exists a. a` except the `Spending` one. -It has the following form: `Datum -> Redeemer -> ScriptContext -> exists a. a`. This is enforced by the Cardano ledger. +All the script purposes have a form of `Redeemer -> ScriptContext -> a` except the `Spending` one. +It has the following form: `Datum -> Redeemer -> ScriptContext -> a`. This is enforced by the Cardano ledger. -We modify the general signature to be `ScriptArgs -> ScriptContext -> exists a. a`. +We modify the general signature to be `ScriptArgs -> ScriptContext -> a`. ```hs data ScriptArgs = @@ -45,11 +49,11 @@ data ScriptArgs = | RedeemerAndDatum Redeemer Datum ``` -## Rationale +## Rationale: how does this CIP achieve its goals? Unifying of the script signature is a very elegant solution to the problem, streamlining the experience of developing on cardano. Given that accessing the datum is almost always made by a spending script, it makes sense to introduce that argument back to the `ScriptPurpose` that now plays a more important role. -It begs the question if it should be added as an argument to all validators, to further emphasize that fact. +It begs the question if it should be added as an argument to all validators, to further emphasize that fact. ## Backwards compatibility @@ -58,8 +62,14 @@ Node code must be modified. ## Path to Active -The appropriate changes need to be made to the node code and a new language major version be introduced. +### Acceptance Criteria + +- [ ] The change has been implemented in the Plutus codebase, integrated in the ledger and released through a hard-fork. + +### Implementation Plan + +None. ## Copyright -This CIP is licensed under Apache-2.0 \ No newline at end of file +This CIP is licensed under Apache-2.0