From 58813b73b6d3d0952efcd7115137bd08038c1b83 Mon Sep 17 00:00:00 2001 From: Michael Peyton Jones Date: Mon, 22 Jan 2024 14:18:38 +0000 Subject: [PATCH 1/9] CIP for checking script return values --- CIP-????/README.md | 83 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 83 insertions(+) create mode 100644 CIP-????/README.md diff --git a/CIP-????/README.md b/CIP-????/README.md new file mode 100644 index 0000000000..d474afdaca --- /dev/null +++ b/CIP-????/README.md @@ -0,0 +1,83 @@ +--- +CIP: ? +Title: Explicit script return values +Category: Plutus +Status: Proposed +Authors: + - Michael Peyton Jones +Implementors: + - Michael Peyton Jones +Discussions: + - https://github.com/cardano-foundation/cips/pulls/? +Created: 2024-01-22 +License: CC-BY-4.0 +--- + +## Abstract + +Today, Plutus Core scripts signal success or failure exclusively by whether the script terminates normally or abnormally (with an error). +This leads to some false positives, where a script terminates normally, but this was not intended by the author. +We propose to additionally look at what the script evaluates to when checking for success or failure. + +## Motivation: why is this CIP necessary? + +Consider the following Plutus scripts, intended to be used as minting policy scripts: + +``` +\redeemer -> \datum -> \script-context -> (builtin error) +``` + +``` +\redeemer -> \script-context -> (con false) +``` + +Today, both of these will unconditionally succeed! + +1. Minting policies only receive two arguments, but this script expects three before it does any work. It therefore evaluates successfully to a lambda. +2. This script evaluates _successfully_ to `(con false)`, but the return value is irrelevant since it terminates successfully. + +In both cases the user has made a mistake, but this result is that the script fails _open_, that is, anyone can spend such an output. +A variant of the first mistake is for a script to expect too _few_ arguments, but this will almost always result in an error and so fail closed.[^failing-open] + +[^failing-open]: It is not universally clear whether it is good to fail open or closed, but generally for systems like this we tend to fail closed, and it is also easier to detect such failures during testing. + +Historically, Plutus Core was going to be a typed language, and at least the first kind of error would have been caught by the typechecker. +However, today there is little stopping people from making such mistakes. + +While these mistakes are relatively easily avoidable (any good smart contract toolkit should prevent them), it is nonetheless a potential landmine for users. + +## Specification + +The specification for checking whether a Plutus Core script accepts a transaction changes as follows (the new part is in brackets): + +> A Plutus Core script S with arguments A1...An accepts a transaction if 'eval(S A1 ... An)' succeeds [and evaluates to the builtin boolean constant 'true']. + +This change is not backwards-compatible and will need to go into a new Plutus ledger language. + +## Rationale: how does this CIP achieve its goals? + +Since the return value of a script will now be significant, a script will only succeed if the whole thing evaluates to 'true'. +This is very unlikely to happen by accident: mistakes in the number of arguments or in what to return will result in failure. + +### Alternatives + +- The status quo is not terrible, and we could simply accept it. +- We could specifically detect when a script returns a lambda, and say that that is a failure. + - This is patching up one particular hole, whereas the proposal here has much more coverage by failing everything that doesn't quite specifically return 'true'. + +## Path to Active + +### Acceptance Criteria + +- The proposal is implemented in the ledger +- The ledger changes are released on mainnnet + +### Implementation Plan + +- The Plutus team will implement the changes to the ledger + +## Copyright + +This CIP is licensed under [CC-BY-4.0][]. + +[CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode From 90ca45863d833c9378438c90c2a1b8fdc2a7ac4a Mon Sep 17 00:00:00 2001 From: Michael Peyton Jones Date: Wed, 24 Jan 2024 11:51:54 +0000 Subject: [PATCH 2/9] Use unit instead --- CIP-????/README.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/CIP-????/README.md b/CIP-????/README.md index d474afdaca..1bdf983329 100644 --- a/CIP-????/README.md +++ b/CIP-????/README.md @@ -1,4 +1,4 @@ ---- +-- CIP: ? Title: Explicit script return values Category: Plutus @@ -50,18 +50,20 @@ While these mistakes are relatively easily avoidable (any good smart contract to The specification for checking whether a Plutus Core script accepts a transaction changes as follows (the new part is in brackets): -> A Plutus Core script S with arguments A1...An accepts a transaction if 'eval(S A1 ... An)' succeeds [and evaluates to the builtin boolean constant 'true']. +> A Plutus Core script S with arguments A1...An accepts a transaction if 'eval(S A1 ... An)' succeeds [and evaluates to the builtin constant 'unit']. This change is not backwards-compatible and will need to go into a new Plutus ledger language. ## Rationale: how does this CIP achieve its goals? -Since the return value of a script will now be significant, a script will only succeed if the whole thing evaluates to 'true'. +Since the return value of a script will now be significant, a script will only succeed if the whole thing evaluates to 'unit'. This is very unlikely to happen by accident: mistakes in the number of arguments or in what to return will result in failure. ### Alternatives - The status quo is not terrible, and we could simply accept it. +- The return value could be a boolean constant, with 'true' indicating success and 'false' indicating failure. + - This is slightly more complicated, and technically we only need a designated success value, since "anything else" indicates failure. We don't need to distinguish between "normal exit indicating rejection of the transaction" and "abnormal exit". - We could specifically detect when a script returns a lambda, and say that that is a failure. - This is patching up one particular hole, whereas the proposal here has much more coverage by failing everything that doesn't quite specifically return 'true'. From 0b8733e15c3408e3f6fdc24b7b66f829e6390570 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Tue, 30 Jan 2024 19:51:38 +0530 Subject: [PATCH 3/9] add proper PR number to Discussions --- CIP-????/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-????/README.md b/CIP-????/README.md index 1bdf983329..e28dee40fa 100644 --- a/CIP-????/README.md +++ b/CIP-????/README.md @@ -8,7 +8,7 @@ Authors: Implementors: - Michael Peyton Jones Discussions: - - https://github.com/cardano-foundation/cips/pulls/? + - https://github.com/cardano-foundation/CIPs/pull/747 Created: 2024-01-22 License: CC-BY-4.0 --- From bb753ff29236d809af3396e81dcbc6c5565821c8 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Tue, 30 Jan 2024 19:52:23 +0530 Subject: [PATCH 4/9] adding Path to Active checkboxes, capitalising proper nouns --- CIP-????/README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/CIP-????/README.md b/CIP-????/README.md index e28dee40fa..1e72ad36b2 100644 --- a/CIP-????/README.md +++ b/CIP-????/README.md @@ -71,12 +71,12 @@ This is very unlikely to happen by accident: mistakes in the number of arguments ### Acceptance Criteria -- The proposal is implemented in the ledger -- The ledger changes are released on mainnnet +- [ ] The proposal is implemented in the Ledger. +- [ ] The ledger changes are released on Mainnnet. ### Implementation Plan -- The Plutus team will implement the changes to the ledger +- [ ] The Plutus team will implement the changes to the Ledger. ## Copyright From b91e01bfbc40ad0f50678252528bc77e044b8e7d Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Tue, 30 Jan 2024 19:56:57 +0530 Subject: [PATCH 5/9] -- instead of --- beginning preamble seems invalid --- CIP-????/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-????/README.md b/CIP-????/README.md index 1e72ad36b2..c622dc3da4 100644 --- a/CIP-????/README.md +++ b/CIP-????/README.md @@ -1,4 +1,4 @@ --- +--- CIP: ? Title: Explicit script return values Category: Plutus From 61070931ef363d41da1f15064edfdd8c873a824d Mon Sep 17 00:00:00 2001 From: Michael Peyton Jones Date: Wed, 20 Mar 2024 10:49:20 +0000 Subject: [PATCH 6/9] Add number --- {CIP-???? => CIP-0117}/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename {CIP-???? => CIP-0117}/README.md (99%) diff --git a/CIP-????/README.md b/CIP-0117/README.md similarity index 99% rename from CIP-????/README.md rename to CIP-0117/README.md index c622dc3da4..95e50c1d17 100644 --- a/CIP-????/README.md +++ b/CIP-0117/README.md @@ -1,5 +1,5 @@ --- -CIP: ? +CIP: 0117 Title: Explicit script return values Category: Plutus Status: Proposed From 31a14ea1354892c22357d276221f04b1b1d5e2a8 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Tue, 11 Jun 2024 21:56:41 +0530 Subject: [PATCH 7/9] fixed formatting of CIP number Co-authored-by: Ryan <44342099+Ryun1@users.noreply.github.com> --- CIP-0117/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-0117/README.md b/CIP-0117/README.md index 95e50c1d17..40121029a5 100644 --- a/CIP-0117/README.md +++ b/CIP-0117/README.md @@ -1,5 +1,5 @@ --- -CIP: 0117 +CIP: 117 Title: Explicit script return values Category: Plutus Status: Proposed From ede1db3985c92a3ff3b717157974daa6460e67bc Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Tue, 11 Jun 2024 21:58:29 +0530 Subject: [PATCH 8/9] implemented in the Ledger Co-authored-by: Ryan <44342099+Ryun1@users.noreply.github.com> --- CIP-0117/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-0117/README.md b/CIP-0117/README.md index 40121029a5..95b1331d7a 100644 --- a/CIP-0117/README.md +++ b/CIP-0117/README.md @@ -71,7 +71,7 @@ This is very unlikely to happen by accident: mistakes in the number of arguments ### Acceptance Criteria -- [ ] The proposal is implemented in the Ledger. +- [x] The proposal is implemented in the Ledger. - [ ] The ledger changes are released on Mainnnet. ### Implementation Plan From 8c93829e1dd3621885a8e5e2a7149ef99f2b4176 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Tue, 11 Jun 2024 21:59:10 +0530 Subject: [PATCH 9/9] implemented in the Ledger (2 of 2, both confirmed in meantime) Co-authored-by: Ryan <44342099+Ryun1@users.noreply.github.com> --- CIP-0117/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-0117/README.md b/CIP-0117/README.md index 95b1331d7a..13e55d7cb1 100644 --- a/CIP-0117/README.md +++ b/CIP-0117/README.md @@ -76,7 +76,7 @@ This is very unlikely to happen by accident: mistakes in the number of arguments ### Implementation Plan -- [ ] The Plutus team will implement the changes to the Ledger. +- [x] The Plutus team will implement the changes to the Ledger. ## Copyright