Make cNFTs more composable and prevent them from breaking transactions

[svc01-metaplex]

Submitter: Jymfletzfur
Email: [email protected]
Submitter wallet: EyLQV7BPgYFjEY63k1icGbDzLMtaTdk32a5FR37bdKzR
Submission transaction: fixsoV2u2wV2Gac1DXrDCnWfRCALsFb52zzVMpuHW4bBtTPBtRH97pJQqzEagCMDkTQi27qFYiejNFAAsEAScxB
Title: Make cNFTs more composable and prevent them from breaking transactions
Links:

Overview:

cNFTs have an extraordinary potential. However, like every technology that exists, their application also has a dark side. They have enabled bad actors to send malicious spam NFTs at a rate that overwhelms current users and actively deters new users.

They are able to be created in such a way that can break transactions, causing platforms to have to implement extensive workarounds to let them be burnt.

Additionally, these transaction breaking configurations prevent seamless composability across other types of platforms as well.

Motivation:

The main motivation behind the proposal is to fix the ability to create transaction breaking cNFTs, which appears to be a bug and not a feature.

If enacted, burns of these specific scam cNFTs can resume as any other cNFT, reducing the friction required to dispose of them.

In addition this would increase the composability of cNFTs across various applications and platforms within the ecosystem, not just limited to burning.

Proposal:

Set limitations on combinations of max depth and canopy depth to limit max size of proof bytes required to a lower limit than currently.

This could be simply enough to just permit all bubblegum instructions to complete, such as burn and transfer, but ideally, it would leave some space free to permit some amount of composability with other programs.

Looking at the costs and proof sizes on https://compressed.app/advanced, I believe permitting a maximum of 17 additional proofs should be sufficient, while still allowing people to mint a lot of cNFTs for a low cost.

For example, a max depth of 18, and a canopy depth of 1 would be permitted - the total proofs equals 17
A max depth of 30 would require a canopy depth of at least 13
A max depth of 24 would require a canopy depth of at least 7

Potential Downsides:

Although this would not limit the ability to manage an extreme amount of cNFTs with one tree, it would make certain configurations slightly more expensive.

[solarnius]

+1 this solves the issue I opened on the bubblegum program: metaplex-foundation/mpl-bubblegum#86

My proposed solution there (slightly more specific):

An assertion should be added to process_mint_v1 in mint.rs that ensures that the tree proof length does not make leaf updating impossible.

I think we should set this limit around the theoretical maximum for burning (assuming the rest of the asset has max creators/metadata) and provide better documentation for legitimate NFT projects about best practices (exchanges like tensor recommend proof lengths of 5-8).

[danenbm]

Metaplex Foundation agrees with the sentiment that cNFTs with a tree proof length that makes updating impossible without an account look-up table should not be considered valid assets. We'll do some analysis as well regarding the proposed tree and canopy depths and follow up within a few days with our recommendation.

[danenbm]

I looked at the results from @solarnius and Jymfletzfur and also ran a test using Umi. In my test setup, when I used a tree of depth 24 with a canopy of 4 (20 proofs needed) I was able to burn, but when I used a canopy of 3 (21 proofs needed) it failed:
`VersionedTransaction too large: 1660 bytes (max: encoded/raw 1644/1232)'. I got same failure using a tree of depth 30. Not sure of exact difference between my test setup and @solarnius setup.

Also we looked at some heavily used Merkle trees in the community and saw that they had a depth of 20 and a canopy of 5 (15 proofs needed). So 15 as a limit is too low, and somewhere in the range of 20-24 is too high. We also like the idea expressed in the MIP of leaving some space free to permit some amount of composability with other programs.

Thus Metaplex Foundation agrees with the proposal of permitting a maximum of 17 additional proofs.

[solarnius]

17 seems fine, the 24 was envelope math for an upper limit and not a practical test so I probably missed a few bytes somewhere -- sorry for not making that clear

[MetaplexFoundation]

The community feedback period for this submission has ended. It will now be converted to MIP-9 and move to a vote on the Metaplex DAO (https://dao.metaplex.com/). The voting period will open on March 20, 2023, and remain open for 14 days. If passed, MIP-9 will be a Metaplex Foundation implementation.

[MetaplexFoundation]

The Metaplex DAO voted to approve MIP-9. Development for MIP-9, including the accompanying independent security audit, is expected to be completed by the end of May 15, 2024.

[MetaplexFoundation]

Bubblegum with support for MIP-9 has been deployed to devnet, with Rust and JS packages published. The independent security audit of the alterations to Bubblegum is underway.