-
Notifications
You must be signed in to change notification settings - Fork 5.4k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Draft EIP: Multiple contenthash records for ENS (#2520)
This adds my draft EIP for multiple contenthash records for ENS. Contract implementation is available in ensdomains/resolvers#30, and discussion should be in #2393.
- Loading branch information
Showing
1 changed file
with
75 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,75 @@ | ||
--- | ||
eip: 2520 | ||
title: Multiple contenthash records for ENS | ||
author: Filip Štamcar (@filips123) | ||
discussions-to: https://github.com/ethereum/EIPs/issues/2393 | ||
status: Draft | ||
type: Standards Track | ||
category: ERC | ||
created: 2020-02-18 | ||
requires: 1577 | ||
--- | ||
|
||
## 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. | ||
|
||
```solidity | ||
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. | ||
|
||
```solidity | ||
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 | ||
```solidity | ||
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 | ||
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). |