research: poseidon-constraint-attribution

[alexandre-mrt]

Summary

Nightly research loop, 2026-08-30. Two parts:

• Re-verified queue item feat: Veil privacy payment protocol — full stack MVP #1 (on-chain gas) and confirmed it's now structurally blocked, not a toolchain gap: this session's GitHub access is scoped to alexandre-mrt/veil only (blocks sui CLI release binaries), and direct JSON-RPC to six different Sui fullnode providers all get an identical network-policy connect_rejected/403. Needs a human to grant GitHub access to MystenLabs/sui or add a network-policy exception — no in-session workaround exists. Re-ranked in EXPERIMENTS.md with this noted so future nights don't re-spend a night on it.

• Measured Poseidon's exact share of each circuit's constraint budget (scripts/bench/constraint-breakdown.mjs): compiled every named gadget (Poseidon(2/3/4/5), range checks, comparators, the whole MerkleProof(20) template) in isolation via circom2, and reconciled the sum against a fresh full-circuit compile — exact to within 0–3 constraints for all three circuits.

  Circuit	Non-linear constraints	Poseidon share
  transfer.circom	6,470	93.1%
  compliance.circom	6,057	94.3%
  withdraw.circom	1,465	78.0%

  This bounds what a future Poseidon2 port could ever save. The port itself is PARKed — no verified Poseidon2 .circom gadget is reachable from this session (same GitHub-scoping root cause as item feat: Veil privacy payment protocol — full stack MVP #1); writing one from memory was rejected as unverified crypto rather than measured.

• Added circom2 (npm-distributed circom 2.2.3, WASM) as a circuits/ devDependency — a GitHub-independent reproduction path that reproduces the 2026-07-22 baseline bit-for-bit, since the original from-source cargo build against a cloned iden3/circom no longer works in every environment this loop runs in.

Full report: docs/research/2026-08-30-poseidon-constraint-attribution.md. Ledger, experiment queue, and BASELINE.md all updated.

Test plan

• node --experimental-vm-modules test/{transfer,compliance,withdraw}.test.mjs — 108/108 pass (real Groth16 proofs, freshly compiled with circom2)
• cd scripts && bun run src/test-converter.ts — 109/109 pass
• cd scripts && bun run src/test-compliance-utils.ts — 67/67 pass
• cd scripts && bun run src/fuzz-tests.ts — 6/6 properties × 500 cases pass
• cd frontend && bunx vitest run — 19/19 pass
• cd contracts && sui move test — NOT RUN, same pre-existing blocker as 2026-07-22 (no sui CLI available this session)
• node scripts/bench/constraint-breakdown.mjs — reproduces the per-gadget table and reconciliation in the report

No circuit, Move module, or frontend proving code was changed — this is a measurement-only night.

---

Generated by Claude Code

[alexandre-mrt]

CI on this PR: Move contracts and Circom circuits pass. Proof converter + compliance utils and Frontend fail — but not because of anything in this diff.

Both fail identically, at the very first step, before any checkout of test code:

##[error]Unable to resolve action `oven-sh/setup-bun@735343b667d3e6f658f44e0a462d63b48e3324cb`, unable to find version `735343b667d3e6f658f44e0a462d63b48e3324cb`

That pin is in .github/workflows/ci.yml on main, unchanged by this PR. Checking CI history on main: every run back to at least 2026-05-16 (run #10 through the latest push, #63) has conclusion: failure — this job has never been green, on any commit, for months. This is a pre-existing base-branch failure, not something this PR introduced or can fix from its own diff (this PR doesn't touch .github/workflows/, and widening it to fix unrelated CI infra isn't in scope for a measurement-only research PR).

Proposed patch, for whoever picks this up: the pinned commit SHA for oven-sh/setup-bun no longer resolves (likely history was rewritten/retagged upstream). Repointing both occurrences in .github/workflows/ci.yml (script-tests and frontend-tests jobs) to a currently-resolvable ref — either a fresh pinned SHA for a current setup-bun release, or the moving oven-sh/setup-bun@v2 tag if a SHA pin isn't a hard requirement here — should unblock it. I can't independently verify a current SHA from this session (GitHub API access here is scoped to alexandre-mrt/veil only, so api.github.com/repos/oven-sh/setup-bun/... 403s), so I'm flagging the fix rather than pushing a guess.

Not blocking this PR's own changes (measurement scripts + docs; Move and Circom circuits — the two jobs that actually exercise anything this diff touches — are green), but worth a follow-up since it's silently red on every PR and every push to main.

---

Generated by Claude Code