Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
ENS support for reverse resolution of Ethereum addresses #181
EIP: draft Title: ENS support for reverse resolution of Ethereum addresses Author: Nick Johnson Status: Draft Type: Informational Created: 2016-12-01
This EIP specifies a TLD, registrar, and resolver interface for reverse resolution of Ethereum addresses using ENS. This permits associating a human-readable name with any Ethereum blockchain address. Resolvers can be certain that the reverse record was published by the owner of the Ethereum address in question.
While name services are mostly used for forward resolution - going from human-readable identifiers to machine-readable ones - there are many use-cases in which reverse resolution is useful as well:
Reverse ENS records are stored in the ENS hierarchy in the same fashion as regular records, under a reserved domain,
Note that this means that contracts wanting to do dynamic reverse resolution of addresses will need to perform hex encoding in the contract.
The owner of the
When called by account
Allowing the caller to specify an owner other than themselves for the relevant node facilitates contracts that need accurate reverse ENS entries delegating this to their creators with a minimum of code inside their constructor:
A new resolver interface is defined, consisting of the following method:
Resolvers that implement this interface must return a valid ENS name for the requested node, or the empty string if no name is defined for the requested node.
The interface ID of this interface is 0x691f3431.
Future EIPs may specify more record types appropriate to reverse ENS records.
Appendix 1: Registrar implementation
This registrar, written in Solidity, implements the specifications outlined above.
It seemed like a good idea at the time.
No, and I agree this is a bit confusing. The 'eth' in 'eth-addr' refers to the type of address it's a reverse registry for (eg, Ethereum addresses). If we provided reverse lookups for, say, swarm addresses, that would be on 'swarm-addr.reverse', even though there wouldn't be a .swarm TLD. So, there could be a 2ld under .reverse for each type of address ENS resolves to, rather than for each TLD in a forward address.
Yes, this is more or less how IPv4 addresses (with
Yes, instead of hex encoding the address, we could specify that the reverse record for an address is held at
Do you really foresee the need to do reverse lookups on-chain? The use cases mentioned could probably be satisfied with an off-chain database (perhaps stored in swarm) that is regularly updated to match the forward mapping. An on-chain reverse database doubles the storage requirement for ENS.
No; that's why I didn't think the cost of having to hex encode the data onchain was a compelling one.
Couldn't the same argument be made about forward lookups? Doing either offchain introduces significant challenges in determining how the database is located, and how it's verified to be correct, however.
No because the auction etc needs to be on-chain. It's useful to be able to transfer ownership of domains in a decentralized way. In contrast, the reverse mapping is merely a reorganization of the forward mapping.
That's true, but I suggest these challenges are worth confronting to halve the on-chain storage requirement. The reverse database could be located by a well-known contract that stores a swarm hash. How trustworthy does the reverse mapping need to be? If occasional errors could be tolerated then updates could be managed in a decentralized way by using a security deposit.
I disagree. I think that this is exactly the sort of small-but-valuable data with clearly defined update rules that blockchains are good at storing.
This introduces a dependency on swarm for anyone wanting to do reverse resolution, though. It also turns reverse lookup support from a fairly simple proposition into a significant undertaking all of its own. Reverse resolution is useful now, not if & when we can figure that out.
One really common use-case for reverse lookups is wallets displaying the names associated with contracts and wallet addresses in, eg, transaction histories and address books. If Swarm is required to be able to do these reverse lookups, then a lot of wallet software simply won't support this, because it would impose a significant extra dependency.
Anyone can set a name to point to an address, but is not the reverse true as well? An address can claim some arbitrary name to be its authoritative address, which allows it to masquerade as another entity. This will doubtlessly confuse users, to say nothing of mindless contracts.
I believe that the reverse lookup system must verify that address A owns name B before allowing the reverse lookup to be claimed. Further, there should be a way for any random user to force address A to stop claiming to be the reverse of name B if B is no longer owned by A, for the same reason.
Yes. Resolvers for which this matters (forward and reverse records make different assertions, and not everyone needs both to be true) should perform both resolutions and check they match.
This is doable, but it complicates the system a lot: when a registrar hands ownership of a name (in this case a reverse record) over, it doesn't know what resolver is going to be set for it, or what that resolver will claim the corresponding name is. The only way I can see this working is if the registrar retained ownership of the name and deployed its own resolver, which only supported the
I could well be missing another way to enforce this - so suggestions are welcome.
This will be fine if whatever official library for ENS automatically checks this, but I'm concerned that developers will carelessly ignore this. I suppose if the standard is "THOU SHALT CHECK THE ERROR CODE OF THINE CALL LEST THOU FOOLISHLY BELIEVE A name() IS ACCURATE!" then it's not all that different from any other of the potential-but-avoidable landmines in Ethereumland.
I suppose for contracts, one could provide an on-chain system that caches both lookups, and then a contract that cares must use that specific resolver. Unfortunately, that also is a kind of landmine. "Hello, new developer, here's how to use the ENS within solidity! ...now here's how you actually need to do it if you're concerned about the name being accurate."
On the contrary, however, there are probably legitimate uses for giving an "incorrect" name to an address. (i.e. you're truly claiming to be a certain entity, but it isn't convenient for you to actually set up the names just right.)
I was thinking the registrar could drop a claim if it was proven that the
I suppose the situation overall is not that weirder than being able to lie about who a name "really" belongs to. It's just that UX-wise, the average user's been trained to trust names. If the official message gets out that "Hey, google.eth actually really belongs to Google, don't trust g00gle.eth," which is then followed by a contract which is "named" google.eth asking them to send 100 ETH... well...
But again, you can already perform some weird phising scam with a false name-to-address assertion. If the libraries interacting with ENS are smart enough, this will be much less of an issue.
Update: I've implemented the registrar with unit-tests in the ENS repo. In response to a suggestion from @alexvandesande, I've renamed