ERC-2520: Multiple contenthash records for ENS
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, thesetContenthash
MUST provide additionalproto
parameter and use it to save thecontenthash
. Whenproto
is not provided, it MUST save the record as default record. -
For getting a
contenthash
record, thecontenthash
MUST provide additionalproto
parameter and use it to get thecontenthash
for requested type. Whenproto
is not provided, it MUST return the default record. -
Resolver that supports multiple
contenthash
records MUST returntrue
forsupportsInterface
with interface ID0x6de03e07
.
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 defaultcontenthash
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
Security Considerations
TBD
Copyright
Copyright and related rights waived via CC0.