Dual introspection detection ERC721 (ERC165 vs SRC5)

[martriay]

The good

With good reasons, we're replacing EVM's ERC165 introspection mechanism with Starknet's native SRC5. Yay! 🎉

The bad

The problem though, is that we use it extensively in some critical places such as ERC721's safe_transfer_from to detect whether the receiver contract is either an Account or it implements the ERC721Receiver interface to make sure it will be able to handle the to-be-received token:

cairo-contracts/src/openzeppelin/token/erc721/erc721.cairo

Lines 446 to 460 in d86eb73

	if (IERC165Dispatcher {
	contract_address: to
	}.supports_interface(erc721::interface::IERC721_RECEIVER_ID)) {
	// todo add casing fallback mechanism
	IERC721ReceiverABIDispatcher {
	contract_address: to
	}
	.on_erc721_received(
	get_caller_address(), from, token_id, data
	) == erc721::interface::IERC721_RECEIVER_ID
	} else {
	IERC165Dispatcher {
	contract_address: to
	}.supports_interface(account::interface::IACCOUNT_ID)
	}

The ugly

This poses the question: what detection mechanism should we support in our standard ERC721 implementation? we need to use at least one, and SRC5 has to be favored over ERC165 for the reasons stated in the proposal. This leaves us with two options:

option A: we support SRC5 only

this would be the easiest to reason about, test, and implement. It'd would also be cheapest. The downside would be breaking compatibility with older ERC721Receiver and account contracts, which won't be implementing SRC5 nor the right interface ID.

This would be the best option if we think regenesis will wash out every ERC165-supporting ERC721Receiver and if most accounts are either Argent or Braavos which are upgradeable and we know they're implementing SRC5.

option B: we support both

probably the safest call for backwards and forward compatibility but with added testing complexity, code overhead, and execution cost. This would also imply delaying an already delayed ERC721 standard contract that has already been struggling to get released.
We're unsure if this approach is worth the cost, since it depends on whether current ERC721 deployed contracts rely heavily in ERC721Receiver contracts, or if there is a significant number of accounts holding ERC721 tokens that are neither Argent nor Braavos.

The question

So we're asking you, the ERC721 implementers, minters, and users what would you prefer the standard ERC721 implementation from OpenZeppelin to support?: cheap, released-sooner vs complex but backwards compatible standards. Bear in mind that whatever we decide in here will also be replicated in ERC1155.

[bal7hazar]

From my personal perspective, I would say that no matter how painful a transition may be, only the end target matters, everything else is matter of communication. With that being said, I would recommend breaking away from ERC165 and focusing on the SRC5-only scenario, especially because it will bring greater efficiency.

Additionally, the fact that we are still in the alpha phase and everyone is currently working on the Cairo 1 transition presents a good opportunity to implement this change as soon as possible.

Since interface IDs are stored in the contract's state during initialization, we won't be able to update our contracts to make it work. However, I believe we can handle this by adding a dedicated function to update this storage (a safe example would be appreciated, I suppose).

[glihm]

I would tend to agree with @bal7hazar and focus on SRC5-only Option A.

Also, about the double case debt we have for backward compatibility, do you think guys it's something that we can get rid of with the re-genesis? Because if we are in a scheme to enforce change, this can be great to also stick to the new casing only.

But I fear that unfortunately several collections may not be upgradable as they don't have proxy / replace_class implemented. It's still alpha though, so people are aware of changes that are coming as @bal7hazar said.

[0xChqrles]

Apparently we can't "try catch" transactions on starknet, it only works in tests (cf. this discussion). Then DualCase fallback mechanism cannot work, and ERC165 fallback over SRC5 won't neither.

[martriay]

Thanks for the heads up!