-
Notifications
You must be signed in to change notification settings - Fork 759
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
evm: fix modexp edge cases #3169
Conversation
Codecov Report
Additional details and impacted files
Flags with carried forward coverage won't be shown. Click here to find out more. |
Have added a fuzzer which I will run now. It finds more error cases. |
Fuzzer tests: run inputs [0,1,2] on the modExp inputs (6 fields: |
Test cases: array of |
@@ -151,17 +151,10 @@ export function precompile05(opts: PrecompileInput): ExecResult { | |||
return OOGResult(opts.gasLimit) | |||
} | |||
|
|||
if (bLen === BIGINT_0) { | |||
if (bLen === BIGINT_0 && mLen === BigInt(0)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if (bLen === BIGINT_0 && mLen === BigInt(0)) { | |
if (bLen === BIGINT_0 && mLen === BIGINT_0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally looks good. I think we should definitely consider whether these utility methods (like setLengthLeft
) should throw if there is under/overflow but that can be solved separately.
One nit suggestion too.
Will approve once the "fuzzer" tests are added.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Closes #3168
This PR fixes the edge cases in ModExp. Specifically, ModExp has 6 inputs, and the inputs for [0,1,2] are all tested on all inputs. These are cross-referenced against infura. (File here: 144963a)
Test files are here. The format is [input, expectedOutput]
tests.txt
Note: one of the causes is that
bigIntToBytes(BigInt(0))
returnsUint8Array(1) [ 0 ]
(length 1) instead ofUint8Array(0) []
(length 0). If you thensetLengthLeft(r, 0)
then it still outputs the array with length 1. This raises 2 questions:bigIntToBytes
onBigInt(0)
return the empty array? (Note: this is super breaking so we cannot do it, we could introduce a new method?)setLengthLeft
throw if the expected length is lower than the current length? (It is unknown if we should trim left or right 🤔 )