§16. Layer 2: Distribution & Execution

Jason St George. "§16. Layer 2: Distribution & Execution" in Next Generation Stores of Value: Privacy, Proofs, Compute. Version v3.2. /v/3.2/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 [TUF 2011–] [Kuppusamy et al. 2016] — 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 [Laurie et al. 2013] applied to release artifacts, with Reproducible Builds [Reproducible Builds 2014–] 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 two independent builders reproduce 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 [Laurie et al. 2013] 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 and expiry-bounded timestamp and snapshot metadata, per TUF [TUF 2011–]. Version counters stop rollback (serving an older, signed release); they do nothing against a freeze attack, in which a mirror or a captured network path serves the current release indefinitely while a patched one exists. Timestamp metadata is therefore re-signed at short interval and carries an expiry; clients reject any metadata older than $T$ hours (reference: $T = 24$, aligned with I4 and I5) and treat an expired timestamp as a failed update, not a successful no-op.

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, and witnessed checkpoints: checking an inclusion proof against a root proves only that the release is in a log the client was shown, and a log operator who serves different roots to different clients (a split view) defeats it without forging anything. Log checkpoints are therefore co-signed by an independent witness set—the pattern of the Sigstore/Rekor witness network and Go’s checksum database—and a client accepts a root only when it carries a threshold of witness signatures, each attesting that the root is consistent with every earlier root that witness has seen.

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 for resolution, Encrypted Client Hello so the SNI itself is not readable on the wire, 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.

Execution Integrity

The chapter’s title promises execution as well as distribution, and delivering correct bytes is not the same as executing them correctly. Three requirements close the gap, each reusing machinery already specified rather than adding a trust root.

Reproducibility verified at install.
I3 has two independent builders reproduce each release before it ships. The client repeats the check on its own machine: at install it recomputes the artifact digest and matches it against both the threshold-signed targets manifest and the builder digests recorded in the transparency log, refusing to activate a binary on which those disagree. A release that reproduced at the ceremony but not on the client’s path is a supply-chain incident.

Least privilege and sandboxing.
The reference verifier runs with no network access it does not need, no filesystem access beyond its receipt store and keys, and no ambient authority over wallet or host, inside the platform sandbox (seccomp/Landlock, App Sandbox, or a WASM runtime). A compromised dependency may lie about one receipt; it must not be able to exfiltrate keys.

Runtime attestation through the same log.
Where the host offers measured boot or a TEE, the running verifier’s measurement is compared against the release digest in the transparency log; a mismatch is surfaced to the user and to telemetry as a signature-failure event. The log that proved the bytes were the released bytes proves the process is running them. Its limit is that of §14: Layer 0: Verifiable Machines & Energy: the measurement is only as trustworthy as the attesting root of trust, and hosts without one degrade to the install-time check, reported as the client’s execution-integrity grade.

None of this is novel; all of it is routinely omitted. The title is earned only if the client that verifies proofs is itself verified to be the client that was released.

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.

New here? Start with the one-minute version.

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