zk-bench

	Polylang	Miden	Risc Zero	Noir
Frontend	Typescript-like	MASM (Assembly)	Rust, C, C++	Rust-like
ZK	STARK	STARK	STARK	SNARK
External Libraries	❌	❌	✅	❌
GPU	✅ Metal	✅ Metal	✅ Metal, CUDA	❌
Assert	0.03s	0.03s	6.94s	0.01s
SHA-256
1 byte	0.64s	0.64s	6.72s	1.86s
10 bytes	0.65s	0.65s	6.78s	1.81s
100 bytes	2.54s	2.54s	28.06s	1.87s
1000 bytes	22.14s	22.14s		3.81s
Fibonacci
1	0.03s	0.03s	6.73s	0.01s
10	0.03s	0.03s	6.72s	0.01s
100	0.03s	0.03s	6.72s	0.01s
1,000	0.09s	0.09s	6.73s	0.01s
10,000	0.64s	0.64s	13.72s	0.01s
100,000	10.49s	10.49s	115.34s	0.01s

Last Updated:

17 hours ago (6th September 2023)

FAQ

What is ZK?

ZK (Zero Knowledge) is a type of cryptography that allows a proof (a kind of certificate) to be generated that allows one party to prove to another that they know a value (or that some condition holds true), without revealing any information about the value itself.

There are two main components to ZK:

Zero Knowledge - the ability to run computation without revealing all of the inputs, but having the output be trusted
Provable computation - proves the code ran as designed, and therefore the output can be trusted

Here's a simple example to demonstrate the idea of provable computation. Below the code checks if the input provided is over 18. If we ran this in zero knowledge, we could generate a proof that the input value was > 18 without revealing the actual number:

function isOver18(age: number): boolean {
  return age > 18;
}

What’s the difference between a STARK and a SNARK?

These are two different approaches to provable zero knowledge computation.

You should prefix everything below with "in general" - there are always exceptions to the rule!

Feature	SNARK	STARK
Definition	Succinct Non-interactive ARguments of Knowledge	Scalable Transparent ARguments of Knowledge
Setup Phase	Typically requires a trusted setup to generate a shared secret key. Parameters must be kept secret	Does not require a trusted setup
Turing Completeness	Program must be bounded at compile time	Fully Turing complete
Transparency	Less transparent due to the trusted setup	More transparent due to the lack of a trusted setup
Proof Size	Generally produces shorter proofs	Generates longer proofs, proof size is still non-linear
Verification Time	Usually offers faster verification times	Slower verification, especially with larger data. Not suitable for Ethereum
Prover Time	Generally efficient but depends on the specific construction	Proving time can be longer, particularly for larger datasets
Cryptographic Assumptions	Relies on stronger, more specific assumptions	Relies on lesser cryptographic assumptions, more "future-proof"
Quantum Resistance	Generally not quantum-resistant	Generally quantum-resistant

How do you run the benchmarks?

We run the benchmarks using a Github Action using a self-hosted runner, running on a dedicated AWS instance. We use a dedicated instance to ensure that the performance calculations are not degraded by other users that might otherwise be using a shared instance. Benchmarks are updated automatically whenever we add, update benchmarks or the versions on the underlying frameworks.

Which is the best framework?

There is no “best” framework. As you can see from the table above, there are a lot of caveats and trade offs. You should choose the framework that best meets your needs, which will depend on what kind of application you are building.

Can you benchmark X or add framework X?

Sure, just submit a PR 😉

Why did you make this?

We made ZK-bench to help the ZK community to better understand the trade-offs and performance of different frameworks.