CIP-0068 | Datum Metadata Standard #299
Conversation
|
Is there any consideration given or made for the amount of Lovelace that would potentially need to be permanently locked to hold individual metadatums for each token? For a 10k NFT set that is "locked" you're potentially talking about permanently sequestering ~15k ADA just to utilize this method. |
|
Aside from the locked Ada, I see other complications that can come out of this, including introducing attack vectors that are otherwise non existent with native assets. If the goal is to have update-able metadata; I've already solved this with the GYOA platform for Cardano Budz, and am happy to share my concepts with you. It doesnt require any locking of ada, nor a smart contract; which only adds more bloat. The next complication is getting all wallet makers to adopt this new standard; which seems fairly unlikely. It would be much better to have an open dialogue with asset makers. Much like Open Source software, the final product can be substantially better with more people's input. |
|
[This is my personal GitHub but I am @WildTangz / @iOddestHumanDad on Twitter] I like the proposal and think it has some good use cases as you mentioned. Just to clarify my understanding:
If I am understanding correctly I think there are a few potential downsides:
Couple of questions for you @alessandrokonrad:
|
Right off the bat, there is no need for overly complicating evolving metadata. You dont need to hold an asset to update its metadata. You just mint another with the updated metadata, then burn it. The holders asset is thusly updated. No smart contract required, no locked ada, and no dodgy wallet logic to say "If I hold this asset, show this other assets metadata". |
I'm not sure what attack vectors you mean exactly, but if you talk about usage of Plutus scripts then you face the same risks with any dApp you interact. But you can verify the contracts as they should be open source.
That's not the goal, but it's what the standard allows you to do as it's very generalized. I'm not sure how you achieve utxo authenticity without a native asset. With the standard you should be able to bring the metadata securely into the plutus validator context. But I'm happy to hear your solution.
I don't think so
Well that's why this CIP is open. Anyone is free to contribute to it. |
That is true you can do that, but there are some drawbacks to that approach (namely diluting the supply, albeit temporarily and confusing intrepid blockchain explorers). The contribution here to update the metadata without changing supply is novel in my opinion. |
|
My primary concern would be the Ada/Lovelace "locked" via the minUTXO but the secondary concern is for ledger bloat due to needing, for example, 10k UTXO on-chain that can never be modified, consolidated, or moved without "rugging" the user tokens. So, particularly for a "locked" token/set... How is this method preferable to the existing CIP-25 metadata standard? I suppose in this case the answer is "it's not" and this particular CIP would actually more be suitable in cases where there is a great and on-going need to modify or change the metadata of a user token based on some sort of validation or approval via the token issuer (policy holder and controller of the reference tokens). i.e. I want to update my phone number in my DID... I go to website example.com and perform an update after authenticating myself, and example.com issues the update to my DID reference token. Still not 100% sure that this is ultimately the best approach due to the aforementioned "issues" but worth considering. |
Good question and yes, we have. Note that the locking script for the Key point here, this is a fundamental property of the ledger and has nothing to do with how you implement your script, or this standard for that matter. The standard opens up all the possibilities that plutus has for the developer, it is our responsibility to be creative with it! |
Thank you for adding to the dialogue! I know that currently we have a system for updating NFT's in CIP25, but there is a big problem with that way of doing things, it is centralized and errors may occur. The artist must check that the correct metadata is put in while burning/minting it, plutus cannot access that. We need a one size fits all standard that will solve the problems across the board for all token classes. That is what this standard is achieving. |
Correct, but you are not only limited by using your private keys to update them as a creator of the collection. You can utilize all the power of plutus! With plutus, you can predetermine exactly under what conditions metadata is update so that no central party has to control it.
This is also correct, thought I must say I dislike the idea of putting votes publicly on a blockchain (you can attack opponents of your view). Instead, people should use protocols like mixing nets to obscure the origin of the vote without losing the ability to verify the vote. A lot of research is already put into this. But that's just my two ada.
You do not have to mint tokens directly. You can use Merkle trees in your minting policy to predetermine exactly what a collection might entail. Also see the post above about implementing a burning function in the policy. Again, the point of the standard is to open up the full power of plutus.
This is more of a legal matter, but my guess is that the one who controls the value has the IP, that is not the
Yeah, the minting with time locking simple scripts is not optimal since it is centralized.
This standard allows for the wrapping of existing tokens by creating a script with predetermined metadata associated with the previous collection (using again Merkle trees). So, if the right tools are built, the standard is not necessary anymore.
Fair and good question! We struggled as well with the way to represent data on-chain in the datum when writing this CIP. Initially, we tried to decode the data in CBOR, but this raised issues with on-chain decoding, which consumes a lot of execution units. See (1). I just commented on all your remarks, hope my answer are okay for you. Thanks for your input and effort regarding this CIP! Much appreciated :) |
I agree with this. There is some good research on this from a while back I knew about: https://dl.acm.org/doi/10.1145/1866307.1866346. It uses xors to send encrypted communications (a communication could just be a vote).
Sorry I meant not the cost, but the minUTXO you have to lock up. I get that this is technically "the user's money", but right now you only have to send (1 x minUTXO) back with each asset. This proposal would double that, lowering creator's fees.
Definitely a legal matter. This is more along the lines of "the difference between theory and practice is in theory quite small, but in practice quite large". I don't think the standard itself implies anything from it, it is just that if the standard is widely adopted, it could add friction to the creator ecosystem. m2c
Agreed.
But, unless I am mistaken, you are specifying the metadata structure as serialized JSON inside of this proposal. Is this proposal just about arbitrary bytestrings? For example, I would love a metadata standard that enabled me to do columnar compression of PFP traits (e.g., "Wings" -> 0x00000001, "Tails" -> 0x00000010) and then I can compose them on-chain with an AND. If I put that in the reference NFT as of CIP-0068?, it would not conform to the standard as I understand it.
Fair. I would like to see support for more columnar compression formats that are used in the Big Data ecosystem (last time I checked Avro was popular), but likely out of scope for this CIP.
No worries, thanks for the consideration! |
|
The idea of accessing metadata in Plutus Scripts is definitely something that would expand the possibilities of what the Cardano Smart contract can achieve in many aspects. The proposed solutions suggest for a standard applicable to all versions of Plutus that doesn't require changes to the protocol I'd like to suggest an alternative way to access metadata through script context. This idea obviously requires a new (extended) format of the ScriptContext provided to the script, but it comes with the advantage of being easier to use and implement. The high-level idea is to have a field in the ScriptContext containing the metadata attached to the validating transaction (if any) as mentioned by @alessandrokonrad in a brief open discussion on Twitter including the metadata in the script context doesn't really solve for the accessibility of metadata on-chain outside the minting transaction. to overcome this issue could be proposed a standard that allows exposing the metadata through an oracle. The high-level idea of such a standard is to have a minting policy that checks for an UTxO to be created at the address of such Oracle, containing the information present in the metadata of the minting transaction in the attached Datum; and fails otherwise. this way the metadata information is stored at the Oracle address and stays on-chain |
The issue is solved within the CIP. You have the |
| - The `user token` and associated `reference NFT` **must** follow the standard naming pattern. The asset name of both assets is prefixed with its respective `asset_name_label` followed by a pattern defined by the asset class (e.g. asset_name_label 222) | ||
|
|
||
| Some remarks about the above, | ||
| 1. The `user token` and `reference NFT` do not need to be minted in the same transaction. The order of minting is also not important. |
There was a problem hiding this comment.
This is a clever approach that also doesn't depend on any logging standard.
One way you could get around some of the restrictions with your approach is to instead having some meta-NFT for the project that is used in all the transactions that create the reference NFTs and the user tokens. This would avoid the asset-name stuffing issue your CIP introduces and this meta-NFT could be kept after the initial mint is done to add other reference NFT CIPs for the collection in the future without having to keep the policy used for the user tokens open. This is of course significantly more complicated than your approach though
There was a problem hiding this comment.
Thank you for the feedback. The asset_name_label is primarily used for classifying the different kinds of tokens, as described in our other CIP 0067. From only the name, wallets might not know how to display/handle the token. They can leverage this classification, with many tokens it can be quite the task for 3rd parties.
About your idea on keeping the minting policy open for future standards, we thought the same. Have a look at the following construction visualized by Alessandro,
,
Besides this, we thought it would be a good idea for pre-determined collections to use a Merkle root in the minting policy to commit to what can be minted, this allows for decentralized minting as well. If the collection is open, say for a game another route need to be used, of course.
There was a problem hiding this comment.
I was thinking more something similar to what NMKR is doing with their DID proposal (#294) except instead of an open minting policy to store multiple DIDs, the open minting policy is what is connected to other minting scripts
In other words, the minting policy script in the your image servers two purposes: minting the assets and connecting to the reference scripts. This could be split up into two different scripts similar to the diagram in the DID proposal
|
This CIP needs a Rationale section that explains how it achieves its goals, and in particular whether it is secure. My reading of it is that this is much more secure than CIP-25, which is I believe seriously flawed (#85 (comment)). The corresponding risk here is that this CIP imposes an assumption that asset names have a particular meaning, which may not be true for an arbitrary asset (and you can't tell without... metadata, and if you already have a functioning metadata channel you don't need this). However, it seems much harder for an unsuspecting token issuer to be attacked here. They would have to:
This isn't totally impossible. Consider e.g. a hypothetical dapp that issues tokens for user accounts. They innocently choose the following format for their asset names: So as before, to be truly safe this standard would have to be opt-in, but there is no way to tell whether a token has opted in without... metadata. Hence this CIP does still open an attack vector on innocent third party token issuers, and I would like the proposal to clearly explain this and declare that it is to be considered an acceptable risk. |
|
Thanks for the feedback @michaelpj!
Will work on a Rational section to make this more clear.👍🏻
This is why the The advantage of this approach is that you have a very strong link between the two tokens just from the policy id and the asset name without the need for additional metadadata. |
|
Very interesting read and many possible gains contained in this specification. The standard proposal elegantly solves the need for making metadata available also for smart contract validators and at the same time to lay ground for functioning as a decentralized on-chain token name registry! The concept of token classes also support the possibility to have different property standards for different token types. Really exciting ideas! As has been mentioned by several people already, the cost related to locked lovelaces in lots of reference NFTs was an unwanted consequence, especially for NFT user tokens collections. Have you considered describing the possibility of specifying a regular expression or valid id range in the reference NFT instead of exact comparison of token names? In that case, this could lead to each NFT collection also being able to refer to only one reference NFT that works for the entire collection. |
Yeah I thought about that, this would work perfectly for NFTs that share the same metadata. |
This is exactly the hole that I'm pointing to. You have no way of knowing whether a minting policy was written in any particular way (without another metadata channel). It is a perfectly legitimate use of Cardano to be ignorant of this CIP or just not care. What is dangerous is to assume that everyone will follow a policy when it is not enforced. More strongly, it's not the case that this CIP is "ineffective" if people don't follow the constraints, rather it creates a new attack vector against non-conforming users. I think actively reducing the security of innocent other network participants is pretty bad and needs to be taken seriously. Like I said, I think the policy is complicated enough that it's fairly unlikely that someone would accidentally produce asset names that appear to follow it. But looking at it from the security angle suggests that it might be a cheap win to make the policy more obscure, so that we can argue that it is really extremely unlikely to be used by accident. |
|
Great work, would open up a lot of possibilities! But, just wanted to add some long-term perspective on the issue of the locked ADA. We all like to believe Cardano is going to be around for a very long time, so 100 year should not seem unreasonable :-) In the first year of Cardano NFTs we had around 5M assets issued. Even assuming a linear growth (very unlikely), in 100 year that would mean 500M assets, resulting in 750M ADA locked. Even if the specification only requires one reference asset per policy, we currently have 55K collections (according to https://www.cnftjungle.io/statistics), meaning that it could still be a problem over the long horizon, because again, the growth will most likely not be linear. Either the minimum ADA required to be sent/locked with a token is drastically reduced or this becomes unfeasible in the long-run. |
I get your point, but with Plutus you can implement a native burning mechanism, which would allow you to redeem these ADA again. Of course if people continue using only time locked policies it's bad, but this CIP more or less forces you to write a plutus validator, so you can also think about a burning mechanism. |
|
The entire comment is based on the assumption that a large number of NFTs would still be time locked, otherwise it’s not a problem, of course. Would it be possible to execute the burning mechanism before the NFTs are locked? The thing is that locked NFTs are ingrained in the culture at this point, and not just on Cardano, meaning that the demand for them will still be here. A lot of people don’t even consider open NFTs as “true NFTs”. We’re probably going to see a lot of new applications where open policies are the norm, but for art and collectible NFTs in particular, most of the arguments for locking make sense. They especially make sense if you consider the long-term, decades, centuries, as the risk of policy keys being compromised increases. As a personal anecdote, we created the policy for our collectibles in May of last year, and because we wanted to keep things as flexible as possible and be able to take advantage of new developments as they become available, we chose an open policy. But we got complaints about that over the last 14 months. In our case, we could always satisfactorily explain why we made the choice, as it made sense and fits in with a wider vision for the collection, but that’s mostly not the case. The demand for locked NFTs is not just a Cardano thing either. This could mean that if it’s perceived to be more difficult to implement locked NFTs on Cardano it could hurt adoption. It doesn’t even have to be true, the perception will be enough. |
I think there is a huge misunderstanding in the ecosystem about "locked" vs "open" policies. If we talk purely about native scripts, I agree time locking is the only way to achieve immutability. But with Plutus things change. The possibilities are endless since you can embed any logic you want into the Plutus script. And actually it's far more elegant, people are just so used to time locking and simple scripts. There is not only "open" and "locked" with Plutus. There is more than just these 2 discret states and there are hundreds of different ways to achieve immutability. It just really depends on the logic. |
|
Some (AI-generated) summary of the conversations above (I invite the authors / commenters to reach out if they disagree with the summary, but from having also read through the conversation, I find it relatively accurate). The main conversation is about a proposal for a new standard that would allow for metadata to be securely attached to NFTs. The standard would require that the NFTs be locked in a UTXO, which would then be referenced by a user token. The metadata would be stored in a datum object within the UTXO. There are some concerns about the cost of locking the NFTs in a UTXO, as well as the potential for ledger bloat. There is also some discussion about whether or not this standard would be preferable to the existing CIP-25 metadata standard. A conversation between @michaelpj and @alessandrokonrad: @michaelpj is pointing out that this could be used to attack innocent third-party token issuers, who might not be aware of the standard or might not have implemented it correctly. @alessandrokonrad suggests a solution where there would be a mechanism to enable metadata for a minting policy, so that innocent people are not put at risk. @michaelpj suggests that making the token name format obscure enough might be the best compromise. Another conversation is between @cent-development, @alessandrokonrad, and @newmindflow. They are discussing the implications of the standard proposal for making metadata available for smart contract validators and the possibility of using a single reference NFT for all FT user tokens. @newmindflow brings up the point that there could be a problem with the long-term growth of NFTs if the minimum ADA required to be sent/locked with a token is not reduced. @alessandrokonrad suggests that a burning mechanism could be used to redeem the ADA. @newmindflow agrees that this could work if the burning mechanism is executed before the NFTs are locked. A final conversation is about the trade-offs between two different ways of storing data for NFTs on the Cardano blockchain. One way is to store the data on the blockchain itself (CIP-68), and the other way is to store a link to the data off-chain (CIP-54). The advantages of CIP-68 are that it is more secure and doesn't require scanning the entire history of the chain. The disadvantages are that it is more complicated and expensive, and that it is not compatible with the existing 5 million NFTs minted under CIP-25. Adding my own grain of salt to this: it occurs to me that one source of disagreement being the "depreciation of CIP-0025", which is maybe something that has been slightly extrapolated from the proposal? I don't think CIP-0068 comes to deprecate CIP-0068, but it certainly positions itself as more flexible and more secure alternative way to associate metadata to assets on-chain, albeit introducing of course its sheer amount of complexity to achieve it. Whether or not you want to embrace this standard or prefer to keep using CIP-0025 is a different story. If the plan is to deprecate CIP-0025 and mark it as obsolete, then I'd suggest to have this conversation in due time and on the PR proposing that change. This conversation is otherwise orthogonal to this proposal. |
Well it's non-trivial to determine if a policy is locked, and I generally only care if the token is an NFT at the present time, I cannot and do not try to predict the future.
If the user mints the token, they should be able to put what they like in the metadata. If you want to control what's in the mint, you should generate the transaction server-side and sign it with the policy key, then pass it to the user to sign with their key. If people are minting tokens entirely in the client side, without requiring something non-client side to sign with the policy key, then they should expect that the user can change the token metadata. This is not a security flaw in my opinion, it's perhaps a caveat worthy of mention, but it's not inherently insecure. I still don't think there is a security issue here, as long as people using the standard understand it, which is a lot easier with CIP25 than it is with this standard - CIP25 requires much less fundamental blockchain knowledge than this new standard - CIP25 is written in terms that are understandable to a non-blockchain developer, so I think it's safer than expecting people to mint via a regime which, to my mind at least, is more complicated. Complexity in itself can be a vulnerability if it means people are using the standard without fully understanding the implications of it. |
I believe you're missing the point about the mentioned security flaws. This is something we mentioned in the last CIP editor meeting and suggested @alessandrokonrad to perhaps emphasize a bit more in the motivation section: the flaws inherently affecting CIP-0025 and standards built upon it. The issue is not for people using it. It's for those who don't. If you are unaware that this CIP exists, and wants to mint token in a different way, possibly providing metadata using a different mechanism, then you've open up your protocol to metadata spoofing since platforms will today, by default, interpret anything from a minting transaction as legitimate metadata. If you do differently, you're likely screwed. Such standard is therefore unsound unless everyone is using it. Yet, since it can't be enforced at the protocol-level, there's no such guarantee. While CIPs have grown popular, there are still many people out there -- especially new joiners -- who do not know about them and may launch projects at scale irrespective of what CIP-0025 is specifying. CIP-0068 on the contrary is much harder to spoof, because the conditions to be recognized as a CIP-0068 metadata are far less "accidental" and can probably be made even less likely. |
I wanna add to this that CIP-0025 overshadows every new metadata standard by default if not really adopted. But that shouldn't be the case, the worst case should be not displaying anything by 3rd parties, but there is not guarantee for that. |
|
While this is an interesting proposal, the concerns raised by some are important considerations. It is also not clear to me why it is important to design a solution around the need to have mutable/programable metadata on-chain. It feels like we are trying to replicate other blockchains, rather than trying to innovate in the Cardano way. I realise that there will be scenarios where information related to an NFT needs to be mutated, such as gaming data. But there are ways of doing this (using the blockchain for proofs) without needing to update the NFT itself. With NFTs in Ethereum existing as smart contracts, it is their simplistic way of achieving that objective, but Cardano isn't bound by smart contracts for tokens, so we don't need to just copy their approach. I have been trying to promote this broader way of thinking since the topic of metadata was first raised, including taking the opportunity to think beyond Cardano (i.e. an inter chain approach). My suggestion therefore is a compromise, whereby the token CAN be minted with immutable metadata (like a CIP-0025 compliant time locked NFT) to address the concern raised by @kieransimkin, but the token MAY also be referenced via a DID (if the creator wants to extend its capabilities), the URI of which is constructed from the asset ID, e.g. did:cnft:assetid (addressing the naming concerns raised by @michaelpj with the "reference NFT" approach). If the NFT creator wants to lock a "reference NFT" in a smart contract (as per the suggestion in this proposal), then it can be referenced as a linked resource in the DID. This would only put the additional cost burden (as highlighted by @newmindflow and others) on tokens that need this option. This would help address the issues raised in this CIP, by allowing Services in the DID to define serviceEndpoints for additional metadata (programmable or otherwise, on-chain or off-chain). It would also provide a mechanism to address the verification challenge posed in CIP-0066, by using the Verifiable Credentials standard that already works with DIDs. It could also move our NFTs towards a cross chain interoperability standard (others are exploring this approach), if that is important to the NFT creator. By using a DID as a common interface, alternate standards for different token types (see the Token Taxonomy Framework) can be introduced as required. I would be interested in people's thoughts on this, as I may consider submitting my own CIP with this approach for consideration. |
Co-authored-by: Matthias Benkort <5680256+KtorZ@users.noreply.github.com>
|
@phillewis I think that taking the policy ID + asset name and using it to look up metadata in an external system (whether it be DID-based or otherwise) is fairly reasonable, that was the basis of CIP-26, for example. You still need to prevent credentials being registered by the wrong person, but I think that's soluble, and is something that you can iterate on off-chain without having to change the base mechanism. So it might well be viable. |
Thanks for the feedback @michaelpj. If there are others interested in exploring this approach, would you be interested in connecting to help flesh it out further? |
Either I'm still missing the point, or I just don't agree with it. The minting transaction is the authoritative source of the metadata in CIP-25. If people are not following CIP-25, their NFTs are not valid and all bets are off. Minting an NFT requires a signature from the policy key, so how is that insecure? It is correct to interpret anything in the minting transaction as the correct metadata, because the minting transaction requires a signature by the policy. If you have the private key of the policy, you have the right to put whatever you like in the metadata, this is not a security issue? |
That's not always the case. You could have complex plutus minting policies where there isn't an owner behind it, but just some conditions need to be met in order to mint. Imagine a DEX where you mint liquidity tokens. The process is autonomous and decentralized. What stops someone from injecting metadata according to CIP-0025 into the mint transaction. |
Ah okay thanks for the explanation - I get it now. I am still stuck in the mindset that all NFTs will be minted with the same locked policy, because that is still the only policy that is documented at all on the official site. My counter to this, is that if you're savvy enough to be writing your own minting policy scripts, you're going to understand the implications of doing so (obviously better than I do). This just puts me back to my original point though - if we're aiming to completely replace CIP-25 - I would much prefer a cleaner solution whereby the token metadata becomes a first class primitive in the blockchain itself, rather than just stuffing it in some ad-hoc metadata/datum field, as this feels like a hack to me, in much the same way CIP-25 feels like a hack. I don't really wanna replace one hacky way of storing the metadata with another one that that actually feels worse, and more confusing for people (thus potentially more prone to errors). |
We could use the same DEX example here. Regardless of how skilled the devs are, why would they even care about metadata in the first place for liquidity tokens and so they may not even be aware of CIP-0025.
CIP-0068 gives you a lot of flexibility and is imo not hacky. You separate control over the NFT/token itself and metadata, which allows yout to create far more sophisticated and interesting token standards, but of course still allows you to do the same as with CIP-0025. The datum is meant to store information inside, you could then also reference these data and bring them into plutus validators. And since these data are part of the ledger state they could be useful for Mithril, which allows you to query and fully verify the metadata as light client. |
This CIP defines just that, a universal place where metadata associated with any native asset can reside onchain (in a standardized way). It does not fill in the blanks on how and in what format this data should be formatted (we suggest two standards for FT/NFT's but more are possible). This CIP addresses the abstraction on how data of any token is linked to its value. And a good thing to remember here is that metadata should be strictly separated from its representation of value, this because this value is moved a lot. Were the metadata attached to the native asset that is the transferable value (or the UTxO that has this token), this data would fill up valuable transaction space each time the value is moved. With reference inputs, you can separate this data and value while still preserving the option of having the data available in a transaction. That is the core of this proposal. Again, it does not fill in the blanks, how you manage /structure the metadata is up to the asset label standard used. |
|
I would propose to make the 222 NFT Standard In practice, the PS: I'm not talking about the main |
|
The CIP meeting just finished has noted that this CIP is considered ready for acceptance, pending only the resolution of the questions still being discussed in related CIP-0067 (#298). |
|
(cc: @KtorZ) @alessandrokonrad @perturbing the consensus at today's CIP meeting # 54 is that this proposal is almost ready to be merged, if you will please:
|
|
We'll be reviewing the Path to active in the next session. As a reminder, this should emphasis on demonstrating adoption of the CIP, which includes working implementations and adoptions across various actors of the ecosystem through observable metrics. I believe the type ought to be 'Process' as well instead of information, since it defines a, albeit off-chain, process to follow. |
CIP-0068/README.md
Outdated
|
|
||
| ### Pattern | ||
|
|
||
| The `user token` and `reference NFT` **must** have an identical name, followed by the `asset_name_label` prefix. |
There was a problem hiding this comment.
Must be
The
user tokenandreference NFTmust have an identical name, preceded by theasset_name_labelprefix.
CIP-0068/README.md
Outdated
|
|
||
| ### Pattern | ||
|
|
||
| The `user token` and `reference NFT` **must** have an identical name, followed by the `asset_name_label` prefix. |
There was a problem hiding this comment.
Must be
The
user tokenandreference NFTmust have an identical name, preceded by theasset_name_labelprefix.
rphair
changed the title
This proposal defines a metadata standard for native assets making use of output datums not only for NFTs but any asset class.
see rendered Markdown