595e751ac1
The goal here is to end up with a single "root" circuit representing any EVM proof. I.e. it must verify each STARK, but be general enough to work with any combination of STARK sizes (within some range of sizes that we chose to support). This root circuit can then be plugged into our aggregation circuit. In particular, for each STARK, and for each initial `degree_bits` (within a range that we choose to support), this adds a "shrinking chain" of circuits. Such a chain shrinks a STARK proof from that initial `degree_bits` down to a constant, `THRESHOLD_DEGREE_BITS`. The root circuit then combines these shrunk-to-constant proofs for each table. It's similar to `RecursiveAllProof::verify_circuit`; I adapted the code from there and I think we can remove it after. The main difference is that now instead of having one verification key per STARK, we have several possible VKs, one per initial `degree_bits`. We bake the list of possible VKs into the root circuit, and have the prover indicate the index of the VK they're actually using. This also partially removes the default feature of CTLs. So far we've used filters instead of defaults. Until now it was easy to keep supporting defaults just in case, but here maintaining support would require some more work. E.g. we couldn't use `exp_u64` any more, since the size delta is now dynamic, it can't be hardcoded. If there are no concerns, I'll fully remove the feature after.
Plonky2 & more
This repository was originally for Plonky2, a SNARK implementation based on techniques from PLONK and FRI. It has since expanded to include tools such as Starky, a highly performant STARK implementation.
Documentation
For more details about the Plonky2 argument system, see this writeup.
Building
Plonky2 requires a recent nightly toolchain, although we plan to transition to stable in the future.
To use a nightly toolchain for Plonky2 by default, you can run
rustup override set nightly
in the Plonky2 directory.
Running
To see recursion performance, one can run this bench, which generates a chain of three recursion proofs:
RUSTFLAGS=-Ctarget-cpu=native cargo run --release --example bench_recursion -- -vv
Jemalloc
Plonky2 prefers the Jemalloc memory allocator due to its superior performance. To use it, include jemallocator = "0.5.0" inCargo.tomland add the following lines
to your main.rs:
use jemallocator::Jemalloc;
#[global_allocator]
static GLOBAL: Jemalloc = Jemalloc;
Jemalloc is known to cause crashes when a binary compiled for x86 is run on an Apple silicon-based Mac under Rosetta 2. If you are experiencing crashes on your Apple silicon Mac, run rustc --print target-libdir. The output should contain aarch64-apple-darwin. If the output contains x86_64-apple-darwin, then you are running the Rust toolchain for x86; we recommend switching to the native ARM version.
Licenses
As this is a monorepo, see the individual crates within for license information.
Security
This code has not yet been audited, and should not be used in any production systems.
While Plonky2 is configurable, its defaults generally target 100 bits of security. The default FRI configuration targets 100 bits of conjectured security based on the conjecture in ethSTARK.
Plonky2's default hash function is Poseidon, configured with 8 full rounds, 22 partial rounds, a width of 12 field elements (each ~64 bits), and an S-box of x^7. BBLP22 suggests that this configuration may have around 95 bits of security, falling a bit short of our 100 bit target.