12 Commits

Author SHA1 Message Date
Daniel Lubarov
018fb005f8
Move stuff around (#135)
No functional changes here. The biggest change was moving certain files into new directories like `plonk` and `iop` (for things like `Challenger` that could be used in STARKs or other IOPs). I also split a few files, renames, etc, but again nothing functional, so I don't think a careful review is necessary (just a sanity check).
2021-07-29 22:00:29 -07:00
Nicholas Ward
ffc90e902b exp_biguint test 2021-07-22 13:08:14 -07:00
Nicholas Ward
7f92a33964 cargo fmt 2021-07-21 13:05:40 -07:00
Nicholas Ward
1dd850b0e5 fixes 2021-07-21 13:05:32 -07:00
Nicholas Ward
906a0c00f4 Merge branch 'main' into order_bigint 2021-07-20 15:42:51 -07:00
Nicholas Ward
b103c0774f progress 2021-07-20 15:42:27 -07:00
Nicholas Ward
a74fce0196 quick fix 2021-07-19 17:11:42 -07:00
Nicholas Ward
8a51e6a323 started 2021-07-19 17:11:22 -07:00
wborgeaud
6b407e45ef Progress on FRI 2021-04-21 22:31:45 +02:00
Daniel Lubarov
74ce37250e Avoid separate exp calls 2021-04-05 11:39:16 -07:00
Daniel Lubarov
37761a32e8 Simplify as per William's comment 2021-04-04 15:26:38 -07:00
Daniel Lubarov
cb1c69e50f Validate that the cosets for Plonk's permutation argument are disjoint
When we had a large field, we could just pick random shifts, and get disjoint cosets with high probability. With a 64-bit field, I think the probability of a collision is non-negligible (something like 1 in a million), so we should probably verify that the cosets are disjoint.

If there are any concerns with this method (or if it's just confusing), I think it would also be reasonable to use the brute force approach of explicitly computing the cosets and checking that they're disjoint. I coded that as well, and it took like 80ms, so not really a big deal since it's a one-time preprocessing cost.

Also fixes some overflow bugs in the inversion code.
2021-04-04 14:34:33 -07:00