CIP-0054? | Cardano Smart NFTs #263
Conversation
kieransimkin
changed the title
| Authors: Kieran Simkin | ||
| Comments-URI: https://forum.cardano.org/t/cip-draft-cardano-smart-nfts/100470 | ||
| Status: Draft | ||
| Type: Standards |
There was a problem hiding this comment.
This one would be a "Process" track as it does not entail any changes in the core Cardano components (no ledger or consensus changes; it is purely built upon the current system capabilities).
There was a problem hiding this comment.
Support of the mutable NFT part is necessary for recording system eternal changes and will allow to chase use cases like gaming (build your character, add items to stash, work your stats) as well as multi-verse cases (transfer your character and play in another game; interactions with multi-verse market places, etc.). You can also chase cases as Cardano Weather Station, Cardano Seismic Activity, Cardano Financial Markets, New Google Maps layers from Cardano NFTs (Helium internet coverage, Favourite fruit prices in your surroundings,...). And many many many more!
|
(comment made prematurely) |
|
Just continuing my prophet-of-doom role to point out that CIP-25 still has security problems. |
|
|
||
| ## Abstract | ||
|
|
||
| This CIP specifies a standard for an API which should be provided to Javascript NFTs, it also defines some additions to the 721 metadata standard defined in [CIP-0025](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0025) which allow an NFT to specify it would like to receive certain current information from the blockchain. |
There was a problem hiding this comment.
Anything below this paragraph seems to belong more the "Motivation" than the abstract.
| Created: 2022-05-18 | ||
| License: CC-BY-4.0 | ||
| --- | ||
| # Cardano “Smart NFTs” |
There was a problem hiding this comment.
Please no title in the markdown 🙏, the title already is part of the front-matter data.
|
|
||
| This combination of functionality enables many exciting new possibilities with on-chain NFTs. | ||
|
|
||
| ## Description: |
There was a problem hiding this comment.
Please rename as Specification (no colon)
There was a problem hiding this comment.
Whoops, not sure where my mind was.
|
|
||
| ``` | ||
| { | ||
| "721": { |
There was a problem hiding this comment.
This proposal should use new key or, a new version number for 721. But either way, there needs to be a way to programmatically tell the expected structure of the metadata.
|
|
||
| "uses": { | ||
| "transactions": <string | array>, | ||
| "tokens": <string | array>, |
There was a problem hiding this comment.
I'd suggest to avoid double types when designing API as much as possible. If there's only one item, then an array of one item is just fine and makes it much easier for code dealing with that structure later on.
There was a problem hiding this comment.
Also, consider providing a CDDL specification for that on-chain format, rather than JSON. JSON is only how on-chain metadata are typically rendered, but they are actual stored as binary objects following in CBOR.
|
|
||
| ``` | ||
| "uses": { | ||
| "transactions": "own" |
There was a problem hiding this comment.
What would be the semantic of "own"? How would a transaction identify as "own"? Would that refer to any transaction that has moved this NFT around (even if it didn't change wallets but was just carried as change)? Would that include the minting transaction? etc..
| "asset1frc5wn889lcmj5y943mcn7tl8psk98mc480v3j" | ||
| ] | ||
| } | ||
| ``` |
There was a problem hiding this comment.
Both examples with the asset id and the address are heavily user-facing / JSON-specific. In principle, this metadata would be stored on-chain and I would advise against storing these things are text strings. Both addresses and asset ids have well-defined on-chain binary representation, use them!
Also, regarding asset fingerprints, these are not meant to be global unique identifiers. They are fine in the context of a single wallet but they should not be used as id in a global setup. Rather, use the asset id (i.e. policy id + asset name). Incidentally, it would be okay to however display the asset fingerprint to the user, so long as it is stored as an asset id.
|
|
||
| To enable modifier tokens - (that is, a token which you can hold alongside a Smart NFT which changes the Smart NFT's appearance or behaviour in some way); we provide a way for the Smart NFT to monitor the tokens held by a specific address. Similarly to the “transactions” key, the “tokens” key will also accept either a string or array. | ||
|
|
||
| In this case we define the “own” keyword to mean the tokens held by the same stake key that currently holds the Smart NFT itself. |
There was a problem hiding this comment.
What about stake part not directly associated to a single stake key? For instance, a stake part captured by a native monetary script as a combination of three keys? Or simply, an address without stake part? Would those be simply excluded from the 'own' keyword?
|
|
||
| It would also be nice to be able to retrieve data that has been previously committed to the blockchain, separately to the NFT which wishes to access it. This would be useful for retrieving oracle data such as current Ada price quotes – as well as for allowing an NFT to import another NFT’s data. | ||
|
|
||
| Further to this - for on-chain programatically generated NFTs, it makes sense to mint the code to render the NFT as one token, and then have the individual NFTs contain only the input variables for that code. This CIP specifies an additional metadata option which specifies that an NFT should be rendered by another token - this will massively reduce code duplication in on-chain NFTs. |
There was a problem hiding this comment.
side-note: I'd love to see some example of existing JavaScript NFT in introduction to build a mental picture of those :)
| "transactions": "own", | ||
| "renderer": "asset1frc5wn889lcmj5y943mcn7tl8psk98mc480v3j" | ||
| } | ||
| ``` |
There was a problem hiding this comment.
I am not sure to understand the rationale for storing the rendering code on-chain 🤔 ? It seems to me like a misuse of a blockchain as a database (which it is not!). If the goal is to enforce that only a certain code is executed for rendering an certain NFT, I'd suggest to instead store a hash of that code and have client applications select the right rendering code based on that.
If the issue is to keep the client as dumb as possible then, I'd suggest to store the code on a system meant to store files such as IPFS, and only record a link / hash to that file on the Cardano blockchain.
mangelsjover
added
the
State: Waiting for Author
|
today's IO Dev Digest has linked back to this thread, calling for "community feedback" - https://mailchi.mp/iohk/dev-april-digest-675582 |
mangelsjover
added
the
State: Last Check
rphair
removed
State: Last Check
I've received a lot of feedback on this proposal both on the forum and in direct communication with various NFT creators. I've redrafted this proposal based on that feedback - I'm now moving on to create an initial implementation at Artifct - I will of course continue to take feedback and update the document as the implementation progresses.