§16. Layer 2: Distribution & Execution

Jason St George. "§16. Layer 2: Distribution & Execution" in Next Generation Stores of Value: Privacy, Proofs, Compute. Version v1.9. /v/1.9/read/part-iii/16-layer-2/

Layer 2: Distribution & Execution

Software distribution is where lofty protocol guarantees meet the boring reality of phones, laptops, and routers that have to run code. In a repression cycle, app stores are throttled, DNS is poisoned, and “safety” policies become chokepoints.

It is far easier to lean on an app store, certificate authority, or CDN than to break a new primitive. If privacy, proofs, and compute are to support an associated base-asset monetary candidate, then the binaries that implement those services must keep moving even when networks are hostile.

Prior art this chapter stands on.

The supply-chain invariants below (I1–I5) are not novel claims; they are the TUF/Uptane guarantee set — threshold signing roles, freshness and anti-rollback, reproducibility, compromise response, multi-path delivery — restated for this stack, and the transparency-log mechanism is Certificate Transparency applied to release artifacts, with Reproducible Builds as the verification floor. Layer 2’s contribution is narrower: adapting these to a monetary client whose update path must survive exactly the states in which the asset’s holder-side service is supposed to deliver, and wiring the update channel’s health into VerifyReach telemetry. Entries in Sources under “Software Update Security & Transparency.”

Threat Model & Objectives

An adversary’s repertoire at this layer:

• App-store removals and policy bans.

• DNS poisoning, SNI and IP blocking, TLS interception.

• BGP hijacks or route blackholing for update servers.

• Certificate revocations; captive portals that substitute their own “secure updates.”

• Targeted developer coercion and “emergency directives.”

Objectives:

• Reachability: users can discover and fetch releases despite interference.

• Authenticity: users can verify what they fetched without trusting a platform.

• Safety: upgrades are atomic, reversible, and survive power loss.

• Neutrality: no single jurisdiction or vendor can gate updates.

• Telemetry without doxxing: reliability is measurable without surveillance.

Design Rules

Authenticity before reachability.
Releases ship with threshold signatures (3-of-5) from independent maintainers, plus inclusion in an append-only transparency log.

Reproducible builds as default.
At least one independent builder reproduces binaries from source; the build process emits deterministic artifact hashes and proofs.

Threshold keys and real revocation.
Root keys live offline and are sharded; release keys rotate regularly; revocation is a signed artifact in the transparency log.

Binary transparency anchored to a proof ledger.
The update log behaves like certificate transparency for releases, periodically anchored to a neutral proof ledger.

Atomic updates with safe rollback.
Clients update into an inactive slot, flip a pointer only after verification, and revert automatically on failure.

Graceful degradation.
Offline packages (USB, SD, QR) use the same receipts and keys.

Supply-Chain Invariants (Must Hold)

I1. Authenticity: Every release requires threshold signatures ($\geq$3-of-5) from independent maintainers in $\geq$2 jurisdictions, plus transparency log inclusion.

I2. Freshness: Clients enforce monotonic version counters. Rollback attacks are detected and rejected.

I3. Reproducibility: At least 2 independent builders reproduce each release. Divergence is release-blocking.

I4. Compromise response: If a signing key is compromised: revocation within 24 hours, affected releases quarantined, post-mortem within 14 days.

I5. Multi-path availability: Releases available via $\geq$3 independent channels. No single channel’s failure blocks updates for $>$24 hours.

Reference Distribution Architecture

The architecture is deliberately multi-homed. We assume any single channel can become a chokepoint.

Control plane (discovery and metadata):

• Standard HTTPS endpoints behind diverse DNS providers.

• Tor onion services exposing the same manifests.

• Signed release announcements gossiped over generic protocols (Matrix, Nostr).

• Append-only transparency log with roots checkable by light clients.

Data plane (artifact delivery):

• Traditional CDNs and anycast mirrors in multiple jurisdictions.

• P2P swarms (IPFS-like or BitTorrent-class) using content addressing.

• Community micro-mirrors with signed manifests.

• Offline channels: USB/SD bundles, QR-encoded update chunks, radio relays.

All of these are interchangeable from the client’s perspective. Whoever delivers the bytes fastest wins, but no one is trusted beyond the hash: the client verifies the final digest and only then installs.

Key Management & Release Process

Key management is where many otherwise sophisticated systems quietly re-centralize. A single HSM in a single jurisdiction becomes a soft power lever: compromise the humans or the box, and you own the distribution pipeline.

A capture-resistant release process needs:

• Public release ceremony. Changes land on protected branches; CI produces deterministic binaries; independent builders confirm bit-for-bit equality. A quorum of maintainers signs the targets manifest.

• Emergency freeze and unfreeze. Any maintainer can propose a freeze, but activation requires a threshold of signatures. Unfreeze requires an explicit, signed artifact explaining the incident.

• Compromise playbook. Detect, revoke, rotate, and re-sign last-known-good releases. All steps produce receipts that anyone can audit.

• Jurisdictional diversity. Key shards and signers are distributed across legal zones, making it difficult for one government to unilaterally subvert the process.

Update Economics & Neutrality

Distribution has an economics layer just as proofs and compute do. Instead of pretending bandwidth and storage are free, we let mirrors be market actors: they meter what they serve, emit receipts, and get paid for honest work.

• Receipts for bytes: mirrors export metered receipts signed by their nodes; a broker aggregates and pays out via privacy rails with SLA escrow.

• Open admission: any party can become a mirror by publishing bandwidth and uptime commitments and staking a small bond.

• Anti-capture telemetry: publish house-share, top-N mirror share, geographic/ASN diversity. If a CDN dominates beyond thresholds, route weight decays automatically.

Fallback Playbooks

Having explicit, rehearsed playbooks keeps censorship events from becoming existential crises:

Soft network blocks (DNS/SNI/IP):
Bias clients toward alternative control-plane channels (DoH/DoT, onions), and toward content-addressed P2P for artifacts.

Hard regional blocks:
Rely on offline kits (USB/SD bundles, QR sets) seeded through civic institutions and NGOs.

App-store bans:
Publish signed sideload bundles with clear, localized installation instructions.

Key compromise:
Hit the freeze button; revoke; rotate; and re-sign last-known-good releases, with all steps recorded in the transparency log.

Lawful Privacy in Distribution

The same architectural moves that make distribution censorship-resistant also make it more legible to good-faith auditors. Transparent logs, reproducible builds, and signed receipts give regulators something objective to look at:

• Which releases were shipped, and when.

• Which vulnerabilities were patched, and how quickly.

• Whether there were jurisdiction-specific forks or backdoors.

Crucially, auditors can examine this evidence without sitting in the middle of every update flow. The system does not ask to be exempt from scrutiny; it insists that scrutiny be applied at the level of receipts and logs rather than taps and implants.

Update Telemetry

To make distribution part of the triad’s credibility, networks should publish continuously:

• Update health: p50/p95 metadata and artifact fetch times; per-path success rates; rollback and signature-failure rates.

• Transparency evidence: current log roots; inclusion proofs for each release.

• Decentralization metrics: top-N mirror share; geographic and ASN diversity.

• Key material and incidents: root fingerprints; release-key roster; revocation lists; incident reports.

Tip: hover a heading to reveal its permalink symbol for copying.