I’ve written an EIP proposing a new ‘EXTCODEHASH’ opcode here. Feedback appreciated!
I think that one has been suggested before, and I’m all for it.
I think this is a no brainier.
Would it be a constant gas operation?
Sounds quite useful!
Need clarification in EIP: what should happen if the argument taken from the stack (assumed to be address):
- is over (or: is not exactly) 20 bytes long? EDIT: Perhaps: "same answer as for
- is a precompile address (a non-bytecode one like
0x01..0x04)? EDIT: Perhaps: "if it does have EVM
bytecodein the state, then a hash of that; if nothing, then
0x, i.e. nothing, - not a hash of
0x3d opcode slot is already taken by
0x3e is taken by
RETURNDATACOPY). Please bump the opcode number to
Posting here for completeness:
Here is my issue with EIP-1052 (the version as of 80b8f80).
I believe this test case:
“The EXTCODEHASH of an precompiled contract is either c5d246… or 0.”
is ambiguous and could lead to multiple, conflicting implementations. That of course would lead to a network split and cost billions of dollars.
The solution is to provide more explicit test cases, one that returns c5d246… and one that returns 0.
This issue may be resolved and it is also discussed here https://github.com/ethereum/EIPs/issues/1699#issuecomment-457867195 but I am cross posting here and sorry I should have posted here first then crossposted elsewhere.
This is covered by the ethereum reference tests for EXTCODEHASH, specifically https://github.com/ethereum/tests/blob/develop/src/GeneralStateTestsFiller/stExtCodeHash/extCodeHashDynamicArgumentFiller.json (and probably others) which checks both precompile 0x01 and 0x02 where 0x01 does not exist in state and 0x02 does. Basically precompiles have no code and whether they are present or not is determined by whether they exist in the actual world state or not like any other contract.