Fix `check_deployment` disagreement due to non-deterministic `signer` by Antonio95 · Pull Request #3346 · ProvableHQ/snarkVM

Antonio95 · 2026-07-31T08:23:39Z

This PR fixes a problematic interaction between an issue in resolve_dynamic_target and non-deterministic sampling of a signer in some CallStack modes.

Issue

The function resolve_dynamic_target, called in synthesizer/process/src/stack/call/dynamic.rs::{execute, evaluate}, returns a Result<Option<ResolvedTarget>>. In the two CallStack modes it refers to as "dummy", i.e.
Synthesize and CheckDeployment, it returns Ok<None> in some cases and Err in others (specifically, Err is returned when the target can be resolved but it points to a closure). The correct thing to do would be to return Ok<None> in all cases for those two modes, since in those no dynamic calls are actually followed through and executed (one is synthesising a single function's circuit, and closures cannot be called via call.dynamic). This is indeed the way resolve_dynamic_target was documented - but not implemented. The documentation has been updated to match actual behaviour.

As can be seen in execute, the target returned by resolve_dynamic_target is never used in the dummy modes. However, execute always applies ? to the Result<<Option<ResolvedTarget>>>, which means execute fails (in a controlled manner) when the register values as they exist during synthesis happen to cause the target to be an existing closure. In particular, verify_deployment rejects it.

So far this would mainly be a usability issue, where technically valid programs could not be deployed. However, one element is not sampled deterministically when starting circuit Synthesize and CheckDeployment modes: the signer, which is sampled from the OS's rng instead of the deterministic seeded_rng used for function inputs, etc. This makes easy to construct simple programs where vm.deploy and vm.check_deployment succeed or fail randomly depending on the OS's unpredictable rng, leading to a disagreement between validators: simply have the target of a call.dynamic instruction depend on the signer (for instance, it's last bit), being an existing closure in some cases and a non-existent target (or a function) in others. Cf. the test https://github.com/ProvableHQ/snarkVM/blob/fix/dynamic_target_resolution_closure/synthesizer/src/vm/tests/test_v19/closure_dynamic_targets.rs#L21.

Fix

Two options present themselves:

Sample the signer from seeded_rng instead of rng. This means if one validator rejects the deployment, all do. This does not need to be version guarded, since in principle it is switching from "machine-dependent random, sometimes correct, sometimes not" to "deterministic, correct".
Modify resolve_dynamic_target to always return Ok<None> in Synthesize and CheckDeployment modes, as mentioned above. This was done in this PR (ccfe407) but has since been reverted.

Point 2 would more robust and future-proof, as it also guards against other sources of randomness we may have missed (none have been found after an AI-aided search) or which may be introduced in the future. However, the call to resolve_dynamic_target lives in an internal part of the stack we do not want to be consensus-version-dependent. For that reason, we implement point 1 only (which is a positive change in itself). As a result, pathological Aleo programs such as the one proposed may either be rejected by all validators, or accepted by all, i.e. the risk of forking is avoided. The fact that such a program (which technically has valid Aleo instructions) could be rejected at random is a minor usability issue given its pathological semantics (a dynamic call can never execute pointing to a closure, so a program definition which allows that in some register state is, at best, questionable).

A way to implement point 2 and circumvent the ConsensusVersion threading issue would be to add a boolean flag to CallStack::Synthesize and CallStack::CheckDepoyment to mark which version of resolve_dynamic_target to use (fixed one in the since reverted ccfe407). @raychu86 let me know if you prefer this option (to the current state, i.e. not implementing point 2).

Tests

One small test has been added which tests the narrow type of problematic programs: test_v19::test_conditional_dynamic_call_target_deployment. Details therein.

Copilot

Pull request overview

This PR addresses a consensus-risky nondeterminism in deployment checking by making the “dummy” signer used during CheckDeployment circuit synthesis deterministic (derived from a seeded RNG), preventing validator disagreements when call.dynamic targets depend on self.signer.

Changes:

Make the burner private key (and thus self.signer) deterministic during deployment verification by sampling it from the deployment-ID-seeded RNG.
Update resolve_dynamic_target documentation to reflect current behavior in Synthesize / CheckDeployment modes.
Add a V19 regression test covering dynamic target resolution involving closures, and update several related comments for clarity.

Reviewed changes

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

Show a summary per file

File	Description
synthesizer/process/src/stack/deploy.rs	Samples burner private key from a deployment-ID-seeded RNG to make `CheckDeployment` deterministic.
synthesizer/process/src/stack/call/dynamic.rs	Updates documentation for `resolve_dynamic_target` return behavior (esp. closure cases).
synthesizer/src/vm/tests/test_v19/closure_dynamic_targets.rs	Adds regression test for deterministic `verify_deployment` behavior with closure-vs-function dynamic targets.
synthesizer/src/vm/tests/test_v19/mod.rs	Registers the new V19 test module.
synthesizer/src/vm/tests/test_v18/mod.rs	Comment wording/line-wrapping cleanup.
synthesizer/process/src/stack/helpers/synthesize.rs	Comment clarifying `is_root = true` semantics during synthesis.
synthesizer/process/benches/check_deployment.rs	Comment clarifying `is_root = true` semantics in benchmark setup.
synthesizer/process/src/tests/test_credits.rs	Comment clarifying `is_root` is set (not sampled).
circuit/program/src/request/verify.rs	Comment clarifying `is_root = true` semantics in circuit-side request verification tests.

cbeck88 · 2026-08-10T22:13:49Z

+// Deploys a program whose function points the target of a call.dynamic instruction to a closure or a
+// function depending on the last bit of self.signer. The test checks several runs of test-


the code comment trails off, so some edit here seems desirable

cbeck88 · 2026-08-10T22:13:04Z

@@ -160,7 +160,7 @@ impl<N: Network> Stack<N> {
            deployment.program().functions().values().zip_eq(deployment.function_verifying_keys())
        {
            // Initialize a burner private key.
-            let burner_private_key = PrivateKey::new(rng)?;
+            let burner_private_key = PrivateKey::new(&mut seeded_rng)?;


imo this is a pretty decent suggestion -- we used an approach like this in another project with similar constraints around determinism where we still wanted to be able to make changes easily

@cbeck88 What do you think about the following? At the two (relevant) places where we just replaced rng by seeded_rng (signer sampling and get.record.dynamic resolution), we pass a cloned copy of seeded_rng instead?

i think instead of cloning seeded_rng, could call SeedableRng::from_seed(seeded_rng.next_u64())? or something like this

only because, using an rng to seed another rng still results in pseudo-independent draws, but cloning the rng doesn't do that, so it could conceivably cause an obscure problem. it just seems a little more defensive

raychu86 · 2026-07-31T18:21:33Z

A way to implement point 2 and circumvent the ConsensusVersion threading issue would be to add a boolean flag to CallStack::Synthesize and CallStack::CheckDepoyment to mark which version of resolve_dynamic_target to use (fixed one in the since reverted ccfe407). @raychu86 let me know if you prefer this option (to the current state, i.e. not implementing point 2).

I'd like to keep the CallStack minimally altered if we can, unless the problem is serious enough. This issue seems a bit more of an inconvenience for the developer.

I recall at some point there was a similar false-negative (incorrectly rejecting) case for standard deployments as well. Does Fix 2 address that as well?

Antonio95 · 2026-08-03T13:58:50Z

A way to implement point 2 and circumvent the ConsensusVersion threading issue would be to add a boolean flag to CallStack::Synthesize and CallStack::CheckDepoyment to mark which version of resolve_dynamic_target to use (fixed one in the since reverted ccfe407). @raychu86 let me know if you prefer this option (to the current state, i.e. not implementing point 2).

I'd like to keep the CallStack minimally altered if we can, unless the problem is serious enough. This issue seems a bit more of an inconvenience for the developer.

I recall at some point there was a similar false-negative (incorrectly rejecting) case for standard deployments as well. Does Fix 2 address that as well?

@raychu86 I'm not sure which false negatives you have in mind. We've fixed a couple of unrelated valid-program rejections lately (e.g. programs which cast fields to scalars and output the latter; or programs with some complex cast-to-external-struct isntructions), but point 2 is not related to any of those fixes. Lmk if you meant something else.

raychu86 · 2026-08-10T16:05:12Z

@Antonio95 I may be misremembering, but a while back we had a similar non-deterministic outcome for deployment verification. However I don't recall if it was consistent between validators. I just checked, and it should be fine with the deterministic RNG, so non-issue.

cbeck88 · 2026-08-10T16:11:20Z

I'd like to keep the CallStack minimally altered if we can, unless the problem is serious enough. This issue seems a bit more of an inconvenience for the developer.

@raychu86 the seriousness of the problem is that it can cause a chain split, as mentioned by antonio:

This makes easy to construct simple programs where vm.deploy and vm.check_deployment succeed or fail randomly depending on the OS's unpredictable rng, leading to a disagreement between validators

The attacker need not have control of a validator node in quorum to cause this chain split, which is why it's a serious vulnerability

This vulnerability was found by a security researcher and we paid it out

cbeck88

imo this is an important fix and we should take it

i am staging an additional PR on top of this which addresses a similar problem in get_record_dynamic

Builds on the burner-key fix (seeding `self.signer` for `CheckDeployment`) by closing the remaining ambient-RNG sources reachable during deployment verification, so that verification is a pure function of the deployment. Most importantly, `get.record.dynamic` sampled its dummy entry value from `rand::rng()` on the not-present branch, which is reached during `CheckDeployment` synthesis (a sampled dynamic record carries no data). That value is stored to a register a program can feed into a `call.dynamic` target (closure vs. non-closure), so the same deployment could verify on some validators and abort on others — an independent fork vector not closed by seeding the burner key, since the exploiting program never reads `self.signer`. It is now drawn from a ChaChaRng seeded by the record root and entry identifier, both deterministic across validators verifying the same deployment. Additionally, in `verify_deployment`, the `Request::sign` nonce and the record-translation sampling are now drawn from the deployment-ID-seeded RNG rather than the ambient `rng`. These are defense-in-depth: once the burner key is seeded neither currently changes a verification outcome, but this removes any dependence of verification on the ambient RNG. The `rng` argument is now unused and renamed `_rng` (the signature is retained for API compatibility). Out of scope: the Synthesize-mode (key-generation) burner in `synthesize.rs` runs during `deploy()`/proving, never during validator verification, so it is not a fork source and is left unchanged. Adds `test_v19/get_record_dynamic_targets.rs`, mirroring `closure_dynamic_targets` but driving the `call.dynamic` target from a `get.record.dynamic` read; it fails without the fix and asserts repeated verifications agree. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

raychu86

Code looks straightforward. Some merge conflicts

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Signed-off-by: Antonio Mejías Gil <anmegi.95@gmail.com>

…rification-hardening Harden deployment verification: seed remaining ambient RNG sources (follow-on to #3346)

veria-ai · 2026-08-11T12:50:34Z

        {
            // Initialize a burner private key.
-            let burner_private_key = PrivateKey::new(rng)?;
+            let burner_private_key = PrivateKey::new(&mut seeded_rng)?;


Medium: Ungated consensus verification change

A deployer can submit a pre-V19 program whose call.dynamic target depends on self.signer or a sampled dynamic-record value. Using the deployment-seeded witness for all consensus versions can make an upgraded validator reject a deployment previously accepted with the legacy ambient-RNG witness, causing disagreement during historical replay. Gate the deterministic behavior on its activation consensus version and retain the legacy path for earlier versions; the deterministic sampling added in get_record_dynamic.rs needs the same gate.

From the PR description: "This does not need to be version guarded, since in principle it is switching from "machine-dependent random, sometimes correct, sometimes not" to "deterministic, correct"."

Thanks for the detail. I can't automatically confirm this is safe to dismiss, so I'm leaving the thread open for a maintainer to make the call.

veria-ai · 2026-08-11T12:50:42Z

PR overview

This pull request makes signer and dynamic-record sampling deterministic during deployment checks to prevent inconsistent check_deployment results.

One security issue remains open: the deterministic verification behavior is not gated by consensus version, so a crafted pre-V19 deployment can be interpreted differently by upgraded validators during historical replay. This can cause consensus disagreement until the legacy behavior is retained for versions before activation.

Open issues (1)

Medium: Ungated consensus verification change — synthesizer/process/src/stack/deploy.rs:166

Fixed/addressed: 0 · PR risk: 7/10

Antonio95 added 11 commits July 25, 2026 11:54

added test

63de76b

documented

2c5b7ee

made signer deterministic

b628d1e

fixed resolve_dynamic_target

ccfe407

reverted changes to resolve_dynamic_target

b3df9e4

Merge branch 'staging' into fix/dynamic_target_resolution_closure

944f964

adapted test, polished

9e52ca4

made test return type void

d369176

merged staging, fixed consensus version

5f35822

fixed documentation of

e296956

removed TODOs

13db1fd

Antonio95 requested review from Copilot and raychu86 July 31, 2026 08:23

Copilot started reviewing on behalf of Antonio95 July 31, 2026 08:24 View session

Copilot AI reviewed Jul 31, 2026

View reviewed changes

vicsn mentioned this pull request Aug 3, 2026

Make synthesis limit tracking robust against function calls #3344

Open

cbeck88 approved these changes Aug 10, 2026

View reviewed changes

cbeck88 mentioned this pull request Aug 10, 2026

Harden deployment verification: seed remaining ambient RNG sources (follow-on to #3346) #3365

Merged

raychu86 approved these changes Aug 10, 2026

View reviewed changes

Antonio95 and others added 2 commits August 11, 2026 10:11

Copilot allocation-related tweak

3d71db4

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Signed-off-by: Antonio Mejías Gil <anmegi.95@gmail.com>

Merge pull request #3365 from cbeck88/fix/deterministic-deployment-ve…

89ecd9f

…rification-hardening Harden deployment verification: seed remaining ambient RNG sources (follow-on to #3346)

veria-ai Bot reviewed Aug 11, 2026

View reviewed changes

Antonio95 added 2 commits August 11, 2026 14:52

merge staging

74e3666

merged test files, minor tweaks

286ad60

Antonio95 added 3 commits August 11, 2026 15:44

minor formatting

e16da07

switched to secondary seeded rng in the new usage instances

7e65ba4

Merge branch 'staging' into fix/dynamic_target_resolution_closure

547239f

		// Deploys a program whose function points the target of a call.dynamic instruction to a closure or a
		// function depending on the last bit of self.signer. The test checks several runs of test-

Uh oh!

Conversation

Antonio95 commented Jul 31, 2026

Issue

Fix

Tests

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

cbeck88 Aug 10, 2026

Choose a reason for hiding this comment

Uh oh!

cbeck88 Aug 10, 2026

Choose a reason for hiding this comment

Uh oh!

Antonio95 Aug 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cbeck88 Aug 11, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

raychu86 commented Jul 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Antonio95 commented Aug 3, 2026

Uh oh!

raychu86 commented Aug 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cbeck88 commented Aug 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cbeck88 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

raychu86 left a comment

Choose a reason for hiding this comment

Uh oh!

veria-ai Bot Aug 11, 2026

Choose a reason for hiding this comment

Uh oh!

Antonio95 Aug 11, 2026

Choose a reason for hiding this comment

Uh oh!

veria-ai Bot Aug 11, 2026

Choose a reason for hiding this comment

Uh oh!

veria-ai Bot commented Aug 11, 2026

PR overview

Open issues (1)

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Antonio95 Aug 11, 2026 •

edited

Loading

raychu86 commented Jul 31, 2026 •

edited

Loading

raychu86 commented Aug 10, 2026 •

edited

Loading

cbeck88 commented Aug 10, 2026 •

edited

Loading

cbeck88 left a comment •

edited

Loading