EIP-5269: ERC-identifying Interface

An interface to identify if major behavior or optional behavior specified in an ERC is supported for a given caller.

Abstract

An interface that returns true or false when queried by ERC numbers, if it implement certain ERC number.

Motivation

This EIP is created as a supplement to and competing standard for against EIP-165.

Here are the major differences between this EIP and EIP-165.

1. EIP-165 uses hash of method signature which basically declares the existence of method or list of methods, therefore it requires a method to exist in the first place. In some case, some ERCs interface are not represented in the way of method signature, such as some EIPs related to data format and signature schemes.
2. EIP-165 doesn’t provide query ability based on caller. This EIP respond true or false based on caller. An example would be the OpenZeppelin has Transparency Proxy contract that behaves differently when ProxyAdmin calls or other user calls.
3. Using ERC numbers improves human readability as well as make it easier to work with named contract such as ENS.

Specification

1. Any compliant smart contract MUST implement the following interface

interface IERC5269 {
  function supportsErc(uint256 majorNumber, uint256 minorNumber, address caller) external view returns (boolean isSupported);
}

1. majorNumber is the ERC number under query. minorNumber = 0is to reserved for the main interface. Other minorNumber is reserved for the optional interface extension of that ERC.

2. Any compliant contract that is an IERC5629 MUST return true for the call of supportsErc(5269, 0, (any caller)).

3. Any compliant standard is RECOMMENDED to declare the minorNumber for their optional interface extensions.

4. Any compliant contract MUST return true when a behavior defined in that ERC and optional interface extensions is available to acaller.

Rationale

1. EIP numbers are returned in an array to reflect the practice that a smart contract usually implements more than one interface.

2. We didn’t require the ordering of return value. And we only suggest but didn’t require deduplication because it’s cheaper to do such computation outside of chain.

3. Compared to EIP-165, we also add an addition input of address caller, given the increasing popularity of proxy patterns such as those enabled by EIP-1967. One may ask: why not simply use msg.sender? This is because we want to allow query them without transaction or a proxy contract to query if whether interface ERC-number will be available to that particular sender.

4. We reserve the input ercNumber above 2**32 in case we need to support other collection of standards which are not ERC/EIP.

Security Considerations

Similar to EIP-165 callers of the interface MUST assume the smart contract declaring they support such EIP interfaces doesn’t necessarily correctly support them.

Copyright

Copyright and related rights waived via CC0.

参考文献

Please cite this document as:

Zainan Victor Zhou, "EIP-5269: ERC-identifying Interface [DRAFT]," Ethereum Improvement Proposals, no. 5269, July 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-5269.