Future optimization for plonky3 keccak memory (16 bits limbs) #2146
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This draft PR documents the one final optimization that we can apply to the existing optimizations for Plonky3 memory Keccak (16-bits).
The Issue
The current optimization (branch compared against) moves inverse and carry constraints for incrementing 4 to two 16-bit limbs addresses to the main machine. These constraints require degree-4 constraints, which our current Plonky3 parameters limit to degree-3, which our current optimization solves by creating 50 additional
helper[50]
columns that are used to reduce the degrees.This Future Optmization
This optimization removes the need for the 50 helper columns while reducing degree-4 constraints to degree-3, by populating intermediate columns for constraining the increment 4 logic, to the second and third row of each block (for input addresses) and to the 22nd and 23rd row of each block (for output addresses). Currently constraint is only implemented by input addresses but doesn't work yet according to the
output.txt
witgen trace.Most specifically, this optimization has the following column layout for row 1 - 3:
The degree-4 constraint is due to a
first_step * inverse * addr_l * addr_l
term, which we can now move to row two (which can reference row three via rotation). I was able to mathematically prove that two rows won't be sufficient to accommodate for the degree-4 constraint without adding additional columns, so we need to use at least 3 rows and this should be one way to make it work. The other way is to makeaddr_l * inverse
in row 3addr_l * addr_l
, but the idea is similar.Where This Optimization Doesn't Work
According to witgen trace from
output.txt
, output addresses increment 4 are calculated correctly (Appendix 1), input address is copied from the latch row to the first row, but then input addresses increment 4 aren't calculated as intended (Appendix 2).How We Might Fix This Optimization In the Future
Currently witgen can't figure out the value of these three rows, likely due to the fact that it only has context of two rows while we have three rows that express the logic of increment 4 here. We might be able to add hints and calculate the increment 4 logic using if else for all
addr_l[50]
andaddr_h[50]
columns in the first step rather than letting witgen do it. I'm not sure if rotations in prover functions are allowed, to express logics like those betweenaddr_l
andcarry
.When Is This Optimization Worth It
Again, this optimization will shave off another 50 columns, out of a total of 2700+, so it might be worth or not worth it depending on the time it takes.
Appendix 1
Appendix 2