Owners: @Thomas Lavaur @Mehmet

Summary

Os: Ubuntu 22.04.4 LTS 64 bits

Memory: 32,0 GiB

Processor: Intel® Core™ i7-10850H CPU @ 2.70GHz × 12

Graphics: NVIDIA Corporation TU117GLM [Quadro T1000 Mobile] / Mesa Intel® UHD Graphics (CML GT2) (⇒ Used the Quadro with cuda)

Rust: 1.79

ZKVM (name) Risc0 SP1 Valida Jolt Nexus Lurk Cairo-VM Miden PSE/Taiko/Scroll zkevm Hermez Boojum Eigen zkVM zkwasm OlaVM Triton VM
Company Risc0 Succinct Labs Lita Fundation a16z crypto Nexus Argument Computer Starkware Polygon Scroll, Taiko, Ethereum Fundation Polygon ZKSync EigenLabs DelphinusLab sin7Y Neptune protocol
Ready for Production ✅* ✅* alpha release ❌ ✅(from github) ❌ ✅(from github) ❌(from github) ✅ (already deployed on Scroll rollup) Not mentioned ✅ (already deployed on their rollup) ❌(from github) ❌ (documentation no finished) ❌ (testnet alpha) ❌(from github)
Proving System(s) STARKs STARKs STARKs Lasso (type of SNARKs) Nova (Folding) SNARKs STARKs STARKs SNARKs STARKs STARKs STARKs, SNARs SNARKs STARKs STARKs
ZK building blocs FRI,Plonk, Plookup, DEEP-ALI, Groth16 Plonky3, Plonk, Groth16 Plonky3 KZG, Hyrax, Binius, (Planning to add Groth16 for proof recursion) Nova, CycleFold, Protostar, Spartan, Zeromorph, (also planning to add Groth16) plonky3, fork of SP1 FRI STARKs recursion Halo2 Groth16, Plonk, FRI Plonkish arithmetization, FRI, cq (lookup argument), recursion with Halo2, RedShift Plonk, KZG, Starky, starkjs, Groth16, plookup Halo2 Starky, Plonky2 FRI
Finite field Goldilock, baby-bear Goldilock, baby-bear, Bn254, bls12-381 Goldilock, baby-bear, M31, Binius (binary field) Bn254 Cycles of curve (pallas-vesta) (bn245-grumpkin) Goldilock, baby-bear, Bn254, bls12-381 Goldilock, M31 Goldilock BN128, BN128, Goldilocks Goldilocks BN128, BLS12-381, Godilock BN128, BLS12-381, Jubjub Goldilock Goldilock
Security (bits) 98 bits of conjectured security Considering the fields it operates in, it's believed to be above 96 bits, but the exact result hasn't been determined approximately 128 bits above 100 bits For Stwo: approx 124 - log polynomial size + 12 bits of grinding 96 by default not found but BN128 is less than 100 bits (96 bits in the code but it’s a parameter) not found but BN128 is less than 100 bits “approximately 100 bits” with grinding to achieve this level less than 100 bits for BN128, 128 bits for BLS, not sure for starks less than 100 bits for BN128, 128 bits for BLS 96 bits 160 bits
Call to prover Language Rust Rust Rust Rust Rust Rust Python, Rust, WebAssembly Rust Rust C++, JavaScrypt, Go Rust Rust Command line Rust Rust
Proof Programming Language Rust Rust Valida instruction set Rust Rust Lurk Cairo Miden Assembly EVM EVM LLVM PIL Wasm Assembler like in Rust or not
Language compiler developed C, Wasm, Any program that can be compile into LLVM (elf file) Any program that can be compile into LLVM (elf file) ValidaIR (any program that can be compile into LLVM), Rust,C , C++, Solidity, still a WIP Rust Rust, From their doc any high-level but not found in their code None Solidity* (using the Kakarot zkEVM) Yul, MidenIR, //
rust and wasm soon Solidity? Solidity Solidity, Vyper, Yul None Wasm, C, C++, Go, Rust, Assembly script, JavaScript, and compiler that compile to Wasm None
Future language compiler ? ? ? ? ? ? None “Rust, Move, Sway, and others” ? PIL (with pilcom) ? ? ? None None
Instruction Set Risc-V Risc-V Specific Risc-V Risc-V transform Lurk to Risc-V Specific (CASM but I didn’t find documentation) Specific EVM opcodes mostly EVM op Specific Risc-V Wasm Bytecode Risc-V Specific (not to be considered final**)**
SDK ? “SDK support exists for Rust, C, and C⁠+⁠+.” Jolt-sdk Nexus-sdk None None Typescript soon None Only for their rollup Only for their rollup Rust js_sdk None
Support GPU? ✅ beta version ❌ not yet ❌ ❌ not yet ? ✅ with Stwo ✅ Only Apple with Metal ❌* ❌ not yet ✅ ✅* (not open source) ✅ ❌not yet ?
Support wrapping? ✅ STARK -> SNARK wrapping ❌Planning to add Groth16 wrapper in the future ❌ Planning to add Groth16 wrapper in the future support folding ❌ ❌ but may be adapted from Polygon wrapper ❌ ✅ ✅ ✅ ✅ in circom ❌ ❌
100 Hash (256 bits) Proving Time on CPU 28.92 s Core: 22.07 s, cannot run others on my laptop //BIG MACHINE Core: 4.74 s Compressed: 173.9 s, PLONK: Not enough RAM 43.1s Hyrax: 17.33 s, Zeromorph: 32.03 s, Hyper-KZG: 35.13s nova-seq: 21 s, nova-par: 35.4 s, nova-par-com: 31.3 s (after a lot of time loading things) (the time is longer on the big machine). sphinx: 910.53 ms Using Giza (winterfell without trace generation time) 30ms 71ms and 865ms with recursion (with 38% of padding for the minimum number of VM cycles) Can only prove ETH blocks Skipped for now (require 115Go for installation) More research needed to know how to compile the code to this VM doesn’t work for now (script errors) cannot prove fibonacci in less than 20s and the process was killed running out of memory (we skipped the SHA256 circuit) Mocked for different reasons explaines in the disadvantages Native Hash like Miden which is using Tip5 permutation function : 1.7311 s
Wrapping Time on CPU ~94 s (independent of the program) See above for PLONK (no Groth16) ❌ ❌ cannot run on my laptop //BIG MACHINE 37 min to load the SRS and the process was killed during spartan key generation (Not enough RAM) ❌ ❌ ❌
Proof size 217.4 KB before wrapping and 256 B Core: 5.6 MB, Compressed: 1.526 MB, Plonk: 765.5 KB Hyrax: 2,380.5 KB, Zeromorph: 473.8 KB, Hyper-KZG: 490.9 KB nova-seq: 47.9 MB, nova-par: 69.7 MB, nova-par-com: 69.7 MB sphinx : 2283903 B ⇒ 2.283 MB Giza: 164.5 KB 56.3 KB without recursion, 73.3 KB with recursion 698.43 KiB
Hash Proving Time on GPU
Wrapping Time on GPU
Date of evaluation / Version 12/08 risc 1.0.5 12/08 version 1.1.1 13/08 llvm compiler v0.3.0-alpha 12/08 Nexus zkVM v0.2.1 05/09 0.10.3 0.12. 6.0.2 19/08 0.0.5 20/08 20/08
Maintained ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ❌by PSE as they switch to zkVM but ✅ by Scroll Slow (once a month) ✅ ✅ Slow (once a month) ✅ ✅
Advantages Fast enough, easy to develop apps in C, Wasm and Rust (possibly more with LLVM), has a wrapper with correct wrapping time. Support wrapping both on BN and BLS, proofs seems to be faster to generate, Can be used with any LLVM program. Use more recent techniques (Plonky3). A compiler from LLVM to their instruction set. Use recent techniques (Plonky3). An original VM that has a different architecture compare to the others. It’s only based on very recent research only using SNARKs. The security level is a bit higher and the proof time reasonable. Can compile from Rust code An original VM that has a different architecture compare to the others. Based on the Nova folding scheme. Proof time are correct. Fast proof system Cairo-vm is compatible with several STARK provers like Stone and Stwo that support Circle Stark. Very very fast prover (for hashes and Merkle path as they have their dedicated opcode). Proof sizes are smaller than the others. ? ? ? ? ? ? The proof is faster than other VMs. The security level is way higher than the others (160 bits).
Disadvantages Not the fastest, it’s a bit hard to know if a Rust crate will be compatible or not before testing (they claim 71% of top crates) Use Plonk as a wrapper (bigger than Groth16). Big proofs and a lot of RAM needed for the proof generation (and even more for setup generation). Not a clear claimed security level. No wrapper (but a planned one). Their annonced time is way better than the reality (they compare with risc0 only on one hash which doesn’t make sense as risc0 require a minimum number of cycles). In conclusion their proof generation time is worst than the others. They use their own instruction set. Not a clear claimed security level. No wrapper (but a planned one). Proof are bigger. And it doesn’t support GPU acceleration (no communication on this subject yet) No wrapper exist while the proofs are HUGE. a lot of time and RAM are needed at the beging of proving for loading the SRS (this could be done only once if the prover is loaded as a server and wait for proving tasks). Specific language that is hard to write function with, no wrapper, doesn’t support GPU, a bit niche, not documented well.

Very big proofs | There is no wrapper, no compiler except from Solidity using Kakarot. Provers are hard to link to the cairo-vm (the Stwo prover is not ready yet for Cairo but is fastly evolving). They use their own instruction set in their own language. It’s promising but for now it’s worst than the other STARK zkVMs. | No wrapper, no compilers ready for now. The Miden assembly langugage in close to assembler code that is hard to produce. Promising time and size but not developper friendly at all. | It’s a full zkEVM meaning it really only prove state transition taking Ethereum blocks as input. | It’s a zkEVM that require a lot of space for installation. We decided to skip it for this reason. | Boojum looks like it’s just a prover (as Stwo) and more research is needed to connect a real zkVM to this prover. | The provided code cannot even be executed without errors. | The fibonacci example provided took more than 20s while it’s way simpler than a chain of 100 hashes. Moreover, the process was kill on my computer running out of memory before the end. Taking too much ressources, we discarded this VM. | Their documentation isn’t up to date. The commands needed to executes and compile a program are no the same as the one exposed in the documentation/ readme. The documentation is incomplete. The code need to be written in Ola language or in assembly code. | The native hash is really new (Tip5). There is no wrapper and the proof is bigger than the first VMs. The instruction set is specific and you have to write your code directly in their assembly code without compiler. Writting a simple program is tedious and hard to debug. | | Miscealenous | Whitepaper, their is a minimum number of 2**16 cycles, could replace rapidsnark groth16 prover with tachyon, measured with criterion | Blog post Can be used for aggregation, measured with std::time | specification | paper, measured with std::time | specification | highly active forum | Kakarot is a zkEVM built on Cairo-vm (can compile solidity). Blog post about Stwo. A new AIR for Blake hash, cannot prove with Stow but it’s fastly evolving | documentation It may also be compatible with Stwo, natively use Rescue as 1 assembly operation making it really quick | documentation | Mainly build for the Polygon rollup | Mainly built for the ZkSync Ethereum zk-rollup | proof architecture | documentation (WIP) | whitepaper Breakdown PCS | | | Licence(s) | Apache License 2.0 | Apache License 2.0 and MIT | Apache License 2.0 and MIT | MIT | Apache License 2.0 and MIT | MIT | Apache License 2.0 | MIT | MIT | Polygon zkEVM Mainnet Beta | Apache License 2.0 and MIT | Apache License 2.0 | Apache License 2.0 | MIT | Apache License 2.0 |

zk-vm's.jpg

Comments

  1. The Stwo prover is in very early beta
  2. Starknet doesn’t have a Groth16 wrapper implemented yet technically, nothing should stop them or even we to implement it, but it's a lot of work and probably not exactly high priority for them
  3. We can use Risc0 or SP1 meantime, and switch at a future point when Stwo is ready. one thing to keep in mind is that StarkWare use their own language/ISA, it's not risc-v, so the statement programs written for Risc0/SP1 will probably need to be rewritten
  4. Valida is quite fast (though not all benchmarks are representative) It's also in very early stages though, they don't even have proof recursion, so aggregation will be problematic
  5. Valida also use their own ISA, but they have an LLVM frontend, so we can write our statement in Rust (C, Go etc is planned, but seems not yet implemented)