-
Notifications
You must be signed in to change notification settings - Fork 1.5k
core/vm: fix a corner case in EIP-7823 #16494
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
Conversation
chfast
left a comment
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.
In evmone, I handle EIP-7823 in the "gas" function by returning the MAX_GAS in case the lengths are above the limits. May this potentially improve code structure?
To my mind relying on the gas function is a bit brittle because it disperses EIP-7823 checks among two functions. |
I think this would keep the EIP-7823 in the gas function only. But I'm not pushing here. |
| // 32 - 8 bytes are truncated in the Uint64 conversion above | ||
| baseLenHighBitsAreZero = allZero(header[0 : 32-8]) | ||
| expLenHighBitsAreZero = allZero(header[32 : 64-8]) | ||
| modLenHighBitsAreZero = allZero(header[64 : 96-8]) |
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.
I think baseLenHighBitsAreZero and modLenHighBitsAreZero are always true in practice because otherwise we would get huge gas cost because of the "mult complexity" calculation. I.e. these will not be testable.
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.
Yes, but I'd like to have them here for consistency and robustness so that Run is self-explanatory w/o a hidden dependency on the behaviour of RequiredGas.
core/vm/contracts.go
Outdated
| } | ||
|
|
||
| // Handle a special case when both the base and mod length is zero | ||
| if baseLen == 0 && modLen == 0 && baseLenHighBitsAreZero && modLenHighBitsAreZero { |
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.
I think the original check was overspecified. This is true for only the modLen being 0 (you can skip the base check).
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.
You're right. I've amended the special case.
Make sure that lengths of the form 2^64*_n_, _n_>=1 are not accepted (that would be a violation of [EIP-7823](https://eips.ethereum.org/EIPS/eip-7823)). N.B. EIP-7823 restricts the range of `expLen` even in the special case `baseLen == 0 && modLen == 0`.
Make sure that lengths of the form 2^64*_n_, _n_>=1 are not accepted (that would be a violation of [EIP-7823](https://eips.ethereum.org/EIPS/eip-7823)). N.B. EIP-7823 restricts the range of `expLen` even in the special case `baseLen == 0 && modLen == 0`.
Make sure that lengths of the form 2^64*n, n>=1 are not accepted (that would be a violation of EIP-7823).
N.B. EIP-7823 restricts the range of
expLeneven in the special casebaseLen == 0 && modLen == 0.