ENS Integration

[carver]

What was wrong?

We should enable sending transactions from/to an ENS address, and create a contract by referencing an ENS name.

How can it be fixed?

Integrate ens.py inside web3 as a side-loaded module, then add default web3 middleware that converts from values ending in '.eth' to their address as resolved in ENS. ie~ ens.address('to-addr-name.eth')

For security, the name lookup should be relatively fresh, so stalecheck will become a default middleware.

Additionally, an optional middleware reverse_ens could do reverse name lookups when an address would be returned. You might see something like miner = getBlock('latest') return block with: block.miner == 'f2pool.eth'

• add stalecheck middleware as default (maybe 72 hours?) (This logic can stay inside ENS)
• add ens module Import ENS #343

These are in limbo, waiting to be rebased and reopened after #343 is merged:

• create name_to_address_middleware as a default middleware (auto-populates from/to in sendTransaction)
• ENS-aware Contracts (wait for Remove all positional eth.contract args, except address #317 )
  • ABI address inputs could look up .eth names
  • Initialize contracts with ENS addresses: eg~ TokenContract('totally-legit-ico.eth')
  • Deploy contracts with args of ENS addresses: eg~ TokenContract.deploy(args=['withdrawal-wallet.eth'])
• Documentation
  • make it very clear that the address can change mid-stream when using ENS names.
  • how to do token = TokenContract(resolve('name.eth')) for when a user only wants to resolve up-front and only use the address

Reminder to open these issues:

• create address_to_name_middleware as an optional middleware which would replace returned addresses with ENS names
• support name lookups on networks other than mainnet (like testnets), probably using a chain ID lookup in ENS.fromWeb3()

Punt until user demand builds:

• optionally trigger contract failures if name resolution changes (see part # 3 of Documentation above)
• solicit feedback for dynamic contract name lookup, but with strictness around address changes (maybe changes in a recent period, or any changes)

[carver]

When creating a contract, should we save the resolved address or save the name and resolve it on demand? (either way, we should resolve it once to validate that the name points to an address)

For example, if I have a long-running process that sets up a link to some token contract on init:

token = TokenFactory('unicorn.tokens.eth')

Some days or weeks later, say 'unicorn.tokens.eth' points to a new address for an updated token contract. Should the following line make calls to the new token contract address or the old one?

token.balanceOf('mypersonalaccount.eth')

---

Reasons to store the name:

• The user can reproduce the "store the address" option with a manual call to ENS().address('unicorn.tokens.eth') before creating the contract, but the user can't reproduce the "store the name" feature easily.
• In the DNS-equivalent world, say you open a tab and keep it open a long time. Async JS calls in that environment would resolve to the new IP address of the domain.
• Maybe some security fix requires everyone to use the new address, and it's bad to have any requests to the old one

Reasons to store the address:

• Storing the name requires an extra ENS lookup on every contract call/transaction
• Simpler value kept in `contract.address'

I'm leaning toward storing the name.

Did I miss any reasons to store the address, instead? We can mitigate the performance issues with a caching layer.

[pipermerriam]

Dump from my Gitter chat on the subject with you:

I generally agree with the approach of storing the name, however....

1. It would be good to have clear documentation that makes it very clear that the address can change mid-stream when using ENS names.
2. It would be good to have documentation on how to do token = TokenContract(resolve('name.eth')) for when a user only wants to resolve up-front and only use the address.
3. It would be good to have configuration options for the ENS code that did something like either rejecting names that have changes since they were last resolved, or rejected names that were set within some recent time window

1 and 2 are just good documentation practices.

3 may be a made-up use case, but I can imagine an app which you would want it to fail if one of the names it was resolving suddenly changed (but where you still wanted to use ENS names). By configuring a dead period shortly after a name changes, it would allow you a buffer window to respond in the event of a security breach. Your app would start throwing errors because of the sudden change and you'd have time to get into the app and turn it off, or respond in whatever way necessary.

[carver]

Plus follow-up that it doesn't need to be implemented right away:

Jason Carver @carver 13:14
3: I see where you're going. It would be nice to find at least one real production use case to make sure we're building it with reasonable assumptions. Maybe we could add a note in the docs saying that feature is in the design stage, and to on a linked ticket if the reader would use it, then we can get an idea of who would use it and why.

Piper Merriam @pipermerriam 13:15
3 yagni works for me to punt on actually implementing it