# Brainstorm: Storing DNS Public Keys (Active & Inactive)

## Context
- **Active keys**: Can be fetched directly over DNS lookups with relatively little friction.
- **Inactive keys**: Pose a significant challenge, as they may no longer be resolvable via DNS but are still valuable for historical verification, cryptographic research, or replay validation.

This document explores potential approaches for storing and maintaining both active and inactive DNS public keys, along with their advantages, disadvantages, and possible design considerations.

---

## 1. Archival Database with On-Chain Commitments

**Idea**
- Maintain a global archive (centralized or federated) that stores all observed DNS keys.
- Contributions:
- Archive collects all *active* DNS keys directly.
- Community can contribute inactive keys.
- Multiple signatures observed from the same key allow public key reconstruction (e.g., via GCD across RSA signatures).
- To ensure trust:
- Each time the archive sees a new key, it publishes a *commitment* on-chain.
- Commitments that remain unchallenged for a long period gain stronger credibility.

**Advantages**
- Provides a canonical historical record of all keys.
- On-chain commitments ensure integrity and tamper resistance.
- Community contributions enrich the archive with otherwise lost inactive keys.

**Disadvantages**
- Archive needs governance (who maintains it?).
- Risk of malicious submissions.
- Relying on chain commitments increases costs (gas fees, scalability).

---

## 2. Optimistic Proofs via Smart Contracts

**Idea**
- Deploy a smart contract that maintains a “DNS → key” mapping.
- Keys can be updated optimistically by anyone.
- Updates are subject to a challenge period (e.g., one week).
- If unchallenged, the update becomes final (“fossilised”).

**Advantages**
- Lightweight: only disputed updates require active resolution.
- Aligns with established optimistic rollup / fraud-proof paradigms.
- Historical trail of key changes remains preserved on-chain.

**Disadvantages**
- Requires active challengers (watchdogs) to prevent false updates.
- Potential latency between update and finalisation (waiting period).
- Challenge game design complexity.

---

## 3. AVS (Actively Validated Service) via Eigenlayer

**Idea**
- Build an AVS where multiple operators reach consensus on DNS public keys.
- Query flow:
- A client queries DNS for a key.
- AVS participants collectively respond.
- If they collude or lie, they get *slashed*.

**Advantages**
- Leverages existing Eigenlayer economic security.
- Strong disincentives against malicious behaviour.
- Distributed, reduces single-point of failure.

**Disadvantages**
- Requires large, incentivized operator set.
- Slashing conditions must be carefully defined (how do you *prove* misbehaviour?).
- Latency and cost may be higher than DNS queries.

---

## 4. Historical Snapshots via Distributed Storage (IPFS/Arweave)

**Idea**
- Regularly snapshot DNSKEY zones and publish them to IPFS/Arweave.
- Each snapshot timestamped and content-addressed.
- Provides immutable record of both active and inactive keys as they evolve over time.

**Advantages**
- Low on-chain cost (only need to anchor snapshot hashes periodically).
- Provides a verifiable timeline of DNS keys.
- Leverages existing decentralized storage systems.

**Disadvantages**
- Snapshots may miss short-lived keys (requires high frequency crawling).
- Storage growth over time can be large.
- Trust in the crawler(s) needed unless multi-party crawlers are used.

---

## 5. Certificate Transparency-Style Logs for DNS Keys

**Idea**
- Adapt the **CT log model** (used for TLS certificates).
- Append-only Merkle tree storing DNS public keys.
- Auditors and monitors continuously check logs for consistency and new entries.

**Advantages**
- Well-understood model with real-world deployments.
- Provides strong auditability guarantees.
- Easy to integrate into client validation (like browsers do for CT).

**Disadvantages**
- Requires dedicated log operators.
- Doesn’t prevent malicious logs unless there’s diversity and gossip protocols.
- Still needs client adoption for validation.

---

## 6. Hybrid Approaches

- **On-Chain Anchoring + Off-Chain Storage**:
Commitments stored on-chain; actual keys stored on IPFS/Arweave/archive DB.
- **Multi-Party Witnessing**:
Keys are valid only if attested by multiple independent crawlers/validators.
- **Incentive-Backed Challenges**:
Similar to optimistic proofs, but challengers are rewarded for catching incorrect entries.

---

## Comparison Matrix

| Approach | Trust Model | Cost | Pros | Cons |
|----------|-------------|------|------|------|
| Archival DB + Commitments | Centralized + On-chain anchoring | Medium | Canonical history, easy contributions | Governance, gas costs |
| Optimistic Proofs | Anyone can propose, challengers verify | Low to Medium | Lightweight, simple fraud proof model | Needs active challengers |
| AVS / Eigenlayer | Decentralized validators | High | Strong crypto-economic security | Complex slashing proofs |
| Snapshots (IPFS/Arweave) | Trust in crawlers | Low | Immutable history, cheap anchoring | Might miss transient keys |
| CT-Style Logs | Log operators + auditors | Medium | Battle-tested model, strong auditability | Needs multiple logs, gossip |