@frangio
Great, we agree on the general goal of making token balance totally accountable by events.
Let’s debate one of the design decision here
Design Choices for which “transfer event” to use for batching
- Option 1. Use EIP-2309
ConsecutiveTransfer
instead of Transfer
when transferring multiple tokens with consecutive ids, and use Transfer
otherwise.
- Option 1a, [See update]Use
ConsecutiveTransfer
in addition to Transfer
s
- Option 1b, [See update]Use
ConsecutiveTransfer
only at contract creation.
- Option 2. Use ERC-721
Transfer
for all cases, emit Transfer event multiple times for multiple token ids, regardless of consecutive token ids.
- Option 3. use something like
TransferBatch
with unit256[] tokenIds
that allows specifying uint256 tokenIds. (similar to EIP-1155)
My thoughts
Here is my thoughts.
First, let me re-iterate this and make sure if we are on the same page:
Both Option 1 and Option 3 are NOT backward compatible with ERC-721, because let’s say Coinbase, OpenSea and Etherscan are already watching Transfer
of ERC721 hoping to learn all transfers and do something upon a Transfer. Now, if a new contract start adopting Option 1 or Option 2, start using a transfer event different from what’s already in ERC-721. In this case, without updating the logic Coinbase, OpenSea or Etherscan will none be able adopt to Option 1 or Option 2. This is why I say Option 1 and Option 3 are not backward compatible.
On the other-hand, for any new contract using Option 2, despite being gas-inefficient, is backward compatible with ERC721: that is to say, Coinbase, OpenSea or Etherscan or Subgraphs of TheGraphProtocol will not need to make change to their logic to also watch for a new transfer event with different name. Their old logic will still work.
Let me know if I explain myself clearly If my explanation still lacks clarity, I am happy to write some reference implementation code of both contract and indexer/tests to demonstrate what I mean.
Update after more research.
Context:
- EIP-2309 admits it’s not compatible with ERC-721 and suggest either using both ERC-721 Transfer
For platforms that wish to support the ConsecutiveTransfer
event it would be best to support both the original Transfer
event and the ConsecutiveTransfer
event to track token ownership.
We hereby have two other new options as variant of Option 1:
- Option 1a, Conforming contract to use
ConsecutiveTransfer
in addition to
Transfer
s, this defeats the purpose of gas efficiency and adds more gas cost. and this is incompatible with When emitting the ConsecutiveTransfer event the Transfer event MUST NOT be emitted
in EIP-2309
- Option 1b, Conforming contract to use
ConsecutiveTransfer
only at contract creation. This is limited use-case and also it makes it impossible to support indexers who only watches Transfer
, defeating purpose of maximizing compatibility with ERC-721s.
Also, I have doubt of how much gas cost EIP-2309 really saves overtime for Option 1.b. Here is why:
While one transfer will change gas cost from O(N) to O(1) with N = number of tokenIds, If one address is going to receive a large amount of tokens, my unverified probably uneducated hypothesis is that such batch holding is for the purpose of distributing the NFTs down the road. Since they will only distribute tokens one by one given EIP-721 doesn’t support batchTransfer, if we only use ConsecutiveTransfer
for creation, when the holding is doing secondary distribution, the long term gas cost is still cost of O(N). Therefore the overall gas saving, if only adopting at creation time, is very limited.
Therefore, so far I find Option 2 still the most preferred design option for this decision question.