anthropics/FlashProve

What it is

FlashProve 0.16.0 is an unmaintained Anthropic research prototype (Apache 2.0, not accepting contributions) for zero-knowledge proofs of LLM inference. The README says it runs Llama 4 Maverick at full size on one H100 with a 1,024-token context window. Prefill reaches about 110 tokens/second at 24 requests per batch. The README presents the Lean 4 soundness proof as covering the protocol, not the implementation.

Preconditions / Affected

The verifier needs far less than the prover. Verification (route 1) needs Linux, bash, g++ 13+ and under 2 GB RAM. The build takes 1 to 2 minutes and the check takes under 2 seconds. Routes 3 and 4 need the only supported prover platform:

• x86-64 Linux 4.14 or later, on a CPU with SHA extensions
• one H100 80 GB used by nothing else
• CUDA 13.2 Update 2 (nvcc 13.2.86)
• gcc and g++ 13, on a local disk

Memory for the other routes:

• Toy proofs on CPU (route 2) need about 1.5 GB RAM and take about 1 minute.
• The 8-layer synthetic small model needs 10 GB RAM and takes about 29 minutes to build and 23 to 30 seconds to run.
• The full-size synthetic run (1,001 tokens) needs 280 GB RAM and takes about 42 minutes.
• Real Maverick (route 4) downloads a 232 GB 4-bit conversion and needs 330 GB RAM, 245 GB disk, Python 3.13 and a calibration set you make first. It takes hours.

What to do

Build the verifier and check the stored example proof, as an ordinary user and never under sudo:

verifier/build.sh
bin/cp_verify examples/accepted-proof/config examples/accepted-proof/ivk examples/accepted-proof/example.req examples/accepted-proof/example.y examples/accepted-proof/example.proof -id "$(cat examples/accepted-proof/ID.txt)"

The build prints a line starting THE VERIFIER IS BUILT: and exits 0. The check should end with YES and exit code 0. That example uses synthetic weights, so it shows only that the verifier works.

To verify a real proof, the invocation is bin/cp_verify CONFIG_DIR PUBLIC_KEY_DIR REQUEST_FILE TOKEN_FILE PROOF_FILE -id COMMITMENT_ID. Take the commitment ID from a party you trust, never from the server being checked or from files sent with the proof. Build the request file yourself.

Read the exit code together with the last line:

• 0: YES or WITHIN LIMITS: … (exact match, or clipped gap).
• 1: NO: <name> (rejected, or a local fault).
• 5: NOT CHECKED: <name> (no verdict). Retry once only for internal-stage or internal-exception-parFor.
• 14: NOT-A-VERIFICATION (the call was invalid).
• 2, 3, 4, 15: bad command line or file, or a partial call, with no verdict.

Further checks:

• Route 2 runs the CPU suite with ./run_suite.py cpu "$D/work". It overwrites bin/cp_verify and bin/weight_sums. Exit 77 means tools are missing. Exit 3 means a test saw a false acceptance, to be reported per SECURITY.md.
• The GPU quickstart is examples/quickstart-gpu.sh. It can be silent for over 15 minutes. Success is exit 0 plus quickstart-gpu: all steps ended as expected. Confirm every Compiled by line says release 13.2, V13.2.86. A newer nvcc does not stop the build but is unsupported.
• The full-size run is prover/examples/run_target_example.sh target_full_f2 "$WORK". Too little memory gives exit code 2 at the start.

For accepted proofs, report the exact command, exit code, full last line, the commitment ID passed, and the covered: and result-v1 lines.

Caveats

The README's bound of about q/2^124 + 2^-101 applies after q hash queries. The README names weight hiding, known limits and the provider's duties as separate pages, and says they are required reading before committing secret weights. This page does not summarise them. The README also says never to work around an error with sudo, chmod, chown, rm or source edits.