Checklist
Description
Background
Currently ENS resolution (e.g. for vitalik.eth resolving to vitalik-eth.ipns.inbrowser.link) relies on delegated-ipfs.dev (and behind the scenes dns.eth.limo) to get the IPFS / IPNS name referenced by the ENS name. It would be nice if we could reduce the users' need to trust the results of dns.eth.limo and ideally to have some resilience in the event of any issues with dns.eth.limo.
Proposal
When detecting a request for an ENS name dynamically load code for ENS traversal and for verifiable Ethereum lookups backed by public verifiable Ethereum RPC endpoints (e.g. supporting eth_getProof, eth_createAccessList, etc.). The verifiable RPC endpoints could be provided by anyone in the Ethereum ecosystem, although given the alignment here the ENS community seems the most impacted and perhaps a public goods operator like the great folks over at eth.limo might be able to help here.
If this is something you'd like to see happen give a 👍 reaction on this comment.
Checklist
Description
Background
Currently ENS resolution (e.g. for vitalik.eth resolving to vitalik-eth.ipns.inbrowser.link) relies on delegated-ipfs.dev (and behind the scenes dns.eth.limo) to get the IPFS / IPNS name referenced by the ENS name. It would be nice if we could reduce the users' need to trust the results of dns.eth.limo and ideally to have some resilience in the event of any issues with dns.eth.limo.
Proposal
When detecting a request for an ENS name dynamically load code for ENS traversal and for verifiable Ethereum lookups backed by public verifiable Ethereum RPC endpoints (e.g. supporting eth_getProof, eth_createAccessList, etc.). The verifiable RPC endpoints could be provided by anyone in the Ethereum ecosystem, although given the alignment here the ENS community seems the most impacted and perhaps a public goods operator like the great folks over at eth.limo might be able to help here.
If this is something you'd like to see happen give a 👍 reaction on this comment.