-
Notifications
You must be signed in to change notification settings - Fork 298
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
Conversation
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? |
The paper is still WIP, the method used in this PR can be found in Section 3.2 |
There was a problem hiding this 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?
Thanks for reviewing! In this case, you'd better not use a field Merkle tree since it will not reduce the Merkle proof size. |
There was a problem hiding this 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.
Thanks for the careful reviews! Comments are addressed in 59d637f. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still reviewing, thanks!
/// 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> |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
} | ||
|
||
/// Produces a batch opening proof. | ||
pub fn prove_openings( |
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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. |
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. |
Hi @sai-deng, sorry for the wait! |
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks again!
Co-authored-by: Robin Salen <[email protected]>
Co-authored-by: Robin Salen <[email protected]>
Co-authored-by: Robin Salen <[email protected]>
The method used in this PR can be found in Section 3.2 in the paper.