Skip to content

[0.32][ZK/P4] Measure application proving and on-chain costs before selecting new profiles #46

Closed

Description

@a19q3

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

  1. added this to the 0.32 milestone on Oct 4, 2026
  2. a19q3 commented on Oct 12, 2026

    @a19q3
    CollaboratorAuthor

    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.

    The acceptance checklist now records the evidence and the explicit no-gates validation disposition.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions