chore: bump linked bb version

[TomAFrench]

Description

Problem*

Resolves

Summary*

Additional Context

Documentation*

Check one:

• No documentation needed.
• Documentation included in this PR.
• [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist*

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[github-actions]

Changes to circuit sizes

Generated at commit: c503b60e62ff530d450dba8646f39f01939734d5, compared to commit: f25ebd61019e7aa44ac974a5827c7e9a3496128d

🧾 Summary (10% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
regression_7744	0 ➖	0.00%	+2 ❌	+3.45%
regression_5045	0 ➖	0.00%	+4 ❌	+0.33%
simple_bitwise	0 ➖	0.00%	-6 ✅	-0.20%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
regression_7744	8 (0)	0.00%	60 (+2)	+3.45%
regression_5045	11 (0)	0.00%	1,219 (+4)	+0.33%
simple_shield	47 (0)	0.00%	4,916 (+8)	+0.16%
embedded_curve_ops	13 (0)	0.00%	5,412 (+8)	+0.15%
pedersen_check	15 (0)	0.00%	3,176 (+4)	+0.13%
pedersen_commitment	8 (0)	0.00%	2,931 (+2)	+0.07%
bench_ecdsa_secp256k1	162 (0)	0.00%	39,331 (+5)	+0.01%
ecdsa_secp256k1	162 (0)	0.00%	39,331 (+5)	+0.01%
ecdsa_secp256k1_invalid_pub_key_in_inactive_branch	227 (0)	0.00%	39,396 (+5)	+0.01%
ecdsa_secp256r1_3x	486 (0)	0.00%	205,315 (+15)	+0.01%
ecdsa_secp256r1	162 (0)	0.00%	70,910 (+5)	+0.01%
ecdsa_secp256r1_invalid_pub_key_in_inactive_branch	227 (0)	0.00%	70,975 (+5)	+0.01%
xor	5 (0)	0.00%	3,142 (-2)	-0.06%
u128_type	205 (0)	0.00%	4,730 (-6)	-0.13%
bit_and	50 (0)	0.00%	3,016 (-4)	-0.13%
binary_operator_overloading	88 (0)	0.00%	3,294 (-6)	-0.18%
simple_bitwise	18 (0)	0.00%	2,948 (-6)	-0.20%

[github-actions]

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark 'Execution Time'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.

Benchmark suite	Current: d8ea914	Previous: 8a6ef48	Ratio
private-kernel-inner	0.019 s	0.014 s	1.36

This comment was automatically generated by workflow using github-action-benchmark.

CC: @TomAFrench

[TomAFrench]

@saleel, it looks like there's been changes to the bb CLI + bb.js. Do you know why these are now failing?

[saleel]

I can think of:

• Verification key -k is now expected to be provided to the bb prove command
• UltraHonkZK flavor is the default now in the CLI, but it was not implemented in wasm when the above release was made 😔 (so you have different proof size on cli vs js unless you add --disable-zk flags).
• KeyHash is now enforced on recursion - not sure if that was included in the above release

I would say we update to version 1.2.0 when that comes out

[asterite]

A couple of tests fail with:

Contract code size is 25518 bytes and exceeds 24576 bytes

I don't know how the size can be reduced. I tried using a newer Solidity compiler, or running more optimizations, but it led to even more code.

[TomAFrench]

We can tell hardhat to ignore the max contract size limit: https://v2.hardhat.org/hardhat-network/docs/reference#allowunlimitedcontractsize

[asterite]

Ah, I saw that but I didn't know if it was okay to bypass that restriction.

In any case now it fails with this:

Error: VM Exception while processing transaction: reverted with custom error 'ProofLengthWrong()'

I'll check if there's something that can be done...

[saleel]

Error: VM Exception while processing transaction: reverted with custom error 'ProofLengthWrong()'

@asterite Can you try changing this to keccakZK: true

ZK variant is the default in cli now iirc. keccak: true means use the non-ZK version of solidity verifier - which is what we had before (these config names needs to be improved)

[asterite]

@saleel Thanks! Is it just in that line or also a few lines below that?

• If I change only that line I get "Proof fails verification in JS"
• If I change both I get "VM Exception while processing transaction: reverted with custom error 'SumcheckFailed()'"

[saleel]

It should be both those lines.
Let me give it a try now.

[github-actions]

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark 'Test Suite Duration'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.

Benchmark suite	Current: f997c9f	Previous: f25ebd6	Ratio
test_report_zkpassport_noir-ecdsa_	3 s	2 s	1.50

This comment was automatically generated by workflow using github-action-benchmark.

CC: @TomAFrench

[asterite]

I feel like the issue is on barretenberg's side.

There are a bunch of imports like this:

import { pino } from "pino";

However, I'm seeing that recent tutorials say to import it like this:

import pino from "pino";

Maybe pino exposes both forms of imports? Not sure if that's possible. I also don't know how it would work on barretenberg's CI but not here. I wanted to try that change but ./bootstrap.sh doesn't work for me because it seems it doesn't work on Macs.

[asterite]

Or maybe not... at least that change didn't work in Aztec-Packages.

[asterite]

This seems to always fail when UltraHonkBackend is used. But it also fails if we just have this code:

let backend = UltraHonkBackend;

That is, just referring to that type will produce a failure. That's why maybe mocking pino doesn't work (though it is strange that we get a different error).

[saleel]

Yes, the error is different now. I changed the config to use the relative path rootDir: fileURLToPath(new URL('./', import.meta.url)),
and now it seems to go to a different error - "Buffer is not defined" (which is a polyfill issue, and Buffer is being used in bb.js)

Trying to polyfill that, but not sure how it was working until now with the rootDir: fileURLToPath(new URL('./../..', import.meta.url)) path

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	@​types/​path-browserify@​1.0.3
	process@​0.11.10
	path-browserify@​1.0.1
	clsx@​1.2.1
	adm-zip@​0.4.16 ⏵ 0.5.16			+7

View full report

[asterite]

Looks great, thank you!

[TomAFrench]

Thanks for addressing this @asterite and @saleel!