Solidity verifier fails for circuits with no public inputs

[lazovicff]

To reproduce, run the tests https://github.com/eigen-trust/protocol/blob/evm-verifier-tests/circuit/src/verifier/mod.rs#L104-L350
Here you have 2 circuits defined - one with a public input and one without. For both of the verifiers are created successfully and deployed to evm. The test fails when trying to verify proofs in evm, but only the proofs without public inputs.
My guess that it enters some infinite loop, since the gas used is unusually high, which is the reason why the smart contract reverts.

But here are results that I'v gotten:

running 6 tests
test verifier::test::verify_dummy_dev ... ok
test verifier::test::verify_dummy_pi_dev ... ok
test verifier::test::verify_dummy_evm ... FAILED
test verifier::test::verify_dummy_prod ... ok
test verifier::test::verify_dummy_pi_prod ... ok
test verifier::test::verify_dummy_pi_evm ... ok

failures:

---- verifier::test::verify_dummy_evm stdout ----
[circuit/src/verifier/mod.rs:225] deployment_code.len() = 2714
[circuit/src/verifier/mod.rs:91] deployment_result.exit_reason = Continue
[circuit/src/verifier/mod.rs:96] result.gas_used = 18446673704965374012
[circuit/src/verifier/mod.rs:97] result.reverted = true
[circuit/src/verifier/mod.rs:98] result.exit_reason = Revert
thread 'verifier::test::verify_dummy_evm' panicked at 'assertion failed: success', circuit/src/verifier/mod.rs:101:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

For comparison, here are the results for verifying proofs WITH public inputs:

[circuit/src/verifier/mod.rs:346] deployment_code.len() = 6235
[circuit/src/verifier/mod.rs:92] deployment_result.exit_reason = Continue
[circuit/src/verifier/mod.rs:97] result.gas_used = 267249
[circuit/src/verifier/mod.rs:98] result.reverted = false
[circuit/src/verifier/mod.rs:99] result.exit_reason = Return

This is not a blocker for us, but I thought its worth reporting.

[han0110]

Thanks for reporting this issue!

Just tested locally, I found the issue is actually caused by the inconsistency degree calculation between halo2 and snark-verifier. So in halo2 the minimum degree is always 3 even we don't have any column enabled with copy constraint, but snark-verifier calculates the degree more precisely, so this difference makes snark-verifier miss to read some chunks quotient polynomial, and the proof reading is basically wrong (the shift messes up the rest stuff so make some static call to precompile to consume all the gas due to invalid ec point input). So in the test circuits you provide, the second one with instance column works is actually because there are some columns enabled with copy constraint, not because it has instance column.

A fix to make the example work with at least NativeLoader has been submitted #29, and I have also opened #30 for investigation if it's okay to have quotient poly's chunks to be identity (the extra chunks will be identity), I feel it's okay but I haven't see any deployed contract allowing that.

[lazovicff]

Is this maybe the reason why my smart contract reverts here: https://github.com/eigen-trust/protocol/blob/solidity-plonk-verifier/data/test_verifier_temp.yul#L820-L824.

This is the circuit that we are verifying (the same as the one described in the issue above): https://github.com/eigen-trust/protocol/blob/solidity-plonk-verifier/circuit/src/verifier/mod.rs#L168-L266

And the place where we do this test is here: https://github.com/eigen-trust/protocol/blob/solidity-plonk-verifier/client/src/utils.rs#L166-L181.

[lazovicff]

Is this maybe the reason why my smart contract reverts here: https://github.com/eigen-trust/protocol/blob/solidity-plonk-verifier/data/test_verifier_temp.yul#L820-L824.

This is the circuit that we are verifying (the same as the one described in the issue above): https://github.com/eigen-trust/protocol/blob/solidity-plonk-verifier/circuit/src/verifier/mod.rs#L168-L266

And the place where we do this test is here: https://github.com/eigen-trust/protocol/blob/solidity-plonk-verifier/client/src/utils.rs#L166-L181.

I will open a new issue for this