Appendix E. Hardware Profiles

Jason St George. "Appendix E. Hardware Profiles" in Next Generation Stores of Value: Privacy, Proofs, Compute. Version v3.2. /v/3.2/read/appendix/e-hardware-profiles/

Hardware Profiles

Throughout this thesis we treat “hardware profiles” as first-class objects. They are the way we talk about machines in the same language we use for proofs and receipts.

Concept

A hardware profile is a public description of a class of devices that are interchangeable for security and performance purposes. It is not a single physical unit; it is the specification for what counts as a valid unit of that type.

Informally: a profile says, “devices that meet this description behave like this, within these error bars, under this sampling regime.”

We use hardware profiles to:

• express trust and threat-model assumptions at the protocol and application layer;

• bind proofs and receipts to the types of machines that produced them; and

• make the honesty (and failure rates) of machines measurable over time.

Naming

Profiles are identified by short, stable strings. Three broad kinds:

1. Open-hardware profiles — devices whose RTL/microarchitecture and sampling regime are publicly documented.

   • open_tee_v1 — first open TEE design with published RTL, side-channel budget, and lot-sampling plan. No such device yet exists; the profile string names the specification a lab would build to (below).

   • open_signer_v1 — simple key-storage/signing chip with open RTL and sampling.

   • open_camera_v1 — camera/capture pipeline with documented sensor path, secure element, and sampling method.

2. Logical or pure-cryptography profiles — paths that do not rely on special hardware.

   • pure_zk_only — verification/proving path relying only on general-purpose CPUs/GPUs and cryptographic assumptions.

   • software_only_v1 — profile used for testing or where hardware attestations are unavailable.

3. Vendor or mixed profiles — existing devices not fully open but characterized and sampled.

   • vendor_tee_X_v1 — proprietary TEE profile with documented side-channel and attestation scheme.

   • gpu_cluster_Y_v1 — particular GPU farm configuration with known performance and sampling behavior.

Hardware Profile Specification

Each profile has a specification that is part of the public “bill of materials” for the stack. At a minimum:

• profile_id: string (e.g., “open_tee_v1”)

• device_class: what the device is used for (e.g., “TEE”, “signer”, “accelerator”, “camera”)

• trust_mode: “open”, “mixed”, “opaque”, or “logical”

• design_commit: identifiers for design artifacts (hashes of RTL, GDS, firmware images)

• side_channel_budget: qualitative/quantitative bounds

• sampling_plan: how lots and devices are checked

• attestation_scheme: how devices prove identity and state

• security_target: high-level security goal

Hardware Profiles in Receipts and Policies

Profiles appear in three main places:

1. Policies — Developers express requirements using profiles:

   allowed_hardware_profiles = ["open_tee_v1", "pure_zk_only"]

2. Receipts (PIDL) — Every PIDL receipt includes a hardware_profile field.

3. Telemetry — The observability layer aggregates metrics by profile.

Example Profiles

open_tee_v1:

• device_class: “TEE”

• trust_mode: “open”

• design_commit: hashes of RTL, layout, firmware

• sampling_plan: random lot sampling, SEM/optical inspection

• intended use: high-value proving, key storage, secure computation

open_camera_v1:

• device_class: “camera”

• trust_mode: “open”

• sampling_plan: device sampling and destructive testing per lot

• intended use: origin-anchored capture for media provenance

pure_zk_only:

• device_class: “logical”

• trust_mode: “logical” (no hardware assumptions)

• intended use: contexts where hardware trust is unacceptable

What a Lab Would Need to Specify

The profiles above are specifications for describing machines. They are not machines, and this appendix attaches no prices to any of them; a bill of materials with costs belongs to a procurement study against the ladder of §14: Layer 0: Verifiable Machines & Energy, not to a thesis. What can be stated here is the shape of what a lab would have to specify before the first receipt could carry an open profile string honestly.

L0-A reference prover and verifier: component list, no prices.

The reference verifier is the machine every VerifyPrice figure is measured on (Laptop tier, §19: Layer 4: Truth & Work), so its bill of materials is a public artifact even though every part in it is commodity. The reference prover is the machine the production denominator of $r(W)$ is priced against (Appendix A: Formal Model of Verification Asymmetry & VerifyPrice).

• Reference verifier: commodity x86-64 or ARM host meeting the Laptop-tier specification (4 cores, 16 GB, SSD, 100 Mbps); a pinned operating-system image and kernel version; the reference verifier software build, reproducible from source (§16: Layer 2: Distribution & Execution); an external power meter at the wall for the energy field; a hardware RNG source for the adversarial-mix sampler; and a signing key on a commodity secure element for result attestation. Nothing in it is open silicon: L0-A is the characterized commodity rung, and the profile says so.

• Reference prover: commodity GPU or CPU cluster node with the pinned kernel and driver stack that sets the FP32 acceptance bound (§19: Layer 4: Truth & Work); metered rack power distribution for the per-run energy figure; a pinned firmware inventory (hashes published); and the same reproducible software build.

• For both: the design_commit is the set of hashes of every image the machine runs; the sampling_plan is electrical test and firmware-hash comparison on a random sample of units per lot, since counterfeit dies, binned-down parts, and firmware substitution are the high-sensitivity defect classes (§14: Layer 0: Verifiable Machines & Energy).

Proving-cost roadmap: the metric, today’s reading, and the bet.

The lab’s headline cost series is stated in a unit a buyer can price: US dollars per $10^{9}$ zkVM cycles for general programs, and per $10^{9}$ constraints for circuit-native workloads, measured on the reference prover above as cost—hardware amortization plus metered energy, in the per-run price model of §19: Layer 4: Truth & Work—and published beside the market price on open proving markets, which is a different number and must not be substituted for it. The distinction is load-bearing at the outset because the market reading today sits below any plausible cost floor. The open proof markets that launched in 2025 (Boundless [Boundless 2025]; the Succinct Prover Network [Succinct 2025]) clear reverse auctions in which posted prover supply exceeds order flow: Boundless reported [Shankar 2026] roughly USD 0.02 per $10^{9}$ cycles in February 2026 against some 400 trillion cycles per day of posted capacity, with auction clears near zero at times, and Succinct [Succinct 2026] prices in prover gas units at an auction-set rate plus a dynamic base fee. A price set by oversupplied provers competing for subsidised order flow is evidence about the auction, not about the cost of proving, and the lab’s series is the cost. This paragraph deliberately fixes no figure for that cost; the first quarterly reading does. The author’s prior, stated so it can be wrong, is that all-in cost on commodity GPUs sits one to two orders of magnitude above the February 2026 auction clear, which is what oversupply predicts.

Two series ride beside the headline. The first is the proving overhead $p(W)/p_{0}(W)$: the production cost of a result with its proof over the cost $p_{0}(W)$ of executing the same workload natively with no proof, per registered SKU. It is the number the buyer actually pays for verifiability and the one the capturable wedge (§19: Layer 4: Truth & Work) is measured against; a workload’s M1 SKU becomes economic when that overhead falls inside the buyer’s differential $\Delta$ for it, and not before. The second is the same overhead for the M3 alternative—a committee of $k$ re-executing the work, whose overhead is roughly $k$ and falls only as hardware does.

The modality bet is then a statement about slopes. The monetary mechanism rides on M1 and M2 (§19: Layer 4: Truth & Work); the bet is that M1 proving overhead per unit of useful work falls faster than the M3 committee’s, so that the set of workloads for which succinct verification is economic widens over time rather than staying fixed at the small-circuit end. Its checkpoints are dated to the lab’s deliverables (§32: Kardashev Labs: Build and Measure): first published reading at $T_{0}+6$; first annual slope at $T_{0}+12$; and a pre-registered kill condition at eight quarters—if the measured decline in M1 overhead over that window is no steeper than the decline in the M3 committee’s, the bet is lost for that workload class, the class stays M3 in the registry (§19: Layer 4: Truth & Work), and the affected _ZKML-style destination SKUs remain targets rather than becoming constitutional. A projection with no such condition would be a forecast, and this appendix publishes instruments.

The first L0-C open components.

Open PDKs exist today only at mature nodes, so the first open components are the ones whose job is trust rather than throughput (§14: Layer 0: Verifiable Machines & Energy). A lab would specify, in this order:

• Root of trust (RoT): an open RISC-V measured-boot and key-storage core, with published RTL, a documented attestation scheme, and a side-channel budget; this is what open_signer_v1 names.

• Random number generator (RNG): an open entropy source and conditioner with a published health-test specification [Turan et al. 2018], since every sampling plan and every adversarial mix in the thesis draws on it.

• Metering: an open power and capacity meter whose firmware signs the FER fields (Appendix A: Formal Model of Verification Asymmetry & VerifyPrice), so that “energy_it_kwh” is attested by a component the operator does not control alone.

Side-channel budget metric.

A profile’s side_channel_budget is stated in a form an independent lab can reproduce: Test Vector Leakage Assessment (TVLA), as the pass/fail leakage test at a stated trace count and statistical threshold, with the ISO/IEC 17825 test procedure as the reference method. The published budget names the trace count at which the device is claimed to pass, and a device is re-tested at that count on every sampled lot.

Sampling plan reference.

Lot acceptance follows a published acceptance-sampling standard — ANSI/ASQ Z1.4 [DoD 1989] (the successor to MIL-STD-105) — with the acceptable quality level, inspection level, and switching rules stated in the profile; the rule-of-three converse and the sensitivity term of §14: Layer 0: Verifiable Machines & Energy then convert the plan into a published upper bound on undetected compromise for the high-sensitivity defect classes, and into a deterrent statement, not a bound, for dopant-level trojans [Becker et al. 2013].

New here? Start with the one-minute version.

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