Defs. Key Definitions

Jason St George. "Defs. Key Definitions" in Next‑Gen Store of Value: Privacy, Proofs, Compute. Version v1.0. /v/1.0/read/front-matter/key-definitions/

Key Definitions

Before proceeding, we establish precise definitions for the core constructs that recur throughout this thesis. These are not metaphors; they are operationally specified primitives.

Definition: VerifyPrice(W) — Specification Stub

For a canonical workload $W$, VerifyPrice is the public KPI vector:

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

Where:

• $p_{50,t}(W)$, $p_{95,t}(W)$: median and 95th-percentile verification time (seconds)
• $p_{50,c}(W)$, $p_{95,c}(W)$: median and 95th-percentile verification cost (see cost vector below)
• $\text{fail}(W)$: verification failure rate (fraction of attempts that fail or timeout)

---

Verifier Hardware Class (Reference Machine)

Tier	CPU	RAM	Storage	Network	Use Case
Laptop (baseline)	4-core x86-64, 2.5GHz	16 GB	SSD	100 Mbps	Default reference; any user should be able to verify
Mobile	ARM, 2GHz	4 GB	Flash	20 Mbps	Lightweight verification for wallets
Datacenter	16-core, 3GHz	64 GB	NVMe	1 Gbps	High-throughput verification nodes

All published VerifyPrice metrics specify which tier they target. The baseline is Laptop; mobile and datacenter metrics are supplementary.

---

Cost Vector

Verification cost is expressed as a vector, not a scalar:

$c(W) = (t_{\text{cpu}}, m_{\text{peak}}, b_{\text{net}}, e_{\text{joules}}, c_{\text{est}})$

Component	Unit	Description
$t_{\text{cpu}}$	CPU-seconds	Total CPU time consumed
$m_{\text{peak}}$	MB	Peak memory usage
$b_{\text{net}}$	KB	Bytes transferred (witness, proof, state)
$e_{\text{joules}}$	J	Energy consumed (estimated from CPU/GPU utilization)
$c_{\text{est}}$	USD	Estimated fiat cost at current cloud/energy rates

The scalar $p_{50,c}$ and $p_{95,c}$ typically report $c_{\text{est}}$, but full vectors are available in telemetry for detailed analysis.

---

Adversarial Conditions

VerifyPrice assumes realistic, mildly adversarial network conditions:

• Network RTT: 200ms (global average)
• Packet loss: 10% (degraded conditions)
• Witness size: Worst-case for the workload class (prevents gaming via cherry-picked inputs)
• DoS hardening: Verifier must handle malformed proofs gracefully (no crash, bounded resource use)

---

Measurement Harness

• Reproducible benchmark suite: Open-source, deterministic test vectors for each canonical workload.
• Signed results: Verifiers publish measurements signed by their attestation key.
• Aggregation: Observatory collects results from diverse verifiers (geo, ASN, hardware) and publishes p50/p95 with confidence intervals.
• Auditable: Raw measurements are archived; anyone can reproduce and challenge published metrics.

---

Target SLOs (Reference Design)

Workload Class	$p_{95,t}$	$p_{95,c}$	fail	Notes
ZK proof (SNARK)	≤ 5s	≤ $0.01	≤ 0.1%	Standard recursive/aggregated proofs
MatMul-PoUW	≤ 10s	≤ $0.05	≤ 0.1%	Large matrix verification
Provenance proof	≤ 2s	≤ $0.005	≤ 0.1%	Media/document attestation
Corridor settlement	≤ 30s	≤ $0.10	≤ 0.5%	Includes finality confirmation

These are targets, not guarantees. Actual SLOs are published per workload and adjusted as technology improves.

---

Why this matters: VerifyPrice is the hinge that determines whether proofs and verified compute behave as commodities (publicly checkable) or as platform IOUs (trust someone’s claim). If $r(W) = v(W)/p(W) \ll 1$, verification is cheap relative to production and markets can form; if $r(W) \to 1$, we’re back to “trust the prover.”

Definition: Work Credits

A Work Credit is an energy-anchored claim on a standardized unit of triad work (privacy settlement, proof generation, or verified compute) that has been produced and attested under public SLOs.

Issuance: Credits are minted only when:

1. A valid proof of workload $W$ at tier $T$ is accepted by the network.
2. Telemetry confirms VerifyPrice(W,T) and other SLOs (latency, failure rate, decentralization) are within bounds.

Redemption semantics: Implementation-dependent. Work Credits can be designed across a spectrum:

• Non-redeemable but scarce: pure SoV instruments where credits represent historical work (like BTC tied to historical hashes). Value derives from scarcity and demand, not redemption rights.

• Redeemable vouchers: credits burnable for future proofs, compute, or settlement capacity. Provides direct utility claim.

• Fee/collateral/governance medium: credits required for network operations:

  • Fee prepayment: credit burns in lieu of per-call fees.
  • Collateral: credit staked as skin-in-the-game for provers, routers, and LPs.
  • Governance weight: credit-weighted voting in telemetry disputes and parameter changes.

These options are not mutually exclusive; a single network may support multiple redemption paths for different use cases.

Energy anchoring: Marginal cost of minting one credit is bounded below by energy and hardware required to pass verification. Unlike SHA-256 PoW, the work is useful. Each credit references a Facility Energy Receipt (FER) chain; if the referenced plant drifts out of profile (PUE > 1.5, carbon intensity > threshold, etc.), downstream credits are flagged.

Non-debt property: Work Credits do not promise fixed coupons or redemption in fiat terms. Value floats with demand for triad capacity.

Failure mode: If VerifyPrice regresses materially, new issuance halts until SLOs recover. Existing credits remain valid but may trade at a discount, reflecting the network’s degraded utility.

Definition: Lawful Privacy

Lawful privacy is the design principle: default privacy with optional, user-controlled disclosure.

Concretely:

• Default state: Transactions, identities, and flows are encrypted and unlinkable without explicit consent.
• Disclosure mechanisms: Viewing keys, auditable receipts, and selective-disclosure proofs allow holders to prove specific facts (e.g., “I paid X to Y for purpose Z”) without exposing the full transaction graph.
• No backdoors: The protocol has no master keys, regulatory escrow, or “lawful intercept” APIs. Disclosure is always at the holder’s discretion.

Why “lawful”: The term signals that privacy is compatible with compliance when the holder chooses to disclose, without requiring surveillance infrastructure. Regulated entities can satisfy audits via viewing keys; the protocol itself remains neutral.

Coercion boundary: Lawful privacy is a technical guarantee. It cannot prevent social or legal coercion to disclose viewing keys. What it guarantees is that (1) non-custodial routes exist, (2) disclosure cannot be forced at the protocol level, and (3) coercion surface is minimized by keeping data encrypted by default.

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