research: Poseidon/Merkle constraint-contribution breakdown

[alexandre-mrt]

Summary

Nightly research loop, queue item #2 (option b): decomposes transfer.circom's 13,611 R1CS
constraints into the sum of its isolated gadgets, exactly reconciled (0 delta), to answer the open
question left at the end of the 2026-07-22 baseline report — which Poseidon calls actually dominate
constraint count.

Finding: the 20-level Merkle authentication path (MerkleProof(20), 20x Poseidon(2)) is
76.4% of transfer.circom's constraints (10,400/13,611) and 81.6% of compliance.circom's
— an order of magnitude more than the three domain-tagged commitment/nullifier/amount-hash
Poseidon(4)/Poseidon(3) calls combined (20.7%). This reprioritizes any future Poseidon2 work
toward the Merkle chain specifically, rather than the whole circuit.

Rejected actually porting to Poseidon2 tonight: circomlib 2.0.5 (this repo's dependency) ships no
Poseidon2 implementation, and hand-deriving round constants for a soundness-critical permutation in
one night, with no reference test vectors, was judged too risky — exactly the kind of "invented
benchmark" the loop is supposed to avoid.

Also re-attempted queue item #1 (on-chain gas, still blocked): confirmed the fullnode JSON-RPC path
is a hard sandbox network-policy block, but found git clone + cargo build for the sui CLI do
work here (unlike the 2026-07-22 "impractical" assessment) — left a background build running past
the session's budget and documented a procedural fix for the next run that picks it up.

Verdict: KEEP. BASELINE.md updated with the new decomposition.

Full report: docs/research/2026-08-17-poseidon-merkle-constraint-breakdown.md

What changed

• scripts/bench/poseidon-constraint-breakdown.mjs — new reusable benchmark: compiles standalone
  Poseidon(2)/(3)/(4), MerkleProof(20), and range-check-scaffolding circuits and tabulates their
  R1CS constraint counts against the real transfer.circom total.
• docs/research/2026-08-17-poseidon-merkle-constraint-breakdown.md — the full writeup (hypothesis,
  threat/privacy model, approach + rejected alternatives, raw command output, verdict, where this
  generalizes, open questions).
• docs/research/BASELINE.md — new "Poseidon / Merkle constraint decomposition" section; updated
  on-chain-gas row with fresh blocker evidence.
• docs/research/LEDGER.md — appended tonight's row.
• docs/research/EXPERIMENTS.md — re-ranked: added a cheap compliance.circom full-reconciliation
  item and narrowed the Poseidon2 item to "Merkle chain specifically, gated on finding a trustworthy
  reference implementation"; updated item feat: Veil privacy payment protocol — full stack MVP #1 with the procedural fix for unblocking the sui CLI
  build.

No circuit, Move module, or frontend proving code was modified — this is a measurement/diagnostic
experiment, not a protocol change, so no soundness argument / leakage analysis / negative test is
needed (consistent with how the 2026-07-22 baseline report was scoped).

Test plan

Full suite run, all green except a pre-existing, unrelated gap:

• node --experimental-vm-modules test/transfer.test.mjs — 43/43 pass
• node --experimental-vm-modules test/compliance.test.mjs — 30/30 pass
• node --experimental-vm-modules test/withdraw.test.mjs — 35/35 pass
• cd scripts && bun run src/test-converter.ts — 109/109 pass
• cd scripts && bun run src/test-compliance-utils.ts — 67/67 pass
• cd frontend && bunx vitest run — 19/19 pass
• cd scripts && bun run src/fuzz-tests.ts — 6/6 properties pass (500 cases each)
• cd contracts && sui move test — NOT RUN, no sui CLI available in this sandbox (same
  pre-existing blocker as 2026-07-22; no contract code touched by this PR)

---

Generated by Claude Code