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

Serializaiton regression tests for proof-systems and parts of kimchi #2598

Merged
merged 1 commit into from
Oct 1, 2024

Conversation

volhovm
Copy link
Member

@volhovm volhovm commented Sep 24, 2024

This PR adds some serialization regression tests, in particular for SRS, PolyComm, OpeningProof, ProverProof.

I also had to make rng an explicit parameter in kimchi's prover.

Reference values are valid w.r.t. 1494cf973d40fb276465929eb7db1952c5de7bdc (arkworks 0.3.0).

@volhovm volhovm force-pushed the volhovm/arkworks042-regression-tests branch from c2c8040 to d48799c Compare September 24, 2024 13:56
@volhovm volhovm assigned dannywillems and unassigned dannywillems Sep 24, 2024
@volhovm volhovm force-pushed the volhovm/arkworks042-regression-tests branch 2 times, most recently from 90ba6d9 to a1f5545 Compare September 24, 2024 14:00
@@ -165,13 +169,15 @@ where
pub fn create_recursive<
Copy link
Member

Choose a reason for hiding this comment

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

That seems to introduce a change also in the whole Mina repository. We might want to be more careful regarding this. Can we avoid this in this PR?

Copy link
Member Author

Choose a reason for hiding this comment

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

We can't really, since then the prover is non-deterministic and it serializes to a different value every time.

Copy link
Member

@dannywillems dannywillems left a comment

Choose a reason for hiding this comment

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

I don't think we should introduce the rng parameter in the prover in this PR.

@volhovm
Copy link
Member Author

volhovm commented Sep 24, 2024

@dannywillems Do you want it in a different PR or...? I think it's a fairly small cosmetic change, and it's necessary to be able to run the prover in a reproducible way, so why not?

Edit: you're right that it introduces a change in the mina repo, but only in like ... two places in bindings. So it's still quite lightweight.

@dannywillems
Copy link
Member

dannywillems commented Sep 24, 2024

@dannywillems Do you want it in a different PR or...? I think it's a fairly small cosmetic change, and it's necessary to be able to run the prover in a reproducible way, so why not?

Edit: you're right that it introduces a change in the mina repo, but only in like ... two places in bindings. So it's still quite lightweight.

Ok, giving a second thought...
Can you make the change in Mina accordingly so we can merge all of them? It will imply changing the o1js-bindings also. Let's try to keep the old convention that the branches in o1js-bindings, mina and proof-systems for develop should be all aligned all the time.

@volhovm
Copy link
Member Author

volhovm commented Sep 24, 2024

Sounds good, will do tomorrow!

@volhovm
Copy link
Member Author

volhovm commented Sep 25, 2024

Done for mina in MinaProtocol/mina#16139. WIll see regarding o1js.

@volhovm
Copy link
Member Author

volhovm commented Sep 25, 2024

fn test_serialization_regression() {
// Generated with commit 1494cf973d40fb276465929eb7db1952c5de7bdc
let buf_expected = vec![
149, 148, 159, 145, 145, 196, 33, 36, 165, 245, 213, 186, 207, 201, 96, 141, 145, 71, 154,
Copy link
Member

Choose a reason for hiding this comment

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

Nit: could be nice to load the value from a file.

let data_expected = SRS::<Vesta>::create_trusted_setup(td1, 1 << 3);
// Generated with commit 1494cf973d40fb276465929eb7db1952c5de7bdc
let buf_expected: Vec<u8> = vec![
146, 152, 196, 33, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
Copy link
Member

Choose a reason for hiding this comment

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

Nit: could be nice to load the value from a file

let data_expected = SRS::<Pallas>::create_trusted_setup(td2, 1 << 3);
// Generated with commit 1494cf973d40fb276465929eb7db1952c5de7bdc
let buf_expected: Vec<u8> = vec![
146, 152, 196, 33, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
Copy link
Member

Choose a reason for hiding this comment

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

Nit: could be nice to load the value from a file

let data_expected = chunked_commitment;
// Generated with commit 1494cf973d40fb276465929eb7db1952c5de7bdc
let buf_expected: Vec<u8> = vec![
145, 150, 196, 33, 36, 158, 70, 161, 147, 233, 138, 19, 54, 52, 87, 58, 158, 154, 255, 197,
Copy link
Member

Choose a reason for hiding this comment

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

Nit: could be nice to load the value from a file


// Generated with commit 1494cf973d40fb276465929eb7db1952c5de7bdc
let buf_expected: Vec<u8> = vec![
149, 151, 146, 196, 33, 166, 183, 76, 209, 121, 62, 56, 194, 134, 133, 238, 52, 190, 163,
Copy link
Member

Choose a reason for hiding this comment

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

Nit: could be nice to load the value from a file

Copy link
Member Author

Choose a reason for hiding this comment

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

I'd rather keep it here tbh. I know it's big and ugly, but file management is more annoying imo, you rely on extra kernel calls, it's more files, and if we change serialization in a certain way git would probably just think the whole binary file was replaced, even if it's just a bit. The last case we had before actually when I was replacing the SRS serialization, you could clearly see that the new serialization is just one bit off, which helps with debugging.

@dannywillems
Copy link
Member

Feel free to merge when the PR in o1js/o1js-bindings are good to be merged too.

@volhovm volhovm merged commit 88098fe into develop Oct 1, 2024
6 checks passed
@volhovm volhovm deleted the volhovm/arkworks042-regression-tests branch October 1, 2024 13:51
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.

2 participants