# Blitzar: GPU Acceleration for ZK Proof Primitives in C++

> Blitzar is Space and Time's Apache-2.0 C++ library that moves multi-scalar multiplication and inner product arguments onto Nvidia GPUs, with a CPU backend kept for testing. It is a low-level primitive library, not a proving framework.

**spaceandtimefdn/blitzar** — Zero-knowledge proof acceleration with GPUs for C++ and Rust

- Repository: https://github.com/spaceandtimefdn/blitzar
- Website: https://www.spaceandtime.io/
- Stars: 4,863 · Forks: 158
- Language: C++
- License: Apache-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/spaceandtimefdn-blitzar

## The primitive that Blitzar actually accelerates

Blitzar exists because Space and Time's cryptography team needed a GPU acceleration framework for Proof of SQL, their zero-knowledge proof for SQL operations, and the existing options did not fit. The README states that Proof of SQL can now execute analytic queries on 1M+ rows in less than a second. That claim belongs to Proof of SQL running on Blitzar, not to Blitzar in isolation, and it is the project's own statement rather than an independent measurement.

The library's scope is narrow on purpose. It provides group operations over Curve25519, Ristretto25519, bls12-381 G1, bn254 G1 and Grumpkin elements, an implementation of the Inner Product Argument Protocol for producing and verifying a compact proof of the inner product of two vectors, and bindings that make commitment computations usable from Rust. It is adopted from libsodium and zkcrypto's bls12_381, extending both projects' cryptographic functions to support CUDA.

That framing matters for evaluation. If you are shopping for a circuit compiler, a proving scheme or a verifier service, Blitzar is none of those. It is the arithmetic layer underneath them. The intended user is someone who already has a prover and has profiled it far enough to know that multi-scalar multiplication is where the time goes.

## How the GPU and CPU backends are wired

The repository documents exactly two computational backends. The cpu backend is a serial implementation targeting x86-capable CPUs, and the README is explicit that it exists for the sake of testing. The gpu backend is a parallel implementation targeting Nvidia CUDA-capable GPUs. There is no intermediate multi-threaded CPU path described.

That is a deliberate design decision with a real consequence. A serial CPU implementation of MSM will not be competitive with a tuned CPU library, so anyone without an Nvidia card is effectively running the test path. The README does not present the CPU backend as a production fallback, and reading it as one would be a mistake.

The central operation is the generalized Pedersen commitment. Given group elements g0 through gn and scalars a0 through an, the commitment is the sum of ai times gi. Blitzar computes multiple MSMs of potentially different lengths simultaneously, and it can either use built-in precomputed generators or take generators supplied by the caller. The multi-length, batched shape is the interesting part: it means a prover that needs several commitments at once does not have to serialize them.

The second primitive is the inner product argument, described as a modified implementation in the style of Bulletproofs and Halo2. Both primitives are exposed through cbindings, and the Rust crate lives in a companion repository rather than here.

## Installing Blitzar from a release or from source

The README states that prebuilt binaries are provided for glibc-based, x86-64 Linux distributions. Dependencies are statically linked and given internal linkage with export maps, so the only runtime dependency for GPU acceleration is an up-to-date GPU driver. The project badge pins CUDA 12.8, so that is the version to check against your driver before anything else.

The README gives two installation routes. For most users it recommends installing through cargo via the companion blitzar-rs repository. Users who want the C API directly download the shared library and header file from the GitHub release. The README does not print the exact cargo command, so check the blitzar-rs repository for the published crate name before adding it to a manifest.

If you take the release route, the build script invoked at release time is the one below, run with a version argument and the --with-release flag. It produces libblitzar-linux-x86_64.so.

```bash
bash ./ci/build.sh libblitzar-linux-x86_64.so ${nextRelease.version} --with-release
```

The release automation publishes dist/*.h, dist/*.so*, dist/*.zip and dist/*.tar.gz as GitHub release assets, which tells you what to look for on the release page.

For a first real use, the repository ships runnable examples under example/. The directory listing includes example/cbindings1/, example/exponentiation1/, example/field_arithmetic/ and example/multiproduct1/. The naming maps onto the library's own vocabulary: exponentiation for the MSM and commitment path, multiproduct for the inner product argument, cbindings for the C API, and field_arithmetic for scalar work. Start with the example matching the API surface you intend to call, and expect the build to go through Bazel, since the repository carries MODULE.bazel, WORKSPACE and .bazelrc at the top level alongside a Nix flake. The README does not document a cmake path, so do not assume one.

## Where Blitzar stops being the right tool

The platform constraint is the first thing to check. Prebuilt binaries are glibc-based x86-64 Linux only. The project badges confirm this: the OS badge reads Linux, the CPU badge reads x86, and the CUDA badge reads 12.8. macOS, Windows and ARM are not covered by the prebuilt route, and the README does not describe a supported path for them. If your deployment target is an Apple laptop or a Graviton instance, this is not your library.

The second limitation is conceptual rather than technical. Blitzar is a primitives library. It gives you group operations, MSM and an inner product argument. It does not give you a circuit language, a constraint system, a proof serialization format or a verifier service. Adopting it means writing or already owning all of that. Teams that want an end-to-end proving stack should look elsewhere and treat Blitzar as an optional accelerator underneath, if at all.

The third is the CPU backend's status. Because the README frames it as existing for testing, a machine without an Nvidia GPU in the supported driver range is not a supported production configuration. There is no documented software fallback that the project treats as equivalent.

Finally, the API is low-level C++20 with cbindings. There is a Rust crate, but it is a sys-crate, meaning it exposes the underlying C surface rather than a high-level idiomatic wrapper. Budget for that.

## Blitzar compared with arkworks and blstrs

The most direct comparison is with the Rust ecosystem's pure-CPU curve libraries. arkworks provides field and curve arithmetic plus MSM, and blstrs provides bls12-381 group operations with MSM, both written in Rust and running on the CPU. They are portable to any target Rust compiles for, they integrate with the surrounding Rust toolchain without a sys-crate boundary, and they need no GPU driver.

The difference in approach is where the parallelism lives. arkworks and blstrs parallelize across CPU cores, typically via rayon, and their performance ceiling is memory bandwidth and core count. Blitzar parallelizes across CUDA cores and its ceiling is GPU memory and the PCIe transfer of the input vectors. That trade is only worth taking when the MSM is large enough to amortize the transfer, which is why the batched, multi-length MSM interface matters: it lets you push more work across the bus per call.

The second difference is the curve set. Blitzar covers Curve25519, Ristretto25519, bls12-381 G1, bn254 G1 and Grumpkin. If your proof system uses a curve outside that list, neither the GPU path nor the CPU path helps you, and arkworks' broader curve coverage becomes the deciding factor. Note also that Blitzar's support is for G1 on the pairing curves, so protocols needing G2 arithmetic are outside its scope.

## Maintenance, licensing and what a version bump costs you

The repository is not archived and the last push was on 2026-07-16. Releases are automated through semantic-release driven by conventional commits, with a release rule that treats build-type commits as patch releases. That explains the versioning pattern visible in the release list: v1.115.0 in April 2025, v1.115.1 in June 2025, and v1.115.3 in June 2026. The cadence is irregular, clustered around actual changes rather than a fixed schedule.

For upgrade cost, the practical question is whether you consume the prebuilt shared library or build from source. If you take the release artifacts, an upgrade is swapping a .so and a header, and the version is embedded in the artifact name, so pinning is straightforward. If you build from source, you inherit the Bazel and Nix setup, and the repository's toolchain files are Bazel-centric. The README does not document a rollback procedure or an ABI stability guarantee across versions, so treat the shared library as something to pin explicitly in your own build rather than float.

On licensing, the project is Apache-2.0, and the LICENSE file sits at the repository root. Apache-2.0 includes an explicit patent grant and requires preservation of notices, which is generally friendlier for commercial integration than a copyleft licence. The README also notes the code is adopted from libsodium and zkcrypto's bls12_381, both of which carry their own licences; if you redistribute, check the third_party/ directory and the upstream terms rather than assuming the root licence covers everything. This is a description of what the repository states, not legal advice.

## Conclusion

Adopt Blitzar if you are writing a C++ or Rust prover and your bottleneck is multi-scalar multiplication or an inner product argument over Curve25519, Ristretto25519, bls12-381 G1, bn254 G1 or Grumpkin, and you have an Nvidia GPU. Do not adopt it if you need macOS, ARM, or a complete proving system: the README ships prebuilt binaries for glibc-based x86-64 Linux only, and the library stops at primitives. Before committing, verify the CUDA 12.8 requirement against your driver, check that your target curve is one of the five listed, and confirm you can build the artifacts from source if the prebuilt release does not match your toolchain.

## FAQ

### What is Blitzar?

Blitzar is a C++20 library from Space and Time that accelerates zero-knowledge proof primitives on the CPU and GPU. It provides group operations over several elliptic curves, multi-scalar multiplication, and an inner product argument, with bindings for Rust.

### Which curves does Blitzar support?

The README lists Curve25519, Ristretto25519, bls12-381 G1, bn254 G1 and Grumpkin. Support is for G1 on the pairing curves, so protocols that need G2 arithmetic fall outside the library's scope.

### Does Blitzar need an Nvidia GPU?

The GPU backend targets Nvidia CUDA-capable GPUs and the project badge pins CUDA 12.8. A serial CPU backend is included, but the README says it exists for the sake of testing rather than as a production path.

### Which platforms can run Blitzar?

Prebuilt binaries are provided for glibc-based, x86-64 Linux distributions, and the project badges confirm Linux, x86 and CUDA 12.8. The README does not describe supported prebuilt paths for macOS, Windows or ARM.

### How do I install Blitzar in a Rust project?

The README recommends installing with cargo via the companion blitzar-rs repository, which provides the sys-crate and bindings. Users who want the C API directly download the shared library and header file from the GitHub release instead.

## Sources

- [License: Apache-2.0](https://github.com/spaceandtimefdn/blitzar/blob/main/LICENSE)
- [Project website](https://www.spaceandtime.io/)
- [README](https://github.com/spaceandtimefdn/blitzar/blob/main/README.md)
- [Releases](https://github.com/spaceandtimefdn/blitzar/releases)
- [spaceandtimefdn/blitzar on GitHub](https://github.com/spaceandtimefdn/blitzar)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/spaceandtimefdn-blitzar