Back to Model List

FlashProve: Anthropic's Open-Source Verifiable Reasoning System, Using Zero-Knowledge Proofs to Attest AI Outputs

AI Tech Editorial
RSS Feed
FlashProve: Anthropic's Open-Source Verifiable Reasoning System, Using Zero-Knowledge Proofs to Attest AI Outputs official screenshot
(Image source: official screenshot)

Executive Summary:

FlashProve is an open-source verifiable reasoning system developed by Anthropic based on zero-knowledge proofs (zk-SNARK). Its core value lies in enabling model service providers to offer cryptographi...

1. What is FlashProve

FlashProve is an open-source verifiable reasoning system developed by Anthropic based on zero-knowledge proofs (zk-SNARK). Its core value lies in enabling model service providers to offer cryptographic proof to users or third parties that a particular AI response was indeed generated by a specified model, without revealing the model's weights. This system has been tested on Llama 4 Maverick, a model with 400B parameters and a Mixture-of-Experts (MoE) architecture. A single H100 GPU can generate proofs at a rate of approximately 110 tokens per second, with each 1024-token proof requiring about 19MB of storage. A verifier only needs a standard CPU to complete the verification in about 17 seconds. FlashProve is still a research prototype, with the GPU time required to generate proofs being approximately 70 to 95 times that of regular inference. Moreover, the current proof mechanism only confirms the source of the output and does not guarantee the correctness of the content itself. The release of FlashProve provides the first technically viable solution for scenarios such as trustworthy auditing of AI inference, compliance with model routing, and preventing service providers from "substituting models" under the hood.

flashprove-anthropic official website screenshot
(Image source: official screenshot)

Technical Positioning and Domain: FlashProve belongs to the intersection of cryptography and artificial intelligence, specifically in the fields of verifiable computation and zero-knowledge machine learning (zkML). The system is not intended to replace existing inference engines but rather to serve as an additional proof layer on top of inference servers, providing machine-checkable trust credentials for high-value, highly regulated AI services. Its design goal is to achieve a balance between "model weight confidentiality" and "output verifiability."

Development Background: This system was developed by Anthropic's research team in response to the growing trust issues in the commercial deployment of large models. As API intermediaries and model routing platforms become more widespread, users who pay for high-performance model calls may have their computations silently replaced with cheaper alternative models. Traditional log audits or spot checks are insufficient to address this behavior effectively. FlashProve is a solution specifically designed to bridge this trust gap, and its security properties (integrity, reliability, zero knowledge) have been formally verified using the Lean 4 proof assistant.

Core Value: FlashProve addresses the long-standing challenge of "how to prove the authenticity of computation without disclosing commercial secrets (model weights)." Its significance lies in being the first to bring zkML technology from academic validation "toy models" to ultra-large-scale MoE models with over 400B parameters, and it provides a reproducible open-source implementation (including a C++ verifier and end-to-end scripts). This offers the first practical technical infrastructure for scenarios such as third-party evaluation agencies verifying "what is tested is what is claimed," regulatory bodies auditing computational resource usage, and enterprise users confirming that API calls have not been tampered with.

2. Key Features

  • Zero-Knowledge Identity Verification (Core Identity Proof): Without exposing the model weights, the system generates a cryptographic commitment for specified model weights. The service provider publishes this commitment as a "model fingerprint." Users or third-party verifiers can confirm that the output was generated by the model referenced in the commitment by using the accompanying zkSNARK proof, relying only on the commitment, input text, and output result. Throughout the process, weights, intermediate activations, or expert routing choices are never disclosed.

  • Model Substitution Prevention: For third-party API resellers or model routing platforms, the proof provided by FlashProve makes it impossible to mask the act of using a lower-tier model to impersonate a higher-tier one at the cryptographic level. If the service provider actually deploys a cheaper small model or an open-source model, the verifier will receive a "Reject" result when running cp_verify, thereby providing a machine-checkable basis for ensuring that the computational resources paid for by users are indeed used for the promised model.

  • Output Integrity Verification: In scenarios where the inference server is attacked or the Token stream is tampered with by a man-in-the-middle, FlashProve's proof can effectively expose abnormal conditions. Any modification to the output text (even a minor change at the Token level) will result in proof verification failure (exit code 0 and the last line not being "YES"), ensuring that the user receives a response that is consistent with the content promised by the model service provider.

  • Compliance & Audit Certificate: The proof files generated by the system can serve as machine-checkable audit evidence for regulatory bodies, independent evaluators, and internal security teams. Regulators can require service providers to regularly submit inference proofs to verify that hardware computational power is indeed used for approved model inference tasks, rather than being diverted to unauthorized training operations or computations that bypass approval.

  • Third-party Claim Endorsement: Developers can use FlashProve proofs to demonstrate that code audits were indeed performed by a specific cutting-edge security model. Enterprises can also prove that commercial analysis reports or security assessments were reviewed by designated models. Since the verification process does not involve access to model weights, the party being endorsed can quickly verify the authenticity of the claim without exposing any business secrets.

  • Batch Post-hoc Proof Generation: The system allows for the unified generation of zero-knowledge proofs after inference is completed. By using the already generated text as prefill for parallel reading and opening the weight commitment only once per batch, it significantly reduces the cost of repeated cryptographic computations. Although this design does not support real-time inline proof generation on a per-Token basis, it effectively balances actual throughput performance and security.

3. Application Scenarios

  • Third-party API Proxy and Model Routing Verification: When users or enterprises invoke high-cost designated models (such as Claude, GPT, or Llama 4 Maverick) through an API proxy platform, they can request the platform to include a FlashProve proof. After receiving the output, users can use the public verifier (cp_verify) to verify the commitment, request, output, and proof, thereby confirming that the proxy provider has not secretly routed the request to a lower-cost alternative model, preventing "paying a premium for low-end" computational fraud issues.

  • Independent and Large Model Evaluation Agencies: Third-party evaluation agencies often face disputes where "the model being tested is Model A, but the one deployed is Model B" during large model benchmark testing. With FlashProve, evaluation agencies can require service providers to submit commitments and proofs related to the model weights being tested, thereby confirming that the service under evaluation indeed uses the model being assessed, ensuring the credibility of rankings and evaluation results.

  • Tamper-proof Mechanism for Inference Servers: Internal security teams or compliance departments can require enterprise inference servers to generate proofs alongside their responses. If hackers attempt to inject malicious outputs or use unauthorized models to replace legitimate ones after breaching the system, the verification on the user side will fail, alerting the organization to a security incident. This mechanism provides an additional layer of defense for high-sensitivity internal operations, such as financial risk control analysis.

  • Regulatory Compliance and Computational Resource Auditing: For AI computational resource providers under strict regulation, regulatory authorities can require them to regularly submit inference proof records to verify that computational resources are indeed used for approved model inference tasks. FlashProve enables effective auditing of high-risk behaviors such as "misusing computational resources for training" or "bypassing approval processes" without needing access to the commercial model weights, providing the industry with a new technical tool for regulation.

4. How to Use

  1. Environment Preparation and Prerequisites: For the Verifier, only a standard Linux machine capable of running C++ programs is required. For the Prover, the requirements are more stringent: it must be equipped with a single idle NVIDIA H100 80GB GPU, with Linux recommended as the operating system, and CUDA 13.2 or higher drivers and toolchain must be installed (note that FlashProve has specific requirements for CUDA versions; it does not require the latest version). Additionally, operations must be performed as a regular user in the root directory of the repository to avoid permission issues that could cause the build to fail.

  2. Clone and Build the Verifier: First, execute git clone from the official repository https://github.com/anthropics/FlashProve to obtain the source code. After entering the root directory of the repository, run the verifier/build.sh script to compile the C++ Verifier. A successful build is indicated by the terminal output of the THE VERIFIER IS BUILT field and an exit code of 0. If the build continues to fail, check whether the required dependency libraries (such as the OpenSSL cryptographic library version) are met.

  3. CPU-side Functional Self-check: After the build is complete, execute bin/cp_verify and pass in parameter examples from the examples/accepted-proof directory to check whether the built-in proof samples are correctly accepted (the final output should be YES). Then run blocks/first_look.sh to test the proof library, ensuring that proofs generated honestly are accepted and that artificially forged proofs are explicitly rejected, thereby verifying that the current environment functions normally.

  4. Full Workflow Execution on GPU: On a machine that meets the prerequisites (NVIDIA H100 80GB, CUDA 13.2), run the examples/quickstart-gpu.sh script. This script will automatically execute an end-to-end demonstration: submitting a request, generating a proof, and verifying it for a small model. This script is the best way to verify whether your hardware environment is compatible.

  5. Verification of Proofs for Real Models: Once the service provider has provided the Commitment ID, Request, Output (Token), and Proof files, use the command bin/cp_verify CONFIG PUBLIC_KEY REQUEST TOKEN PROOF -id COMMITMENT_ID to verify them. Note: the Commitment ID must come from a trusted source officially published by the service provider (such as the official website or public statement). If the ID is obtained from an untrusted third-party source, the verification itself becomes meaningless, as attackers could simultaneously forge the commitment.

  6. Result Interpretation and Error Handling: After the command has finished executing, the system returns a numeric exit code. An exit code of 0 with the last line being YES indicates that the proof is valid and the output was indeed generated by the committed model. An exit code of 1 means the proof is rejected (invalid or tampered content). An exit code of 5 means no clear conclusion was reached, and one retry is allowed. Other exit codes (such as 2, 3, 4, etc.) typically indicate incorrect command-line arguments or file path issues, and the command-line parameter format should be checked.

5. Pros and Cons Analysis

Pros
Verifiability without exposing weights: Through zero-knowledge proofs, verifiers can confirm that the output was indeed generated by a specified model without ever coming into contact with sensitive data such as model weights or intermediate activations, providing the only viable cryptographic solution for auditing commercial closed-source models.
Extremely low verification cost: Verifiers only need a proof file of about 19MB and a standard CPU (approximately 17 seconds, 24 threads) to complete the verification without requiring a GPU or rerunning a large model, significantly lowering the entry barrier for auditors.
Breakthrough in scalability: For the first time, a proof speed of approximately 110 tokens/s was achieved on the Llama 4 Maverick model with 400B parameters (single H100 GPU), representing a several-order-of-magnitude increase in throughput compared to previous zkML systems. The cost is tied to the activated parameters through MoE activation-aware optimization.
Formalized security guarantees: The three core security properties—integrity, reliability, and zero-knowledge—have been formally proven using the Lean 4 proof assistant, reducing the risk of logical flaws or security vulnerabilities in the cryptographic implementation.
Full open-source and ecological potential: Utilizing the Apache 2.0 license, it includes the complete verifier, scripts, and documentation, allowing commercial use. This lays a solid foundation for future engineering improvements and innovations in the zkML field.

6. Comparative Analysis with Similar Tools

Dimension FlashProve (Anthropic) VerInf (Academic Research)
Provenance Object Llama 4 Maverick (400B MoE, 4-bit quantization) Same model architecture (Llama 4 Maverick 400B)
Proof Speed (Throughput) Approximately 110 tokens/s per H100 Takes about 14.3 hours to generate 1000 tokens on DGX Spark (approximately 0.02 tokens/s)
Proof Size Approximately 18.78MB per 1024-token request Approximately 93.6GB (large volume, difficult to transfer)
Verification Time Approximately 17 seconds on a regular CPU (24 threads) Nearly one day
Proof Method Each proof checks one output token, generated in batches after the fact End-to-end proof of full inference
Proof Overhead Ratio Approximately 70 to 95 times the standard vLLM inference GPU time Several orders of magnitude higher
Formal Guarantees Completeness, reliability, and zero-knowledge have been machine-proven in Lean 4 No formal verification at the same level
Openness Fully open-sourced under Apache 2.0, including C++ verifier, scripts, and documentation Primarily paper-based, with high code reproduction barriers
Deployment Method Single H100 80GB, CUDA 13.2, GPU streaming execution Requires high-computation hardware at the DGX Spark level
Positioning Research prototype, emphasizes engineering usability and real model verification Academic verification, primarily proving protocol feasibility

Selection Recommendations: For commercial API service providers that need to offer verifiable AI outputs in production environments, FlashProve is currently the only open-source option with engineering deployment potential. Although it incurs significant overhead, its MoE activation-awareness and streaming execution concepts are worth adopting. For academic research teams or developers exploring the limits of zkML, VerInf provides a complete theoretical framework for reference, but its resource consumption is not yet practical for real-world applications. For routine business operations under non-stringent regulatory environments, traditional log auditing combined with random spot checks remains the most cost-effective choice. The performance and cost implications of introducing cryptographic proofs still require careful consideration.

7. Editor's Summary

The emergence of FlashProve marks a critical step in transitioning zero-knowledge proof technology from "academic concepts" to "real-world model execution" within the domain of large model inference verification. Its core technological innovation lies in linking proof costs to the actual activated parameters of a MoE model, rather than coupling them with the model's static total parameter count. This design significantly reduces the complexity of proof generation, enabling a proof speed of approximately 110 tokens/s for the Llama 4 Maverick model with 400B parameters on a single H100 GPU. It provides a new paradigm for future zkML system optimizations.

From a practical standpoint, although the 70 to 95 times GPU time overhead makes this system unsuitable for high-frequency, low-value inference scenarios, it offers a machine-verifiable trust anchor for high-sensitivity, highly regulated, or high-value services—precisely the most scarce resource in today's third-party API intermediary market, which suffers from severe transparency issues.

FlashProve is particularly relevant for three types of users: first, vendors offering high-value model API services, who can use it to enhance customer trust; second, technical teams working on large model security, auditing, and evaluation, who can gain a new tool for independently verifying service provider claims; and third, researchers focused on verifiable computing and advanced cryptographic applications, for whom the system's open-source code and Lean 4 formal proofs provide a high-quality foundation for further study.

Although currently labeled as a research prototype, FlashProve has clearly demonstrated the engineering path for verifiable AI inference. Its future evolution in reducing proof overhead, supporting more model architectures, and improving real-time performance may redefine the standards for transparency and trust mechanisms in the AI service industry.

8. FAQ

Q: Can FlashProve prove that the model's output is correct or of high quality?
A: No. FlashProve's proof mechanism only provides cryptographic-level source assurance, confirming that a particular output was indeed generated by the model weights specified in the commitment. It does not address the factual accuracy, logical correctness, security, or value judgment of the output content. This proof cannot replace content review or manual quality inspection processes.

Q: Does using FlashProve require generating a proof for every inference request?
A: It depends on the specific architecture design. FlashProve employs a batch post-proof generation mechanism, generating proofs uniformly after inference is complete, rather than generating proofs inline for each token in real-time. As a result, it is well-suited for requests that require retaining audit evidence, but for applications requiring real-time interaction or streaming outputs, this mechanism will introduce significant additional latency during the proof generation phase.

Q: What hardware requirements are needed to verify a proof?
A: The verification process is very lightweight. A verifier only needs a standard Linux machine capable of running the C++ validator (CPU is sufficient, approximately 17 seconds with 24 threads). No GPU or specialized cryptographic hardware is required. The proof file size is also relatively small (about 19MB), which significantly lowers the barrier for third-party audits and regulatory involvement.

Q: If a service provider changes the model weights but does not alter the commitment ID, will users notice?
A: They will notice in terms of the commitment's integrity. FlashProve's commitment is bound to specific model weights. If the actual weights used by the service provider do not match those specified in the commitment, even a proof with a legitimate signature will fail verification. However, there is a threat to the model boundary: if an attacker fully controls the service provider and simultaneously replaces the weights and the commitment ID, and publishes this information through official channels, users will not be able to detect it. Therefore, the commitment ID must be obtained from a trusted official source.

Q: Can FlashProve run on GPUs other than H100?
A: The official demonstration script (quickstart-gpu.sh) explicitly requires a single idle H100 80GB GPU and a CUDA 13.2 environment. Whether smaller-memory GPUs or consumer-grade GPUs (such as the RTX 4090) can run the system must be verified independently. Due to the system's reliance on a streaming mechanism that sends the model layer by layer to the GPU, memory capacity is a critical constraint. Official compatibility with hardware not based on the Hopper architecture is not guaranteed.

9. Project Links

© All Rights Reserved. Some content on this site is partially generated by AI with human review.