PaperlayerView exact revision on arXiv

Source-linked AI summary

A Survey of Zero-Knowledge Proof Based Verifiable Machine Learning

Zhizhi Peng, Chonghe Zhao, Taotao Wang, Guofu Liao, Zibin Lin, Yifeng Liu, Bin Cao, Long Shi, Qing Yang, Shengli Zhang

arXiv:2502.18535v2cs.CRcs.AIcs.LG

TL;DR

ZKML aims to establish computational integrity and privacy, while practical systems face limits in circuit generality and proving efficiency. This survey reviews ZKML foundations, systems, bottlenecks, commercial efforts, and hybrid designs. It finds the field moving beyond proof-of-concept demonstrations toward more general, efficient, and deployable systems, though substantial challenges remain.

  • Problem

    ZKML must establish computational integrity and privacy, but common ML operators do not directly fit many proof-friendly finite-field circuits and large models incur high proving and memory costs.

    Source: §I · p. 1, C. Implementation Improvements in ZKML · p. 17

  • Method

    The survey reviews ZKML foundations, representative systems, implementation bottlenecks, commercial efforts, and hybrid cryptographic designs.

    Source: §VII · p. 21

  • Results

    ZKML is moving from proof-of-concept demonstrations toward more general, efficient, and practically deployable systems.

    Source: §VII · p. 21

  • Takeaways & Limitations

    The survey provides a reference for researchers and practitioners working toward trustworthy, privacy-preserving, and verifiable machine learning services.

    Source: §VII · p. 21

    Substantial challenges remain in scalability, model coverage, privacy across the full ML lifecycle, and data authenticity.

    Source: §VII · p. 21

Abstract

from arXiv · show

Machine learning is increasingly deployed through outsourced and cloud-based pipelines, which improve accessibility but also raise concerns about computational integrity, data privacy, and model confidentiality. Zero-knowledge proofs (ZKPs) provide a compelling foundation for verifiable machine learning because they allow one party to certify that a training, testing, or inference result was produced by the claimed computation without revealing sensitive data or proprietary model parameters. Despite rapid progress in zero-knowledge machine learning (ZKML), the literature remains fragmented across different cryptographic settings, ML tasks, and system objectives. This survey presents a comprehensive review of ZKML research published from June 2017 to August 2025. We first introduce the basic ZKP formulations underlying ZKML and organize existing studies into three core tasks: verifiable training, verifiable testing, and verifiable inference. We then synthesize representative systems, compare their design choices, and analyze the main implementation bottlenecks, including limited circuit expressiveness, high proving cost, and deployment complexity. In addition, we summarize major techniques for improving generality and efficiency, review emerging commercial efforts, and discuss promising future directions. By consolidating the design space of ZKML, this survey aims to provide a structured reference for researchers and practitioners working on trustworthy and privacy-preserving machine learning.

I. INTRODUCTION

Outsourced ML makes computation integrity, client privacy, and model confidentiality central concerns; ZKPs can verify claimed computations without disclosing private inputs or model parameters. This survey addresses fragmented prior coverage with a review of ZKML research, its technical trade-offs, and its path toward deployment.

I. INTRODUCTION

  • Outsourced MLaaS raises intertwined concerns: clients may expose sensitive data, providers may reveal model details, and clients need assurance that declared computations produced the results.These concerns arise as clients outsource training, testing, or inference to providers hosting models, hardware, or data-processing pipelines.Source: §I · p. 1
  • ZKPs let parties verify claims about outsourced ML computations while keeping sensitive data and proprietary model parameters undisclosed.Claims can concern a prediction from a committed model and input, or updated parameters from a declared training procedure.Source: §I · p. 1

A. Illustrative ZKML Inference Workflow

  • In the inference workflow, the client’s input and the provider’s prediction are public to verification, while model parameters remain in the private witness.The provider supplies a proof that the prediction is consistent with its model execution; the client verifies the proof.Source: Figure 1 · p. 2, A. Illustrative ZKML Inference Workflow · p. 2

B. Positioning Against Existing Surveys

  • Earlier surveys cover narrower slices of ZKML, leaving a need for an up-to-date review spanning research categories, technical evolution, implementation bottlenecks, commercial deployment, and hybrid cryptography.Prior coverage includes inference benchmarking, a smaller set of early systems, decentralized ML through June 2023, and practical frameworks [10].Source: B. Positioning Against Existing Surveys · p. 2

C. Contributions

  • The survey systematically covers studies from June 2017 to August 2025 and analyzes 27 representative works, technical trade-offs, commercial applications, and open problems.Its stated directions include computational optimization, model support, privacy enhancement, and scenario expansion.Source: C. Contributions · p. 2

II. BACKGROUND

The survey uses supervised learning as its default setting and deep neural networks as its default model, reflecting the focus of most existing ZKML work. It frames learning as fitting model parameters to data so predictions approximate a target mapping.

II. BACKGROUND

  • The background establishes machine learning and zero-knowledge foundations, defines verifiable ML categories, and compares ZKPs with other security techniques.The survey adopts supervised learning as the default because most existing ZKML systems address supervised training, testing, or inference.Source: §II · p. 3, A. Machine Learning · p. 3

A. Machine Learning

  • In supervised learning, a model f_θ maps inputs to labels, and training minimizes empirical loss over labeled training data to obtain parameters θ.After training, the model predicts ŷ = f_θ(x) for a new input.Source: A. Machine Learning · p. 3
  • The survey defaults to deep neural networks because of their popularity and effectiveness and because nearly all existing ZKML work focuses on them.The model parameters θ include network weights and biases.Source: A. Machine Learning · p. 3

B. Zero-Knowledge Proof

A ZKP proves a statement’s validity without revealing information beyond that validity, typically by encoding the statement as an arithmetic circuit. In verifiable ML, the provider proves execution for a declared task while the client checks the result without access to the private witness.

B. Zero-Knowledge Proof

  • A zero-knowledge proof lets a prover convince a verifier that a statement is true without revealing information beyond its validity.Representative proof families include zk-SNARKs, zk-STARKs, and related constructions.Source: B. Zero-Knowledge Proof · p. 4
  • Many ZKP systems encode statements as arithmetic circuits, where public inputs and a private witness satisfy a circuit relation that defines the statement being proven.The ZKP components are key generation, proof generation, and verification; the witness remains hidden while being proven known.Source: B. Zero-Knowledge Proof · p. 4
  • ZKP systems suit different circuit structures: R1CS-based zk-SNARKs fit arithmetic circuits, while sum-check- or GKR-style systems often suit layered neural-network computations.The survey notes that many neural-network verification systems use sum-check- or GKR-style frameworks for efficiency.Source: B. Zero-Knowledge Proof · p. 4
  • Verification is usually much cheaper than proving and does not require the private witness, allowing clients to check outsourced results while sensitive data or parameters remain hidden.Hidden information may include model parameters, training data, or internal intermediate states.Source: B. Zero-Knowledge Proof · p. 4

C. Verifiable Machine Learning

  • Verifiable ML certifies outsourced work against a declared dataset, model, and procedure across training, testing, and inference.Training certifies parameter updates, testing certifies metrics on the declared test setting, and inference certifies that a prediction matches the model on the declared input.Source: C. Verifiable Machine Learning · p. 4

D. Comparison of Security Techniques for Verifiable Machine Learning

Privacy and security techniques offer different guarantees, and none of the listed alternatives alone combines privacy preservation with succinct public verifiability as ZKPs do. The survey presents ZKPs as complementary to other techniques and reviews hybrid designs.

D. Comparison of Security Techniques for Verifiable Machine Learning

  • Differential privacy protects individual records with calibrated noise, but the noise may reduce utility and DP alone cannot prove its budget or computation was enforced.Source: D. Comparison of Security Techniques… · pp. 4–5
  • Homomorphic encryption supports computation on encrypted data, but ciphertext expansion, noise management, and costly operations add overhead, and HE alone does not verify correct execution.Source: D. Comparison of Security Techniques… · p. 5
  • Federated learning keeps raw data local, but it does not inherently prevent poisoned updates or prove that aggregation and local training were executed correctly [22].Source: D. Comparison of Security Techniques… · p. 5
  • Trusted execution environments can run complex programs with low overhead, but users must trust the hardware and platform, and security can be weakened by side channels or implementation vulnerabilities.Remote attestation is not equivalent to a succinct public proof of each computation step.Source: D. Comparison of Security Techniques… · p. 5
  • Secure multiparty computation hides private inputs during joint computation, but communication, interaction, and implementation costs challenge large-scale ML, while guarantees are usually not succinctly third-party verifiable.Source: D. Comparison of Security Techniques… · p. 5
  • ZKPs directly address computational verifiability while protecting private witnesses, making them complementary to HE, FL, DP, or TEE in systems seeking stronger end-to-end guarantees.Source: D. Comparison of Security Techniques… · p. 5

III. ZKML RESEARCH LANDSCAPE

  • The survey organizes its research-landscape review around system workflow, studies of training, testing, and inference, and implementation challenges and improvements.Source: §III · p. 5

A. ZKML Overview

ZKML uses cryptographic proofs to let a verifier check outsourced ML computations in a trustless setting. The overview frames training and testing as circuits that check committed data or models and produce verifiable outputs.

A. ZKML Overview

  • ZKPs let a prover demonstrate a statement's validity without revealing information beyond that validity, supporting integrity and privacy in outsourced ML.Dishonest providers might use incorrect data, skip computation, or fabricate results.Source: A. ZKML Overview · p. 5
  • A prover executes the agreed ML task and returns a result with a proof; the verifier checks it against the public input and accepts or rejects.The parties agree on the task, circuit, and public information, and the verifier commits to relevant data or model state.Source: A. ZKML Overview · p. 5
  • ZKP statements are encoded as arithmetic circuits that process public inputs and private witnesses, with circuit configurations varying across training, testing, and inference.The overview identifies circuit input, logic, and output as the three components.Source: A. ZKML Overview · p. 6
  • Training circuits commit to private training features and labels, check the loss threshold, and output an updated-model commitment with a validity outcome.If loss remains above the threshold, the circuit computes gradients and updates model parameters; otherwise, training halts.Source: A. ZKML Overview · p. 6
  • Testing circuits use the declared test set and performance threshold to verify a metric computed from a committed model whose parameters remain private.The circuit checks the parameter commitment, evaluates the model on test inputs, and outputs the metric and proof.Source: A. ZKML Overview · pp. 6–7

3) ZKP-based Verifiable Inference:

The survey describes inference circuits that verify predictions from committed models while keeping parameters private, then reviews systems across ZKML tasks. Its training examples use different circuit and proof strategies, with reported efficiency results for deep-network training and LLM fine-tuning.

3) ZKP-based Verifiable Inference:

  • Inference circuits check the model-parameter commitment, apply the committed model to public input x, and output a prediction and proof without revealing θ.The survey classifies representative studies by verification objective and reports efficiency metrics in separate training, testing, and inference tables.Source: 3) ZKP-based Verifiable Inference · p. 7, B. Representative ZKML Studies · p. 9

1) ZKP-based Verifiable Training:

  • VeriML commits to selected training-iteration inputs and outputs for retrieval on request, and supports six model types.Its computational overhead is reported to be dominated by batch size and to increase linearly with it.Source: 1) ZKP-based Verifiable Training · p. 9
  • Hydra [45] partitions neural-network circuits by depth, streams subcircuit proofs for overlapping proving and verification, and uses interactive layerwise quantization.The generated subcircuit proofs are aggregated into a final proof.Source: 1) ZKP-based Verifiable Training · p. 9
  • zkMLaaS [27] uses client-selected random sampling of committed intermediate weights in a two-round challenge-response protocol to generate training proofs.The survey says its approach reduces proof-generation time while ensuring verifiable training integrity.Source: 1) ZKP-based Verifiable Training · p. 9
  • zkDL reports completing full forward and backward propagation for training networks with 10 million parameters within tens of seconds.Its FAC4DNN design flattens circuit depth by O(N), while zkReLU converts ReLU computations into an equivalent linear form using auxiliary inputs.Source: 1) ZKP-based Verifiable Training · p. 9
  • zkPoT [29] separates arithmetic and non-arithmetic training computations so proof size scales with training samples rather than feature dimension.It also streams data from auxiliary memory instead of keeping the full computation trace in RAM.Source: 1) ZKP-based Verifiable Training · pp. 9–10
  • Kaizen extends proof-of-training from simple models to DNNs using optimized per-iteration proofs and recursive composition across gradient-descent iterations.Its sumcheck-based construction targets gradient updates, while polynomial commitments help produce compact proofs over long training trajectories.Source: 1) ZKP-based Verifiable Training · p. 10
  • Below 600 seconds per sample for proving, below 4 seconds for verification, and below 80GB peak GPU memory are reported for VeriLoRA.The system covers forward and backward propagation and LoRA updates for OPT and LLaMA-family models from 3B to 13B parameters.Source: 1) ZKP-based Verifiable Training · p. 10

2) ZKP-based Verifiable Testing:

These works develop proofs for verifiable machine-learning testing and inference, including decision trees, CNNs, and large Transformers, using specialized circuits, lookup arguments, hybrid designs, and proving and system optimizations. They report reduced proving or verification costs and succinct proofs, while noting commitment-checking bottlenecks for larger models and datasets and a limitation to quantized inference for zkGPT.

ZKP-based Verifiable Testing

  • For a 23-level, 1029-node decision tree and 5000 test samples, zkDT proves accuracy in 250 seconds with a 287 KB proof and 15.6-second verification.It reduces inference-circuit size to O(d + h) and validates shared path nodes across samples in one step rather than individually.Source: 2) ZKP-based Verifiable Testing · pp. 10–11
  • Matrix-lookup methods [52] encode decision trees as committed matrices and prove reached-leaf membership, removing tree-size dependence from the prover’s asymptotic complexity.Privacy-preserving lookups can protect both the queried substructure and underlying table; batched statements handle multiple reached leaves through a committed matrix of rows.Source: 2) ZKP-based Verifiable Testing · p. 11
  • pvCNN combines homomorphic encryption, collaborative inference, and zk-SNARKs, using QMPs to encode convolutions and aggregate proofs across test instances.Splitting the model into private and public components enables encrypted partial execution; relative to earlier QAP-based approaches, pvCNN reduces setup and proving cost for CNN testing.Source: 2) ZKP-based Verifiable Testing · pp. 11–12
  • ZEN offers ZENacc for accuracy proofs and ZENinfer for individual inference proofs, using quantization and stranded encoding to reduce neural-operator R1CS cost while preserving accuracy.The survey presents it as an early optimizing compiler for verifiable neural networks, moving from hand-crafted circuits toward compiler-assisted development.Source: 2) ZKP-based Verifiable Testing · p. 12
  • For VGG16, zkCNN [35] generates proofs in 88.3 seconds, 1264 times faster than existing schemes, with a 341-kilobyte proof and 59.3-millisecond verification.Its two-dimensional convolution sumcheck and FFT protocol provide efficient proving, and the scheme also supports proving accuracy on 20 images.Source: 2) ZKP-based Verifiable Testing · p. 12
  • Apollo and Artemis [36] reduce commitment-checking burden in commit-and-prove SNARKs, a cost that can dominate testing or inference proofs on larger models and datasets.Apollo targets KZG settings with white-box access; Artemis supports generic homomorphic polynomial commitments with black-box access and is compatible with IPA- and Halo2-style settings without trusted setup.Source: 2) ZKP-based Verifiable Testing · p. 12

Verifiable inference

  • zkGPT combines grouped multilinear evaluation and precomputation for matrix multiplication, result-as-witness proofs for nonlinear and normalization operators, and constraint fusion and circuit squeezing.These optimizations reduce range-check overhead and increase parallelism.Source: 2) ZKP-based Verifiable Testing · p. 17
  • About 101 KB proofs and under 25 seconds of end-to-end GPT-2 proving time demonstrate zkGPT’s performance for Transformer-scale inference.The system produces succinct Fiat–Shamir proofs.Source: 2) ZKP-based Verifiable Testing · p. 17
  • zkGPT currently supports inference under quantized arithmetic but not verifiable training or long multi-token generation.The work presents Transformer-scale inference as closer to practical ZKML deployment.Source: 2) ZKP-based Verifiable Testing · p. 17

C. Implementation Improvements in ZKML

ZKML implementation remains difficult because common ML operations do not align naturally with finite-field proof systems, and modern models create costly circuits. The literature addresses these challenges through generality and efficiency improvements.

C. Implementation Improvements in ZKML

  • The survey groups responses to these bottlenecks into improving generality and efficiency, alongside related system-level optimizations.These directions are summarized in Fig. 7.Source: C. Implementation Improvements in ZKML · p. 17
  • Finite-field arithmetic circuits do not directly represent common floating-point, nonlinear, and comparison-based ML operations, so adaptations often require custom arithmetization.ReLU, for example, needs auxiliary binary variables, polynomial approximation, or operator-specific gadgets.Source: C. Implementation Improvements in ZKML · p. 17
  • Even after arithmetization, modern models can produce enormous circuits, driving high proving time, large commitment and key material, and memory pressure.A naive zk-SNARK treatment of VGG16-scale inference would be impractical because of circuit size and prover cost.Source: C. Implementation Improvements in ZKML · p. 17

1) Improving Generality:

Generality improvements bridge real-valued ML computation and finite-field proof arithmetic. The surveyed approaches range from task-specific quantization and operator adaptations to reusable conversion and arithmetization primitives.

1) Improving Generality:

  • Quantization maps real-valued inputs, activations, and parameters to integers, but bit width trades overflow risk and quantization error against circuit size and proving cost.Too few bits raise the first pair of risks; too many bits inflate the latter pair.Source: 1) Improving Generality · p. 17
  • Early systems use task-specific quantization, including global rescaling in SafetyNets [46], power-of-two scaling in VeriML, and affine quantization in zkCNN.The Halo2-based MobileNet v2 implementation in [47] uses low-bit parameters; these approaches remain coupled to particular proof frameworks and model families.Source: 1) Improving Generality · p. 17
  • The taxonomy separates improvement goals—generality, efficiency, and system-level directions—and further distinguishes verification tasks and inference privacy settings.Inference work is divided into public-input/private-output and private-input/private-output scenarios.Source: Figure 7 · p. 18
  • Reusable primitives broaden proof-friendly representations: Mystique supplies value and commitment conversions, while ZEN optimizes floating-point model compilation and MSCProof composes verifiable evaluation components.The Halo2-based system in [47] also uses custom gates and lookup arguments for ImageNet-scale MobileNet v2.Source: 1) Improving Generality · p. 18
  • Nonlinear operators are handled through restrictions, approximations, bit decomposition, matrix forms, specialized protocols, or advice-based verification across surveyed systems.SafetyNets restricts activations and pooling; zkGPT verifies certain operator outputs through inverse relations with range and lookup checks.Source: 1) Improving Generality · pp. 18–19

2) Improving Efficiency:

Efficiency work reduces proving and system overhead by reformulating operators, exploiting model structure, and changing proof representations or composition. The surveyed approaches span CNNs, language models, decision trees, and training pipelines.

2) Improving Efficiency:

  • zkCNN uses FFT-aware GKR protocols for two-dimensional convolutions with prover complexity O(n^2), while Fan et al. recast operators as matrix computations and use Freivalds’ algorithm.Related work reduces circuit complexity through separable convolutions, approximate activations, adaptive pooling, and modular components linked by hash-based integrity checks.Source: 2) Improving Efficiency · p. 19
  • Alternative convolution proof representations include vCNN’s quadratic polynomial programs and pvCNN’s quadratic matrix programs, while zkLLM and VeriLoRA use lookup-based approaches for tensor operations and LoRA finetuning.pvCNN also enables proof aggregation across repeated CNN layers.Source: 2) Improving Efficiency · p. 19
  • Decision-tree systems reduce path, commitment, or leaf-verification costs through sibling information, improved tree encodings, and matrix lookup arguments.These approaches make proving time less sensitive to tree size and improve verification performance.Source: 2) Improving Efficiency · p. 19
  • System-level methods reduce work or compose proofs more effectively, including verifier-selected training rounds in VeriML, parallel subcircuits in Hydra, and lower commitment-check overhead in Apollo and Artemis [36].Hydra also uses progressive quantization to limit accuracy loss.Source: 2) Improving Efficiency · p. 19
  • Approximately 273× less proof-generation overhead is reported for zkMLaaS with random sampling, im2col conversion, and Freivalds-based matrix verification than for a more direct zk-SNARK approach.The survey presents these as system-level strategies for reducing proof cost.Source: 2) Improving Efficiency · p. 19

IV. COMMERCIAL APPLICATIONS OF ZKML

Commercial ZKML efforts include deployment toolchains and application-facing platforms for trust-minimized services. The reviewed examples point to early adoption clustering around on-chain inference, verifiable agent logic, and user interaction.

IV. COMMERCIAL APPLICATIONS OF ZKML

  • EZKL exports PyTorch or TensorFlow models through ONNX and compiles them into zk-SNARK circuits with input formatting, witness generation, and proof creation support.It can prove MNIST-scale models within a few seconds using modest memory by current zkML standards.Source: §IV · p. 19
  • Coda illustrates recursive zk-SNARK infrastructure that compresses large computation histories into constant-size blockchain proofs relevant to future decentralized ML services.The survey notes that Coda is not itself a ZKML platform.Source: §IV · p. 19
  • DeFiChain highlights ZKML-style ideas for AI-assisted fraud detection and credit-risk assessment, aiming to validate outputs without exposing user data or proprietary model internals.Source: §IV · p. 19
  • Modulus Labs demonstrates on-chain model applications through RockyBot and a verified chess engine, and has published a proving-system speed-and-cost benchmark across model sizes.Source: §IV · p. 19
  • Giza combines ONNX representation, transpilation to Cairo, deterministic execution, and smart-contract components for on-chain model deployment.Source: §IV · p. 19
  • ZKaptcha provides CAPTCHA-style proof services for smart contracts, relying mainly on ZKP rather than full ZKML.The survey presents proof-backed behavioral classification as an adjacent application area.Source: §IV · p. 19
  • Early commercial ZKML adoption clusters around on-chain inference, verifiable agent logic, and trust-minimized user interaction.The survey identifies these as emerging application patterns.Source: §IV · p. 20

V. HYBRID CRYPTOGRAPHIC FRAMEWORKS FOR VERIFIABLE ML

Hybrid ZKML assigns complementary roles to cryptographic primitives, combining privacy or confidentiality mechanisms with ZKP-based integrity rather than relying on one primitive.

V. HYBRID CRYPTOGRAPHIC FRAMEWORKS FOR VERIFIABLE ML

  • Hybrid designs use complementary primitives to address privacy, confidential computation, and verifiability rather than expecting one technology to provide every guarantee.They assign each primitive the role it handles best.Source: §V · p. 20

A. Hybridization of Homomorphic Encryption and ZKP

  • pvCNN pairs homomorphic encryption for sensitive intermediate computation with ZKP attestation that the returned result matches the prescribed CNN execution.Drynx combines homomorphic encryption, differential privacy, and ZKP across confidentiality, secure aggregation, and verifiability.Source: A. Hybridization of Homomorphic… · p. 20

B. Hybridization of Differential Privacy and ZKP

  • Verifiable differential privacy uses ZKPs to check noise generation and parameter compliance because common differential-privacy mechanisms are not naturally proof-friendly.Circuit-oriented linearization expresses those mechanisms within arithmetic constraints.Source: B. Hybridization of Differential… · p. 20

C. Hybridization of Federated Learning and ZKP

  • VPFL protects client updates during aggregation with homomorphic encryption and uses SNARK-style proofs for the server’s federated-averaging computation.Wang et al. [83] also propose Veri-CS-FL, where clients prove local-model performance-metric quality before server-side selection.Source: C. Hybridization of Federated Learning… · p. 20

D. Hybridization of Secure Multiparty Computation and ZKP

Hybrid designs separate privacy and verifiability roles, while the survey identifies efficiency, scalability, generality, and usability as barriers to practical deployment.

D. Hybridization of Secure Multiparty Computation and ZKP

  • CrypTen is an MPC substrate, not a ZKP-integrated system; MPC can protect private multi-party computation while ZKP attests selected computations or outputs.Separating the roles avoids requiring one primitive to provide both high-throughput privacy and full public verifiability.Source: D. Hybridization of Secure Multiparty… · p. 20

E. Benefits of Hybrid Cryptographic Designs

  • Hybrid designs delegate bulk confidential computation, cover multiple threat dimensions, support scalable verification, and reduce trust assumptions.The cited examples include pvCNN’s reduced end-to-end overhead, Drynx’s combination of privacy, confidentiality, and integrity, and VPFL’s logarithmic verification overhead as participants grow.Source: E. Benefits of Hybrid Cryptographic… · p. 20

VI. FUTURE DIRECTIONS FOR ZKML

  • The field remains far from mature, and the survey identifies five especially important directions for future work.The supplied discussion specifies efficiency and scalability, and generality and practicality, among those directions.Source: §VI · p. 20

A. Improving Computational Efficiency and Scalability

  • Efficiency and scalability remain immediate deployment barriers, especially for large neural, multimodal, and generative models with potentially prohibitive circuits, witness generation, and memory needs.Proposed work includes recursive proof composition, efficient circuit layouts, hardware-aware witness generation, and proof systems tailored to layered ML computation.Source: A. Improving Computational Efficiency… · p. 20

B. Improving Generality and Practicality

  • Many systems are tied to specific proof backends, quantization rules, operator sets, or model families, and require substantial cryptographic expertise.Better compilers, reusable operator libraries, domain-specific languages, and mainstream-toolchain interfaces are proposed to improve usability and comparison.Source: B. Improving Generality and Practicality · p. 21

C. Support for Diverse and Complex Machine Learning Models

The survey identifies model coverage, lifecycle privacy, security beyond basic correctness, and data authenticity as unresolved challenges for ZKML.

C. Support for Diverse and Complex Machine Learning Models

  • Current ZKML centers on supervised inference and structured training, leaving multimodal, generative, retrieval-augmented, and self-supervised settings under-supported.For stochastic systems, one proposed direction is proving deterministic sub-computations while scoping correctness claims; self-supervised and unsupervised verification targets may need new theory.Source: C. Support for Diverse and Complex… · p. 21

D. Strengthening Privacy and Security

  • Privacy work remains concentrated at inference, while full-lifecycle protection and security beyond basic correctness remain open challenges.Future work should explore combining ZKP with MPC, homomorphic encryption, and differential privacy for broader lifecycle guarantees.Source: D. Strengthening Privacy and Security · p. 21

E. ZKP-Based Verification of Data Authenticity

  • Most current ZKML work assumes datasets are legitimate and properly governed, although provenance, authorization, and data integrity can matter as much as model-computation correctness.Proposed directions include proofs of provenance, authorization, preprocessing integrity, and version consistency, plus scalable mechanisms for distributed datasets.Source: E. ZKP-Based Verification of Data… · p. 21

VII. CONCLUSION

  • The survey finds ZKML moving from proof-of-concept demonstrations toward more general, efficient, and deployable systems, while substantial challenges remain.Those challenges include scalability, model coverage, privacy across the ML lifecycle, and data authenticity.Source: §VII · p. 21

Related papers

Loading 2502.18535v2…