You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am testing various Ethereum virtual machines and have observed that when executing the opcode 0x59 (MSIZE), all the EVM implementations I tested (Geth, Besu, EthereumJS, Py-EVM) consistently return a value that is a multiple of 32 to the stack.
Push the size of active memory in bytes onto the stack.
Parameters
----------
evm :
The current EVM frame.
"""
# STACK
pass
# GAS
charge_gas(evm, GAS_BASE)
# OPERATION
push(evm.stack, U256(len(evm.memory)))
# PROGRAM COUNTER
evm.pc+=1
It seems that the specification directly pushes the length of evm.memory to the stack without accounting for the fact that the current memory size may not be a multiple of 32.
I noticed that when executing some opcodes that may cause memory expansion, this function will be called to make sure the length of memory to be multiple of 32.
My question is whether the specification ensures that the length of memory will always be a multiple of 32, or if we need to add conditional checks or annotations to the MSIZE opcode to guarantee that it outputs a value that is a multiple of 32. Thank you for your attention.
Sources
evm.code
According to the definition of msize at evm.code, "The size is always a multiple of a word (32 bytes)."
yellow paper
I also check the shanghai version yellow book, in p36 it said:
EVM implementation
I will give a bytecode example and its result after execution on different EVM implementations.
Bytecode as input : 631456015261af0b525960005260406000f3
After execution, all EVMs returned with output 000000000000000000000000000000000000000000000000000000000000af400000000000000000000000000000000000000000000000000000000000000000
where 0xaf40 is the result of opcode msize and 0xaf40 is a multiple of 32.
I noticed that when executing some opcodes that may cause memory expansion, this function will be called to make sure the length of memory to be multiple of 32.
Did you notice anywhere that expanded memory without using calculate_gas_extend_memory? I think we're pretty consistent in using it, but I've been wrong many times before 😅
It might not be a bad idea to insert an assert into the MSIZE implementation (or maybe in the interpreter loop), to catch any bugs.
Metadata
What was wrong?
Hello developers,
I am testing various Ethereum virtual machines and have observed that when executing the opcode
0x59
(MSIZE
), all the EVM implementations I tested (Geth, Besu, EthereumJS, Py-EVM) consistently return a value that is a multiple of 32 to the stack.However, when I check the execution-spec at
execution-specs/src/ethereum/cancun/vm/instructions/memory.py
Lines 122 to 142 in 44ceab2
It seems that the specification directly pushes the length of
evm.memory
to the stack without accounting for the fact that the current memory size may not be a multiple of 32.I noticed that when executing some opcodes that may cause memory expansion, this function will be called to make sure the length of memory to be multiple of 32.
execution-specs/src/ethereum/cancun/vm/gas.py
Lines 154 to 190 in 44ceab2
My question is whether the specification ensures that the length of memory will always be a multiple of 32, or if we need to add conditional checks or annotations to the
MSIZE
opcode to guarantee that it outputs a value that is a multiple of 32. Thank you for your attention.Sources
evm.code
According to the definition of
msize
at evm.code, "The size is always a multiple of a word (32 bytes)."yellow paper
I also check the shanghai version yellow book, in p36 it said:
EVM implementation
I will give a bytecode example and its result after execution on different EVM implementations.
Bytecode as input :
631456015261af0b525960005260406000f3
After execution, all EVMs returned with output
000000000000000000000000000000000000000000000000000000000000af400000000000000000000000000000000000000000000000000000000000000000
where
0xaf40
is the result of opcodemsize
and0xaf40
is a multiple of 32.The details are in the json files.
gethout.json, besuout.json, jsout.json, pyout.json
Thanks for your time.
The text was updated successfully, but these errors were encountered: