Benchmark pages are where a privacy-and-rights architecture can be damaged by careless wording fastest. The corpus already separates “what can be claimed today” from “what still needs benchmark evidence,” and this page keeps that separation visible. A number without its workload, proof system, batch shape, or state-transition context is not evidence. It is just an attractive fragment.
What Benchmark Evidence Is Good For
| Good use of benchmark evidence | Why it is legitimate |
|---|---|
| Comparing relative cost surfaces inside one bounded setup | It helps explain where the architecture spends time or proof budget |
| Showing that a design direction is plausible enough to keep researching | It supports roadmap discipline without pretending the work is done |
| Bounding claims about proof generation, verification, or settlement-path overhead | It stops “privacy” from becoming a synonym for “free” |
| Explaining what still needs operator-grade evidence | It keeps future performance work explicit instead of hidden |
Benchmarks are not there to prove universal scale, universal decentralization, or universal deployment readiness.
The Benchmark Questions That Matter
Most readers only need to separate four kinds of measurements.
| Measurement family | What it helps answer | What it does not answer alone |
|---|---|---|
| Proof generation cost | How expensive a private or checkpoint-bound operation is to construct | End-to-end network or operator throughput |
| Proof verification cost | What a verifier pays at settlement time | Whether the full publication path is production-ready |
| State transition and storage mutation cost | How inserts, deletes, or path updates scale inside one setup | Real-world behavior under heterogeneous operators and external services |
| Artifact size and batching shape | How publication cost might move with batch composition | Whether every topology or workload mixes equally well |
This distinction matters because Z00Z spans wallet preparation, checkpoint settlement, publication, and optional external custody or service edges. No single benchmark line speaks for all of them.
Safe Claim Language
The corpus already gives a good language posture for benchmark pages.
| Stronger but unsafe wording | Safer wording |
|---|---|
| “Z00Z already scales to X in production.” | “The current benchmark evidence suggests the cost surface may support X under bounded conditions, but wider operator evidence is still required.” |
| “Proof size is solved.” | “The measured proof size in this workload is compatible with the current design direction.” |
| “Storage benchmarks prove real-world finality speed.” | “Storage benchmarks illuminate one component of the settlement path, not the entire deployment surface.” |
| “Privacy is cheap.” | “Some privacy costs are manageable in the current measurements, while others still depend on batching, topology, and workload mix.” |
The point is not to sound timid. The point is to keep the numbers usable after scrutiny.
Why Z00Z Needs Benchmark Caveats
The main whitepaper is explicit that checkpoint settlement, proof verification, batching, and external publication are separate surfaces. The benchmark page therefore has to preserve at least three caveats.
First, measured internal cost is not the same as operator-grade end-to-end behavior. A strong verifier micro-benchmark does not prove a complete publishing topology.
Second, state-transition cost depends on workload shape. Rights-heavy workloads, voucher-like object flows, or claim-heavy reward systems may stress a different part of the architecture than simple asset movement.
Third, privacy is not one number. Entry and exit concentration, delayed publication, batch structure, and later audit or disclosure lanes can all affect the real privacy-performance tradeoff.
Recommended Reading Order For Performance Questions
| If you are trying to evaluate… | Read these sources together |
|---|---|
| Settlement cost and proof path | Main Whitepaper + this page |
| Storage and tree-shape implications | HJMT Research + this page |
| Whether a use case is operationally mature | the relevant use-case page + this page + Use Cases Whitepaper |
This prevents a common mistake: using one performance line to upgrade a whole scenario family from target architecture into shipped capability.
Benchmark Reading Checklist
Before you repeat a number, confirm that you can also answer:
- Which object family or proof path was being measured?
- Was the measurement about generation, verification, publication, or storage mutation?
- What surrounding service or operator layers were not included?
- Does the main corpus still classify the related feature as live, near-core, or future?
If you cannot answer those questions, keep the claim qualitative.
Benchmark Question Matrix
The matrix exists to enforce “no benchmark, no claim.” A page may describe a performance question before measurement exists, but it should not write the answer in production language. Commitments and proof checks need generation cost, verification cost, proof size, transcript context, and failure behavior. Publication claims need batch shape, checkpoint cadence, data-availability path, and retry semantics. Data-availability retrieval needs witness size, lookup cost, degraded-mode behavior, and evidence of what happens when a provider is slow or absent. OnionNet latency needs route length, carrier behavior, low-load privacy assumptions, and replay/backpressure discipline. Wallet UX needs scan time, backup overhead, quarantine behavior, and recovery tests. PoUW review needs evidence ingestion cost, challenge-window overhead, reviewer load, and authorization timing.
These categories should not be averaged into one universal “fast” or “slow” label. A proof path may be acceptable while network privacy remains unmeasured. A wallet flow may feel responsive in a simulator while operator-grade DA retrieval remains unproven. A PoUW review lane may have clear evidence objects while governance challenge latency remains target architecture. Benchmark pages should preserve those distinctions because they determine which claims survive review.
Measurement Language
Use measured language only when the artifact exists and the workload is stated. Use bounded language when the result supports only one setup. Use target language when the paper defines the desired evaluation but the measurement is absent. Use unsupported language when neither the paper nor the repo provides enough evidence. The main whitepaper appendix C explicitly separates what current benches can justify from what still needs operator-grade evaluation, while the privacy and PoUW papers add separate measurement obligations for leakage and useful-work evidence.
What Must Be Re-Measured
Re-measure whenever the object family, proof stack, batch shape, data-availability path, transport route, wallet scan mode, or review policy changes. A number from a simple asset transfer does not automatically cover a voucher transition. A local proof-generation number does not cover publication latency. A simulated network path does not cover low-load privacy or real carrier behavior. A small useful-work review example does not cover reviewer-market load, appeals, or challenge windows.
This rule should make docs wording more useful, not less useful. It lets a page say exactly what is promising: “this component has a measured local cost under this workload,” “this claim still needs operator-grade measurement,” or “this scenario is architecturally plausible but benchmark-incomplete.” Readers can trust that kind of claim because it does not hide the measurement surface.
Read Next
Read Verification Orchestrator for evidence layers, OnionNet for transport measurement boundaries, and Proof Of Useful Work before repeating reward-review performance claims.
Evidence and Further Reading
- Main Whitepaper appendix C is the main source for conservative performance wording, current benchmark interpretation, and evaluation work still required.
- Proof-of-Useful-Work Whitepaper sections 5 and 11 are the source for evidence-discipline workloads and useful-work rollout questions that still need measurement.
- Privacy Threat Model And Metrics section 10 is the place to check whether a benchmark claim is quietly ignoring privacy telemetry, timing, ingress, egress, or operator metadata pressure.
- Use Cases Whitepaper helps determine whether a measured path belongs to the core settlement wedge or to a later scenario family that still depends on more surrounding infrastructure.