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

Remove restriction to binary-only multiplicities #1577

Merged

Conversation

matthiasgoergens
Copy link
Contributor

This is a simpler PR to prepare the ground for #1575

@matthiasgoergens
Copy link
Contributor Author

Btw, why does starky lack tests?

@Nashtare
Copy link
Collaborator

Btw, why does starky lack tests?

We have an open issue for it (#1514). All tests were specific to the zkEVM and migrated to the new repo. I agree this definitely needs some more testing. I have pinged the person who assigned themselves this task but no answer yet.

@Nashtare
Copy link
Collaborator

Related to testing, have you tested this? Haven't reviewed yet but it's failing on our integration tests there https://github.com/0xPolygonZero/zk_evm/tree/develop.

@matthiasgoergens
Copy link
Contributor Author

matthiasgoergens commented Apr 23, 2024

I ran all the tests in the plonky2 repository. I'm still running tests elsewhere. Thanks for pointing to your other repository, I'll try to run those tests, too.

Update: the develop branch on the zk_evm repo fails with the main branch here already, it doesn't build. So it would break even more with this branch developed against that main branch.

I'll see about making you a fix quickly.

@matthiasgoergens
Copy link
Contributor Author

matthiasgoergens commented Apr 23, 2024

Here's your fix to make zk_evm compatible with plonky2's main: 0xPolygonZero/zk_evm#183

@matthiasgoergens matthiasgoergens force-pushed the matthias/actual-multiplicities-upstream branch 3 times, most recently from ee8a8ff to 51746e2 Compare April 23, 2024 02:14
@Nashtare
Copy link
Collaborator

I already have a branch working with main. But moving deps to your current branch gives me an quotient polynomial evaluation error.

@matthiasgoergens matthiasgoergens force-pushed the matthias/actual-multiplicities-upstream branch from 51746e2 to 1d60d98 Compare April 23, 2024 02:44
@matthiasgoergens
Copy link
Contributor Author

matthiasgoergens commented Apr 23, 2024

I already have a branch working with main. But moving deps to your current branch gives me an quotient polynomial evaluation error.

Thanks. I found the bug.

I cleaned up the code a bit while fixing the bug.

 starky/src/lookup.rs | 84 ++++++++++++++++++++----------------------------------------------------------------
 1 file changed, 20 insertions(+), 64 deletions(-)

@matthiasgoergens matthiasgoergens force-pushed the matthias/actual-multiplicities-upstream branch from 1d60d98 to 26b7e7a Compare April 23, 2024 02:49
let (first_col, first_filter) = cols_filts.next().unwrap();

let mut filter_col = Vec::with_capacity(degree);
let first_combined = (0..degree)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I removed the duplication of logic here, and replaced it with a single call to reduce further down.

@@ -761,79 +761,35 @@ pub(crate) fn get_helper_cols<F: Field>(
.len()
.div_ceil(constraint_degree.checked_sub(1).unwrap_or(1));

let mut helper_columns = Vec::with_capacity(num_helper_columns);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Iterators in Rust have a size hint, so collect automatically does what we were trying to do manually via with_capacity here.

@Nashtare
Copy link
Collaborator

I already have a branch working with main. But moving deps to your current branch gives me an quotient polynomial evaluation error.

Thanks. I found the bug.

I cleaned up the code a bit while fixing the bug.

 starky/src/lookup.rs | 84 ++++++++++++++++++++----------------------------------------------------------------
 1 file changed, 20 insertions(+), 64 deletions(-)

For things touching starky, I usually run them against our zk_evm monorepo as sanity check, until we get some good coverage here. Priority wise it's a bit tough for us to dedicate time for it at the moment, but it will be done sooner or later. In the meantime, as long as myself and other maintainers are testing against zk_evm, we should be fine.

// Dummy value. Cannot be zero since it will be batch-inverted.
F::ONE
}
let mut combined = F::batch_multiplicative_inverse(&combined);
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 remember correctly, the reason why the previous code did not use batch_multiplicative_inverse (and was therefore more complicated). was because the filter column is often (not always!) sparse, so we wanted to avoid inverting a lot of values that would be later zeroed out. However, I am not sure how much of an impact it would actually have, and this code does look much nicer!

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, though the code in main already uses batch multiplicative inverse.

Copy link
Contributor

@muursh muursh left a comment

Choose a reason for hiding this comment

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

I'm good with this

@matthiasgoergens
Copy link
Contributor Author

Please feel free to merge when you are ready.

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.

LGTM too

@Nashtare Nashtare merged commit ca362ee into 0xPolygonZero:main Apr 26, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

4 participants