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

Make lagrange basis handling safe #2672

Merged
merged 6 commits into from
Oct 9, 2024
Merged

Conversation

mrmr1993
Copy link
Member

@mrmr1993 mrmr1993 commented Oct 8, 2024

This PR adds the concept of HashMapCache to remove the potential for errors / panics in code. In particular, this addresses o1-labs/o1js#1411.

@45930
Copy link
Contributor

45930 commented Oct 8, 2024

@mrmr1993, I am working through some linting errors. It looks like you removed the function add_lagrange_basis, but it is still referenced by some srs (in test cases, AFAICT). e.g.

error[E0599]: no method named `add_lagrange_basis` found for struct `poly_commitment::srs::SRS` in the current scope
    --> kimchi/src/circuits/expr.rs:3012:17
     |
3012 |             srs.add_lagrange_basis(constraint_system.domain.d1);
     |                 ^^^^^^^^^^^^^^^^^^ help: there is a method with a similar name: `get_lagrange_basis`

If that function is meant to be removed, what should be done with these references?

@45930
Copy link
Contributor

45930 commented Oct 8, 2024

@mrmr1993 is there a test case explicitly for the case for which we are implementing this? Would it be easy to whip one up?

@querolita
Copy link
Member

@45930 One of the references to the old add_lagrange_basis was in a comment, and the other was inside circuit-construction which is still not a member of the Cargo.toml (work in progress). Either way, I updated both in a70e020.

@querolita
Copy link
Member

@45930 Because the issue was found in o1js, we probably want to create any remaining PRs for the mina / bindings / o1js sides with a test in o1js (probably just one of the few that were raised in o1-labs/o1js#1411) to see the effects of this fix.

@45930
Copy link
Contributor

45930 commented Oct 9, 2024

@querolita , thanks for the review!

Is it possible to test this branch in o1js locally? There is a PR up for o1js: o1-labs/o1js#1857 but I'm not sure how to get these changes into that branch to test with.

@querolita
Copy link
Member

@45930 Oh thanks for pointing me to the other PR, I was not aware that it was already being done. I will take a look at it locally to try to test the changes before merging 😄

@45930 45930 merged commit 3689889 into develop Oct 9, 2024
6 checks passed
@45930 45930 deleted the feature/safe-lagrange-basis branch October 9, 2024 21:15
impl<Key: Hash + std::cmp::Eq, Value> HashMapCache<Key, Value> {
pub fn new() -> Self {
HashMapCache {
contents: Arc::new(Mutex::new(HashMap::new())),
Copy link
Member

Choose a reason for hiding this comment

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

Cool! I did something like this in parallel in my working branch: 444e07f#diff-c89c45dc84ecd1f409b94d69ca374ed88678982f04f419b79435fd5ebff85b4fR362

Copy link
Member

Choose a reason for hiding this comment

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

@mrmr1993 I'd suggest using RWLock though. Unless I'm misunderstanding, Mutex won't allow two concurrent reads, locking several parallel uses (which is the case in mina), and the upgrade to RWLock is easy. Any reasons not to?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants