mirror of https://github.com/status-im/EIPs.git
ERC-165 is now accepted, add strong support for 820 extension of 165
Thanks @eordano for bringing this up
This commit is contained in:
parent
39396a50a2
commit
3442342c5a
|
@ -48,7 +48,7 @@ import "./ERC165.sol";
|
|||
|
||||
/// @title Required part of ERC-721 Deed Standard
|
||||
/// @dev See https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md
|
||||
/// Note: the ERC-165 (DRAFT) identifier for this interface is 0xb3a99827
|
||||
/// Note: the ERC-165 identifier for this interface is 0xb3a99827
|
||||
interface ERC721 /* is ERC165 */ {
|
||||
/// @dev This emits when ownership of any deed changes by any mechanism.
|
||||
/// This event emits when deeds are created (`from` == 0) and destroyed
|
||||
|
@ -119,7 +119,7 @@ interface ERC721 /* is ERC165 */ {
|
|||
/// @param _approved True if the operators is approved, false to revoke approval
|
||||
function setApprovalForAll(address _operateor, boolean _approved) payable;
|
||||
|
||||
// CONFORMANCE TO ERC-165 (DRAFT) //////////////////////////////////////////
|
||||
// CONFORMANCE TO ERC-165 //////////////////////////////////////////////////
|
||||
|
||||
/// @notice Query if this implements an interface
|
||||
/// @param interfaceID The interface identifier, as specified in ERC-165
|
||||
|
@ -136,7 +136,7 @@ The **metadata extension** is OPTIONAL for ERC-721 implementations (see "caveats
|
|||
```solidity
|
||||
/// @title Optional metadata extension to ERC-721 Deed Standard
|
||||
/// @dev See https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md
|
||||
/// Note: the ERC-165 (DRAFT) identifier for this interface is 0x2a786f11
|
||||
/// Note: the ERC-165 identifier for this interface is 0x2a786f11
|
||||
interface ERC721Metadata /* is ERC721 */ {
|
||||
/// @notice A descriptive name for a collection of deeds in this contract
|
||||
function name() external pure returns (string _name);
|
||||
|
@ -180,7 +180,7 @@ The **enumeration extension** is OPTIONAL for ERC-721 implementations (see "cave
|
|||
```solidity
|
||||
/// @title Optional enumeration extension to ERC-721 Deed Standard
|
||||
/// @dev See https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md
|
||||
/// Note: the ERC-165 (DRAFT) identifier for this interface is 0x5576ab6a
|
||||
/// Note: the ERC-165 identifier for this interface is 0x5576ab6a
|
||||
interface ERC721Enumerable /* is ERC721 */ {
|
||||
/// @notice Count deeds tracked by this contract
|
||||
/// @return A count of valid deeds tracked by this contract, where each one of
|
||||
|
@ -280,9 +280,9 @@ Creating of new deeds and destruction of deeds is not included in the specificat
|
|||
|
||||
**ERC-165 interface**
|
||||
|
||||
This specification includes a function `supportsInterface` which is standardized in [ERC-165](https://github.com/ethereum/EIPs/pull/881) (draft pending acceptance). So any contract MAY query your contract to see if it complies with ERC-721 and the extensions. This creates a dependency, which is a risk. However, ERC-165 is an extremely simple proposal, has implementations deployed in the wild for years and the draft meets all EIP requirements for acceptance, including [the new requirements](https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Meeting%2031.md#10957-decision-process-for-eips) that aren't even documented yet. The lead author of this standard is also the official champion for ERC-165. One EIP reviewer [has "ACK"ed the draft](https://github.com/ethereum/EIPs/pull/881#pullrequestreview-97124296).
|
||||
This specification includes a function `supportsInterface` which is standardized in [ERC-165](https://github.com/ethereum/EIPs/pull/881). So any contract MAY query your contract to see if it complies with ERC-721 and the extensions.
|
||||
|
||||
We chose ERC-165 over competing standard ERC-820 because of maturity. We consider ERC-165 low risk. But ERC-820, as recently as two weeks ago, [discovered a complete show-stopping flaw](https://github.com/ethereum/EIPs/issues/820#issuecomment-362049573). ERC-820 may be a great option, but we deem dependency on that standard an unacceptable risk at this time.
|
||||
A future EIP may create a global registry of interfaces for contracts. We strongly support such an EIP and it would allow your contract to to implement ERC721Enumerable, ERC721Metadata, or other interfaces by delegating to a separate contract.
|
||||
|
||||
**Gas and complexity** (regarding the enumeration extension)
|
||||
|
||||
|
|
Loading…
Reference in New Issue