-
Notifications
You must be signed in to change notification settings - Fork 43
Verifiable ENS Resolution #1052
Copy link
Copy link
Open
Labels
kind/enhancementA net-new feature or improvement to an existing featureA net-new feature or improvement to an existing featureneed/community-inputNeeds input from the wider communityNeeds input from the wider community
Description
Activity
Metadata
Metadata
Assignees
Labels
kind/enhancementA net-new feature or improvement to an existing featureA net-new feature or improvement to an existing featureneed/community-inputNeeds input from the wider communityNeeds input from the wider community
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.