Unified Recursion Circuit for Multi-Degree Starky Proof Verification #1635

sai-deng · 2024-11-01T17:27:12Z

This PR introduces an enhanced recursion circuit that supports Starky proof verification across multiple degrees. This work significantly reduces the number of recursion circuits needed for zkVM/zkEVM proof recursion. Although the new circuit adds approximately 1000-4000 more gates compared to the previous fixed-degree recursion circuit, the padded circuit size remains unchanged for commonly used cases within the 2^22 - 2^26 range (fibonacci_stark). Additionally, the extra gates added for the more complex recursive circuit (e.g. Keccak STARK) can be considered negligible.

Circuit Size Comparison (fibonacci_stark):

degree bits (old)	circuit size (old)	circuit size after padding (old)	degree bits (new)	circuit size (new)	circuit size after padding (new)
14	4668	8192	4-14	5781	8192
18	6889	8192	4-18	8488	16384
22	9417	16384	4-22	12126	16384
26	12289	16384	4-26	15633	16384
30	15502	16384	4-30	19480	32768

Example: In the previous setup, the recursion circuit supported proof verification at degree bits 22 with a final degree of 16384. The updated recursion circuit supports proof verification across degree bits from 4 to 22 while retaining the final degree of 16384.

Old Circuit Details:

[DEBUG plonky2::util::context_tree] 9416 gates to root
[DEBUG plonky2::util::context_tree] | 112 gates to verify one (of 84) query rounds
[DEBUG plonky2::plonk::circuit_builder] Total gate counts:
[DEBUG plonky2::plonk::circuit_builder] - 31 instances of MulExtensionGate { num_ops: 13 }
[DEBUG plonky2::plonk::circuit_builder] - 84 instances of ArithmeticExtensionGate { num_ops: 10 }
[DEBUG plonky2::plonk::circuit_builder] - 226 instances of ArithmeticGate { num_ops: 20 }
[DEBUG plonky2::plonk::circuit_builder] - 336 instances of CosetInterpolationGate { subgroup_bits: 4, degree: 6, barycentric_weights: [17293822565076172801, 256, 1048576, 4294967296, 17592186044416, 72057594037927936, 68719476720, 281474976645120, 1152921504338411520, 18446744069414584065, 18446744069413535745, 18446744065119617025, 18446726477228539905, 18374686475376656385, 18446744000695107601, 18446462594437939201], _phantom: PhantomData<plonky2_field::goldilocks_field::GoldilocksField> }<D=2>
[DEBUG plonky2::plonk::circuit_builder] - 168 instances of ReducingExtensionGate { num_coeffs: 32 }
[DEBUG plonky2::plonk::circuit_builder] - 672 instances of RandomAccessGate { bits: 4, num_copies: 4, num_extra_constants: 2, _phantom: PhantomData<plonky2_field::goldilocks_field::GoldilocksField> }<D=2>
[DEBUG plonky2::plonk::circuit_builder] - 7638 instances of PoseidonGate(PhantomData<plonky2_field::goldilocks_field::GoldilocksField>)<WIDTH=12>
[DEBUG plonky2::plonk::circuit_builder] - 174 instances of BaseSumGate { num_limbs: 63 } + Base: 2
[DEBUG plonky2::plonk::circuit_builder] - 87 instances of ExponentiationGate { num_power_bits: 66, _phantom: PhantomData<plonky2_field::goldilocks_field::GoldilocksField> }<D=2>
[DEBUG plonky2::plonk::circuit_builder] Degree before blinding & padding: 9417
[DEBUG plonky2::plonk::circuit_builder] Degree after blinding & padding: 16384

New Circuit Details:

[DEBUG plonky2::util::context_tree] 12125 gates to root
[DEBUG plonky2::util::context_tree] | 143 gates to verify one (of 84) query rounds
[DEBUG plonky2::plonk::circuit_builder] Total gate counts:
[DEBUG plonky2::plonk::circuit_builder] - 31 instances of MulExtensionGate { num_ops: 13 }
[DEBUG plonky2::plonk::circuit_builder] - 151 instances of ArithmeticExtensionGate { num_ops: 10 }
[DEBUG plonky2::plonk::circuit_builder] - 1608 instances of ArithmeticGate { num_ops: 20 }
[DEBUG plonky2::plonk::circuit_builder] - 336 instances of CosetInterpolationGate { subgroup_bits: 4, degree: 6, barycentric_weights: [17293822565076172801, 256, 1048576, 4294967296, 17592186044416, 72057594037927936, 68719476720, 281474976645120, 1152921504338411520, 18446744069414584065, 18446744069413535745, 18446744065119617025, 18446726477228539905, 18374686475376656385, 18446744000695107601, 18446462594437939201], _phantom: PhantomData<plonky2_field::goldilocks_field::GoldilocksField> }<D=2>
[DEBUG plonky2::plonk::circuit_builder] - 168 instances of ReducingExtensionGate { num_coeffs: 32 }
[DEBUG plonky2::plonk::circuit_builder] - 1092 instances of RandomAccessGate { bits: 5, num_copies: 2, num_extra_constants: 2, _phantom: PhantomData<plonky2_field::goldilocks_field::GoldilocksField> }<D=2>
[DEBUG plonky2::plonk::circuit_builder] - 7638 instances of PoseidonGate(PhantomData<plonky2_field::goldilocks_field::GoldilocksField>)<WIDTH=12>
[DEBUG plonky2::plonk::circuit_builder] - 255 instances of ExponentiationGate { num_power_bits: 66, _phantom: PhantomData<plonky2_field::goldilocks_field::GoldilocksField> }<D=2>
[DEBUG plonky2::plonk::circuit_builder] - 174 instances of BaseSumGate { num_limbs: 63 } + Base: 2
[DEBUG plonky2::plonk::circuit_builder] - 672 instances of RandomAccessGate { bits: 4, num_copies: 4, num_extra_constants: 2, _phantom: PhantomData<plonky2_field::goldilocks_field::GoldilocksField> }<D=2>
[DEBUG plonky2::plonk::circuit_builder] Degree before blinding & padding: 12126
[DEBUG plonky2::plonk::circuit_builder] Degree after blinding & padding: 16384

sai-deng · 2024-11-15T18:51:50Z

I would like to provide some clarification based on my offline discussion with @hratoanina

Currently, we only support maximum degree bits of {30, 26, 22, 18, …} in the recursive verifier circuit, as they generate the max final polynomial length when using the default configuration ConstantArityBits(4, 5). This ensures that for other degrees, the final proof polynomial will not be longer than the circuit’s final polynomial length.

We will always pad the proof with smaller degree bits (than the circuit’s degree bits) with zeros to Merkle proofs and final polynomials and "skip" some FRI steps or hashing steps in Merkle verification. Compared to the previous method, degree bits are now variables instead of constants.

This PR does not affect the speed of the provers or alter any security assumptions of STARK.

LindaGuiga

Globally, I think it would be better to have more comments, and I think it would be beneficial to have one big paragraph explaining how the multiple degrees work. So it would be nice to explain the verifier has a max number of folding steps and some are skipped if the actual degree is lower.

In addition, saying the FRI strategy has to be the same across proofs using this multi-degree circuit would be nice.

Finally, I think the degrees you mentioned above (and in the test) are off by one, aren't they? (Shouldn't it be 29, 25, ... instead of 30, 26, ...?)

Thanks for this work though, it is really great!

LindaGuiga · 2024-11-21T09:31:41Z

plonky2/src/fri/prover.rs

+        let zero_cap = vec![F::ZERO; cap_len];
+        for _ in fri_params.reduction_arity_bits.len()..step_count {
+            challenger.observe_elements(&zero_cap);
+            challenger.get_extension_challenge::<D>();


Why do we need this? We just need to observe, but we don't need a challenge, do we?

Yes, we need to observe and get a challenge here, as we want the challenger to be in sync with the verifier.

LindaGuiga · 2024-11-21T11:45:55Z

plonky2/src/fri/recursive_verifier.rs

+        let log_n = params.config.rate_bits + params.degree_bits;
+        let mut current_log_n = self.constant(F::from_canonical_usize(params.config.rate_bits));
+        current_log_n = self.add(current_log_n, current_degree_bits);
+        let min_log_n_to_support = log_n - (params.degree_bits - min_degree_bits_to_support);


Nit: I think it would be a tad clearer to write it like this instead:

Suggested change

let min_log_n_to_support = log_n - (params.degree_bits - min_degree_bits_to_support);

let min_log_n_to_support = params.config.rate_bits + min_degree_bits_to_support;

LindaGuiga · 2024-11-21T14:02:35Z

plonky2/src/fri/recursive_verifier.rs

+
+        let mut index_in_degree_sub_one_bits_vec = {
+            let mut degree_bits_len = degree_sub_one_bits_vec.len();
+            for artity_bits in &params.reduction_arity_bits {


nit

Suggested change

for artity_bits in &params.reduction_arity_bits {

for arity_bits in &params.reduction_arity_bits {

LindaGuiga · 2024-11-21T18:25:54Z

plonky2/src/gadgets/random_access.rs

@@ -39,6 +41,20 @@ impl<F: RichField + Extendable<D>, const D: usize> CircuitBuilder<F, D> {
        claimed_element
    }

+    /// Like `random_access`, but padding `v` with the last element to a power of two.


Maybe add that this is necessary because random_access requires a power of two? (I'm not sure whether it would be better to add it here or to random_access directly)

Sounds good, I modified random_access directly.

LindaGuiga · 2024-11-21T19:21:35Z

plonky2/src/fri/challenges.rs

@@ -28,6 +32,8 @@ impl<F: RichField, H: Hasher<F>> Challenger<F, H> {
        pow_witness: F,
        degree_bits: usize,
        config: &FriConfig,
+        final_poly_coeff_len: Option<usize>,
+        query_round_step_count: Option<usize>,


I find this name unclear: maybe say that it's the max number of steps? So something like max_number_steps?

renamed to max_num_query_steps

hratoanina

Same comments as Linda, very nice work!

I have a general question about the method: it seems that an arbitrary reduction strategy for the multi-verifier is supported, as long as the prover correctly follows the same strategy, and skips steps as needed. Is it in the scope of this PR, or do you want to restrict it to ConstantArityBits strategies? In any case this should be clearly stated somewhere in the code.

sai-deng · 2024-11-22T17:17:02Z

Same comments as Linda, very nice work!

I have a general question about the method: it seems that an arbitrary reduction strategy for the multi-verifier is supported, as long as the prover correctly follows the same strategy, and skips steps as needed. Is it in the scope of this PR, or do you want to restrict it to ConstantArityBits strategies? In any case this should be clearly stated somewhere in the code.

We don’t have to, but I added checks to restrict it to ConstantArityBits, mainly because it is widely used and I want to avoid making this PR more complex.

sai-deng · 2024-11-22T17:36:10Z

Globally, I think it would be better to have more comments, and I think it would be beneficial to have one big paragraph explaining how the multiple degrees work. So it would be nice to explain the verifier has a max number of folding steps and some are skipped if the actual degree is lower.

In addition, saying the FRI strategy has to be the same across proofs using this multi-degree circuit would be nice.

Finally, I think the degrees you mentioned above (and in the test) are off by one, aren't they? (Shouldn't it be 29, 25, ... instead of 30, 26, ...?)

Thanks for this work though, it is really great!

The degrees are correct, as the final poly's degree_bits need to account for an additional bit due to the rate_bits.

sai-deng · 2024-11-22T18:42:00Z

Thanks for the reviews! All comments have been addressed. Additionally, we already have a fri_param check in the prover to ensure that the proof can be verified in a circuit with multi-degree support.

sai-deng added 15 commits October 26, 2024 16:10

add test

56bc632

wip

3d7c443

update witness util

78d3851

degree_bits: usize->target

b4213bb

wip

fc46e07

fix

99c3ccb

opt

8561399

passed 3 tests

8ea1952

fix

c231038

convert g to g_ext

cff4da4

hack observe final poly coeffs

13801e4

wip

de75e83

poc works

33836d5

wip

e685b9a

pass tests

02548a0

sai-deng self-assigned this Nov 7, 2024

sai-deng added 14 commits November 7, 2024 15:48

more in test

c9ea54c

better test

999532c

fix ci

9667294

clippy

773b695

fix

58196b8

fix

dcd973d

start on multi steps

b9c3365

wip

1eb7053

set all zeros

d94800f

wip

104ed57

challenge passes

a6fbf7c

work

6368726

poc done

309ecaa

fix non std build

de1c230

sai-deng changed the title ~~[wip] Sai/multi degrees recursion circuit~~ One recursion circuit for all degrees Nov 12, 2024

sai-deng changed the title ~~One recursion circuit for all degrees~~ Unified Recursion Circuit for Multi-Degree Proof Verification Nov 12, 2024

sai-deng changed the title ~~Unified Recursion Circuit for Multi-Degree Proof Verification~~ Unified Recursion Circuit for Multi-Degree Starky Proof Verification Nov 12, 2024

sai-deng marked this pull request as ready for review November 12, 2024 23:42

sai-deng requested review from wborgeaud, Nashtare and LindaGuiga as code owners November 12, 2024 23:42

sai-deng requested a review from hratoanina November 12, 2024 23:42

sai-deng added 2 commits November 15, 2024 09:56

update stark verifier

bafcf74

fix clippy

1e3c8b9

sai-deng force-pushed the sai/multi_degrees_recursion_circuit branch from 870bbe7 to 1e3c8b9 Compare November 15, 2024 17:59

sai-deng added 2 commits November 15, 2024 10:37

fix test build

f31babe

fix tests

8572c81

sai-deng added 4 commits November 15, 2024 10:56

add comments

93ba39c

add checks

853acb4

polish the checks

281d738

more checks

1e32adf

sai-deng requested a review from 4l0n50 November 18, 2024 17:24

LindaGuiga approved these changes Nov 21, 2024

View reviewed changes

hratoanina approved these changes Nov 21, 2024

View reviewed changes

comments

32314ea

Nashtare approved these changes Nov 25, 2024

View reviewed changes

Nashtare merged commit 7203b7a into main Nov 25, 2024
5 checks passed

Nashtare deleted the sai/multi_degrees_recursion_circuit branch November 25, 2024 16:58

sai-deng mentioned this pull request Dec 23, 2024

feat: FRI higher arity Plonky3/Plonky3#592

Open

jonathanpwang mentioned this pull request Dec 23, 2024

[wip]Sai/fri high arity Plonky3/Plonky3#591

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Unified Recursion Circuit for Multi-Degree Starky Proof Verification #1635

Unified Recursion Circuit for Multi-Degree Starky Proof Verification #1635

sai-deng commented Nov 1, 2024 •

edited

Loading

sai-deng commented Nov 15, 2024 •

edited

Loading

LindaGuiga left a comment

LindaGuiga Nov 21, 2024

sai-deng Nov 22, 2024

LindaGuiga Nov 21, 2024

sai-deng Nov 22, 2024

LindaGuiga Nov 21, 2024

sai-deng Nov 22, 2024

LindaGuiga Nov 21, 2024

sai-deng Nov 22, 2024

LindaGuiga Nov 21, 2024

sai-deng Nov 22, 2024

hratoanina left a comment

sai-deng commented Nov 22, 2024

sai-deng commented Nov 22, 2024

sai-deng commented Nov 22, 2024

	let min_log_n_to_support = log_n - (params.degree_bits - min_degree_bits_to_support);
	let min_log_n_to_support = params.config.rate_bits + min_degree_bits_to_support;

	for artity_bits in &params.reduction_arity_bits {
	for arity_bits in &params.reduction_arity_bits {

Unified Recursion Circuit for Multi-Degree Starky Proof Verification #1635

Unified Recursion Circuit for Multi-Degree Starky Proof Verification #1635

Conversation

sai-deng commented Nov 1, 2024 • edited Loading

sai-deng commented Nov 15, 2024 • edited Loading

LindaGuiga left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hratoanina left a comment

Choose a reason for hiding this comment

sai-deng commented Nov 22, 2024

sai-deng commented Nov 22, 2024

sai-deng commented Nov 22, 2024

sai-deng commented Nov 1, 2024 •

edited

Loading

sai-deng commented Nov 15, 2024 •

edited

Loading