Design Goal

We want DA nodes to store and serve blob data while not learning which Zone/App the blob belongs to.

Key point: we’re not primarily trying to hide contents, we’re trying to hide the linkability:

(blob / column / share) ↔ (zone_id / app identity / namespace / routing metadata)

Encryption may be optional, but if the only robust way to break linkability requires it, we should consider it.

Security Goals

ID Goal Description
G1 Private attribution (unlinkability) A DA node and passive observer cannot reliably decide which zone/app produced or consumes a particular DA object, beyond negligible advantage over guessing within a large anonymity set
G2 DA correctness remains public Availability and integrity of blobs are still publicly verifiable, as in normal DA. Sampling, reconstruction, and KZG proof verification are unchanged
G3 Deployment compatibility Zones can adopt Private DA incrementally. Existing DA APIs require minimal changes, ideally isolated behind a proxy/relay layer
G4 Practicality Avoid heavyweight primitives unless justified by strong threat assumptions and bounded cost

Threat Model (what “private DA” must resist)

Assume DA nodes / observers can see:

We want to prevent:

  1. Direct labeling: explicit zone/app identifiers in DA-layer objects or requests.
  2. Traffic analysis linkage: correlating submitter → DA storage → sampler/fetch patterns.
  3. Cross-layer correlation: consensus events + DA fetch patterns reveal zone/app.
  4. Dictionary attacks: small structured identifiers (zone_id, short namespace) guessed offline.
  5. Replay / fingerprinting: repeated formats, stable handles, or deterministic request shapes.

Design principle: separate “DA validity” from “app attribution”