EZKL: Zero-Knowledge ML Proving Framework

• EZKL is a zero-knowledge machine learning proving framework that converts neural network operations into arithmetic circuits via Halo2 and Plonkish arithmetization.
• It supports generic neural network architectures by compiling models (e.g., ONNX) into circuits, enabling client-side proof generation and verification.
• However, EZKL faces high computational and memory costs, with larger proof sizes and proving times compared to Groth16-based systems.

EZKL is a zero-knowledge machine learning proving framework focusing on generic circuit construction for neural networks, particularly leveraging the Halo2 proving system and Plonkish arithmetization. It enables client-side generation of zero-knowledge proofs for model inference, allowing users to attest to the correctness of machine learning model execution on private data. Its architecture is designed for compatibility with common neural network formats such as ONNX, and it provides tooling for circuit compilation, proof generation, and verification both on-chain and off-chain.

1. Architectural Principles and Proving System

EZKL is built around the Halo2 proving system, utilizing Plonkish arithmetization. In Halo2, arbitrary arithmetic operations within neural networks (e.g., matrix multiplications, convolutions, activation functions) are compiled into a circuit in which each linear addition operation incurs a gate cost. As a result, circuit complexity in EZKL scales with the number of gates required by the computational graph: $\text{Halo2 (EZKL) Circuit Size} = \mathcal{O}(n)$ where $n$ is the total number of arithmetic operations (including both linear and nonlinear layers).

EZKL supports a wide range of neural network architectures by translating ONNX or other declarative model representations into arithmetic circuits. Each parameter and weight is typically encoded as a public signal, and all arithmetic, including multiplications, require explicit constraints within the circuit.

2. Performance Characteristics and Resource Requirements

Benchmark data shows that compared to frameworks using Groth16/R1CS arithmetizations (such as Bionetta (Zakharov et al., 8 Oct 2025)), EZKL exhibits substantially higher resource usage in several key metrics:

• Proof Size: EZKL’s proof size is approximately 15.75 times larger than Bionetta’s UltraGroth benchmarks (320 bytes for Groth16 vs. several kilobytes for EZKL).
• Verification Key Size: EZKL typically generates verification keys of hundreds of kilobytes to several megabytes (e.g., 4.2 MB for certain models), which is orders of magnitude larger than Bionetta’s 3–4 KB VK.
• Proving Time: Proving time for Halo2 circuits in EZKL is up to 373.26 times larger than Groth16-based systems, with proof generation sometimes taking several minutes to hours for complex models.
• Verification Cost: On-chain verification in EZKL requires a large constant number of pairing operations, which is 173.39× higher than the Groth16 reference, resulting in significant costs for EVM-compatible deployments.

These metrics indicate that while EZKL enables generic support for model architectures, its approach yields significantly greater computational and memory burdens during proof generation and especially during on-chain verification.

Metric	EZKL	Bionetta UltraGroth (Zakharov et al., 8 Oct 2025)
Proof Size	~5 KB+	320 bytes
VK Size	0.5MB–4MB	3–4 KB
Proving Time	Minutes–Hours	Sub-second–Seconds
On-chain Pairings	Large constant	4

3. Circuit Compilation and Setup

EZKL compiles circuits dynamically from generic neural network graphs (e.g., ONNX), supporting arbitrary architectures but incurring higher per-constraint costs. It does not hardcode weights as circuit constants; instead, weights are mapped as public signals, and every matrix operation is translated into individual gates. This design decision allows EZKL to flexibly support a wide variety of models but results in higher circuit sizes:

• Proving Key Size: Circuit sizes and corresponding keys can require hundreds of gigabytes of RAM to generate and produce multi-megabyte verification keys.
• Trusted Setup: The trusted setup process is required to generate parameters for proving and verification. While less expensive than circuit embedding approaches for simple models, for large or deep neural networks the setup costs become substantial.

A plausible implication is that users deploying EZKL at scale must carefully manage RAM and storage requirements, especially when working with complex or large models destined for on-chain verification.

4. Deployment Strategies and EVM Integration

EZKL supports both off-chain and on-chain verification scenarios, but its large proof sizes and verification keys significantly impact Ethereum Virtual Machine (EVM) compatibility. In the context of smart contract verification:

• Verification keys of several hundred kilobytes to megabytes challenge the block gas and storage limits of EVM.
• Proof verification time, dominated by the number of required pairing operations proportional to circuit complexity, results in nontrivial gas consumption.

This suggests that, while EZKL is well suited for off-chain audits, batch verification systems, or research prototyping, its deployment on the EVM for low-latency, cost-sensitive applications is less practical than protocols with Groth16-based optimizations (Zakharov et al., 8 Oct 2025).

5. Supported Applications and Use Cases

EZKL is designed for generic, client-side zero-knowledge machine learning proving across a diversity of use cases. Its compatibility with standard neural network graph descriptions (especially ONNX) enables support for:

• Flexible model architectures (CNNs, RNNs, transformers) in inference proofs.
• Off-chain verification for privacy-preserving audits, data sovereignty, and regulatory compliance scenarios.
• Proofs for model correctness that preserve client privacy, permitting applications in private biometric inference, confidential data analysis, and decentralized access control.

However, for use cases where the model weights are fixed and public, and where on-chain verification cost is critical (e.g., identity proofs, biometric liveness attestation), Groth16-based frameworks with circuit-embedded weights (such as Bionetta) provide superior performance and lower resource utilization.

6. Comparison with Bionetta and zkML Frameworks

Benchmarking against Bionetta’s UltraGroth variant (Zakharov et al., 8 Oct 2025), EZKL exhibits distinct trade-offs:

• Flexibility vs. Efficiency: EZKL’s support for generic architectures contrasts with Bionetta’s efficiency in models with constant, embedded weights.
• Performance: Bionetta achieves sub-second proving times on commodity hardware (including mobile devices), while EZKL may require minutes to hours for similar models.
• On-Chain Usability: Bionetta’s small, constant-sized proofs and verification keys (320 bytes and 3–4 KB) are explicitly optimized for EVM on-chain deployments, requiring only four pairing operations. EZKL’s large proofs and verification keys, and the significantly higher verification cost, limit its suitability for on-chain smart contracts.
• Trusted Setup Costs: EZKL may involve lower initial setup costs for small models but, for large-scale circuits, the RAM and time requirements escalate dramatically.

A plausible implication is that, for high-assurance, low-latency, and cost-sensitive deployments in cryptographically constrained environments, circuit-optimized frameworks should be preferred, while EZKL’s flexibility benefits prototyping, diverse architecture support, and off-chain auditability.

7. Technical Challenges and Ongoing Research Directions

EZKL’s design exposes several research challenges relevant to zero-knowledge ML proving:

• Optimization of Halo2 circuit size and gate cost to improve proving and verification efficiency.
• Strategies for maintaining modular model compatibility (e.g., ONNX import) while minimizing resource requirements.
• Exploration of hybrid approaches, such as partial circuit embedding of weights or activation-specific optimizations.
• Addressing EVM deployment constraints for large-scale verification keys and proof objects.

These directions reflect broader activity in the zkML space, seeking to balance model-general compatibility, privacy, and cost-effective on-chain or decentralized verification. The trade-off between generic circuit support and optimal cryptographic efficiency remains a critical topic for future work.