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

Unit test for parity between JoltIn and memory checking instances #378

Closed
sragss opened this issue Jun 4, 2024 · 2 comments
Closed

Unit test for parity between JoltIn and memory checking instances #378

sragss opened this issue Jun 4, 2024 · 2 comments

Comments

@sragss
Copy link
Collaborator

sragss commented Jun 4, 2024

After #368 the inputs to the Jolt R1CS instances are hardcoded into the JoltIn enum. We should be able to write a unit test that the size of this iterable enum matches the size spit out by vm/mod.rs.

@sragss
Copy link
Collaborator Author

sragss commented Jun 10, 2024

Discussed with @moodlezoup. We don't have a great strategy here yet. Ideally we have some static information about what is output by the memory checking instances and then we can constrain those to the JoltIn enums.

The simplest strategy is that we check Inputs::clone_to_trace_len_chunks and Inputs::format_commitments output things matching JoltIn::COUNT. These would not catch ordering related bugs, but would catch sizing related bugs which are likely more common.

@sragss
Copy link
Collaborator Author

sragss commented Jun 10, 2024

I've added this to clone_to_trace_len chunks in #368 but have not added to format_commitments as this includes auxiliary variables and we do not have access to this count statically. We could use an assert_static_aux_index as is used for next_pc_jump_branch in jolt_constraints.rs.

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

No branches or pull requests

2 participants