Use decentralized SaladCloud compute as the most cost-effective power for zero-knowledge proof calculations.

Introduction

Over the past decade, digital technology has accelerated at a breathtaking pace. What used to be a world of simple 0s and 1s is now fully integrated into all aspects of daily life—social interactions, business workflows, even politics. Among the foundational technologies that impact society at large is blockchain. Blockchain emphasizes transparency—anyone can verify what happened on the ledger and when. But people and organizations still need privacy. How can those ideas coexist? With zero-knowledge proofs (ZKPs), it’s possible.

What is ZKP? 

A zero-knowledge proof lets one party—the prover—convince another—the verifier—that a statement is true without revealing the secret behind it.

The verifier issues challenges that only someone with the hidden information can answer correctly—a guesser will fail with high probability.

The Ali Baba cave parable is a popular analogy to explain how ZKPs work. Imagine a circular tunnel with two entrances that meet at a locked magic door opened only by a secret word. Peggy, who claims to know the word, walks into the cave while Victor waits outside; he then calls out a random entrance for her to reappear from. If Peggy truly knows the word, she can open the door inside and emerge from whichever entrance Victor names; if she doesn’t, she can only come out from the one she originally took, matching Victor’s request only by luck. Repeating this many times takes luck out of the picture, so Victor becomes convinced she knows the secret. He learns nothing about the word itself—only that Peggy consistently succeeds—capturing the essence of zero knowledge.

ZKPs were first formalized in a 1985 paper by Shafi Goldwasser, Silvio Micali, and Charles Rackoff. They showed a prover can convince a verifier of a fact without revealing anything else about the data. ZKPs come in two modes: interactive (back-and-forth with a specific verifier) and non-interactive (a single proof anyone can verify). Two widely used non-interactive families today are zk-STARKs (zero-knowledge scalable transparent argument of knowledge) and zk-SNARKs (zero-knowledge succinct non-interactive argument of knowledge).

Basic Architecture of ZKP

Although the underlying math is complex, it’s useful to keep a high-level view of the workflow in mind. A zero-knowledge proof involves two parties: a prover, who possesses a secret (the witness), and a verifier, who needs to be convinced that a statement about that secret is true without learning the secret itself. The statement is first written in a precise, mathematical form—often as a circuit or a small program that encodes the rules. Typical claims might be “I control this account without revealing the private key,” or “this confidential transaction balances correctly without showing the amounts,” or even “this output truly came from running that program on hidden input.”

The process often begins with setup, which ties the intended computation to the proof system. Not every scheme needs a per-circuit setup: many SNARKs do, while STARKs and some modern SNARK variants are transparent and rely on public randomness or universal parameters instead of a special ceremony. When setup is required, it produces two artifacts: a proving key, used by whoever will build proofs, and a verification key, used by anyone to check them. Who runs or validates this step is part of the trust model; running it yourself—or at least verifying how it was produced—ensures the circuit being proved is exactly the one you expect.

The heart of the workflow is proving. The prover combines public inputs with the private witness and the proving key to construct a compact proof. This is the compute-intensive phase. In SNARK systems, most time and memory go into large polynomial transforms (FFT/NTT, i.e., fast Fourier transforms / number-theoretic transforms) and big elliptic-curve multi-scalar multiplications (MSMs), with a transcript hash to make the proof non-interactive. In STARK systems, the weight shifts to generating a large execution trace, extending it to low degree via FFT, committing with Merkle trees, and running hash-heavy FRI checks (Fast Reed–Solomon Interactive Oracle Proofs of Proximity). All of this parallelizes well, which is why the prover is the part you accelerate on GPUs—exactly the workload that benefits from running on SaladCloud.

Verification is deliberately lightweight. A verifier takes the proof, the public inputs, and the verification key and performs a small amount of work—typically a few pairings or an inner-product check in SNARKs, or a handful of hash lookups and FRI checks in STARKs. On a server this is quick; on-chain it’s still modest in compute terms, though gas costs matter. Throughout, the verifier learns nothing about the witness itself—only that the statement is true.

_{Diagram from https://docs.midnight.network/}

In simple terms: setup is the first step (when your scheme requires it) and establishes the keys; proving is the heavy lift that turns secrets and inputs into a succinct proof; verification is the fast final check that makes the result easy to trust.

Performance of Zero-Knowledge Proofs on GPUs

Zero-knowledge proving is dominated by a handful of algebraic kernels that are both highly parallel and memory-hungry. In SNARK stacks those are large NTT/FFT stages and MSMs on elliptic curves; in STARK stacks, you also see big hash-driven stages (Merkle/FRI) around an execution trace. When MSM is well-optimized on the device, studies find NTT often becomes the main bottleneck—accounting for a large share of wall-clock time—and end-to-end GPU implementations can deliver order-of-magnitude speedups versus CPU baselines. That mix of wide parallelism and streaming access patterns is exactly what modern GPUs are built for. arXiv

You don’t need datacenter-only hardware to benefit. Several open zkVM (zero-knowledge virtual machine) and prover stacks officially support single, consumer-grade GPUs: RISC Zero exposes a one-flag CUDA path for its prover, zkSync’s Airbender advertises single-GPU block proving from RTX 4090 up to H100, and SP1 documents GPU proving with a practical floor around 24 GB of VRAM (video RAM) and Compute Capability ≥ 8.6.

Many provers are already open source and optimized for running on GPUs. Airbender has public releases and CUDA components; SP1 provides GPU requirements and container-runtime notes; RISC Zero’s prover can be toggled to CUDA; and acceleration libraries like ICICLE make MSM/NTT/hash kernels pluggable in your own images. Some of the solutions are already containerized or have straightforward instructions to do so. That means you can run your own provers on compute of your choice—SaladCloud, for example.

Proving time and cost

A great source of real time proofs metadata is https://ethproofs.org/.

EthProofs is a block-proof explorer for Ethereum. It aggregates results from multiple zkVM teams to present a continuously updated view of proven blocks, along with key metrics such as cost, latency, and proving time. Users can compare proofs by block, download artifacts, and inspect rich proof metadata—size, clock cycles, and prover type—to better understand how each zkVM generates its proofs.

The project’s aim is to serve as a public good and evolve into a neutral standard for Ethereum block-execution proofs, eventually covering all blocks while keeping latency and costs reasonable.

EthProofs’ proof cost is typically based on compute prices from Vast.ai, RunPod, and AWS. We compared those prices for every proof with SaladCloud. The compute used typically has different amounts of CPU/RAM/storage but uses the same GPU class. ZKP proving mostly uses the GPU; CPU/RAM does not matter as much. However, to keep things fair we matched as much as possible while comparing cost with SaladCloud. Every row uses a single NVIDIA RTX 4090 as the baseline and only the vCPU/RAM configuration varies.

For each prover/cluster we take EthProofs’ average proving time and recalculate cost per proof using the same linear model.

As the table shows, running the same ZKP jobs on SaladCloud is about 20%–77% cheaper than the prices reported on other providers, depending on priority and configurations. Typical savings vs. RunPod/Vast are ~45%–69%, and with AWS ~63%–77% lower. Unlike other providers nodes on SaladCloud are granularly configurable, so most likely the costs would be even lower if we assign CPU and Memory that is actually needed to run the proofs. Because most proofs complete in seconds to a few minutes, using interruptible nodes is a safe and very profitable method.

Conclusion

Zero-knowledge proofs are a powerful building block that makes authentication and blockchain systems safer—letting prove facts without exposing the underlying data. They’re also a natural fit for GPU acceleration. As our comparison shows, running the same proving workloads on SaladCloud can cut costs by ~20% to as much as ~77% versus other GPU providers, depending on configuration and priority. Because most proofs finish in seconds to minutes, interruptiblecompute is a safe, practical choice—and it maps perfectly to short, GPU-heavy proving jobs.

Beyond cost reduction, SaladCloud provides geographically distributed, decentralized compute, which aligns with blockchain’s ethos of openness and resilience and transparent per-resource pricing, making cost-per-proof planning simple.

SaladCloud already operates thousands of GPUs and serves hundreds of AI customers—including ZKP teams—so you can start proving at scale quickly. To learn more, check out our site or contact our team.