CIP-???? | Efficient Proofs for Dynamic Minting and Burning of NFTs.

[ilap]

📄 Rendered CIP proposal

[rphair]

Marking this for Triage at Tuesday's CIP meeting (https://hackmd.io/@cip-editors/98) at least to introduce that this CIP is back on the boards with a corresponding CPS. I won't be at the meeting but I feel sure the other editors will insist that this be broken up into 2 separate PRs (I would suggest this one for the CIP + another for the CPS).

@ilap the documents still look like works in progress because the headings are different than those outlined in CIP-0001 (for CIPs) and CIP-9999 (for CPSs), and in fact the CPS seems to contain a complete copy of the CIP. It will take some substantial editing to get these into enough of a standard form for comprehensive review.

[rphair]

Also an early review item should be whether this category should be Tokens or Tools (based on how much of the activity dictated by the CIP might be done off-chain).

[ilap]

I am not sure which category suits it best.

But I think, it depends.

In the PoC/MVP project I implemented, which is a Single Page Application (SPA), each individual user first downloads all the elements during the initial page load. If the same user accesses the page again, only the deltas from the last fetched elements are downloaded.

This approach works well for data sets with up to 10K or even 100K elements, although performance may vary based on the backend used. It's important to emphasise that that is a PoC/MVP meant to demonstrate functionality and not a final, bulletproof solution.

Different implementers may choose varying solutions based on their use cases, such as integrating with an API provider or building a shared backend that others can use.

Additionally, if there is interest in the implemented fully decentralised PoC/MVP dApp it could evole to a more robust solution.

[Ryun1]

It would really help understanding this proposal if you provided some examples of what the data structures could like

[ilap]

Hi @Ryun1,

This CIP outlines a generic approach to dynamic, decentralized NFT minting and burning within the constraints of the EUTxO model. The idea is to store a compact representation of an off-chain dataset as the state on-chain.

Therefore, different implementations, such as:

Sparse Merkle Tree (SMT)
Merkle Patricia Forestry (MPF)
BLS-based Plutus Accumulator
can all follow the same core principles.

For my specific implementation, I’m using a complete binary tree, which I’ve named IntegriTree. You can explore the technical details on its GitHub repo, and there’s a working demo available on the Preview Network at adatag.io. Please note that the code has not been audited.

To summarize:

The proposal offers a general solution/recommendation for dynamic NFT minting.
Different use cases can adopt various implementations, but, to my knowledge, all of them would need to follow the principles outlined in this CIP.

The state is stored on-chain, and state transitions occur by submitting a minting/burning transaction that includes

• the old state as an input's inline datum,
• the new state as an output's inline datum,
• and a proof as a max 5KB long redeemer, that verifies the validity of the addition or removal of an element from the set.

Conceptually, it works like:
newState == Prove(proof, oldState, element, add or remove).

Meaning, burning/minting occurs if this—and other validation checks—are valid.

[ilap]

Here is an image of the complete transaction (state transition from the initial state) example from my MVP/PoC implementation.

[rphair]

@ilap it would be great to see at least the key components of this material in the CIP.

[ilap]

Hi @rphair,

The core components of my implementation are described in the DESIGNSPEC.md document.

However, these components are quite detailed, and I believe they should not be included in the more generic CIP.

[rphair]

@ilap the reaction from the CIP meeting today, as before after the earlier PR was submitted:

• CIP-???? | Efficient Proofs for Dynamic Sets #816

is still that this is a method of interest of dealing with the general problem, and which still needs to be qualified as a specific solution.

One way of doing that would be the follow the original suggestion of linking this CIP to & from a forthcoming CPS also authored by you about the general problem (as per #816 (review)).

Or: without a CPS to contain it, the general problem space could be outlined more in this CIP so potential implementors would clearly see the benefit of following this as a "standard" rather facing uncertainty that this is only one project's implementation with the potential to be imitated.