refactor(mithril-stm): refactor and stabilize the SNARK setups by hjeljeli32 · Pull Request #3349 · input-output-hk/mithril

hjeljeli32 · 2026-06-22T07:14:46Z

Content

This PR refactors and stabilizes both SNARK setups (the non-recursive certificate circuit and the recursive IVC circuit). It replaces the test-only "unsafe" setup plumbing and the duplicated key-computation paths with a single compute-on-miss key provider backed by a typed on-disk cache, introduces per-circuit key newtypes with their own (de)serialization, aligns the prover/verifier setup types and names across both circuits, and makes the test setup deterministic, race-free, and key-reusing.

Changes

Key provider + cache: CircuitVerificationKeyProvider<C> owns the on-disk key cache and computes the key pair on a miss through the circuit's CircuitKeyGenerator; the standalone key cache was folded into the provider. The cached verifying key is checked for staleness against the embedded production verifying-key bytes.
Per-circuit key newtypes: NonRecursiveCircuit{Verifying,Proving}Key and RecursiveCircuit{Verifying,Proving}Key wrap the Midnight and raw PLONK key types, each with its own key (de)serialization. The raw PlonkVerifyingKey/PlonkProvingKey aliases remain only at the Halo2/verifier boundary.
Non-recursive setup: the certificate verifying key is computed through the verification key provider; renamed SnarkSetup → SnarkProverSetup.
Recursive setup: renamed IvcProverSetup → IvcSnarkProverSetup; it loads a single SRS, derives the certificate verifying key through the provider, downsizes the SRS to the recursive circuit degree, builds the recursive provider from that certificate key, and derives the IVC key pair — aligning the setup types and names across both circuits.
IVC setup memo: renamed the process-wide IVC prover-setup memo temp_ivc_prover_cache → ivc_prover_setup_cache (it memoizes the assembled setup on the clerk path, not key computation).
Naming: renamed the IVC circuit degree constant to RECURSIVE_CIRCUIT_DEGREE.

Tests

The slow SNARK tests share a single content-keyed key cache under the Cargo target directory (keyed by the protocol parameters, Merkle-tree depth, unsafe-SRS identity, and the embedded production verifying keys), so the first test to need a configuration pays key generation and the rest — and later runs — reuse it. An exclusive lock serializes cold-start key generation across parallel test processes.
The certificate key is shared across the non-recursive setup builders for a given configuration; SnarkProof::try_new_with_unsafe_srs is documented as being only for the deterministic unsafe SRS.

Pre-submit checklist

Branch
- Tests are provided (if possible)
- Crates versions are updated (if relevant)
- CHANGELOG file is updated (if relevant)
- Commit sequence broadly makes sense
- Key commits have useful messages
PR
- All check jobs of the CI have succeeded
- Self-reviewed the diff
- Useful pull request description
- Reviewer requested
Documentation
- No new TODOs introduced

Issue(s)

Closes #3300

Copilot

Pull request overview

This PR refactors and stabilizes the STM SNARK setup code paths (non-recursive certificate circuit + recursive IVC circuit) by removing test-only unsafe setup plumbing, adding typed on-disk key caching with unified key (de)serialization, and aligning setup/type naming between circuits.

Changes:

Introduces a CircuitKeySerialization trait and circuit-specific implementations to uniformly serialize/deserialize proving/verifying keys.
Refactors the on-disk CircuitKeyCache into a typed cache with staleness detection and typed VK/PK accessors.
Reworks recursive/non-recursive setup plumbing: removes temporary unsafe providers, adds cache-backed key providers, aligns naming (SnarkSetup → SnarkProverSetup), and standardizes the recursive circuit degree constant (RECURSIVE_CIRCUIT_DEGREE).

Reviewed changes

Copilot reviewed 33 out of 33 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
mithril-stm/src/protocol/aggregate_signature/signature.rs	Updates tests to use `SnarkProverSetup` naming.
mithril-stm/src/proof_system/mod.rs	Updates re-exports to align with the new SNARK setup types.
mithril-stm/src/proof_system/ivc_halo2_snark/verifier_setup.rs	Renames/aligns recursive verifier key types (`PlonkVerifyingKey`).
mithril-stm/src/proof_system/ivc_halo2_snark/unsafe_setup_helpers.rs	Removes temporary unsafe setup helper module.
mithril-stm/src/proof_system/ivc_halo2_snark/prover_setup.rs	Refactors `IvcProverSetup::load` to orchestrate key providers around a single downsized SRS; updates tests to use caches.
mithril-stm/src/proof_system/ivc_halo2_snark/prover_input.rs	Updates slow tests to use cache-backed key providers and `RECURSIVE_CIRCUIT_DEGREE`.
mithril-stm/src/proof_system/ivc_halo2_snark/proof.rs	Updates IVC proving/verification code and tests to use new key/provider types.
mithril-stm/src/proof_system/ivc_halo2_snark/mod.rs	Removes unsafe helpers module and re-exports recursive PLONK key aliases from circuit layer.
mithril-stm/src/proof_system/ivc_halo2_snark/key_providers.rs	Adds cache-backed key providers for certificate and recursive circuits.
mithril-stm/src/proof_system/halo2_snark/unsafe_helpers.rs	Removes old SNARK setup implementation file.
mithril-stm/src/proof_system/halo2_snark/setup.rs	Adds the new `SnarkProverSetup` / `SnarkVerifierSetup` implementation using the typed key cache.
mithril-stm/src/proof_system/halo2_snark/proof.rs	Updates proof/prover code to use `SnarkProverSetup` and isolates test caches.
mithril-stm/src/proof_system/halo2_snark/mod.rs	Wires in the new `setup` module and updates exports.
mithril-stm/src/proof_system/halo2_snark/circuit_verification_key.rs	Switches VK byte conversion to the shared `CircuitKeySerialization` trait.
mithril-stm/src/circuits/mod.rs	Adds the new `key_serialization` module.
mithril-stm/src/circuits/key_serialization.rs	Introduces the `CircuitKeySerialization` trait.
mithril-stm/src/circuits/key_cache.rs	Refactors cache state, adds typed VK/PK accessors, and adds `store_key_pair`.
mithril-stm/src/circuits/halo2/mod.rs	Adds the certificate-circuit key serialization module.
mithril-stm/src/circuits/halo2/key_serialization.rs	Implements key (de)serialization for `MidnightVK` / `MidnightPK`.
mithril-stm/src/circuits/halo2_ivc/tests/verification_key_computation.rs	Updates to `RECURSIVE_CIRCUIT_DEGREE`.
mithril-stm/src/circuits/halo2_ivc/tests/off_circuit/mod.rs	Updates documentation references to `RECURSIVE_CIRCUIT_DEGREE`.
mithril-stm/src/circuits/halo2_ivc/tests/off_circuit/circuit_validation.rs	Updates to `RECURSIVE_CIRCUIT_DEGREE` in assertions/errors.
mithril-stm/src/circuits/halo2_ivc/tests/golden/mod.rs	Removes redundant local `RECURSIVE_CIRCUIT_DEGREE` constant.
mithril-stm/src/circuits/halo2_ivc/tests/common/mod.rs	Removes redundant local `RECURSIVE_CIRCUIT_DEGREE` constant.
mithril-stm/src/circuits/halo2_ivc/tests/common/helpers.rs	Updates `MockProver` invocations to use `RECURSIVE_CIRCUIT_DEGREE`.
mithril-stm/src/circuits/halo2_ivc/tests/common/generators/verification_key.rs	Updates imports to use `RECURSIVE_CIRCUIT_DEGREE` from module root.
mithril-stm/src/circuits/halo2_ivc/tests/common/generators/setup.rs	Updates to use module-level `RECURSIVE_CIRCUIT_DEGREE`.
mithril-stm/src/circuits/halo2_ivc/mod.rs	Introduces shared raw PLONK key aliases and renames `K` to `RECURSIVE_CIRCUIT_DEGREE`.
mithril-stm/src/circuits/halo2_ivc/key_serialization.rs	Implements key (de)serialization for raw PLONK verifying/proving keys.
mithril-stm/src/circuits/halo2_ivc/gadget.rs	Updates gadget configuration to use `RECURSIVE_CIRCUIT_DEGREE`.
mithril-stm/src/circuits/halo2_ivc/errors.rs	Updates docs to refer to `RECURSIVE_CIRCUIT_DEGREE`.
mithril-stm/src/circuits/halo2_ivc/circuit.rs	Updates validation and domain sizing to use `RECURSIVE_CIRCUIT_DEGREE`.
mithril-stm/src/circuits/halo2_ivc/certificate_proof.rs	Switches verifier key type to `PlonkVerifyingKey` for accumulator preparation.

github-actions · 2026-06-22T08:25:09Z

Test Results

5 files ±0 206 suites ±0 3h 10m 54s ⏱️ + 2m 43s
3 316 tests +6 3 316 ✅ +6 0 💤 ±0 0 ❌ ±0
10 979 runs +3 10 979 ✅ +3 0 💤 ±0 0 ❌ ±0

Results for commit d5e79b1. ± Comparison against base commit 5d25797.

This pull request removes 19 and adds 25 tests. Note that renamed tests count towards both.

mithril-stm ‑ circuits::key_cache::tests::for_non_recursive_circuit_has_correct_path_and_uses_production_vk
mithril-stm ‑ circuits::key_cache::tests::for_recursive_circuit_has_correct_path_and_uses_production_vk
mithril-stm ‑ circuits::key_cache::tests::validate_handles_absent_pk_during_stale_cleanup
mithril-stm ‑ circuits::key_cache::tests::validate_removes_stale_files_and_returns_empty
mithril-stm ‑ circuits::key_cache::tests::validate_returns_empty_when_vk_absent
mithril-stm ‑ circuits::key_cache::tests::validate_returns_empty_when_vk_matches_but_pk_absent
mithril-stm ‑ circuits::key_cache::tests::validate_returns_valid_when_vk_matches
mithril-stm ‑ membership_commitment::merkle_tree::tree::tests::snark::slow::test_create_invalid_proof
mithril-stm ‑ proof_system::halo2_snark::unsafe_helpers::test::disk_cache_empty_writes_keys_to_disk
mithril-stm ‑ proof_system::halo2_snark::unsafe_helpers::test::disk_cache_valid_returns_expected_vk_bytes
…

mithril-stm ‑ circuits::circuit_verification_key_provider::tests::cold_miss_generates_stores_and_returns_the_pair
mithril-stm ‑ circuits::circuit_verification_key_provider::tests::empty_golden_trusts_the_cached_key
mithril-stm ‑ circuits::circuit_verification_key_provider::tests::get_proving_key_returns_none_when_proving_key_absent
mithril-stm ‑ circuits::circuit_verification_key_provider::tests::get_proving_key_surfaces_deserialization_error
mithril-stm ‑ circuits::circuit_verification_key_provider::tests::get_verification_key_clears_stale_files_and_returns_none
mithril-stm ‑ circuits::circuit_verification_key_provider::tests::get_verification_key_deserializes_present_production_vk
mithril-stm ‑ circuits::circuit_verification_key_provider::tests::get_verification_key_surfaces_deserialization_error
mithril-stm ‑ circuits::circuit_verification_key_provider::tests::missing_verifying_key_recomputes_the_pair
mithril-stm ‑ circuits::circuit_verification_key_provider::tests::new_roots_cache_paths_under_the_circuit_cache_folder
mithril-stm ‑ circuits::circuit_verification_key_provider::tests::store_key_pair_leaves_no_verification_key_when_proving_key_store_fails
…

♻️ This comment has been updated with latest results.

damrobi

LGTM overall 👍
I think @jpraynaud comments on the PR #3348 about downsizing the srs will apply to the key provider of the IVC
A more general remark, are we planning to store/download the srs of degree 19 for the IVC circuit instead of downsizing? The downsizing operation appears to be pretty slow sometimes.

curiecrypt

Thanks @hjeljeli32, this PR will resolve a lot of issues we have been struggling.
I have a suggestion that would also avoid some ambiguotions we might have and @jpraynaud 's comment about using MidnightVK.

The certificate and recursive circuits share the same raw key type (VerifyingKey<F, KZGCommitmentScheme<E>>), and MidnightVK::vk() hands back that same type. Since PlonkVerifyingKey is only an alias for it, the CircuitKeySerialization impl is effectively defined on the shared raw type, and deserialize_key always rebuilds with IvcCircuitData. It works today because only recursive keys are ever deserialized raw, but nothing stops a certificate key (same type) from being decoded as the IVC circuit, and that would only surface at proving or verification time.

Proposal: give each circuit its own clearly named key types, so the names answer the "why not MidnightVK" question and the serialization impls become unambiguous.

// circuits/halo2 (non-recursive)
pub struct NonRecursiveCircuitVerifyingKey(MidnightVK);
pub struct NonRecursiveCircuitProvingKey(MidnightPK<StmCertificateCircuit>);

// circuits/halo2_ivc (recursive)
pub struct RecursiveCircuitVerifyingKey(VerifyingKey<F, KZGCommitmentScheme<E>>);
pub struct RecursiveCircuitProvingKey(ProvingKey<F, KZGCommitmentScheme<E>>);

A few notes so this lands cleanly:

Make the recursive pair real newtypes, not type aliases. A renamed alias is still the shared raw type, so it reads better but does not stop a certificate key from matching the recursive impl. If you want to keep them as aliases, add a degree check (== RECURSIVE_CIRCUIT_DEGREE) inside the recursive deserialize_key so a wrong-circuit decode fails loudly instead of silently.
circuit_verification_key.rs is not dead code. CircuitVerificationKey is the serde-embedded VK field in SnarkProof and exposes get_midnight_vk() and from_bytes(), both of which are used. So this is a relocate and rename into the non-recursive keys file, carrying new, from_bytes, get_midnight_vk, the serde derive, and the midnight_vk_serde module. It is not a delete.
Once the impl lives on NonRecursiveCircuitVerifyingKey, midnight_vk_serde and CircuitKeySerialization for MidnightVK encode the same "MidnightVK to RawBytes" logic. Point the #[serde(with = ...)] at serialize_key and deserialize_key so there is a single source of truth.
CircuitVerificationKey::to_bytes is only used by a #[cfg(test)] golden test, so gate it with #[cfg(test)] rather than #[allow(dead_code)].
MidnightPK is generic, so the non-recursive proving key wraps MidnightPK<StmCertificateCircuit>.

This also sets up the later move to generic TryToBytes / TryFromBytes traits in codec.rs: distinct newtypes avoid conflicting impls on the shared foreign key type.

We can have a discussion about my proposal and decide on the best choice.

hjeljeli32 · 2026-06-23T06:57:54Z

Thanks @hjeljeli32, this PR will resolve a lot of issues we have been struggling. I have a suggestion that would also avoid some ambiguotions we might have and @jpraynaud 's comment about using MidnightVK.

The certificate and recursive circuits share the same raw key type (VerifyingKey<F, KZGCommitmentScheme<E>>), and MidnightVK::vk() hands back that same type. Since PlonkVerifyingKey is only an alias for it, the CircuitKeySerialization impl is effectively defined on the shared raw type, and deserialize_key always rebuilds with IvcCircuitData. It works today because only recursive keys are ever deserialized raw, but nothing stops a certificate key (same type) from being decoded as the IVC circuit, and that would only surface at proving or verification time.

Proposal: give each circuit its own clearly named key types, so the names answer the "why not MidnightVK" question and the serialization impls become unambiguous.
// circuits/halo2 (non-recursive)
pub struct NonRecursiveCircuitVerifyingKey(MidnightVK);
pub struct NonRecursiveCircuitProvingKey(MidnightPK<StmCertificateCircuit>);

// circuits/halo2_ivc (recursive)
pub struct RecursiveCircuitVerifyingKey(VerifyingKey<F, KZGCommitmentScheme<E>>);
pub struct RecursiveCircuitProvingKey(ProvingKey<F, KZGCommitmentScheme<E>>);
A few notes so this lands cleanly:

Make the recursive pair real newtypes, not type aliases. A renamed alias is still the shared raw type, so it reads better but does not stop a certificate key from matching the recursive impl. If you want to keep them as aliases, add a degree check (== RECURSIVE_CIRCUIT_DEGREE) inside the recursive deserialize_key so a wrong-circuit decode fails loudly instead of silently.

circuit_verification_key.rs is not dead code. CircuitVerificationKey is the serde-embedded VK field in SnarkProof and exposes get_midnight_vk() and from_bytes(), both of which are used. So this is a relocate and rename into the non-recursive keys file, carrying new, from_bytes, get_midnight_vk, the serde derive, and the midnight_vk_serde module. It is not a delete.

Once the impl lives on NonRecursiveCircuitVerifyingKey, midnight_vk_serde and CircuitKeySerialization for MidnightVK encode the same "MidnightVK to RawBytes" logic. Point the #[serde(with = ...)] at serialize_key and deserialize_key so there is a single source of truth.

CircuitVerificationKey::to_bytes is only used by a #[cfg(test)] golden test, so gate it with #[cfg(test)] rather than #[allow(dead_code)].

MidnightPK is generic, so the non-recursive proving key wraps MidnightPK<StmCertificateCircuit>.

This also sets up the later move to generic TryToBytes / TryFromBytes traits in codec.rs: distinct newtypes avoid conflicting impls on the shared foreign key type.

We can have a discussion about my proposal and decide on the best choice.

@jpraynaud @damrobi
Thanks @curiecrypt, really good proposal. It fixes a real issue: PlonkVerifyingKey / PlonkProvingKey are just aliases over the shared raw Midnight key type, so the codec lives on that shared type and always deserializes with IvcCircuitData. As you said, nothing stops a certificate key (same type via MidnightVK::vk()) from being decoded as the IVC circuit, and that will fail only at proving/verification.

IMO, the newtype direction is the right fix: it makes the cross-circuit decode impossible by construction, gives each key its own codec. A couple of your points are already in this PR (the generic TryToBytes/TryFromBytes traits in codec.rs, and to_bytes gated with #[cfg(test)])

The one challenge is scope: the aliases are used in ~37 places across 9 files, and it touches the same IVC area @damrobi is changing in #3348, so folding it into this PR would risk conflicts. My suggestion: do the newtypes as a follow-up ticket, coordinated with @damrobi once #3348 is merged. WDYT?

…UIT_DEGREE

…erifyingKey/PlonkProvingKey

…ircuits, delegating CircuitVerificationKey

…etup through it

…ly SRS plumbing

…vider

…ey provider

…he provider

damrobi

Left a few non blocking comments I think. I haven't had time to look at the tests in details so I will do so on Monday and approve

damrobi · 2026-06-26T15:21:22Z

+            return Err(error).with_context(|| "Failed to store the proving key in the cache");
+        }
+        if let Err(error) = fs::rename(&verification_key_temp, &self.verification_key_path) {
+            let _ = fs::remove_file(&verification_key_temp);


We don't want to remove the proving key file in that case ?

damrobi · 2026-06-26T15:25:26Z

    merkle_tree_depth: u32,
    /// Circuit verification key
-    circuit_verification_key: CircuitVerificationKey,
+    circuit_verification_key: NonRecursiveCircuitVerifyingKey,


Should we continue to store the verification key with the proof or try to get it from the cache when trying to verify the proof?

damrobi · 2026-06-26T15:28:24Z

+    pub(crate) verification_key: NonRecursiveCircuitVerifyingKey,
+    /// Proving key for the SNARK proof.


This might not be needed anymore if we remove the verification key from the proof but if we leave it this can stay.

damrobi · 2026-06-26T15:37:20Z

+    ) -> StmResult<Self> {
+        let circuit = provider.circuit().clone();
+        zk::downsize_srs_for_relation(&mut srs, &circuit);
+        let (verification_key, proving_key) = provider.key_pair(&srs)?;


This key_pair() function can clone the srs to downsize it again if the keys are not available. Maybe it's worth checking if we can remove the second downsizing as it demands cloning the full SRS.

damrobi · 2026-06-26T15:40:56Z

    tau_g2: G2Affine,
    /// Verifying key of the IVC circuit.
-    ivc_verifying_key: CircuitVerifyingKey,
+    ivc_verifying_key: PlonkVerifyingKey,


I think this should be the new type RecursiveCircuitVerifyingKey.

jpraynaud · 2026-06-23T14:49:52Z

+) -> StmResult<(MidnightVK, MidnightPK<StmCertificateCircuit>)> {
+    // The proving key is only read once the verifying key is present, so an orphan proving key left
+    // by a failed store (which removes the verifying key) is recomputed rather than surfaced as a
+    // deserialization error.
+    if let Some(verification_key) = disk_cache.get_verification_key::<MidnightVK>()?
+        && let Some(proving_key) =
+            disk_cache.get_proving_key::<MidnightPK<StmCertificateCircuit>>()?
    {
-        return Ok(pair);
+        return Ok((verification_key, proving_key));
    }


This should be a guarantee of the CircuitKeyCache (and I believe it is once the validate function has been called).

jpraynaud · 2026-06-26T08:59:36Z

+    }
+
+    /// Borrows the wrapped Midnight verifying key.
+    pub(crate) fn midnight_vk(&self) -> &MidnightVK {


This could be implemented with Deref trait.

jpraynaud · 2026-06-26T09:00:19Z

+
+impl NonRecursiveCircuitProvingKey {
+    /// Borrows the wrapped Midnight proving key, for proof generation.
+    pub(crate) fn midnight_pk(&self) -> &MidnightPK<StmCertificateCircuit> {


This also could be implemented with Deref trait.

jpraynaud · 2026-06-26T09:03:26Z

+    }
+}
+
+impl CircuitVerificationKeyProvider<StmCertificateCircuit> {


Maybe this should live in the CircuitVerificationKeyProvider module?

jpraynaud · 2026-06-26T09:10:41Z

+    }
+
+    #[test]
+    fn provider_returns_cached_verifying_key_on_hit() {


This test looks like you are trying to test underlying implementation details and can probably be removed.

jpraynaud · 2026-06-26T16:11:36Z

-    // once they ship.
+    /// `recursive_provider_factory` builds the recursive provider once the certificate verifying key
+    /// is known; production passes [`CircuitVerificationKeyProvider::for_recursive_circuit`].
    pub(crate) fn load(


We should try to align as much as possible the function names between recursive and non-recursive.

jpraynaud · 2026-06-26T16:13:36Z

+        recursive_provider_factory: impl FnOnce(
+            &NonRecursiveCircuitVerifyingKey,
+        ) -> StmResult<
+            CircuitVerificationKeyProvider<IvcCircuitData>,
+        >,


Why not inject the non-recursive CircuitKeyProvider in the recursive one and provide on the recursive one to this function instead? This would avoid this complex constructor.

jpraynaud · 2026-06-26T16:14:22Z

+    use crate::circuits::{
+        halo2::NON_RECURSIVE_CIRCUIT_VERIFICATION_KEY_FOR_PRODUCTION,
+        halo2_ivc::RECURSIVE_CIRCUIT_VERIFICATION_KEY_FOR_PRODUCTION,
+        test_utils::key_cache::with_shared_key_cache,
+        trusted_setup::{UNSAFE_SRS_SEED, build_provider_with_unsafe_srs},
+    };


Can you avoid imports in function body?

jpraynaud · 2026-06-26T16:18:53Z

+    /// bare-key shape (a `MidnightVK` and a `PlonkVerifyingKey`, each via a raw-bytes `#[serde(with)]`
+    /// module), serializes it through the same codec, then asserts the current struct decodes those
+    /// bytes and re-encodes them byte-for-byte.
+    mod wire_format_compatibility {


I don't really understand what this tests do.

jpraynaud · 2026-06-26T16:20:47Z

This module should stay as temporary or better be removed as it is only here to avoid re-computing SRS and circuit keys constantly.

hjeljeli32 self-assigned this Jun 22, 2026

hjeljeli32 requested review from curiecrypt, damrobi and jpraynaud as code owners June 22, 2026 07:14

jpraynaud requested a review from Copilot June 22, 2026 07:28

Copilot started reviewing on behalf of jpraynaud June 22, 2026 07:28 View session

Copilot AI reviewed Jun 22, 2026

View reviewed changes

Comment thread mithril-stm/src/circuits/key_cache.rs Outdated

Comment thread mithril-stm/src/circuits/key_cache.rs Outdated

Comment thread mithril-stm/src/circuits/key_cache.rs Outdated

hjeljeli32 temporarily deployed to testing-preview June 22, 2026 08:27 — with GitHub Actions Inactive

hjeljeli32 force-pushed the hjeljeli32/3300-refactor-unsafe-snark-setup branch from 9b62741 to 23d3d73 Compare June 22, 2026 09:34

hjeljeli32 temporarily deployed to testing-preview June 22, 2026 10:53 — with GitHub Actions Inactive

damrobi mentioned this pull request Jun 22, 2026

feat(stm): wire IVC snark prover #3348

Merged

10 tasks

damrobi approved these changes Jun 22, 2026

View reviewed changes

Comment thread mithril-stm/src/proof_system/halo2_snark/circuit_verification_key.rs Outdated

Comment thread mithril-stm/src/proof_system/halo2_snark/setup.rs

jpraynaud reviewed Jun 22, 2026

View reviewed changes

curiecrypt reviewed Jun 22, 2026

View reviewed changes

github-advanced-security AI found potential problems Jun 23, 2026

View reviewed changes

Comment thread mithril-stm/src/circuits/key_cache.rs Fixed

Comment thread mithril-stm/src/circuits/key_cache.rs Fixed

hjeljeli32 force-pushed the hjeljeli32/3300-refactor-unsafe-snark-setup branch from 4633f9b to 8382b4b Compare June 23, 2026 02:53

hjeljeli32 temporarily deployed to testing-preview June 23, 2026 06:14 — with GitHub Actions Inactive

hjeljeli32 force-pushed the hjeljeli32/3300-refactor-unsafe-snark-setup branch from 089bdcc to 5a0d3a8 Compare June 23, 2026 06:30

hjeljeli32 force-pushed the hjeljeli32/3300-refactor-unsafe-snark-setup branch from 5a0d3a8 to 8f6b387 Compare June 23, 2026 07:28

hjeljeli32 temporarily deployed to testing-preview June 23, 2026 08:44 — with GitHub Actions Inactive

hjeljeli32 requested review from curiecrypt and jpraynaud June 23, 2026 08:48

hjeljeli32 force-pushed the hjeljeli32/3300-refactor-unsafe-snark-setup branch 2 times, most recently from ff7e18a to fbe74b2 Compare June 25, 2026 06:09

hjeljeli32 temporarily deployed to testing-preview June 25, 2026 07:28 — with GitHub Actions Inactive

hjeljeli32 temporarily deployed to testing-preview June 25, 2026 09:22 — with GitHub Actions Inactive

hjeljeli32 added 2 commits June 26, 2026 07:57

refactor(stm): rename IVC circuit degree constant K to RECURSIVE_CIRC…

7bb9c9b

…UIT_DEGREE

refactor(stm): relocate and rename shared PLONK key aliases to PlonkV…

7631e6f

…erifyingKey/PlonkProvingKey

hjeljeli32 added 9 commits June 26, 2026 08:37

feat(stm): add CircuitKeySerialization trait and key serde for both c…

5ead51f

…ircuits, delegating CircuitVerificationKey

feat(stm): give CircuitKeyCache typed key access and wire the SNARK s…

b279268

…etup through it

refactor(stm): rename certificate snark setup module and drop test-on…

d75701a

…ly SRS plumbing

refactor(stm): rename SnarkSetup to SnarkProverSetup

d3b8449

test(stm): isolate test key caches per test via current_function!

38ab8bf

refactor(stm): apply first round of review feedback on the SNARK setup

c186356

test(stm): apply second round of review feedback on the SNARK setup

d60f3d8

refactor(stm): turn the circuit key cache into a verification key pro…

b918b3b

…vider

refactor(stm): compute the certificate key through the verification k…

4ee3c5c

…ey provider

hjeljeli32 force-pushed the hjeljeli32/3300-refactor-unsafe-snark-setup branch from 355a3f2 to 4ee3c5c Compare June 26, 2026 01:30

hjeljeli32 temporarily deployed to testing-preview June 26, 2026 02:47 — with GitHub Actions Inactive

refactor(stm): rename IvcProverSetup to IvcSnarkProverSetup and use t…

52f80cf

…he provider

hjeljeli32 temporarily deployed to testing-preview June 26, 2026 04:37 — with GitHub Actions Inactive

hjeljeli32 added 2 commits June 26, 2026 15:39

test(stm): share a content-keyed key cache across the slow tests

bdc8c7c

refactor(stm): share the certificate test key and clarify setup naming

d5e79b1

hjeljeli32 requested review from Alenar and turmelclem as code owners June 26, 2026 07:23

hjeljeli32 temporarily deployed to testing-preview June 26, 2026 08:52 — with GitHub Actions Inactive

damrobi reviewed Jun 26, 2026

View reviewed changes

jpraynaud reviewed Jun 26, 2026

View reviewed changes

		pub(crate) verification_key: NonRecursiveCircuitVerifyingKey,
		/// Proving key for the SNARK proof.

Uh oh!

Conversation

hjeljeli32 commented Jun 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Content

Changes

Tests

Pre-submit checklist

Issue(s)

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

github-actions Bot commented Jun 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test Results

Uh oh!

damrobi left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

curiecrypt left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

hjeljeli32 commented Jun 23, 2026

Uh oh!

damrobi left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

hjeljeli32 commented Jun 22, 2026 •

edited

Loading

github-actions Bot commented Jun 22, 2026 •

edited

Loading