I was discussing different ways to make mass NFT minting and sales more scalable with a few other devs (like MGPai, lgd, Ilya). Currently, if you want to mint and sell 1000 NFTs, you need to do 1000 NFT minting transactions, and then over time do 1000 sale transactions.
To make this more efficient, one could use an AVL Tree. Lets say the tree holds sequential, serialized long values as it’s keys. In it’s values it holds 1000 unique metadata’s for different potential NFTs. We insert this pre-filled tree into a Mint&Sale box in R4.
Whenever someone wants to buy an NFT from the Mint&Sale box, a key is selected (For simplicity’s sake we’ll say the user selects the NFT, other selection methods are possible but might require some changes). Once selected, a lookup is performed on the key. A serialized Coll[Byte] representing all of the NFT metadata is then returned. This Coll[Byte] is then parsed and placed into the registers of OUTPUTS(0) according to EIP-04 standards. A new NFT is then minted and also placed into OUTPUTS(0). Finally, the Mint&Sale box is remade in OUTPUTS(1) so that other sales may occur. If re-use of metadata is an issue, then the used key may be deleted from the tree existing in OUTPUTS(1)
At the same time, the sale is also performed. The ERG provided by the buyer in one of the inputs goes to the artist. In this way, the sale and minting of the NFT is combined into a single transaction. NFTs are only minted when a user wants to buy them, so there is no need to pre-mint 1000 NFTs before the sale.
I believe this would help scale NFT minting and sales considerably, though I don’t have the time to implement it myself.
I might implement this for ErgoPad as well. One could imagine using what you outlined if someone wanted to only mint NFTs, while the more complex protocol with the pre-minting would be used if tokens needed to be minted.
I don’t see why one would be needed. Just set the EIP-04 registers on the box holding the NFT. That box’s prop bytes will be the prop bytes of the buyer.
Yeah I discussed this with MgPai, it requires some slight changes (making a separate contract as the issuer box in INPUTS(0)) but in general should still work if done correctly.
I think this is great! But it may have a bunch of issues.
Assumption that an NFT sale happens ‘over time’ is kinda hopeful, this has to handle every single NFT being sold in a minute flat.
If tx is user-initiated, users can cancel a mint and get a different nft by re-spending their input
If the first P2PK found in mint chain is a box originating from the buyer, they’re the mint address. With the collection EIP this could be mitigated, but imo it’s gonna cause issues with the existing ‘mint address is the authenticity prover’ method
I suppose you can avoid this by the first input into minting tx being the mint box, BUT that presents another issue, described below.
Currently the mint address is first P2PK addr found in the chain of boxes which led to the nft mint issuance.
In this model, you would send some erg from a P2PK to form the contract’s box. The first mint would be done by spending this box, creating an NFT and a new, second mintSaleBox.
Finding the mint address for nft 1 is just checking the tx which issued the mintSaleBox, then checking each input box, and you have the mint addr. 1 api call.
For nft 2, you have to check the tx issuing mintSaleBox2, check input (mintSaleBox1) check tx that issued, check input boxes addresses, you’re at mint address. (2 api calls)
For nft 1000, you’d be performing 1000 API calls to find a mint address - a nightmare for apps to cope with.
The same principles used in liquidity pools to deal with concurrency can be dealt with here. That is, proxy contracts and chaining transactions together, possibly using bots for full decentralization
This can also be solved with proxy contracts and bots / centralized service
Yeah this issue was brought to me by MGPAI as well. A separate issuer contract is needed, however that has some other problems (traits being assigned on the issuer contract)
This one is tough to handle, MgPai also brought it up to me as well. Not really sure how to fix this easily, if we require multiple set up transactions to create multiple issuer boxes, then we have not solved the problem, because 1000 set up transactions are now needed (while the old problem was 1000 minting transactions).
One possible way to fix this is to put a singleton token on the Sale&Mint box. Then find the transaction that mints this singleton token, and use its 0’th input as the minting address for the entire collection. But to be honest I don’t know much about this side of NFT’s, the most I know is EIP-04
If the above solution isn’t viable, then maybe something else could be done?
I guess for point 4, with your idea we would need to change the standard. Seems like the standard is limiting case. Or it would force the need that if you wanted to mint multiple NFTs you would need to make them part of a collection and mint a collection token beforehand. The standard doesn’t scale lol.
So you would need four api calls I think, anyone please correct me if I’m wrong:
to see which tx the nft came from, in order to check for the issuer box input that contains the collection token
to find the minting tx of the collection token issuer box
to find the tx which created the nft collection issuer box, whose input is the user’s proxy address box
to find the pk which sent money to the proxy
For mass token minting (i.e. pre-mint, not on-demand nft sale), since mass minting occurs using many tx chain “modules” (each chain having it’s first “chain input” being the output of the same initial tx) this can scale for however many tokens you want to mint. 1K/10K/100K/100M etc. Using Plasma of course
I guess you could also make the NFT collection issuer box the proxy contract as well, so reducing the calls to 3 only. Then make the user sign a ReducedTxBytes so the output box could be created/formatted properly beforehand.
