Add Support for Batch STARKs with Proving, Verification, and Recursion #1600

sai-deng · 2024-06-12T00:26:21Z

The method used in this PR can be found in Section 3.2 in the paper.

Nashtare · 2024-06-12T15:18:36Z

Hey @sai-deng! Thank you for the PR! As this is quite dense, could you write some explanation about the approach taken, and any specific parts that may help reviewers?
Also could you explain how this impacts STARK recursive verification now that they're batched together? Thanks!

sai-deng · 2024-06-12T20:54:23Z

Hey @sai-deng! Thank you for the PR! As this is quite dense, could you write some explanation about the approach taken, and any specific parts that may help reviewers? Also could you explain how this impacts STARK recursive verification now that they're batched together? Thanks!

The paper is still WIP, the method used in this PR can be found in Section 3.2

hratoanina

Still in the middle of reviewing. Looks really nice!

I have a random question: from what I'm seeing you can only open leaves from the bottom layer, and you open all intermediary leaves you encounter on your way to the top. If for some reason you want to open only a leaf from one of the smaller trees, can't you have a shorter proof starting at the smaller tree's height?

plonky2/src/hash/field_merkle_tree.rs

sai-deng · 2024-06-18T00:18:42Z

Still in the middle of reviewing. Looks really nice!

I have a random question: from what I'm seeing you can only open leaves from the bottom layer, and you open all intermediary leaves you encounter on your way to the top. If for some reason you want to open only a leaf from one of the smaller trees, can't you have a shorter proof starting at the smaller tree's height?

Thanks for reviewing! In this case, you'd better not use a field Merkle tree since it will not reduce the Merkle proof size.

Nashtare

Fairly minor comments as well for now, will do another pass at FRI later.

plonky2/src/hash/field_merkle_tree.rs

plonky2/src/hash/merkle_proofs.rs

plonky2/src/hash/merkle_tree.rs

plonky2/src/fri/batch_oracle.rs

plonky2/src/fri/validate_shape.rs

plonky2/src/hash/field_merkle_tree.rs

sai-deng · 2024-06-19T02:23:18Z

Fairly minor comments as well for now, will do another pass at FRI later.

Thanks for the careful reviews! Comments are addressed in 59d637f.

hratoanina

Still reviewing, thanks!

plonky2/src/hash/merkle_proofs.rs

hratoanina · 2024-06-20T23:53:56Z

plonky2/src/batch_fri/oracle.rs

+/// Represents a batch FRI oracle, i.e. a batch of polynomials with different degrees which have
+/// been Merkle-ized in a [`BatchMerkleTree`].
+#[derive(Eq, PartialEq, Debug)]
+pub struct BatchFriOracle<F: RichField + Extendable<D>, C: GenericConfig<D, F = F>, const D: usize>


Nit: the name is a bit confusing since this is the batched version of PolynomialBatch. Personally I would rename the latter FriOracle but I don't have a strong feeling about it.

Yes, I think we should rename the later FriOracle but let us do it in a separate PR.

plonky2/src/batch_fri/prover.rs

hratoanina · 2024-06-21T00:16:39Z

plonky2/src/batch_fri/oracle.rs

+    }
+
+    /// Produces a batch opening proof.
+    pub fn prove_openings(


If I understand correctly the logic:

You provide several FriInstanceInfo, which consist in multiple FriBatchInfo, containing each an evaluation point and a batch of polynomials to be evaluated at that point. In the batched version, for a single FriInstanceInfo, the evaluated polynomials can be of different degrees, contrary to the normal version.
But I don't think the inner for loop (at line 154) works well with polynomials of different degrees. To my understanding, what we should be doing is to group all polynomials of the same degree across all instances, and then compose them together with alpha.

In the batched version, for a single FriInstanceInfo, the evaluated polynomials have the same degree.

In zkVM code, we first create a FriInstanceInfo for each table. We then merge FriInstanceInfo instances when two tables have the same degree. Lastly, we have a vec<FriInstanceInfo> with different degrees, but within each FriInstanceInfo, the polynomials have the same degree.

hratoanina · 2024-06-21T19:32:43Z

I have a question with regards to STARK batching in general. From section 3.3 of the paper, I understand that for each individual STARK you pad it to the maximum length it can have given a normal execution (determined via testing with a bunch of different inputs) to have a fixed length you can build a recursion circuit from.
In our zkEVM, we have very wide discrepancies between best and worst case scenarios for individual trace lengths, which can range e.g. from 16 to 2^20. Does that mean we would be forced to make a circuit accommodating a 2^20-length trace, and pad the trace to this length for every single execution?

sai-deng · 2024-06-21T22:25:35Z

I have a question with regards to STARK batching in general. From section 3.3 of the paper, I understand that for each individual STARK you pad it to the maximum length it can have given a normal execution (determined via testing with a bunch of different inputs) to have a fixed length you can build a recursion circuit from. In our zkEVM, we have very wide discrepancies between best and worst case scenarios for individual trace lengths, which can range e.g. from 16 to 2^20. Does that mean we would be forced to make a circuit accommodating a 2^20-length trace, and pad the trace to this length for every single execution?

Yes, we have to pad the trace to a length of 2^20. Alternatively, we can use a Merkle tree to save all the valid recursion circuits hash and treat the Merkle root hash as the public parameters.

hratoanina · 2024-06-26T15:47:21Z

Hi @sai-deng, sorry for the wait!
I'm currently implementing STARK batching on our zkEVM alongside the review, which I treat as another layer of testing. I should be done by the end of the week; if there's no issue I'll approve the PR then!

sai-deng · 2024-06-26T23:56:54Z

Hi @sai-deng, sorry for the wait! I'm currently implementing STARK batching on our zkEVM alongside the review, which I treat as another layer of testing. I should be done by the end of the week; if there's no issue I'll approve the PR then!

Batch STARKs are already implemented in our zkVM; unfortunately, the code is not open-sourced yet. Let me know if you need any help during the implementation.

Nashtare

Thanks again!

plonky2/src/batch_fri/recursive_verifier.rs

plonky2/src/hash/merkle_proofs.rs

plonky2/src/batch_fri/verifier.rs

Co-authored-by: Robin Salen <30937548+Nashtare@users.noreply.github.com>

add batch starks

f6a08bd

sai-deng requested review from muursh, wborgeaud and Nashtare as code owners June 12, 2024 00:26

fix build

795c0cf

sai-deng changed the title ~~Add batch STARKs~~ Add Support for Batch STARKs with Proving, Verification, and Recursion Jun 12, 2024

fix ci

aa2bd3a

Nashtare requested a review from hratoanina June 13, 2024 22:30

Nashtare added the enhancement New feature or request label Jun 13, 2024

hratoanina reviewed Jun 17, 2024

View reviewed changes

plonky2/src/hash/field_merkle_tree.rs Outdated Show resolved Hide resolved

plonky2/src/hash/field_merkle_tree.rs Outdated Show resolved Hide resolved

address comments from hratoanina

e920f88

Nashtare reviewed Jun 18, 2024

View reviewed changes

address comments from Nashtare

59d637f

fix tests

7006244

hratoanina reviewed Jun 21, 2024

View reviewed changes

address comments from hratoanina

49e663d

sai-deng requested review from hratoanina and Nashtare June 26, 2024 00:52

sai-deng added 2 commits June 29, 2024 14:02

Merge branch '0xPolygonZero:main' into main

2917226

Merge branch '0xPolygonZero:main' into main

8670356

hratoanina mentioned this pull request Jul 11, 2024

Enable zkEVM STARK batching #1608

Draft

Nashtare added this to the Performance Tuning milestone Jul 12, 2024

Nashtare assigned hratoanina Jul 12, 2024

Nashtare approved these changes Jul 15, 2024

View reviewed changes

plonky2/src/batch_fri/recursive_verifier.rs Outdated Show resolved Hide resolved

plonky2/src/hash/merkle_proofs.rs Outdated Show resolved Hide resolved

plonky2/src/batch_fri/verifier.rs Outdated Show resolved Hide resolved

Merge branch 'main' into main

e0c9b9f

Nashtare unassigned hratoanina Jul 15, 2024

sai-deng and others added 3 commits July 16, 2024 06:35

Update plonky2/src/batch_fri/recursive_verifier.rs

7b1ce45

Co-authored-by: Robin Salen <30937548+Nashtare@users.noreply.github.com>

Update plonky2/src/hash/merkle_proofs.rs

782f5eb

Co-authored-by: Robin Salen <30937548+Nashtare@users.noreply.github.com>

Update plonky2/src/batch_fri/verifier.rs

4abdd99

Co-authored-by: Robin Salen <30937548+Nashtare@users.noreply.github.com>

Nashtare enabled auto-merge (squash) July 15, 2024 22:40

Nashtare merged commit 0e363e1 into 0xPolygonZero:main Jul 15, 2024
5 checks passed

hratoanina mentioned this pull request Jul 29, 2024

Handle arbitrary, different Stark types as argument #1610

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add Support for Batch STARKs with Proving, Verification, and Recursion #1600

Add Support for Batch STARKs with Proving, Verification, and Recursion #1600

sai-deng commented Jun 12, 2024 •

edited

Loading

Nashtare commented Jun 12, 2024

sai-deng commented Jun 12, 2024

hratoanina left a comment

sai-deng commented Jun 18, 2024

Nashtare left a comment

sai-deng commented Jun 19, 2024

hratoanina left a comment

hratoanina Jun 20, 2024

sai-deng Jun 21, 2024

hratoanina Jun 21, 2024

sai-deng Jun 21, 2024

sai-deng Jun 21, 2024 •

edited

Loading

hratoanina commented Jun 21, 2024

sai-deng commented Jun 21, 2024

hratoanina commented Jun 26, 2024

sai-deng commented Jun 26, 2024

Nashtare left a comment

Add Support for Batch STARKs with Proving, Verification, and Recursion #1600

Add Support for Batch STARKs with Proving, Verification, and Recursion #1600

Conversation

sai-deng commented Jun 12, 2024 • edited Loading

Nashtare commented Jun 12, 2024

sai-deng commented Jun 12, 2024

hratoanina left a comment

Choose a reason for hiding this comment

sai-deng commented Jun 18, 2024

Nashtare left a comment

Choose a reason for hiding this comment

sai-deng commented Jun 19, 2024

hratoanina left a comment

Choose a reason for hiding this comment

hratoanina Jun 20, 2024

Choose a reason for hiding this comment

sai-deng Jun 21, 2024

Choose a reason for hiding this comment

hratoanina Jun 21, 2024

Choose a reason for hiding this comment

sai-deng Jun 21, 2024

Choose a reason for hiding this comment

sai-deng Jun 21, 2024 • edited Loading

Choose a reason for hiding this comment

hratoanina commented Jun 21, 2024

sai-deng commented Jun 21, 2024

hratoanina commented Jun 26, 2024

sai-deng commented Jun 26, 2024

Nashtare left a comment

Choose a reason for hiding this comment

sai-deng commented Jun 12, 2024 •

edited

Loading

sai-deng Jun 21, 2024 •

edited

Loading