Dynamic on-chain resolution

🪳 Bug Reports
1

Hi,

I’m attempting to create a resolver for dynamic address lookup. My users (dApps and contracts) know to refresh the address frequently and not to save long lasting sessions. So I have good confidence that my client code will not cache addresses for too long - However, there is a requirement to emit AddrChanged events (EIPs/eip-137.md at master · ethereum/EIPs · GitHub) which I cannot easily meet. The contracts which determine the actual addresses do not have hooks whereby I can notify my resolver of these changes when they happen. So the resolver is not easily notified of the change.

If I want to satisfy this requirement to emit AddrChanged events I would have to monitor the network constantly and send transactions to my resolver contract whenever the mappings change. which is expensive. I’d like to avoid that.

I suppose this could be a problem for indexing services which rely on these events (thegraph?) however, Since I’m using the default TTL (0), I was hoping it might be ok. I need advice on this.

  1. If I cannot emit AddrChanged events, what else might break?
  2. Are there other commonly used resolvers which violate this requirement? Is it otherwise common to avoid emitting AddrChanged or practical?
  3. should I set TTL to some positive small number (e.g. 10) to signal indexing services they should not rely on cached values? Or is 0 actually “never cache” rather than “always cache”?

Thanks in advance!
Ron

2

I’ve always envisaged this as a potential use-case for resolvers. If there’s no onchain transaction, you can’t emit an event - and I’ve strongly discouraged anyone relying on the subgraph or anything else constructed from AddrChanged events for name resolution. I think you can safely do this - but you might want to have it emit at least one AddrChanged event to a ‘safe’ address - possibly a contract that always reverts?

3

Thanks, good idea to set a safe address!