-
Notifications
You must be signed in to change notification settings - Fork 112
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
Move byte-checks of Keccak to Syscall side and include lookups for length bytes #2276
Conversation
Checked demo, this does not halt the VM and the |
I'm waiting for 2274 and 2305 to be merged to fix conflicts and continue reviewing. Taking care of solving conflicts. |
Solving conflicts now. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2276 +/- ##
=======================================
Coverage 73.40% 73.41%
=======================================
Files 234 234
Lines 54252 54275 +23
=======================================
+ Hits 39824 39846 +22
- Misses 14428 14429 +1 ☔ View full report in Codecov by Sentry. |
This PR aims at constraining the byte-ness of the length prefix read from the oracle in the first few bytes before reading the actual preimage bytes.
In order to simplify the Keccak lookups, I also moved the actual preimage byte-checks from the Keccak side to the MIPS side (this means 4 lookups per
SyscallReadPreimage
row instead of 200 lookups per absorb row).Together with the length bytes checks, this means 8 lookups derived from the
request_preimage_write()
function.I made this PR because I think it is good for soundness, but I am sure there's a better way to do it. In particular, it's absurd to perform 8 lookups when you know at most you read 4 bytes. We should think of a better way to "merge" length and preimage bytes in the same vector instead of having one for each.
I am unsure if the 8 bytes of the preimage are always read in two rows of 4 bytes each, or if instead it could combine things like: first call 3 bytes, second call 3 bytes, third call 2 bytes of length and 2 bytes of preimage. Of course, if it always read 4 and 4, then the length bytes and preimage bytes would never have to "share" the vector, as they would always live in separate rows. And then removing the extra 4 lookups is just trivial.Nonetheless, if that is not the case, we might want to think of smarter ways to combine the vector in a way that is compatible with the preimage chunk computation and the rest of preimage constraints.