Design Name Service

Hard45 min
1 / 30
understanding8 min read

Problem Statement: Ethereum Name Service

Problem Statement: Ethereum Name Service — ENS name service interview depth

Problem Statement: Ethereum Name Service

ENS maps human-readable names (e.g., alice.eth) to machine identifiers—primarily Ethereum addresses, but also IPFS content hashes, text records, and DNS-imported zones. The registry is a Merkleized tree keyed by namehash; resolvers are pluggable contracts per node.

Mechanism (sec-01)

  • Wallet interacts with Gateway under namehash invariants
  • Registry emits events consumed by Resolver projections
  • L1 remains consistent within one finalized block window

ENS invariants

The registry owner field and resolver address at a node are authoritative on-chain at block B. Gateway caches are hints keyed by (namehash, blockTag) and must invalidate on NewResolver or Transfer events.

Failure modes (problem)

  • stale Resolver after reorg depth > confirmation threshold
  • Wallet hotspot during NFT-style label drop
  • Registry outage forcing wallets to raw RPC (latency spike)

Interview checkpoint (sec-01)

Quote namehash, commit-reveal, grace period, and CCIP-Read when understanding interviewers press ENS specifics—not generic DNS slides.

Staff+ talking point

Separate forward (name→address) from reverse (address→primary name). Wallets that skip reverse still work, but explorers and reputation systems need both.

Deep dive (problem)

For Problem Statement: Ethereum Name Service, explain how Wallet, Gateway, Registry, Resolver, L1 cooperate under load. Mention EIP-137 resolution, ENSIP-10 wildcard resolvers, and gasless reads via gateway with Merkle proofs where applicable. Close with a concrete story: user renews brand.eth late, enters grace, competitor attempts register—walk timeline with on-chain events.

javaOne Dark Pro
1public final class EnsSection1 {
2 public static final String TOPIC = "problem";
3 public static byte[] namehash(String name) { return new byte[32]; /* keccak iterative */ }
4}
pythonOne Dark Pro
1SECTION_1_TOPIC = "problem"
2GRACE_PERIOD_DAYS = 90
3def is_available(expiry_ts: int, now: int) -> bool:
4 return now > expiry_ts + GRACE_PERIOD_DAYS * 86400
typescriptOne Dark Pro
1export const SECTION_1 = { topic: 'problem', phase: 'understanding' } as const;
2export function cacheKey(namehash: string, blockTag: number | 'latest'): string {
3 return namehash + ':' + String(blockTag);
4}

Why interviewers care

Name Service interviews reward crisp scope, explicit trade-offs, and failure stories—not generic microservice diagrams.

Interview checkpoint

Name one failure story for Problem Statement: Ethereum Name Service that proves you understand real outages, not happy-path diagrams.

Key Highlights

  • Wallet ↔ Gateway boundary
  • Registry projections with block tags
  • Phase understanding: problem focus
Mention this
Tie Problem Statement: Ethereum Name Service to namehash, resolver records, and expiry/grace—not generic DNS.
Pro tip
Simulate register/reveal with eth_call before quoting gas; pin blockNumber on reads.

Section Rescue Kit

Buzzwords to use:

NamehashCCIP-Read

Safe statements:

  • "For Problem Statement: Ethereum Name Service, I'll separate registry truth from gateway cache with block tags."
  • "If stuck, I'll draw commit → reveal → register → resolve before cloud SKUs."
Design Name Service - System Design | WinJob | WinJob