Managed ENS Registrar and Resolver

[shazow]

Todo

• Managed Registrar
• Resolver frontend
• Deploy script
• Measure gas for deploy and hot paths
• Write frontend example code (standalone dapp or maybe hardhat?) that exercises resolving using an official lib (ethers.js or ens.js?)
• Deploy on Goerli to test it live (Not doable right now? DoS)
• Setup forked local node end-to-end environment
• Implement ENSIP-10 (interface 0x9061b923), seems ethers.js requires it now?
• Investigate optimistic wildcard resolution, if skyteller names are CREATE2'd
  • Overrideable addr's, still backed by a registrar if present (to help migrate old-style addresses, and to deal with drama)
  • Do we care about simple onchain resolving flow? (Also used by forge resolve-name), doesn't work with wildcard
• Decide if we want reverse resolving? (Desirable but don't want to commit to paying more gas)
  • Implement on-demand reverse resolving (basically defer the decision post-launch)
  • Investigate: Could we get it for "free" if the CREATE2'd receiver contract has a name() returns (string)?
    • Hard to prevent griefing, probably not worth it over permit-based registry?
• Decide if we want more functionality fronted by the resolver (Yes)
• Investigate which resolve strategy is used in different contexts
  • 🔴 Onchain (not sure how often this is used today, not very?): Root ENS resolve
  • 🟢 Ethers.js: Recursive resolver, supports wildcards
  • 🟠 Ethers-rs (and foundry/forge/etc): Root ENS resolve
    • Looks like ethers-rs is not interested in adding native wildcard support, punting to a middleware: https://github.com/ensdomains/ethers-ccip-read
  • ensjs (almost definitely 🟢, haven't had a chance to look yet)
  • wagmi/viem
  • 🟢 MetaMask: Uses modern ethers.js
• Casual self-audit, run static analyzers etc
• Write README
• Remove extraneous submodules (can probably get away without the ENS submodule, and maybe without solmate)
  • Ended up switching from solmate to openzeppelin (it had some stuff I needed, and more consistent with the rest of skyteller's contracts). ENS submodule is probably removable, includes are fairly trivial.
• Bonus: Compare gas on L1 (where calldata is cheaper) vs L2 (where calldata is more expensive) -- different optimizations can be done for each.
• Bonus: Could deploy an entire ENS instance for integration tests, but probably not worth it (testing the wrong thing IMO). Added end-to-end fork test for mainnet instance.
• For reverse lookup, need to add claimWithResolver call that needs to be done by the target address (see note below): https://docs.ens.domains/contract-api-reference/reverseregistrar

Gas

Approach 1: Managed registrar

Update: Previous numbers were off, we need to add a subnode (for some SDKs) on the global ENS instance if we want resolver to work onchain.

• 85,958 gas per register that works with naive resolvers, like simple onchain resolvers and ethers-rs.
  💵 $17.2 per set at $2000 ETHUSD and 100 gwei gas.
• 24,180 gas per register for SDKs that support recursive/wildcard resolving (like ethers.js).
  💵 $4.84 per set at $2000 ETHUSD and 100 gwei gas.

Reverse name lookup registry is an additional ~25k gas, plus call to register the resolver in the global instance against the target address. (See note below)

Approach 2: Permit registrar

• 52,092 gas by user to register "foo" with reverse lookup, only wildcard resolver compatible.
  💵 $10.42 per set at $2000 ETHUSD and 100 gwei gas.

Notes

(Removed outdated notes, they were mostly integrated into above.)

• Reverse registry note: The target address for reverse lookup needs to register a resolver with the global ENS contract: https://docs.ens.domains/contract-api-reference/reverseregistrar
  If the target address is a contact (e.g. the skyteller proxy), then the contract would need to call that. This would require adding a helper function to the skyteller proxy (or doing it on init).

[shazow]

Forgot one more thing here: The target address for reverse lookup needs to register a resolver with the global ENS contract: https://docs.ens.domains/contract-api-reference/reverseregistrar

If the target address is a contact (e.g. the skyteller proxy), then the contract would need to call that. This would require adding a helper function to the skyteller proxy (or doing it on init).