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.

Resolvers are onchain contracts. How can they provide merkle proofs against Ethereum’s state?

Also, light clients are only lightly (hah) used at present; what wallets will be in a position to take advantage of this functionality?

How does this work in practice? Unless the entire set of ENS names are sent to the TEE, the host computer can infer which name was queried by observing what data is sent into the TEE. If a name is resolved using CCIP-Read, the TEE will also have to make HTTP requests that may reveal the name being queried.

It seems to me that the best way to do privacy-preserving name resolution is to allow users to resolve names using an endpoint that they own or trust.

I’d like to echo @nick.eth’s concerns here as this was an area of research that we went down at some point, trying to enhance our gateway and offer better security and privacy features.

We spent some time looking at the advantages that we might bring with a TEE based approach, also looked at generating zk-proofs of the data being resolved via our gateway (verifiable resolution), but unfortunately there was always a leak in every approach we looked at, whether through network traffic analysis, timing patterns, or the fundamental issue Nick mentioned about data inference from what gets sent to the TEE.

The way we see it today, is that the biggest security upgrade we could ship is to move the signing process to a secure enclave (using for example AWS Nitro Enclaves with P-256 key generation), and upgrade our resolver contract to verify secp256r1 signatures using the new EIP-7951 precompile. While this doesn’t solve privacy, it does provide hardware-guaranteed protection for our signing keys.

That said, it wasn’t extensive research as we had to cut our time short to focus on other priorities, but hope that helps! Excited to see your approach @bilinearlabs!

3 Likes