Repository navigation
[0.32][ZK/P4] Measure application proving and on-chain costs before selecting new profiles #46
Description
Completion evidence — 2026-10-12
Implemented in signed commit 98375e0a, published on 0.32.
Controlled pilot/acceptance records cover ordinary/fixed-pair applications and complete 1/2/4-counter proof requests. Separate frozen limits bind raw timings/RSS, exact keys/artifacts, all-group/per-VM costs and unavailable metrics. Individual threading/key-reuse candidates and their selected combination were measured; slower thread defaults and gzip transport are rejected. Existing CLI and proof-system defaults remain, with concrete defer decisions for automatic caching, aggregation, recursion, cross-transaction batching and additional systems.
Acceptance record · exact evidence index.
The maintainer's explicit “不要跑CI和gates” instruction supersedes the original gate-execution acceptance item for this work. No CI/gates ran and no gate success is claimed. Setup is public deterministic test material; this is not production setup admission or public deployment.
Outcome and priority
Scoped follow-up for #42 P4, in the 0.32 workstream. Publish complete application-level ZK costs and use them to decide whether a particular transport/prover/verifier improvement or an additional proof profile is worth implementing. A finite measured reject/defer decision is a valid research outcome; a generic roadmap alone is not.
Priority: start the single-state baseline once #42 P1 is reproducible, then add P2's bounded multi-Cell cases when available. Multi-Cell work does not block measuring the existing application. Implementer: Codex, with maintainer ownership. Record a scope-specific review disposition before adopting any new cryptographic, runtime or ABI contract; no external collaborator is assigned work.
Duplicate check and boundaries
#36 establishes observed per-VM stack measurements; #35/#40 own the frozen general compiler cost corpus and optimization frontier. #22 and tests/zk_resources.rs provide the first profile's admission/resource evidence. Reuse those metric definitions, but do not present the general corpus or first-profile bounds as this broader host-prover/application comparison. This issue adds controlled host proving time/memory, full application accounting and explicit decisions about additional ZK profiles. #43 finance remains separate.
Measurement contract
- Record exact application/circuit/PK/VK/verifier/parent identities, setup trust, compiler/toolchain/VM/node versions, source state, host hardware, cache state, warmups, repetitions and measurement tools.
- Measure proving elapsed time and observed peak host memory, plus parent/child/total authoritative CKB execution costs. Keep each VM's observed stack distinct from static bounds; do not sum independent VM peaks into a fictional single stack.
- Account for canonical proof/public-input/VK bytes, witness and full transaction bytes, each deployed ELF, occupied capacity and actual setup/proving artifact sizes. Separate one-time setup/deployment costs from per-update work.
- Include valid, expensive late-invalid and maximum admitted cases, with realistic transaction construction and unchanged proof/transaction bindings. Define unavailable measurements explicitly; never encode missing data as zero.
- Run exploratory pilots to choose numeric ceilings, then freeze them before acceptance. Retain the existing [0.32][Research] Find remaining ELF/cycle costs and measure the optimization frontier #40 budgets and Rust references unchanged, and separately version the ZK measurement corpus.
Decisions and acceptance
- Publish a reproducible baseline with per-case raw observations, repetitions, environment and availability; explain actual bottlenecks rather than inferring them from code size alone.
- Compare selected bounded candidates individually, then measure any selected combination. Preserve valid/reject outcomes, binding mutations and frozen budgets.
- Record adopt/reject/defer decisions for transport improvements and any considered additional proof system, batching, aggregation or recursion, with measured results or concrete blockers.
- Conditional new-profile requirement: no additional proof-system profile is proposed/admitted by this study. Aggregation/recursion/additional systems are explicitly deferred with missing-contract reasons. [0.32][ZK/P2] Bind bounded multi-Cell transitions to complete protected state sets #44 separately owns its versioned application set envelope; no shared API erases those distinctions.
- Demonstrate application benefit for adopted work; publish regressions/tradeoffs and the retained default. Do not claim a global optimum from the finite corpus.
- Exact replay identities and focused validation are retained. The maintainer explicitly instructed no CI or gates on 2026-10-12; unified gates were not run or claimed. No new runtime/cryptographic default is adopted by this study; initial profile security/setup/privacy claims remain unchanged.
No new proof system, trusted setup, public deployment, new optimization CLI mode or circuit DSL is preselected by this issue.
Activity
feat(checker): bind source policies to direct dependency snapshots
feat(checker): bind complete direct Type-group transaction snapshots
a19q3 commentedon Oct 12, 2026
Completion evidence — 2026-10-12
Implemented in signed commit
98375e0a, published on0.32.Controlled pilot/acceptance records cover ordinary/fixed-pair applications and complete 1/2/4-counter proof requests. Separate frozen limits bind raw timings/RSS, exact keys/artifacts, all-group/per-VM costs and unavailable metrics. Individual threading/key-reuse candidates and their selected combination were measured; slower thread defaults and gzip transport are rejected. Existing CLI and proof-system defaults remain, with concrete defer decisions for automatic caching, aggregation, recursion, cross-transaction batching and additional systems.
Acceptance record · exact evidence index.
The maintainer's explicit “不要跑CI和gates” instruction supersedes the original gate-execution acceptance item for this work. No CI/gates ran and no gate success is claimed. Setup is public deterministic test material; this is not production setup admission or public deployment.
The acceptance checklist now records the evidence and the explicit no-gates validation disposition.