Grant Proposal: Verifiable and Privacy‑Preserving ENS Resolution

Introduction

Traditional DNS services lack verifiability and privacy, since the resolver sees every request a user makes. Existing ENS services suffer from the same problem: to our knowledge, none provide cryptographic proof of correctness, and resolvers offer no meaningful privacy guarantees, at best a “trust me” promise.

Grant Proposal

  • Verifiable ENS resolution.
    In addition to returning the usual name.eth → RECORD, the resolver will supply a Merkle‑proof package that any light client can verify against a published block hash, no full node required.
  • Privacy‑preserving ENS resolution.
    Resolution logic will run inside a Trusted Execution Environment (TEE). Along with the name.eth → RECORD, the user receives an attestation that the code executed within the enclave, ensuring the host machine never learns which name was queried.

Rough Timeline (8 months)

  1. Design: define protocols, threat model, TEE architecture
  2. PoC: Verifiable resolution
  3. PoC: Privacy‑preserving resolution
  4. Integrated end‑to‑end PoC
  5. Iteration: refine based on testing and feedback
  6. Production implementation
  7. Documentation & release

Budget

To be defined

Team

Bilinear Labs
Twitter: https://x.com/BilinearLabs

Happy to receive feedback on this idea and to discuss it further if you find it relevant.

2 Likes

This seems interesting but I think it depends on particulars. What software must be executed? What kinds of names can be verified? What’s it take to generate the proof of resolution?


For example, Unruggable Gateways (Urg) is a pretty sophisticated thin client. Urg has a verifier called SelfVerifier which lets you verify nearly anything about the current chain (rather than crosschain/rollup, like L2 Primary Names.)

SelfVerifier.sol was not included in the recent audit but it’s extremely simple (<50 LoC) and its critical components were already audited: GatewayVM.sol and the various proof verifiers like EthVerifierHooks.sol.

Using the SelfVerifier+EthVerifierHooks on mainnet, you can construct a human-readable query which reads the resolver of a namehash from the ENS registry, then reads the necessary data from that resolver, as a single gateway request.

Each resolvers storage layout is different, so you’d need a conditional load of a program specific to each resolver contract.

For example, the PublicResolver (V3) requires the following gateway program to read the addr(60) for an arbitrary node:

// assuming: target = resolver, stack = [node]
const program = new GatewayProgram()
    .setSlot(0) // recordVersions
    .pushStack(0) // node
    .follow() // recordVersions[node]
    .read() // version, leave on stack at offset 1
    .setSlot(2) // addresses
    .follow() // slot
    .follow() // node
    .push(60).follow()  // coinType
    .readBytes() // addresses[version][node][coinType]
    .setOutput(1);

Which is equivalent to the following Urg bytecode: 0x00460029483c0102464848013c483d010133

Then you just read this program stored onchain, conditional on the resolver in the registry, which can be proven as part of the request.

I created a simple demo which proves the addr(60) of "vitalik.eth".

This would require audits on SelfVerifier.sol, VerifyENS.sol, and the program for each resolver. The trust would be on the execution environment and the ability to obtain a relevant blockhash.

A significantly more sophisticated (but limited scope) example is ETHTLDResolver.sol which is the crosschain resolver for Namechain that supports feature parity with the PublicResolver.

In both cases, Urg generates a proof trace for the execution and can interleave logic using its internal VM. Urg has enough expessive power that it can execute ENSIP-10 or Namechain “Registry of Registries” logic.


It would be cool to have other execution environments as not everyone has access to a local Ethereum node or can execute Solidity locally and obtain a known blockhash.

Privacy‑preserving ENS resolution is also interesting.

2 Likes

Thanks for the input. To be more specific, I propose to do both i) verifiable resolution and ii) privacy-preserving resolution for only ENS L1 domains and without using external contracts. Purely proving against Ethereum’s trie directly.