Appendix A. Formal Model of Verification Asymmetry & VerifyPrice

v1.0

Download PDF Table of Contents Cite / Checksums

Cite this section

Copy/paste (plain text):

Jason St George. "Appendix A. Formal Model of Verification Asymmetry & VerifyPrice" in Next‑Gen Store of Value: Privacy, Proofs, Compute. Version v1.0. /v/1.0/read/appendix/a-verifyprice-model/

Appendix A: Formal Model of Verification Asymmetry & VerifyPrice

Definition 1 – VerifyPrice(W) and verification overhead

For each canonical workload W (for example, a constraint system $\text{PROOF}_{2^{20}}$ , a matrix multiplication size MATMUL_4096, or a verified-inference task INFER_LM_70B_256TOK), we care about two things:

How expensive it is to verify a purported result on a reference verifier, and
How that verification cost compares to producing the result from scratch.

VerifyPrice(W): verification profile

Fix a reference verifier and adversarial mix of inputs. From a sample of verification runs for workload W, we estimate:

p50_t(W), p95_t(W): median and 95th-percentile wall-clock verify time from “artifact received” to “accept/reject”;
p50_c(W), p95_c(W): corresponding median and 95th-percentile verify cost in a reference unit (e.g., USD of cloud compute);
fail(W): observed fraction of artifacts that fail verification (invalid, malformed, or timed out).

The VerifyPrice vector for W is then:

$\text{VerifyPrice}(W) \equiv (p_{50,t}(W), p_{95,t}(W), p_{50,c}(W), p_{95,c}(W), \text{fail}(W))$

ProduceProfile(W): production profile

Similarly, we can describe the prover’s cost to produce correct outputs for W. From a sample of production runs (or cost models) we estimate median and 95th-percentile produce time and cost:

$\text{ProduceProfile}(W) \equiv (p_{50,t}^{\text{prod}}(W), p_{95,t}^{\text{prod}}(W), p_{50,c}^{\text{prod}}(W), p_{95,c}^{\text{prod}}(W))$

Verification overhead r(W)

We define separate time- and cost-based overhead ratios:

$(v/p)_W^{\text{time}} = \frac{p_{50,t}(W)}{p_{50,t}^{\text{prod}}(W)}$

$(v/p)_W^{\text{cost}} = \frac{p_{50,c}(W)}{p_{50,c}^{\text{prod}}(W)}$

For convenience, we can summarize these as a single scalar:

$r(W) \equiv \max\left((v/p)_W^{\text{time}}, (v/p)_W^{\text{cost}}\right)$

Implementation note – VerifyPrice telemetry schema (sketch)

The exact encoding of VerifyPrice is implementation-dependent, but for operational dashboards and APIs it helps to standardize a minimal JSON-style schema per canonical workload. A skeletal example:

{
  "workload_id": "PROOF_2^20",
  "window_start": "2025-06-01T00:00:00Z",
  "window_end":   "2025-06-07T00:00:00Z",

  "p50_verify_time_sec": 0.40,
  "p95_verify_time_sec": 0.90,

  "p50_cost_usd": 0.00030,
  "p95_cost_usd": 0.00055,

  "failure_rate": 0.0004,

  "r_time": 0.18,
  "r_cost": 0.21,
  "r_max": 0.21,

  "sample_size": 125000,
  "hardware_profiles": ["open_tee_v2", "gpu_cluster_Y_v1"]
}

This schema is not normative; it is illustrative. The key properties are:

Each canonical workload (workload_id) has its own series of VerifyPrice snapshots over sliding windows.
VerifyPrice is expressed both in time and cost percentiles, with the overhead ratio $r(W)$ reported explicitly.
Enough context is included to interpret shifts (sample size, hardware profile mix, time window), but no user-identifying data is required.

Clients and observatories can compute VerifyPrice from raw receipts and emit them in this or a similar format. The important thing is that:

The mapping from receipts → VerifyPrice is public and reproducible, and
The resulting metrics are exposed in a way that any third party can verify and alert on.

A system that claims “cheap, public verification” but cannot produce machine-readable VerifyPrice series for its canonical workloads is, by construction, asking you to trust what it cannot or will not measure.

We say that $W$ is verification-asymmetric if $r(W) \ll 1$ : checking honest work is much cheaper than re-doing it from scratch, both in time and cost.

A network (or facility) satisfies the VerifyPrice SLO for workload $W$ if, for a published target (e.g., $p_{95,t}(W) < 5$ s, $p_{95,c}(W) < 10^{-3}$ USD), it maintains:

$\text{fail}(W)$ below a small, explicit threshold, and
$r(W) \leq 0.3$ (with a stretch goal $r(W) \leq 0.1$ ),

over adversarial mixes of inputs and artifacts.

Definition 2 – Facility Energy Receipt (FER)

A Facility Energy Receipt (FER) is a signed, machine-readable summary of a site’s energy use and availability over a fixed time interval $\Delta t$ . Each FER is identified by a unique hash fer_id and contains at least:

facility_id: a stable identifier for the site or plant;
interval_start, interval_end: timestamps delimiting the reporting window;
energy_in_kwh: total electrical energy consumed at the site boundary over $\Delta t$ ;
energy_it_kwh: energy delivered to IT loads (provers, routers, storage);
heat_reused_kwh: energy captured and reused (for ERE metrics);
pue, ere, wue: standard efficiency and water-use indicators over $\Delta t$ ;
outages: a list of curtailment or outage events during $\Delta t$ ;
carbon_intensity_kg_per_kwh: average emissions factor for supplied energy;
signature: one or more digital signatures attesting to the report’s correctness.

FERs are produced at regular cadence (e.g., every 5 minutes or hour). Other receipts (e.g., PIDL receipts for proofs) can reference a FER via fer_id, allowing allocators, auditors, and protocols to reconstruct the energy context in which a unit of verified work was performed.

Definition 3 – PIDL Receipt (Proof Interface Definition Language)

A PIDL receipt is the minimal, canonical record of a verified interaction in the Create/Compute → Prove → Settle → Verify loop. It binds together the claim, the evidence, and the operational context into a single, serializable object.

At a minimum, a PIDL receipt contains:

receipt_id: a unique identifier (e.g., a hash of the serialized payload);
claim_id: an identifier or hash of the claim being attested;
workload_id: a canonical tag for the workload type and parameters (e.g., PROOF_2^20, MATMUL_4096);
proof_ref: a hash or pointer to the proof or transcript artifact;
sla_tier: the service class under which the work was promised (e.g., Bronze/Silver/Gold);
verify_time_sec, verify_cost_unit: measured time and cost for verification;
result: an outcome flag (e.g., accept, reject, timeout);
optional context: hardware_profile, fer_id, settlement_txid, policy/jurisdiction tags;
signatures: digital signatures from the prover, verifier, and (if applicable) broker or router.

PIDL receipts are designed to be portable and composable: they can be embedded in blocks, stored off-chain with only their hashes committed on-chain, included in higher-level proofs, or presented to auditors and counterparties.

Definition 4 – VerifyReach(N, R)

Reachability and path diversity for independent verifiers in network N and region R.

For a given network configuration N, client region R, and a target time budget T (e.g., “within 30 seconds”), VerifyReach summarizes how reliably an honest client can reach at least one honest verifier within T seconds over multiple transport classes.

The VerifyReach KPI for network N in region R is the vector:

$\text{VerifyReach}(N, R) \equiv (p_{50,\text{conn}}(N,R), p_{95,\text{conn}}(N,R), \text{succ}_1(N,R), \text{succ}_2(N,R), \text{fail}_{\text{mixnet}}(N,R))$

Where:

$p_{50,\text{conn}}$ , $p_{95,\text{conn}}$ : median and 95th-percentile time-to-first-connection;
$\text{succ}_1$ : 1-path reachability rate;
$\text{succ}_2$ : multi-path reachability rate (resilience to single-path blocking);
$\text{fail}_{\text{mixnet}}$ : distribution over connection failure causes.

Example SLOs:

succ_1(N,R) ≥ 0.98 and succ_2(N,R) ≥ 0.90 for major regions;
p95_conn(N,R) under a few seconds or tens of seconds (depending on transport mix).

Definition 5 – VerifySettle(C)

Time, reliability, and privacy quality of non-custodial settlement on a corridor C.

For a given settlement corridor C (e.g., BTC↔XMR atomic swaps), VerifySettle(C) summarizes whether non-custodial settlement actually clears under its advertised SLOs.

The VerifySettle KPI is:

$\textit{VerifySettle}(C) \equiv (p_{50,t}(C), p_{95,t}(C), s(C), r_{\text{safe}}(C), f_{\text{mix}}(C), a(C))$

Where:

$s(C)$ (success): fraction of settlements that complete as intended within the SLA window;
$r_{\text{safe}}(C)$ (refund-safe): fraction of failed attempts where all funds return safely;
$f_{\text{mix}}(C)$ (failure mix): distribution of failure causes;
$a(C)$ (anonset): summary of anonymity-set size and churn.

A corridor satisfies its VerifySettle SLO if:

success(C) ≥ target (e.g., 0.95), and
refund_safe(C) = 1.0 over adversarial mixes, with no hidden custodian or discretionary freeze paths.

Definition 6 – Repression wedge (real return on rate-capped instruments)

The repression wedge is the realized real return on rate-capped instruments when nominal yields are held below inflation:

$r_{\text{real},t} \equiv \frac{1 + i_{\text{cap},t}}{1 + \pi_t} - 1 \approx i_{\text{cap},t} - \pi_t$

A negative $r_{\text{real},t}$ indicates that holders of capped instruments are being taxed in real terms via financial repression rather than explicit default.

Definition 7 – Liquidation effect (bondholder tax, after Reinhart–Sbrancia)

The liquidation effect measures the effective “tax” on bondholders from negative real rates:

$\text{Liquidation}_t \approx \max(0, -r_{\text{real},t}) \times \frac{\text{Domestic Gov't Debt}_t}{\text{GDP}_t}$

Advanced economies saw negative real rates ~½ the time, with average savings ~1–5% of GDP/yr during 1945–1980.

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