You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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.The text was updated successfully, but these errors were encountered: