Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 13 commits into from
Jul 15, 2024

Conversation

sai-deng
Copy link
Contributor

@sai-deng sai-deng commented Jun 12, 2024

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

@sai-deng sai-deng changed the title Add batch STARKs Add Support for Batch STARKs with Proving, Verification, and Recursion Jun 12, 2024
@Nashtare
Copy link
Collaborator

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
Copy link
Contributor Author

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

@Nashtare Nashtare requested a review from hratoanina June 13, 2024 22:30
@Nashtare Nashtare added the enhancement New feature or request label Jun 13, 2024
Copy link
Contributor

@hratoanina hratoanina left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 Outdated Show resolved Hide resolved
plonky2/src/hash/field_merkle_tree.rs Outdated Show resolved Hide resolved
@sai-deng
Copy link
Contributor Author

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.

Copy link
Collaborator

@Nashtare Nashtare left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

plonky2/src/hash/field_merkle_tree.rs Outdated Show resolved Hide resolved
plonky2/src/hash/field_merkle_tree.rs Outdated Show resolved Hide resolved
plonky2/src/hash/field_merkle_tree.rs Outdated Show resolved Hide resolved
plonky2/src/hash/merkle_proofs.rs Outdated Show resolved Hide resolved
plonky2/src/hash/merkle_tree.rs Outdated Show resolved Hide resolved
plonky2/src/fri/batch_oracle.rs Outdated Show resolved Hide resolved
plonky2/src/fri/batch_oracle.rs Outdated Show resolved Hide resolved
plonky2/src/fri/validate_shape.rs Show resolved Hide resolved
plonky2/src/hash/field_merkle_tree.rs Outdated Show resolved Hide resolved
@sai-deng
Copy link
Contributor Author

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

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

Copy link
Contributor

@hratoanina hratoanina left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still reviewing, thanks!

plonky2/src/hash/merkle_proofs.rs Outdated Show resolved Hide resolved
/// 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>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

plonky2/src/batch_fri/prover.rs Show resolved Hide resolved
}

/// Produces a batch opening proof.
pub fn prove_openings(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

@sai-deng sai-deng Jun 21, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

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
Copy link
Contributor Author

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.

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

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
Copy link
Contributor Author

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 Nashtare added this to the Performance Tuning milestone Jul 12, 2024
Copy link
Collaborator

@Nashtare Nashtare left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks again!

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
@Nashtare Nashtare enabled auto-merge (squash) July 15, 2024 22:40
@Nashtare Nashtare merged commit 0e363e1 into 0xPolygonZero:main Jul 15, 2024
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

3 participants