How does ERC2309 implementation differ or change a standard ERC721

Question

My understanding of the ERC721 minting process is that it follows three basic steps, it updates the owners balance (mapping _balances), it makes a record, associating the tokenId to the owners address (mapping _owners) and then emits a Transfer event for the tokenId from address 0 to owner. There are also checks done to prevent the same token from being assigned to different owners and vice/versa.

ERC2309 only really explicitly talks about the event, stating that in place of or in addition to the Transfer event being emitted you can emit a ConsecutiveTransfer event. This event is very much the same as the transfer event expect that it announces a block of tokenIds as opposed to one and that block is defined only by a starting and ending tokenId.

The big gas consumers when minting many tokens is the repeated emission of the Transfer event and the for loop needed to update the _owners mapping by assigning the owner address to each tokenId. The ConsecutiveTransfer event solves the problem of repeating the Transfer event. But the problem then remains the for loop for updating the _owners mapping.

Is an explicit mapping of each tokenId to the owner address required at this stage? Or can you adopt the same approach as used by the ConsecutiveTransfer event where all you record is a start and end tokenId and associate the block to the owner address?

Moreover, after this "minting" stage the tokens created are for all intents and purposes fungible. To make the token non-fungible the token meta-data will need to be updated with unique characteristics. Then at that stage you can explicitly assign an owner to the specific tokenId, and you would more than likely be transferring the token from the minter address to a new owner.

Is my interpretation and approach correct? Can this be implemented without breaking the ERC721? Besides needing to write a batchMint function, could one continue to use the rest ERC721, in other words continue to use the Open-Zeppelin implementation for example?

Answer 1

There are too many questions here and you may some more in your head, so answer just the ones I can parse:

• Your noted understanding above of ERC-721 is the most popular implementation, and not necessarily the only implementation.
• ERC-2309 does not provide any check about sending tokens to different destinations. This is something you need to implement.
• It is not necessarily true that the owner array must be updated N times to transfer N tokens. I have created several implementations (hint: one is referenced in ERC-721) that make use of (abuse of) this fact.
• I have a marvelous proof that it is not possible to create an O(1) implementation of allowing transfer of consecutive tokens, which this margin is too narrow to contain. O(Log(2^256)) implementations are possible and so are other tricks if you can limit "arbitrary" in certain ways.
• I do not agree that non-fungible tokens will ever be fungible. Metadata can be set to example.com/{tokenId} to make them unique.
• Minting does not always have to come from a preminter. Other models are possible and possible.
• ERC-2309 is NOT compatible with ERC-721. Where it says "ERC-721 compliant contracts MAY implement this...," this is lying and/or extremely equivocal (like how a circle can be a point).
• I'd like to note that ERC-2309 passed at a time when the EIP Last Call RSS feed was not working. I would not have let it pass if I had seen it.

There's a lot here and I don't want to open a discussion on all of these. Please proceed with bite-sided questions if you have more, and if you have an implementation in mind, lmk.