HomeEIPs
EIPsERC-2520
ERC-2520

Multiple contenthash records for ENS

StagnantStandards Track: ERC
Created: 2020-02-18
Requires: EIP-1577
Filip Štamcar (@filips123)
DiscussionsOriginal linkEdit
1 min read

The ERC-2520 proposal suggests adding support for multiple contenthash records on a single ENS name. Currently, ENS domains can only store one contenthash record, which means that site owners have to choose which hosting system to use. However, with the increasing number of ENS-compatible hosting systems available, lack of support for multiple records could become problematic. The proposal suggests adding new public interfaces for setting and getting contenthash records, which would allow for multiple records to be stored and retrieved based on the requested type. Additionally, resolvers that support multiple contenthash records would need to return true for a specific interface ID. Applications using ENS contenthash records are encouraged to handle them in a specific way.

Video
Anyone may contribute to propose contents.
Go propose
Original

Simple Summary

ENS support for multiple contenthash records on a single ENS name.

Motivation

Many applications are resolving ENS names to content hosted on distributed systems. To do this, they use contenthash record from ENS domain to know how to resolve names and which distributed system should be used.

However, the domain can store only one contenthash record which means that the site owner needs to decide which hosting system to use. Because there are many ENS-compatible hosting systems available (IPFS, Swarm, recently Onion and ZeroNet), and there will probably be even more in the future, lack of support for multiple records could become problematic. Instead, domains should be able to store multiple contenthash records to allow applications to resolve to multiple hosting systems.

Specification

Setting and getting functions MUST have the same public interface as specified in EIP 1577. Additionally, they MUST also have new public interfaces introduced by this EIP:

  • For setting a contenthash record, the setContenthash MUST provide additional proto parameter and use it to save the contenthash. When proto is not provided, it MUST save the record as default record.

    function setContenthash(bytes32 node, bytes calldata proto, bytes calldata hash) external authorised(node);
  • For getting a contenthash record, the contenthash MUST provide additional proto parameter and use it to get the contenthash for requested type. When proto is not provided, it MUST return the default record.

    function contenthash(bytes32 node, bytes calldata proto) external view returns (bytes memory);
  • Resolver that supports multiple contenthash records MUST return true for supportsInterface with interface ID 0x6de03e07.

Applications that are using ENS contenthash records SHOULD handle them in the following way:

  • If the application only supports one hosting system (like directly handling ENS from IPFS/Swarm gateways), it SHOULD request contenthash with a specific type. The contract MUST then return it and application SHOULD correctly handle it.

  • If the application supports multiple hosting systems (like MetaMask), it SHOULD request contenthash without a specific type (like in EIP 1577). The contract MUST then return the default contenthash record.

Rationale

The proposed implementation was chosen because it is simple to implement and supports all important requested features. However, it doesn't support multiple records for the same type and priority order, as they don't give much advantage and are harder to implement properly.

Backwards Compatibility

The EIP is backwards-compatible with EIP 1577, the only differences are additional overloaded methods. Old applications will still be able to function correctly, as they will receive the default contenthash record.

Implementation

contract ContentHashResolver { bytes4 constant private MULTI_CONTENT_HASH_INTERFACE_ID = 0x6de03e07; mapping(bytes32=>mapping(bytes=>bytes)) hashes; function setContenthash(bytes32 node, bytes calldata proto, bytes calldata hash) external { hashes[node][proto] = hash; emit ContenthashChanged(node, hash); } function contenthash(bytes32 node, bytes calldata proto) external view returns (bytes memory) { return hashes[node][proto]; } function supportsInterface(bytes4 interfaceID) public pure returns(bool) { return interfaceID == MULTI_CONTENT_HASH_INTERFACE_ID; } }

Security Considerations

TBD

Copyright and related rights waived via CC0.

Further reading
Anyone may contribute to propose contents.
Go propose
Adopted by projects
Anyone may contribute to propose contents.
Go propose

Not miss a beat of EIPs' update?

Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.

View all
Serve Ethereum Builders, Scale the Community.
Resources
GitHub
Supported by