Dusk’s Groth16 Exporter Makes EIP-2537 the New Cross-Chain Boundary

Dusk’s zk-tools project merged a Groth16 Solidity verifier on August 14, 2026. The change is more than a contract template: it defines a practical boundary between a Rust proving stack and EVM verification.

The exporter generates a circuit-specific Solidity verifier from a Groth16 verification key. The resulting contract relies on the BLS12-381 G1 multi-scalar-multiplication and pairing precompiles specified by EIP-2537. Developers can then call verifyProof(bytes,uint256[]) from Solidity with the proof and public inputs.

The transport boundary is deliberately explicit. Dusk’s canonical Groth16 proof remains a 192-byte compressed representation, while EIP-2537 expects a 512-byte uncompressed encoding containing -A, B, and C. The project provides a Rust conversion path, but the documentation warns builders to keep the canonical proof and EVM transport separate.

Public inputs are another security boundary. They must be canonical BLS scalar-field values in the same order emitted by the Rust prover and expected by the verifier. An application should derive them from trusted state rather than accepting an arbitrary array supplied beside the proof.

For ICP and other cross-environment builders, the useful lesson is that “proof compatibility” is not a single checkbox. The circuit, verification key, proof encoding, field representation, public-input order, and destination EVM revision all have to agree. A verifier that compiles successfully can still fail on a network without the required precompiles or on a contract whose public-input count no longer matches the embedded key.

The repository includes Foundry tests for malformed proofs, incorrect public inputs, non-canonical scalars, identity elements, off-curve points, and wrong-subgroup points. That makes the release useful as an integration reference, not merely as generated Solidity.

Caveats: the verifier is circuit-specific, so any circuit-shape or trusted-setup change requires a new contract. EIP-2537 activation varies by EVM network and must be checked per deployment target. The documented Groth16 setup is single-party; MPC ceremonies are not implemented. The generator and contract have not undergone a dedicated security audit, and key provenance and setup integrity remain application responsibilities.