ethers.js
ethers.js copied to clipboard
Support Universal Resolver for looking up name / reverse records for ENS
Describe the Feature
Currently resolving ENS names with ethers.js is very slow due to not supporting universal resolver yet.
If the universal resolver contract is deployed for the chain ( currently mainnet and sepolia supports it , see https://github.com/ensdomains/ensjs-v3/blob/main/packages/ensjs/src/contracts/consts.ts for the full list of it ), it would be able to support multicall like batched calls without waiting for another call like how the current name resolving on ethers.js does it.
This would also speedup overall process of the ethers.js components which uses ens.
You can see some examples on https://github.com/wevm/viem/blob/main/src/actions/ens/getEnsAddress.ts and https://github.com/wevm/viem/blob/main/src/actions/ens/getEnsResolver.ts of how the universal resolver works.
Or on https://github.com/ensdomains/ensjs-v3/blob/main/docs/basics/batching-calls.md for docs.
Code Example
No response
cc @ricmoo I think this is very crucial task and should be implemented as soon as possible. Also right now none of the other libraries of ENS supports this as they only support viem right now.
Thanks! I hadn’t heard of this. Are the calls to the universal resolver done sequentially on-chain? I’m curious how the Ethers MulticallProvider works with this.
@ricmoo For the usecase of ethers.js you don't need multicall to query those records unless if we want to support an array of names or addresses. However, the universal resolver could solve the necessity of multiple eth_calls sent to the nodes to query a name or an address because we don't need to connect an additional resolver contract per name.
@tornadocontrib Could you please elaborate more what are you meaning by saying:
we don't need to connect an additional resolver contract per name.
using the Universal Resolver? Thanks!
@cienhub Hello, I am no expert of ENS but the issue was opened on behalf that the recent Viem and ensjs package supports ENS queries on a single batch through their multicall like contract so if ethers.js adapts it would be able to query multiple results without consuming much resources or rates on nodes.
If you are interested of, you can refer to their codes