Skip to content
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.

Sign up for GitHub

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

Jump to bottom

CIP-0069 | single argument Scripts #774

Closed
wants to merge 3 commits into from
Closed

CIP-0069 | single argument Scripts #774

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
50a40e4
Start updating specification to account for no datum spends
MicroProofs Mar 4, 2024
cf9dcd9
Add to more sections
MicroProofs Mar 4, 2024
037b441
remove usage of recent
MicroProofs Mar 4, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 23 additions & 1 deletion CIP-0069/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,8 @@ The exact change would be to have every validator take as argument the redeemer

## Motivation: why is this CIP necessary?

### Multi-purpose Scripts

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.
Expand All @@ -30,10 +32,24 @@ As it stands the scripts being made on cardano often suffer this problem, and th

- 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 scripts (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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Soley this reason is enough justification for this CIP. As in the case of the withdraw-zero trick and CIP 112, it is simply not healthy for the most critical and widely used design patterns throughout the ecosystem to rely on what is essentially an obscure implementation detail / black magic trick. Given the importance of this design pattern, and its demonstrable utility (on mainnet across a huge number of protocols in the ecosystem in production) it is of great importance that this is granted more official support and formalization.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would, however, remove the part about the "recent Nami bug" since AFAIK CIP are supposed to be timeless and this might lose context in the future. Maybe replace with a brief line about how a bug in nami caused UTxOs without datums to be sent to a script and thus mistakenly locked forever.


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.

### No Datum Spend Purpose

One of the major footguns of Plutus scripts is if a user sends to the script with a wrong or missing datum. This has happened in the case of the Nami wallet having a bug that caused the wrong address to be chosen. There are other instances of user error where they send from a CEX to a script address. A wrong datum can be handled by the Plutus scripts themselves by having an alternative execution branch if type does not match the expected datum type. But in the case of no datum the script is not run and fails in phase 1. The other motivation of this CIP is to be able to create spend scripts that can handle the no datum case.

I see three major use cases when it comes to running spend scripts without datums:

- Use Case 1: A script that acts as a wallet for users. By having no datum spending the user can send directly from exchanges or have friends send to their smart contract wallet with no datum needed.

- Use Case 2: As a DAO treasury. The funds in this script would be controlled by a DAO and anyone can donate/contribute to the DAO without a datum.

- Use Case 3: Allow dApp protocols to have a claim or withdraw mechanism (similar to Ethereum for tokens sent to a contract without call) for claiming tokens sent without a datum.

I'd be remiss if I didn't mention CIP-0112 which has been expanded to improve native script capabilities to provide an alternative solution for use case 1 and 2. But for use case 3, CIP-0112 does not enable a "claim or withdraw mechanism" for contracts.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1


## Specification

### Removing the datum argument
Expand All @@ -49,12 +65,18 @@ data ScriptArgs =
| RedeemerAndDatum Redeemer Datum
```

In the case of a spend purpose, the ledger would execute the script with RedeemerAndDatum Redeemer Datum if a datum is present in the spending input. Otherwise the ledger would execute the script with RedeemerOnly Redeemer. In all other purposes the ledger would enforce only RedeemerOnly Redeemer is used with the script execution.

## 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.

I'm not sure what the above section is talking about?

This CIP turns all scripts into 2 arg scripts with a variant for the first argument that can be matched on to determine if a datum and redeemer or only redeemer is present.

## Backwards compatibility

This change is not backwards compatible; it must be introduced in a new Plutus language version.
Expand Down