feat: migrate bb-prover from direct binary execution to bb.js API

[charlielye]

Summary

• Migrate bb-prover server-side proving and verification from spawning bb binary via child_process.spawn() to using the bb.js TypeScript API (Barretenberg class via NativeUnixSocket backend)
• Eliminates temporary file I/O (writing/reading bytecode, witnesses, proofs, VKs to disk) and stdout-based result parsing. A fresh bb process is still spawned per proof to maintain parallelism, but communication happens via Unix socket instead of files.
• Add new BBJsInstance / BBJsProverFactory adapter layer in bb_js_backend.ts
• Add chonk sub-proof size constants to enable TypeScript-side flat-to-structured proof splitting for chonkVerify
• Remove 6 dead functions from execute.ts (-415 lines)
• AVM proving/verification remains file-based (no bb.js equivalent exists)

What was migrated

Operation	Before	After
UltraHonk proving	bb prove via spawn	api.circuitProve() via bb.js
UltraHonk verification	bb verify via spawn	api.circuitVerify() via bb.js
Chonk (IVC) verification	bb verify --scheme chonk via spawn + temp files	api.chonkVerify() via bb.js
Gate counting	capability added to BBJsInstance	api.circuitStats() / api.chonkStats()
Solidity contract gen	capability added to BBJsInstance	api.circuitWriteSolidityVerifier()

Chonk verification migration detail

The bb.js chonkVerify API expects a structured ChonkProof (with megaProof, goblinProof.mergeProof, etc.), but bb-prover stores proofs as a flat Fr[] array. The C++ code uses compile-time constants to split the flat representation. We added these constants to Noir/TS (CHONK_MEGA_ZK_PROOF_LENGTH_WITHOUT_PUB_INPUTS=407, CHONK_MERGE_PROOF_LENGTH=42, CHONK_ECCVM_PROOF_LENGTH=608, CHONK_TRANSLATOR_PROOF_LENGTH=483) and implemented splitChonkProofToStructured() mirroring C++ ChonkProof::from_field_elements().

Test plan

• Chonk integration tests (8/8 passed)
• Rollup IVC integration tests (1/1 passed)
• E2E block building tests (18/18 passed, 1 skipped)

🤖 Generated with Claude Code

[fcarreiro]

Hey Charlie, this looks nice, just one comment for the AVM. We regularly use the following flow for all kinds of debugging, testing, benchmarking and iterating: we run some test (e.g., the avm bulk test). This test writes the avm inputs file and outputs the exact bb-avm command that you'd need to run. After that, we can just use that command (and that file) and operate 100% on the CLI/C++ side. We can then easily change the passed environment variables, concurrency, etc. IIUC, these changes would break that because the files wouldn't be written?

[charlielye]

Hey Charlie, this looks nice, just one comment for the AVM. We regularly use the following flow for all kinds of debugging, testing, benchmarking and iterating: we run some test (e.g., the avm bulk test). This test writes the avm inputs file and outputs the exact bb-avm command that you'd need to run. After that, we can just use that command (and that file) and operate 100% on the CLI/C++ side. We can then easily change the passed environment variables, concurrency, etc. IIUC, these changes would break that because the files wouldn't be written?

Hey. Yep I was aware this might affect some debug flows. This is all vibe coded btw. Right now I think the AVM path is unaffected as there is no bb.js api for avm proving/verifying. But I was aware this might affect debug flows for the protocol circuits etc. I might make bb.js support avm stuff in future. But in either case, we want to maintain these kinds of useful reproducible flows. It still feels like this should be the responsiblity of bb.js, so I thought to either:

• have another backend in bb.js that would maintain this CLI driven workflows. Selectable when you init the Barretenberg class (currently we support nativeshm, nativeuds, wasm, wasm-threads, etc).
• Have a wrapper that could sit around any backend api, and would do a debug dump of the data in the right formats for the cli + print cli command.

Not sure if you have thoughts one way or other? But as I say, right now I think avm path is unaffected (but have not reviewed Claudes work yet).