[Circuit DSL] Support lookup arguments (Plookup / log-derivative tables) in circuit DSL

[satran004]

Background & Objective

Standard bitwise arithmetic and non-native hashes (e.g. SHA-256, Blake2b, SHA-512, range checks) generate large numbers of R1CS constraints (~25,000+ constraints per hash invocation).

Lookup arguments (such as Plookup or log-derivative lookup tables) allow proving that a tuple of signals exists in a precomputed table using only a few constraints per lookup.

Scope & Tasks

• Research and design lookup table DSL constructs in zeroj-circuit-dsl.
• Add support for precomputed lookup tables (e.g. 8-bit XOR/AND tables, range tables).
• Support lookup verification in the PlonK / multiset permutation compiler.
• Benchmark constraint reduction for Blake2b and SHA-512 key derivation circuits.

Risk Classification

• R2: Circuit compiler & proof system expansion.
• Reference: docs/zeroj-comprehensive-review-and-readiness-gemini.md (Section 5.3).

[satran004]

Real capability gap, but the stated benefit does not apply to the circuits named, and it conflicts head-on with #43. Recommend not starting as written.

The gap is real

ZeroJ's PlonK is the vanilla snarkjs-compatible arithmetisation — five selectors, qL*a + qR*b + qO*c + qM*(a*b) + qC = 0 (PlonKConstraintSystem.java:11). No custom gates, no lookups. So lookup support genuinely does not exist.

Three problems with the issue as filed

1. The benefit does not apply to the circuits it cites. The issue motivates this with "SHA-256, Blake2b, SHA-512, range checks... ~25,000+ constraints per hash" and asks to "Benchmark constraint reduction for Blake2b and SHA-512 key derivation circuits."

Those gadgets — circuit/lib/hash/{Sha512,Blake2b,HmacSha512}.java, plus Ed25519/BIP32 from ADR-0027, and the 19M-constraint derivation circuit — live on the R1CS/Groth16 path. Plookup does not exist for R1CS/Groth16. Lookups would help only circuits already on PlonK, and the expensive ones are not.

2. It contradicts #43. Lookup arguments add at least two more commitments and extra evaluations, so the on-chain Plutus V3 verifier (PlonkBLS12381Lib) must change — and it is already at ~4.9e9 CPU, ~49% of the per-transaction budget (ADR-0024). This issue pushes that number up while #43 asks to roughly halve it. Both cannot be accepted as written.

3. It breaks the snarkjs interop oracle. snarkjs PlonK has no lookup variant, so ZeroJ would lose its main independent verification path for PlonK — at a point where #31 is still open and that oracle is not yet automated in CI.

Risk classification

R2 is too low. A new arithmetisation plus a new argument is a new proof system → R3, ADR-mandatory under CLAUDE.md. Task 1 as written ("Research and design lookup table DSL constructs") also cuts against the "do not invent cryptography" rule — pin a reference first (plookup, logUp, or Halo2's variant) rather than designing in-house.

Suggestion

Park until #43 and #31 resolve, then re-file as an R3 ADR that states which proof-system path it targets, what happens to the on-chain verifier budget, and how snarkjs interop is preserved or deliberately given up.