Skip to content

starknet_os: pin the fold circuit hashes to a vendored registry and pin fold costs - #15086

Open
einat-starkware wants to merge 1 commit into
claude/privacy-proof-os-verify-gsxf2h-3-os-outputfrom
claude/privacy-proof-os-verify-gsxf2h-4-registry-pin
Open

einat-starkware wants to merge 1 commit into
claude/privacy-proof-os-verify-gsxf2h-3-os-outputfrom
claude/privacy-proof-os-verify-gsxf2h-4-registry-pin

Conversation

@einat-starkware

@einat-starkware einat-starkware commented Sep 2, 2026

Copy link
Copy Markdown
Contributor

Part 6 of the privacy proof-fact fold stack, on top of #15064. Test-only: converts the "placeholder circuit hash constants" caveat into a CI-enforced pin, and answers the design's per-block cost question with measured numbers.

Registry drift test:

  • Vendors the canonical_small circuit registry verbatim (proving-dev commit b75d21f9, crates/stwo_run_and_prove_recursive_tree/test_data/circuit_registry.json) into crates/starknet_os/resources/.
  • test_circuit_hash_constants_match_vendored_registry pins LEAF_VERIFIER_CIRCUIT_HASH / MULTIVERIFIER_CIRCUIT_HASH to the registry's values; chained with the existing Cairo-vs-Rust hash tests, the Cairo values are now pinned to the registry end to end. Swapping in the production registry becomes a one-file change whose omissions or later drift fail CI.
  • The test asserts the registry lists exactly one leaf verifier. This is deliberate: the production registry lists one leaf verifier per trace size (25–29), each with its own circuit hash, while the fold hardcodes a single ch_leaf. The assertion failing on a production registry is the forcing function for the open contract question — are all production leaves (re-)proven at one canonical trace size, or must the OS accept a set of leaf circuit hashes? This needs settling with the proving side before the production swap (it would change the fold's leaf-entry construction if the answer is a set).

Fold cost pins (design open question 4):

  • test_fold_block_proof_facts_execution_resources pins the Cairo fold's measured resources over realistic 9-felt proof facts: 943 steps (1 tx), 1281 (2 txs), 5763 (8 txs) — ~747 steps and ~13 range checks marginal per transaction, plus the +14 steps/invoke recording cost already measured in apollo_starknet_os_program,starknet_os,blockifier: emit the proof-fact fold in the OS output #15064. A 100-tx privacy block folds for under ~75K steps: comfortably within the OS budget, so the design's Cairo0-cost concern is closed.

Verified: 23/23 fold tests pass clean; rustfmt and clippy clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01XmPJM3Wph4QLmFmhcxVsh4

@cursor

cursor Bot commented Sep 2, 2026

Copy link
Copy Markdown

PR Summary

Low Risk
Test-only and documentation changes around proof-fact fold; no production fold or OS execution path behavior changes.

Overview
Vendors the canonical_small circuit registry as resources/circuit_registry_canonical_small.json and documents that LEAF_VERIFIER_CIRCUIT_HASH / MULTIVERIFIER_CIRCUIT_HASH are pinned to that file (still test-only until production registry swap).

Adds CI enforcement so Rust hash constants must match the vendored registry (test_circuit_hash_constants_match_vendored_registry), chaining with existing Cairo-vs-Rust hash tests for an end-to-end pin. The registry test requires exactly one leaf verifier entry, deliberately surfacing the open production question about multiple trace-size leaf hashes.

Adds snapshot tests for Cairo fold_block_proof_facts execution resources at 1, 2, and 8 transactions (steps and range checks), locking the per-block fold cost profile for the privacy design.

Reviewed by Cursor Bugbot for commit 4a1bd94. Bugbot is set up for automated code reviews on this repo. Configure here.

@reviewable-StarkWare

Copy link
Copy Markdown

This change is Reviewable

@einat-starkware
einat-starkware force-pushed the claude/privacy-proof-os-verify-gsxf2h-4-registry-pin branch from 3dec722 to 984111c Compare September 2, 2026 11:43
@einat-starkware
einat-starkware force-pushed the claude/privacy-proof-os-verify-gsxf2h-4-registry-pin branch from 984111c to 05ae64e Compare September 2, 2026 11:47
@einat-starkware
einat-starkware force-pushed the claude/privacy-proof-os-verify-gsxf2h-4-registry-pin branch from 05ae64e to 2f011f1 Compare September 2, 2026 12:13
@einat-starkware
einat-starkware force-pushed the claude/privacy-proof-os-verify-gsxf2h-4-registry-pin branch from 2f011f1 to c5a699f Compare September 2, 2026 12:29
@einat-starkware
einat-starkware force-pushed the claude/privacy-proof-os-verify-gsxf2h-4-registry-pin branch from c5a699f to 207de5d Compare September 2, 2026 12:45
@einat-starkware
einat-starkware force-pushed the claude/privacy-proof-os-verify-gsxf2h-4-registry-pin branch 2 times, most recently from 028fc14 to 9898ff6 Compare September 2, 2026 13:41
@einat-starkware
einat-starkware force-pushed the claude/privacy-proof-os-verify-gsxf2h-4-registry-pin branch from 9898ff6 to 800f216 Compare September 17, 2026 13:36
…in fold costs

Vendors the canonical_small circuit registry (proving-dev commit b75d21f9,
crates/stwo_run_and_prove_recursive_tree/test_data/circuit_registry.json) and
pins LEAF_VERIFIER_CIRCUIT_HASH / MULTIVERIFIER_CIRCUIT_HASH against it;
together with the existing Cairo-vs-Rust constant tests, this chains the Cairo
constants to the registry, making the production-registry swap a one-file
change whose omissions or drift are caught in CI. The test also asserts the
registry lists a single leaf verifier: the production registry lists one per
trace size, and that assertion failing is the forcing function for deciding
whether production leaves are proven at one canonical trace size or the OS
must allow several leaf circuit hashes.

Also pins the Cairo fold's execution resources (970 steps for one transaction,
1321 for two, 5965 for eight; ~774 steps and ~13 range checks marginal per
transaction), answering the design's per-block cost-budget question.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XmPJM3Wph4QLmFmhcxVsh4
@einat-starkware
einat-starkware force-pushed the claude/privacy-proof-os-verify-gsxf2h-4-registry-pin branch from 800f216 to 4a1bd94 Compare September 22, 2026 09:22

This branch has not been deployed

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants