Audit scope + production readiness of the ZK-optimized Solidity Honk verifier (honk_zk_optimized_contract.hpp)

[pycckuu]

Hi — question about which Solidity verifier variant is considered production-ready, and whether the audit scope
document is current.

We run Noir circuits with a ZK UltraHonk EVM verifier (bb write_solidity_verifier -t evm). We measured --optimized across our stack and it is a 71.5% verify-gas cut (23.9M → 6.8M total, flat across circuits from 12.5k to 42.5k gates), with identical VK hashes and smaller deployed bytecode. We would like to adopt it, and the only thing stopping us is audit provenance.

What we found:

• barretenberg/cpp/scripts/audit/audit_scopes/honk_solidity_verifier_audit_scope.md lists honk_contract.hpp,
  honk_optimized_contract.hpp and honk_zk_contract.hpp — but not honk_zk_optimized_contract.hpp.
• That scope doc was last updated 2026-03-26, and honk_zk_optimized_contract.hpp first landed 2026-04-10, so
  the omission may simply be that the doc predates the file rather than a deliberate exclusion.
• chore: honk verifier opt + fix review #20547 mentions the optimized verifier had "been submitted for audit already", with the ZK verifier being read through afterwards.
• noir-projects/noir-protocol-circuits/bootstrap.sh uses --disable_zk --optimized, i.e. the non-ZK optimized file.

Questions:

1. Is honk_zk_optimized_contract.hpp in scope for the Honk Solidity verifier audit — either already submitted, or
   planned? Is the scope document current, or does it predate the ZK-optimized work?
2. Is -t evm --optimized (ZK flavor) considered production-ready, or is the non-ZK optimized path the only one
   you'd recommend deploying today?
3. Is anyone deploying the ZK-optimized verifier on mainnet? Any known users would be useful evidence.
4. Do the barretenberg differential / malformed-proof tests cover the ZK-optimized generator specifically, or only
   the non-ZK optimized one?

What we can contribute back: we built a differential-equivalence suite that treats the currently-deployed template
as a reference oracle and requires the two implementations to agree on every input — per relation: every 32-byte proof
word bit-flipped, every public-input word mutated, truncation, all-zero, wrong arity, cross-relation proofs, plus
fuzzed corruption. 56 tests across ten real circuits, and the harness is mutation-verified (injecting a deliberately
unsound verifier fails 10 of 11 checks). We found zero disagreements between the default-ZK and ZK-optimized
templates. Happy to share it if useful.

Thanks!

[zexoverz]

Independent data point on the same question, from a different circuit. I run a Noir plus UltraHonk EVM verifier for an ERC (confidential policy verdicts, keccak transcript, bb 5.1.0, deployed and verifying on Sepolia). I regenerated it with --optimized (the ZK-optimized path) and measured it against the default ZK verifier on the same proof and the same VK.

On my circuit, 3795 gates, the default ZK verifier costs 2,564,863 verify gas at 18,557 bytes deployed, and the ZK-optimized one costs 731,348 gas at 16,892 bytes. That is a 71.5% verify-gas cut, which matches your number exactly, plus smaller bytecode, and the same proof verifies against the same VK. So it reproduces on an independent circuit, and I am a real deployed user of the ZK verifier if that helps the production-readiness question.

The audit-scope observation looks right to me. The scope doc predates honk_zk_optimized_contract.hpp, so the omission reads like a timing gap rather than a deliberate exclusion. I would also value a clear answer on whether -t evm --optimized (ZK flavor) is the path to deploy today. Happy to share the measurement setup.