Anthropic Open-Sources FlashProve, Using Zero-Knowledge Proofs to Verify Model Identity

Just now, Anthropic published a post claiming "new progress in verifiable reasoning for large language models" and open-sourced a system called FlashProve. It is based on zero-knowledge cryptographic proof technology, allowing model providers to prove that a given answer was indeed generated by a specified model without disclosing the model weights.

What does that mean?

Normally, is the AI you pay to call really the model the provider promised? Suppose an enterprise purchases API services for a top-tier large model, and the provider promises to use the most capable model but quietly swaps in a lower-cost small model in the backend—can users detect it?

Or, when a third-party model routing platform forwards requests, it secretly substitutes the originally specified model. Even if the final returned answer is of good quality, what way do users have to prove that it actually came from the model they paid for?

Currently, users can usually only trust the provider's promise, and it is difficult to independently verify technically. The research newly published by Anthropic is trying to solve this problem.

More notably, this technology has already been tested on a mixture-of-experts model with a total parameter count of 400B: a single NVIDIA H100 GPU can generate inference proofs corresponding to about 110 tokens per second, and the proof file for every 1024-token request is about 19 MB.

In the past, research on zero-knowledge machine learning mostly focused on smaller models, while FlashProve further advances verifiable inference to the large language model scenario.

Currently, Anthropic has open-sourced FlashProve's proof generator, C++ and Lean verifiers, as well as related technical documentation and formal proofs.

Anthropic calls this technology "Provable Inference." In the official blog, the team first raised trust problems faced by four types of AI services, attempting to address this kind of need: users initiate requests to an AI service but cannot confirm which model the returned answer actually came from.

For example, a third-party provider may, to reduce costs, replace the high-performance model specified by the user with a cheaper model; the inference server may also be attacked, causing model weights or output tokens to be tampered with. For researchers conducting security evaluations, if they cannot confirm that the tested object is consistent with the actually deployed model, the evaluation results lose reliability.

The core idea of this technology is that the model provider first cryptographically generates a commitment for a determined set of model weights, equivalent to establishing an encrypted fingerprint for the model version. After that, each time a user initiates a request, the provider can attach a zero-knowledge proof (zkSNARK) proving that this answer was indeed generated by the previously committed model based on the corresponding input.

In this way, users do not need to obtain the model weights, nor do they need to rerun the model themselves; they can independently verify the model's identity through the model commitment, input, answer, and proof file. The proof process does not leak the model weights, but it can confirm whether the output comes from the specified model. Of course, it proves the source of the answer, not whether the content of the answer is correct.

For a 400 billion parameter model, proof speed reaches 110 tokens/s

To verify the feasibility of the scheme, Anthropic chose Meta's Llama 4 Maverick for testing. This is a MoE model with 400 billion parameters, with about 17 billion parameters actually activated per token.

On a single NVIDIA H100 GPU, FlashProve's proof generation throughput reaches about 110 tokens/s, and each proof file is about 18.78 MB. The verification side does not need a GPU; using a 24-thread CPU to verify one proof takes about 17 seconds. Note that the current test uses a 1024-token request window, and each proof actually checks one of the output tokens.

This efficiency improvement is related to the optimizations FlashProve makes for the MoE architecture: the proof computation mainly revolves around the experts actually activated, rather than processing all of the model's parameters every time. At the same time, the system adopts batch post-hoc proving, generating proofs uniformly after inference is completed, reducing the overhead caused by repeated computation.

However, proving still incurs additional costs. According to Anthropic's tests, the GPU time required to generate proofs is about 70–95 times that of ordinary vLLM inference. In addition, the current system mainly supports a 1024-token context window and verifies integer models and Greedy Decoding, and cannot yet directly cover all models and inference methods.

To further improve the system's trustworthiness, Anthropic also used the Lean formal verification language to provide machine-checkable proofs of core security properties such as the protocol's integrity, soundness, and zero knowledge, and open-sourced the code, protocol description, and related proofs under the Apache 2.0 license. However, formal verification does not mean that all actually running code has obtained equivalent guarantees; the fast C++ verifier and the formal protocol still require further auditing.

There is a category of users who may very much need this "ID card."

Currently, many users call models from different vendors through third-party API relay stations or model aggregation platforms. Such services lower the barrier to model calls, but they also bring an information asymmetry: users can choose a model name, but may not be able to independently confirm which model is actually running in the backend.

For example, in a multi-layer forwarding call chain, a service provider could in theory, out of cost considerations, forward requests that should originally be handled by a high-performance model to a model with a lower call price. For users, even if they notice a change in answer quality, it is hard to determine whether it is due to the randomness of the model itself, a change in service status, or an actual change in the model being called.

In the absence of independent verification methods, it is difficult for users to confirm what model they actually called based solely on the returned results.

One netizen argued that when ordinary users call models through third parties, it is hard to confirm whether the answer on the screen really comes from the large model advertised, or whether it has been replaced by the service provider with a lower-cost model, or even whether it may have been tampered with by a man-in-the-middle.

FlashProve offers a new approach to checking. If a model service provider publishes in advance a weight commitment for a specific version, then when the service returns an answer, it can also provide a corresponding cryptographic proof. Users do not have to rely entirely on the service provider's verbal promise; instead, by verifying the proof, they can confirm whether this request was indeed completed by the model with the specified weights.

There is still some distance to large-scale application

Of course, Anthropic paints a rosy picture, but it also clearly points out that FlashProve is still a research prototype and still has several engineering and theoretical constraints.

First, the cost of proof remains high. Although it is several orders of magnitude faster than the previous-generation system, the GPU time required to generate a proof is still about 72 to 94 times higher than ordinary inference (vLLM), meaning that if every request required real-time proof generation, service costs would increase significantly.

Second, the forms of computation currently supported are limited. The current experiment targets an integer-arithmetic version of the model and Greedy Decoding; other inference methods such as floating-point computation and random sampling still need further extension.

In addition, the context length is limited. The current experiment demonstrates proof scale for contexts of up to 1024 tokens; for long contexts, large-scale agent workflows, and complex multi-turn interactions, how to efficiently generate and verify proofs remains a problem to be solved.

One more point that needs special mention is that FlashProve proves that an answer really comes from the specified model, not that the answer itself is correct. In other words, if the specified model produces a hallucination, FlashProve may still successfully verify this answer. What it solves is the problem of model identity and inference integrity, not model capability or factual accuracy.

Still, what is worth affirming is that the open-sourcing of FlashProve brings new possibilities for trustworthy governance across the entire AI industry chain. As compliance regulation, model supply chain security, and high-value scenarios (medical diagnosis, financial decision-making, legal analysis) place ever higher demands on confirming model identity, the "tamper-proof model ID card" is moving from a purely academic idea into the stage of engineering practice.

In the future, what model service providers deliver to users may no longer be only answers and tokens, but also an additional cryptographic credential that can prove "this was indeed generated by the model you specified."

Reference link:

This article comes from the WeChat public account "Machine Heart" (ID: almosthuman2014), author: Machine Heart, which follows AI, and is published by 36Kr with authorization.