Update serialization logic of OOD frame #358
Conversation
| // save the evaluations of the current and then next evaluations for each polynomial | ||
| let (main_and_aux_trace_states, lagrange_trace_states) = trace_ood_frame.to_trace_states(); |
There was a problem hiding this comment.
When we build elements_to_hash below, should we try to arrange things so that we always end up with 4 base field elements per extension field element (for 64-bit fields)? Basically, the arrangement would look something like so:
For sequence of degree 2 extension field elements: (a_0, a_1), (b_0, b_1), (c_0, c_1), ..., elements_to_hash would look like:
[a_0, a_1, 0, 0, b_0, b_1, 0, 0, c_0, c_1, 0, 0, ...]
And then, if we were in the degree 3 extension field, it'd look like:
[a_0, a_1, a_2, 0, b_0, b_1, b_2, 0, c_0, c_1, c_2, 0, ...]
One open question here is how to handle this generically given that we could also be in a 128-bit field.
There was a problem hiding this comment.
I would keep it as it is for now as the benefits of the layout you proposed are still not clear to me, especially given its "unnaturalness".
There was a problem hiding this comment.
But maybe you are thinking of it in light of the following proposal 0xPolygonMiden/miden-vm#1610 (comment) ?
If yes, then we can include it in this PR to build on it the solution in the previously mentioned issue.
There was a problem hiding this comment.
One open question here is how to handle this generically given that we could also be in a 128-bit field.
I would probably just go for the simplest solution of conditioning on the case of
There was a problem hiding this comment.
But maybe you are thinking of it in light of the following proposal 0xPolygonMiden/miden-vm#1610 (comment) ?
If yes, then we can include it in this PR to build on it the solution in the previously mentioned issue.
Yes, that's what I had in mind. Basically, "unlashing" becomes more "uniform" across different extension fields and also potentially easier to process in that context (though, it depends on whether this methodology will be used in the VM)..
There was a problem hiding this comment.
So the question is do we do it now with partial genericity or do we leave it till we need it?
There was a problem hiding this comment.
Let's keep as is for now, but create an issue to look into it.
| // save the evaluations of the current and then next evaluations for each polynomial | ||
| let (main_and_aux_trace_states, lagrange_trace_states) = trace_ood_frame.to_trace_states(); |
There was a problem hiding this comment.
Let's keep as is for now, but create an issue to look into it.
Al-Kindi-0
force-pushed
the
al-update-serialization-of-ood-frame
branch
from
ec199cf to
6130210
Compare
Moves away from serializing the current and next raw in a zig-zag manner and serializes them instead as two vectors one after the other.