forked from DecentralizedClimateFoundation/DCIPs
65 lines
3.3 KiB
Markdown
65 lines
3.3 KiB
Markdown
|
---
|
||
|
|
eip: 1844
|
||
|
|
title: ENS Interface Discovery
|
||
|
|
author: Nick Johnson (@arachnid)
|
||
|
|
discussions-to: https://ethereum-magicians.org/t/ens-interface-discovery/2924
|
||
|
|
status: Stagnant
|
||
|
|
type: Standards Track
|
||
|
|
category: ERC
|
||
|
|
created: 2019-03-15
|
||
|
|
requires: 137, 165
|
||
|
|
---
|
||
|
|
|
||
|
|
## Simple Summary
|
||
|
|
Defines a method of associating contract interfaces with ENS names and addresses, and of discovering those interfaces.
|
||
|
|
|
||
|
|
## Abstract
|
||
|
|
This EIP specifies a method for exposing interfaces associated with an ENS name or an address (typically a contract address) and allowing applications to discover those interfaces and interact with them. Interfaces can be implemented either by the target contract (if any) or by any other contract.
|
||
|
|
|
||
|
|
## Motivation
|
||
|
|
EIP 165 supports interface discovery - determining if the contract at a given address supports a requested interface. However, in many cases it's useful to be able to discover functionality associated with a name or an address that is implemented by other contracts.
|
||
|
|
|
||
|
|
For example, a token contract may not itself provide any kind of 'atomic swap' functionality, but there may be associated contracts that do. With ENS interface discovery, the token contract can expose this metadata, informing applications where they can find that functionality.
|
||
|
|
|
||
|
|
## Specification
|
||
|
|
A new profile for ENS resolvers is defined, consisting of the following method:
|
||
|
|
|
||
|
|
```solidity
|
||
|
|
function interfaceImplementer(bytes32 node, bytes4 interfaceID) external view returns (address);
|
||
|
|
```
|
||
|
|
|
||
|
|
The EIP-165 interface ID of this interface is `0xb8f2bbb4`.
|
||
|
|
|
||
|
|
Given an ENS name hash `node` and an EIP-165 `interfaceID`, this function returns the address of an appropriate implementer of that interface. If there is no interface matching that interface ID for that node, 0 is returned.
|
||
|
|
|
||
|
|
The address returned by `interfaceImplementer` MUST refer to a smart contract.
|
||
|
|
|
||
|
|
The smart contract at the returned address SHOULD implement EIP-165.
|
||
|
|
|
||
|
|
Resolvers implementing this interface MAY utilise a fallback strategy: If no matching interface was explicitly provided by the user, query the contract returned by `addr()`, returning its address if the requested interface is supported by that contract, and 0 otherwise. If they do this, they MUST ensure they return 0, rather than reverting, if the target contract reverts.
|
||
|
|
|
||
|
|
This field may be used with both forward resolution and reverse resolution.
|
||
|
|
|
||
|
|
## Rationale
|
||
|
|
|
||
|
|
A naive approach to this problem would involve adding this method directly to the target contract. However, doing this has several shortcomings:
|
||
|
|
|
||
|
|
1. Each contract must maintain its own list of interface implementations.
|
||
|
|
2. Modifying this list requires access controls, which the contract may not have previously required.
|
||
|
|
3. Support for this must be designed in when the contract is written, and cannot be retrofitted afterwards.
|
||
|
|
4. Only one canonical list of interfaces can be supported.
|
||
|
|
|
||
|
|
Using ENS resolvers instead mitigates these shortcomings, making it possible for anyone to associate interfaces with a name, even for contracts not previously built with this in mind.
|
||
|
|
|
||
|
|
## Backwards Compatibility
|
||
|
|
There are no backwards compatibility issues.
|
||
|
|
|
||
|
|
## Test Cases
|
||
|
|
TBD
|
||
|
|
|
||
|
|
## Implementation
|
||
|
|
The PublicResolver in the [ensdomains/resolvers](https://github.com/ensdomains/resolvers/) repository implements this interface.
|
||
|
|
|
||
|
|
## Copyright
|
||
|
|
Copyright and related rights waived via [CC0](../LICENSE.md).
|