-
Notifications
You must be signed in to change notification settings - Fork 47
Open
Description
MODEXP test vectors
Calling MODEXP in a smart contract
If we provide the call data via the transaction we should do something akin to copy the transaction's call data in full to RAM.
// do a full copy of call data to RAM
CALLDATASIZE
PUSH0
PUSH0
CALLDATACOPYThis pre-populates memory with relevant call data for the MODEXP call to come. A CALL to MODEXP with the following parameters should then follow
// the CALL to MODEXP
PUSH2 rac // rac = 1024
PUSH2 rao // rao = 96 + 3*1024
PUSH2 cds // cds = 96 + 3*1024
PUSH0 // zero call data offset
PUSH0 // zero value
PUSH20 0x0000000000000000000000000000000000000005
GAS
CALL Transaction call data
Transaction call data shoud look like so
< 32 bytes for bbs > < 32 bytes for ebs > < 32 bytes for mbs > < base, exponent, modulus proper>
// bbs = base byte size
// ebs = exponent byte size
// mbs = modulus byte sizee.g.
00000000000000000000000000000000000000000000000000000000000003ff 0000000000000000000000000000000000000000000000000000000000000020 0000000000000000000000000000000000000000000000000000000000000020 < gibberish >
<----------------------------bbs-------------------------------> <----------------------------ebs-------------------------------> <----------------------------mbs-------------------------------> <data proper>
in each case these initial 96 bytes being followed by 3 * 1024 random (nonzero) bytes
and again being followed by by 3 * 1024 random (nonzero) bytes (that shouldn't matter in any case)
Purpose
The purpose of the above is twofold:
- the first tests are there to test the new legal range of
MODEXPcalls as per Osaka - the next tests are there to test the internal handling out of bounds of
MODEXPcalls without the sequencer rejecting the transaction
Metadata
Metadata
Assignees
Labels
No labels