EIP 1577: contenthash field for ENS Source

AuthorDean Eigenmann, Nick Johnson
StatusDraft
TypeStandards Track
CategoryERC
Created2018-11-13

Abstract

This EIP introduces the new contenthash field for ENS resolvers, allowing for a better defined system of mapping names to network and content addresses. Additionally the content and multihash fields are deprecated.

Motivation

Multiple applications including Metamask and mobile clients such as Status have begun resolving ENS names to content hosted on distributed systems such as IPFS and Swarm. Due to the various ways content can be stored and addressed, a standard is required so these applications know how to resolve names and that domain owners know how their content will be resolved.

The contenthash field allows for easy specification of network and content addresses in ENS.

Specification

The field contenthash is introduced, which permits a wide range of protocols to be supported by ENS names. Resolvers supporting this field MUST return true when the supportsInterface function is called with argument 0xbc1c58d1.

The fields content and multihash are deprecated.

The value returned by contenthash MUST be represented as a machine-readable multicodec. The format is specified as follows:

<protoCode uvarint><value []byte>

protoCodes and their meanings are specified in the ensdomains/multicodec repository.

The encoding of the value depends on the content type specified by the protoCode; for instance, types in the range 0x00-0xf0 are encoded using multihash, meaning their value is formatted as follows:

<varint hash function code><varint digest size in bytes><hash function output>

When resolving a contenthash, applications MUST use the protocol code to determine what type of address is encoded, and resolve the address appropriately for that protocol, if supported.

Example

Input data:

storage system: IPFS (0x01)
hash function: sha2-256 (0x12)
hash length: 32 bytes (0x20)
hash: 29f2d17be6139079dc48696d1f582a8530eb9805b561eda517e22a892c7e3f1f

Binary format:

0x01122029f2d17be6139079dc48696d1f582a8530eb9805b561eda517e22a892c7e3f1f

Text format:

/ipfs/7CRg9waUqSw8n2qweMebgzgBa4hxtpNonC7RBeWN5HSF4wx

Fallback

In order to support names that have an IPFS or Swarm hash in their content field, a grace period MUST be implemented offering those name holders time to update their names. If a resolver does not support the multiaddr interface, it MUST be checked whether they support the content interface. If they do, the value of that field SHOULD be treated in a context dependent fashion and resolved. This condition MUST be enforced until December 31st, 2018.

Implementation

To support contenthash, a new resolver has been developed and can be found here, which has been deployed at 0xd3ddccdd3b25a8a7423b5bee360a42146eb4baf3

Copyright and related rights waived via CC0.