16 Commits

Author SHA1 Message Date
Daniel Lubarov
ff80f28b93 Revert "Set CI to use an older version of nightly"
This reverts commit da23fb116b934925f8a5cf37c2f1f092452fdc4d.
2023-02-10 23:10:39 -08:00
Daniel Lubarov
137bc78565 Prep for publishing to crates.io 2023-01-30 13:18:06 -08:00
Daniel Lubarov
595e751ac1 Shrink STARK proofs to a constant degree
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.
2023-01-01 23:11:39 -08:00
wborgeaud
e712986a92 Challenger state works 2022-09-23 13:41:14 +02:00
Daniel Lubarov
aa87f2c3ba Public memory 2022-08-25 20:19:18 -07:00
Sebastien La Duca
e48bfa837f fmt 2022-07-24 18:06:03 -04:00
Sebastien La Duca
c9d610ec10 use maybe_rayon in starky and evm 2022-07-24 17:47:14 -04:00
Daniel Lubarov
e73d01a037
packed_field -> packed (#584)
* `packed_field` -> `packed`

For cleaner imports; "field" is usually clear from context

* fix
2022-06-27 15:07:52 -07:00
Daniel Lubarov
3346d3f902
field_types -> types (#583)
* `field_types` -> `types`

Here too, I think "field" is usually clear from context, e.g. in `use plonky2::field::types::Field;`.

* fixes

* fmt
2022-06-27 12:24:09 -07:00
Daniel Lubarov
410e03349c
extension_field -> extension (#581)
It seems redundant in most contexts, e.g. `use plonky2::field::extension_field::Extendable;`. One could import `extension_field`, but it's not that common in Rust, and `field::extension` is now about as short.
2022-06-27 07:18:21 -07:00
wborgeaud
ccc9c024a2 Change some fn to take iterators instead of slices 2022-06-03 19:20:19 +02:00
wborgeaud
fd7eb9e915 PR feedback and add reduce_with_powers_circuit fn 2022-05-30 20:13:25 +02:00
wborgeaud
bd738399dd Clippy 2022-05-26 20:44:59 +02:00
wborgeaud
d47b22d2b5 Compiles 2022-05-24 16:24:52 +02:00
wborgeaud
8e8e4daa9c Start of impl 2022-05-20 11:21:13 +02:00
Daniel Lubarov
c54896dcb8
Rename starky2 -> evm (#547) 2022-05-18 10:32:14 -07:00