Daniel Lubarov
3619c2dd1a
Merge pull request #42 from mir-protocol/interpolation_gate
...
Interpolation gate
2021-05-20 05:36:17 -07:00
Daniel Lubarov
a4be58557e
Fix GMiMCGate
2021-05-20 05:35:16 -07:00
Daniel Lubarov
747974558f
Add test_low_degree for other gates
2021-05-20 05:27:56 -07:00
Daniel Lubarov
229784e574
Delete old FRI gate
2021-05-20 05:27:47 -07:00
Daniel Lubarov
621b097a70
Address most feedback
2021-05-20 05:15:25 -07:00
Daniel Lubarov
d05513475c
Not just quartic
2021-05-19 23:07:24 -07:00
Daniel Lubarov
6e83d956e9
Finish up
2021-05-19 23:03:52 -07:00
Daniel Lubarov
3311981fc4
Minor
2021-05-19 15:57:28 -07:00
Daniel Lubarov
0ce1a4c5eb
Minor
2021-05-19 15:13:33 -07:00
Daniel Lubarov
110763fa79
Minor
2021-05-19 15:00:35 -07:00
Daniel Lubarov
b535bf239a
Minor
2021-05-19 12:24:19 -07:00
Daniel Lubarov
227c80c82e
fmt
2021-05-19 12:10:41 -07:00
Daniel Lubarov
c6fa7eb18e
Minor
2021-05-19 12:10:41 -07:00
Daniel Lubarov
0c91739b3b
[DRAFT] Interpolation gate
...
Over quartic field extension (for now). This would be used in our FRI recursive verifier later, for the consistency check.
To summarize the wires,
- `n` inputs for the `n` points to interpolate (don't need `4n` since they'll be in the subgroup of the base field)
- `4n` inputs for the `n` (extension field) values to interpolate
- `4` inputs for the point to evaluate the interpolant at (beta, which will be drawn from the extension field right?)
- `4` outputs for the interpolated value
- `4n` internal wires for the interpolant's coefficients
This definitely isn't the most optimal approach, e.g. we could route in a single "base" point and derive its neighboring points, but just wanted to keep it simple for now.
2021-05-19 12:10:41 -07:00
wborgeaud
965c4e4da5
Merge pull request #45 from mir-protocol/remove-exp-self
...
Change `Field::exp` to using a `u64` power.
2021-05-19 20:28:47 +02:00
wborgeaud
b438760f72
Use bits_u64
2021-05-19 20:22:20 +02:00
wborgeaud
78f71672a3
Change Field::exp to using a u64 power.
2021-05-19 12:17:43 +02:00
wborgeaud
7d302aac34
Merge pull request #44 from mir-protocol/fri-extension-field
...
FRI with extension fields
2021-05-19 09:46:09 +02:00
wborgeaud
e806d86f86
Remove custom primitive_root_of_unity in extension fields by modifying the generators.
2021-05-19 09:35:39 +02:00
wborgeaud
1cbd12edbd
Fixes based on PR comments
2021-05-18 22:22:15 +02:00
wborgeaud
8737c8d5b9
revert extension field order
2021-05-18 16:37:21 +02:00
wborgeaud
4f6f2192ab
Minor fixes
2021-05-18 16:23:44 +02:00
wborgeaud
96a880193c
Clippy
2021-05-18 16:09:22 +02:00
wborgeaud
9cd00532ce
Generic tests
2021-05-18 16:06:47 +02:00
wborgeaud
adf5c2d4ec
Const generics everywhere
2021-05-18 15:44:50 +02:00
wborgeaud
37f6ee53cc
Merge branch 'main' into fri-extension-field
2021-05-18 15:28:42 +02:00
wborgeaud
a2cf2c03b6
Working FRI with field extensions
2021-05-18 15:22:06 +02:00
Daniel Lubarov
cb4c420dcf
Merge pull request #43 from mir-protocol/poly_inv_fix
...
Fix intermittent inv_mod_xn failure
2021-05-17 12:31:43 -07:00
Daniel Lubarov
1e5dfa405b
Fix intermittent inv_mod_xn failure
...
My recent change made `padded` panic if the padded length is less than the current length. I figured that might indicate that something unexpected was going on, so might be good to fail fast.
It looks like `inv_mod_xn` was relying on the old `padded` behavior, and it seems correct AFAIK, i.e. in this case it wasn't a symptom of anything going wrong.
We could also restore the old behavior of `padded` if you prefer; let me know if you have a preferennce.
2021-05-17 10:37:43 -07:00
BGluth
ecce373b2a
Merge pull request #41 from mir-protocol/os_rng_to_thread_rng
...
Switched over from OsRng --> thread_rng
2021-05-17 09:15:54 -06:00
Daniel Lubarov
bd20ffa52d
cargo fmt
2021-05-16 17:24:45 -07:00
BGluth
949fb879cc
Switched over from OsRng --> thread_rng
...
- At least on my Linux machine, a signiciant amount of time (> 50%) was spent inside
OsRng.
- Likely due to blocking behaviour of the rng devices on Linux.
- thread_rng should not block, but at the same time should provide good
enough rng.
2021-05-14 20:15:03 -06:00
Daniel Lubarov
de0b382fb6
Merge pull request #39 from mir-protocol/three_zeta
...
Use num_checks zetas
2021-05-14 08:07:34 -07:00
Daniel Lubarov
7ff5496308
num_checks -> num_challenges
2021-05-14 08:07:00 -07:00
Daniel Lubarov
13fc0c2261
Merge pull request #40 from mir-protocol/move_timed
...
Move timed! and call from ListPolynomialCommitment
2021-05-14 08:04:22 -07:00
Daniel Lubarov
b14328c2df
Move timed! and call from ListPolynomialCommitment
2021-05-14 07:35:09 -07:00
Daniel Lubarov
17b51dc16e
Merge pull request #38 from mir-protocol/more_poly
...
Finish merging in old_polynomial
2021-05-14 06:50:11 -07:00
Daniel Lubarov
f45c8d9520
Remove old field search code
...
We've moved on to better options.
2021-05-13 22:45:46 -07:00
Daniel Lubarov
78af8830cb
Old TODO
2021-05-13 21:36:25 -07:00
Daniel Lubarov
a04bed282d
Use num_checks zetas
...
The soundness error is (degree of combined constraints)/|F|, so three zetas should be appropriate for all practical circuit sizes.
2021-05-13 21:32:08 -07:00
Daniel Lubarov
7f445686ee
Tweaks
2021-05-13 15:44:36 -07:00
Daniel Lubarov
6d03dd06f5
Finish merging in old_polynomial
2021-05-13 15:35:26 -07:00
Daniel Lubarov
18d59ec9de
Fix minor post-merge conflicts
2021-05-12 11:26:21 -07:00
Daniel Lubarov
51114e4ef6
Missing import
2021-05-12 11:21:31 -07:00
Daniel Lubarov
b7acdb36ca
Merge pull request #36 from mir-protocol/poly_port
...
Some cleanup related to the two polynomial APIs
2021-05-12 10:55:43 -07:00
Daniel Lubarov
22a625e86d
trim b
2021-05-12 10:33:36 -07:00
wborgeaud
ec5416344c
Merge pull request #37 from mir-protocol/extension-field
...
Extension field
2021-05-11 21:08:36 +02:00
wborgeaud
1e45b0b1c0
Move Frobenius to default trait implementation.
2021-05-11 20:58:04 +02:00
wborgeaud
75711f1d3f
Merge branch 'main' into extension-field
2021-05-11 15:28:25 +02:00
wborgeaud
f1d812812e
Added field order test
2021-05-11 15:26:20 +02:00
