Evm-chain reverse resolution #132
Conversation
|
|
||
| ## Specification | ||
|
|
||
| * Use ENSIP-3 to reverse resolve an address to a name. |
There was a problem hiding this comment.
ENSIP-3 doesn't specify how it does reverse lookup for multi chain and storing all the data on L1 is not feasible if we want to support contract base account (eg: multisig wallet). L1 has no knowledge of who the signers of the multisig on other chains nor be able to call isValidSignature specified by EIP-1271 on chain.
The alternative approach is store the reverse record in each l2 chain and have l1 reverse record .reverse to have chain specific namespace (eg: .[[coinType](url)].reverse) that fetches the data via L1 using CCIP-read.
NOTE: coinType follows ENSIP-11
example use case
- ENS lab creates a multisg contract 0x01 on Arbitrum
- ENS lab sets L2(Arbitrum) reverse registrar as
0x01.arbitrumcointype.reverse=arbitrum.ens.ethon Arbitrum - When a dapp wants to display the primary name of 0x01, the site lookup 0x01.aribtrumcointype.reverse on Mainnet but fetches the data via Arbitrum through CCIP-read
The only modification to client code is that the dapp has to passes the chain info (aribtrumcointype) in the lookup at #3, but at least users don’t have to switch networks for the read operation.
There was a problem hiding this comment.
I have written a little bit about this in this gist: https://gist.github.com/jefflau/7e9d303078891a969bfe70011e347bc0#canonical-registry-on-each-supporting-chain-with-discovery-mechanism
I did not specify the discovery mechanism, but I think having it using ccip-read is a reasonable option. The other alternative I could think of is using a resolver and using the addr record on the resolver. But I think using ccip-read makes a lot of sense here is probably a superior option
…-compatible chains
No description provided.