Solidity verifier from bb CLI rejects proofs from bb.js (ProofLengthWrongWithLogN)

[johnathan79717]

Bug Report

Source: User report from ETHDenver workshop (@georgeh0x)

Description

The optimized Solidity verifier generated by bb CLI does not verify keccak-based proofs generated by bb.js (via noirjs). Verification reverts with ProofLengthWrongWithLogN.

The user's workaround is generating the Solidity verifier from bb.js instead, but bb.js does not support the --optimized verifier variant.

Steps to Reproduce

1. Compile a Noir circuit
2. Generate a keccak proof using bb.js with keccak: true
3. Generate an optimized Solidity verifier using bb CLI (bb contract)
4. Attempt to verify the bb.js proof against the bb CLI verifier on-chain
5. Verification reverts with ProofLengthWrongWithLogN

Root Cause Analysis

There is a PAIRING_POINTS_SIZE mismatch between bb.js and the Solidity contracts:

• bb.js (barretenberg/ts/src/proof/index.ts:12): PAIRING_POINTS_SIZE = 16
• Solidity (barretenberg/sol/src/honk/HonkTypes.sol:19): PAIRING_POINTS_SIZE = 8

This constant is used in calculateProofSize() which determines the expected proof byte length. The mismatch causes the Solidity verifier's length check to fail:

• BaseHonkVerifier.sol:53-54: if (proof.length != expectedProofSize * 32) { revert ProofLengthWrongWithLogN(...) }
• BaseZKHonkVerifier.sol:85-86: require(proof.length == expectedProofSize, ProofLengthWrongWithLogN(...))

The discrepancy likely stems from different field element encodings — bb.js may use 4 limbs per BN254 G1 coordinate (FrCodec-style) while the Solidity verifier expects 2 elements per coordinate (U256Codec-style, native 256-bit encoding).

Expected Behavior

Proofs generated by bb.js should be verifiable by Solidity contracts generated by bb CLI (and vice versa), since both tools are part of the same Barretenberg suite.

Additional Context

The user also noted that bb.js can generate a working Solidity verifier, but it doesn't support the --optimized flag, which is only available via bb CLI.

[geovgy]

Hey, thank you for making this issue. I would like to add some more context that may also help.

Both bb.js and bb cli versions used are 3.0.0-nightly.20260102.

The script I would use for generating the solidity verifier via bb cli:

bb write_vk -t evm -s ultra_honk -b ./target/$CIRCUIT_NAME.json -o ./target && bb write_solidity_verifier -t evm -s ultra_honk -k ./target/vk -o ./target/verifier.sol --optimized

While to do the same via bb.js (minus the optimized part), I use something like this script.

Another thing to note is that the bb.js generated solidity verifier has a compiler warning that is not present in the bb cli generated (unoptimized) one. This appears on line 695 for the function generateShplonkZChallenge which should be a pure function. Same function appears on line 728 correctly as pure in the bb cli one.

Another addition:
I generated the same proof both via the CLI and NPM package and resulted in different proof lengths.

CLI proof length (bytes): 8256
JS proof length (bytes): 7328

Only the CLI generated proof verifies properly in optimized verifier contract from CLI.

[Boundary-Labs-dev]

Looking at proof_length.hpp, proof size depends on Flavor::Codec::calc_num_fields().

If bb CLI is using U256Codec for EVM (2 field elements per G1 commitment) but bb.js defaults to FrCodec, that would change num_frs_in_comm.

For log_n = 28, the Shplemini section contributes (log_n - 1) + 2 = 29 commitments.

A 1-word difference per commitment would explain the observed 29 field element delta (928 bytes).

Might be worth checking whether bb.js is selecting a different Codec than the Solidity verifier expects when targeting EVM.

[ledwards2225]

The issue here seems to be the use of write_solidity_verifier + ZK enabled (the default) + --optimized, since there is currently no optimized solidity verifier. The error was of course totally unhelpful so for now the solution is just to add a clear error (here). Optimized ZK verifier coming soon!