Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bug: deploying token contract with proven fails to satisfy constraint #10530

Closed
just-mitch opened this issue Dec 9, 2024 · 1 comment · Fixed by #10593
Closed

bug: deploying token contract with proven fails to satisfy constraint #10530

just-mitch opened this issue Dec 9, 2024 · 1 comment · Fixed by #10593
Assignees
Labels
P-critical 🔥 Priority: critical. Drop all else and do this task now, please.

Comments

@just-mitch
Copy link
Contributor

just-mitch commented Dec 9, 2024

Deploying the Token contract with proving on no longer works, it fails to prove in the PXE.

@PhilWindle Tracked it down to this commit.

Logs/Stack:

Added contract Token at 0x18ef
Executed local simulation for 0x24666

{"hostname":"gke-aztec-gke-aztec-node-pool-6b6ed5c2-hznc", "level":50, "module":"pxe_service", "msg":"Error: Error: Cannot satisfy constraint
    at module.exports.__wbg_constructor_f8f83aa6ec3644b9 (/usr/src/noir/packages/acvm_js/nodejs/acvm_js.js:659:17)
    at acvm_js::js_execution_error::JsExecutionError::new::hebdb1fd5d8918eaa (wasm://wasm/0091f51a:wasm-function[639]:0x1223b5)
    at acvm_js::execute::ProgramExecutor<B>::execute_circuit::{{closure}}::hdef4865f37ab532b (wasm://wasm/0091f51a:wasm-function[76]:0x4e7aa)
    at acvm_js::execute::execute_program_with_native_program_and_return::{{closure}}::h4055275b2107668e (wasm://wasm/0091f51a:wasm-function[420]:0xfb30d)
    at acvm_js::execute::execute_program_with_native_type_return::{{closure}}::hfd113d3fb49d29e9 (wasm://wasm/0091f51a:wasm-function[493]:0x10a673)
    at wasm_bindgen_futures::future_to_promise::{{closure}}::{{closure}}::h31652aa40bcb8f1c (wasm://wasm/0091f51a:wasm-function[395]:0xf53a0)
    at wasm_bindgen_futures::queue::Queue::new::{{closure}}::he31c90183f9be757 (wasm://wasm/0091f51a:wasm-function[714]:0x12c91b)
    at <dyn core::ops::function::FnMut<(A,)>+Output = R as wasm_bindgen::closure::WasmClosure>::describe::invoke::h624a3dfbf78ca22a (wasm://wasm/0091f51a:wasm-function[2391]:0x181f6a)
    at __wbg_adapter_22 (/usr/src/noir/packages/acvm_js/nodejs/acvm_js.js:220:10)
    at real (/usr/src/noir/packages/acvm_js/nodejs/acvm_js.js:205:20) {
  callStack: [ '4705' ],
  rawAssertionPayload: undefined,
  brilligFunctionId: undefined
}", "pid":1}

Repro:

Terminal 1 - run anvil
Terminal 2 - run a sandbox

export ETHEREUM_HOST="http://127.0.0.1:8545/"
cd ~/aztec3-packages/yarn-project/aztec
yarn start start --sandbox

Terminal 3 - run the bot

export AZTEC_NODE_URL="http://127.0.0.1:8080/"
export BOT_TX_INTERVAL_SECONDS=1
export BOT_PUBLIC_TRANSFERS_PER_TX=1
export BOT_PRIVATE_TRANSFERS_PER_TX=1
export BOT_FOLLOW_CHAIN="NONE"
export PROVER_REAL_PROOFS=true
export PXE_PROVER_ENABLED=true
export BOT_NO_START=false
export BB_BINARY_PATH=/mnt/user-data/phil/aztec3-packages/barretenberg/cpp/build/bin/bb
export BB_WORKING_DIRECTORY=/mnt/user-data/phil/tmp
export LOG_LEVEL=debug
export AZTEC_PORT=8081

./yarn-project/aztec/dest/bin/index.js start --bot --pxe
@Maddiaa0 Maddiaa0 added the P-critical 🔥 Priority: critical. Drop all else and do this task now, please. label Dec 10, 2024
@LeilaWang LeilaWang linked a pull request Dec 11, 2024 that will close this issue
@LeilaWang
Copy link
Contributor

Fixed by #10593. Tracking the cause of the problem in #10592

MirandaWood added a commit that referenced this issue Mar 7, 2025
…ndex underflow (#12540)

Closes #10592

## Bug

We previously commented out the array checks for private logs in tail to
public (#10593)
because a constraint was mysteriously failing
(#10530).

It failed because of an attempted underflow array access e.g. `array[i -
1]` where `i = 0`. The thing is that the array access shouldn't have
been called because it was wrapped in an if statement.

I don't think this has anything to do with logs, it just so happened
that logs were the first tx effect array to have `num_non_revertibles =
0` in the above bot run.

## Fix

In this case we had a private log with `.counter() = 8`, `split_counter
= 3`, and `num_non_revertibles = 0`. However the constraint failure* was
coming from `sorted_array[num_non_revertibles - 1]` below:
```rust
 if num_non_revertibles != 0 {
        assert(
            sorted_array[num_non_revertibles - 1].counter() < split_counter,
            "counter of last non-revertible item is not less than the split counter",
        );
    }
```
I added a hacky fix which prevents the constraint failure by simply
multiplying the LHS by zero if the array access will fail:
```rust
   if num_non_revertibles != 0 {
        let is_non_zero = (num_non_revertibles != 0) as u32;
        assert(
            sorted_array[num_non_revertibles - 1].counter()*is_non_zero < split_counter,
            "counter of last non-revertible item is not less than the split counter",
        );
    }
```

*(If we had incorrectly entered the if statement and the assertion
failed, the error would be `Assertion failed`, but the error was
`Constraint failure`).

## Repro

I included the `Prover.toml` which came from the above failure - it's
valid and should pass. To see the failure remove `is_non_zero` from the
above code (in `assert_split_transformed_value_arrays.nr`), then run:

`nargo execute --package private_kernel_tail_to_public`

Add back the fix and run the same to see it passing.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P-critical 🔥 Priority: critical. Drop all else and do this task now, please.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants