[charlielye]

Stacked on #25362. It needs that PR's ipc-runtime server in bb and ipc-runtime client in bb.js.

Why

aztec-node's p2p batch verifier gets each proof's verdict over a side channel: a named pipe (FIFO) that bb writes results to. It does this because bb's msgpack server reads a request, runs it, and replies before reading the next one. A call that waited for its batch would stop more proofs arriving, so batching would never happen.

The side channel brings a lot with it on the TS side:

• a request-id map;
• a startup probe to make bb open the FIFO (bb opens it lazily on its first write, and until then its death goes unseen);
• an in-flight cap matched to bb's queue size;
• inferring from FAILED results whether bb actually judged a proof.

aztec-labs-eng/aztec-node#359 has the details.

What

• bb msgpack run --reactor. bb serves with ipc-runtime's run_reactor instead of run(). Handlers still run one at a time, in arrival order, on the reactor thread, so session state needs no locking. A handler may now respond after it returns, from another thread, and responses go out as they complete, matched by request id. Without the flag nothing changes. The flag is opt-in because the reactor copies each request and wakes across threads.
• ChonkBatchVerifierVerify {vk_index, proof_fields} → {verified, time_in_verify_ms}.
  • Needs a batch verifier started without a FIFO (empty fifo_path).
  • Queues the proof and responds with its verdict once checked. verified: false means bb judged the proof: too short to split, wrong size, or failed the check (off-curve commitments included).
  • Everything else is an error response, not a verdict: an unregistered vk_index, the service not running, or the service stopping before the proof is checked.
  • When the queue is full, bb waits for room instead of refusing, so a caller needs no cap of its own and the wait reaches it as backpressure.
  • Without --reactor the command is refused, rather than stalling the server.
  • The FIFO commands are unchanged. A service started with a FIFO refuses Verify, and one started without refuses Queue.
• Stopping. ChonkBatchVerifierStop, or the server shutting down via run_reactor's new on_stop hook, answers proofs still queued as unchecked errors and only finishes the batch in progress. Otherwise it would verify the whole queue for callers that may be gone.
• ipc-runtime run_reactor.
  • New on_stop hook.
  • A handler or send() that throws now stops serving cleanly instead of unwinding past responders still in flight (use-after-free). A request whose handler threw without responding is released, so shutdown doesn't wait for it forever.
  • notify() now runs before the in-flight decrement, so a cross-thread responder can't touch a server that has just been destroyed.
• bb.js. A reactor option on the NativeUnixSocket backend passes --reactor. Other backends refuse it.

After a bb release with this, aztec-node's BatchChonkVerifier becomes await bb.chonkBatchVerifierVerify(...) per proof. The FIFO, the probe, the request-id map and the in-flight bookkeeping all go away.

Not done

• bb-internal failures during a batch check (e.g. an allocation failure in reduce, or an exception swallowed by batch_check and then bisected) still read as verified: false. That's the same as the FIFO path today. Separating them means telling proof-derived exceptions from bb's own inside the verifier.
• Each pending proof is held twice: the decoded proof in the queue, and the request bytes run_reactor keeps until it responds.
• reactor isn't wired into the shared-memory backends.

Testing

• api_msgpack_reactor.test.cpp: end to end over a real Unix socket through serve_msgpack_reactor, with real (small) Chonk proofs.
  • Five proofs are pipelined, one of them tampered, followed by a Poseidon hash. The hash comes back first, and each proof gets its own verdict.
  • An unregistered key gets an error.
  • With one proof per batch, a stop answers the queued proofs as errors and the rest as verified.
  • The last two failed with their fixes disabled and pass with them.
• bbapi_chonk_batch_verify.test.cpp: through the generated dispatch: verdicts for good, tampered and malformed proofs; refusal without --reactor; the two modes refuse each other's command.
• socket.test.cpp: a reactor handler that throws without responding stops the server, runs on_stop, still sends the deferred response, and returns. Before the change it crashed the process.
• bb.js batch_verifier_verify.test.ts, against the built bb: several calls in flight on one connection, the verdict-vs-error split, and refusal without --reactor.
• Regression: ipc_runtime_tests 32/32, ChonkBatchVerifierTests 12/12, bbapi_tests 43/43 (excluding ChonkPinnedIvcInputsTest, which needs downloaded pinned flows), bb.js tsc (node and browser) and eslint clean.

🤖 Generated with Claude Code