CIP-???? | Supercharged Native Scripts

[nielstron]

Abstract

This CIP proposes replacing the current native scripts used for minting Cardano Native Tokens with simple, parameterized smart contracts called "Supercharged Native Scripts". The main goal is to allow users to burn their native assets at any time by utilizing smart contracts that enforce the minting conditions while always allowing burning. The concept is standardized and generalized for broader use-cases.

(rendered version in branch)

This is a proposed solution to #392

[Ryun1]

In your PR you mention that this proposal addresses the CPS at #392. It would be good to explain how it addresses the CPS, and answer the questions that the CPS poses, here in the rationale.

[nielstron]

I have added a few more sentences on how this addresses #392 in the rationale section :)

[SebastienGllmt]

If you're trying to use Plutus to enforce extra conditions onto native scripts, I suggest that instead #309 is implemented since it requires significantly less changes to Plutus and achieves the same result.

Notably, it would allow you to write a native script that looks like

{
	"type": "any",
	"scripts": [{
		"type": "all",
		"scripts": [{
				"type": "before",
				"slot": 40272443
			},
			{
				"type": "sig",
				"keyHash": "ed6f3e2144d70e839d8701f23ebcca229bcfde8e1d6b7838bda11ac8"
			}
		]
	}, {
		"type": "all",
		"scripts": [{
				"type": "after",
				"slot": 40272443
			},
			{
				"type": "script",
				"scriptHash": "plutus_script_hash_here"
			}
		]
	}]
}

[nielstron]

@SebastienGllmt Thanks for pointer. My suggestion differs from #309 in the point that no changes to the ledger nor Plutus are required at all.

The proposal instead suggests a template of plutus scripts that can be programmed using native scripts for users that don't know plutus or don't want to learn it.

The only thing that needs to be changed is the default tutorial on getting started with native tokens :)

[rphair]

@michaelpj we're talking about this at the CIP meeting now and it's come up that you would be welcome to review this proposal 🙏 (including the question of whether or not to use Plutus)

[michaelpj]

I'm quite confused by this proposal.

1. Plutus scripts can already be used as minting policies, which covers all the expressiveness in this proposal.
2. The proposal itself is quite complex, and feels ad-hoc to me.
3. There are a number of simpler alternatives, some of which are mentioned in CPS-???? | Properly burning NFTs / tokens #392

[michaelpj]

It's a small number of changes in the ledger. What security guarantees does it violate? (I also used to think this but have now been convinced it's actually fine)

[nielstron]

I agree that changing the ledger might be fine after all. Downside: need to change the ledger. Upside: No need for opt-in and retroactive.

[michaelpj]

They can already do this today, though? There's nothing that stops you writing your minting policy to say "burning is always allowed".

[michaelpj]

Also, it's not clear that opt-in is good enough. That means it's still easy for people not to opt-in (it doesn't benefit them much, and they have to do something additional, so why would they?), meaning that people will still be stuck with significant amounts of junk.

[nielstron]

It's not expressable in Native Scripts and Plutus is so complicated that it can not be expected the average token minter is able to set up/compile a contract on their own. The opt-in thing is a problem, agree.

[michaelpj]

What does it mean to make something the "default"?

[nielstron]

Basically replacing every tutorial that says "use this native script to mint your token" with "use this other script to mint your token". Not sure how to better express this.

[michaelpj]

The current process for minting and burning Cardano Native Tokens relies on native scripts

No it doesn't? You can use a Plutus script if you want more complex logic.

[michaelpj]

You can already just use a Plutus script for this, so I'm confused about what this adds.

[nielstron]

@michaelpj The delta of this proposal is not to propose something that was not possible before, but to propose a standard that is tangible for the average user. While yes, all of this can of course be done in Plutus 1) we can not expect everyone to learn haskell for minting tokens 2) even a seasoned computer scientist will waste more than 5h of their life trying to compile a Plutus contract they found on the internet (not sure how much exaggerated this is). Parameterization is the remedy here.

Specifically, this proposes a set of basic smart contracts that can be parameterized by the average user and are hence as simple to handle as native scripts, yet much more expressive.

The specific use case here is an opt-in, no-ledger-change approach to making advanced tokenomics (simplest case: always allow burn tokens) accessible to average creators.

[rphair]

@nielstron apparently neither the Plutus team nor Plutus developers were in agreement about the problem or the solution, so after 16 months of no activity (without having been acknowledged as a CIP candidate) we have to close this with the Abandoned tag.

However if you've done any work to demonstrate this idea in the meantime, please feel free to document it here, reopen the pull request, and resolve the merge conflict... and editors will tag it appropriately and give a current review.