主页EIPs周刊
EIPsERC-1844
ERC-1844

ENS Interface Discovery

StagnantStandards Track: ERC
创建时间: 2019-03-15
关联 EIP: EIP-137, EIP-165
Nick Johnson (@arachnid)
社区讨论原文链接编辑
1 分钟了解
欢迎补充好内容
去提交
相关视频
欢迎补充好内容
去提交
正文

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:

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 repository implements this interface.

Copyright and related rights waived via CC0.

扩展阅读
欢迎补充好内容
去提交
相关项目
欢迎补充好内容
去提交

不想错过最新的 EIP 动态?

订阅 EIPs Fun 周刊以跟进相关更新,建⽴你与 EIP 之间的连接 ,更好地建设以太坊。

详情
支持以太坊贡献者,推动生态建设
资源
GitHub
支持社区