EIP-7823: Set upper bounds for MODEXP #4070
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
| @@ -150,6 +149,7 @@ export function precompile05(opts: PrecompileInput): ExecResult { | |||
| } | |||
| } | |||
|
|
|||
| const maxSize = opts.common.isActivatedEIP(7823) ? BigInt(1024) : BigInt(2147483647) // @ethereumjs/util setLengthRight limitation | |||
There was a problem hiding this comment.
I think to be complicit with the EIP (or rather, before the EIP) a check should only be done if EIP 7823 is active (not hardcoding a "high" maxSize limit, this could fail specifically crafted tests which would not work in practice due to the high gas limit required to call this precompile with such large input data (due to quadratic memory gas costs))
| /** | ||
| * Compute base^exp mod modulus for *arbitrarily* large BigInts | ||
| */ | ||
| function modPow(base: bigint, exp: bigint, modulus: bigint): bigint { |
There was a problem hiding this comment.
Can't this be done directly with bigints?
| it(`MODEXP should reject and consume all gas for inputs over 8192 bits in length - case ${maxInputLen} bytes`, async () => { | ||
| const result = await MODEXP({ | ||
| data: input, | ||
| gasLimit: BigInt(0xffffffff), |
There was a problem hiding this comment.
I think there should be a sanity check to confirm that this gasLimit is enough to pay for the precompile, but that the precompile now rejects it due to the incode length limit
This change implements EIP-7823, which is being considered for inclusion in Fusaka. With this EIP activated, the MODEXP precompile will reject any requests with any inputs of length greater than 1024 bytes, and will consume all gas in the process.