extcodecopy/hash of zero size

[winsvega]

No description provided.

[dwightguth]

I'm a little confused by this test because it seems to not track with the definition of EXTCODEHASH as provided here: https://eips.ethereum.org/EIPS/eip-1052

According to EIP 1052, if the account does not have code then EXTCODEHASH should return c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470. Only if the account does not exist in the state trie should it return 0. However, it seems to me that this test is specifying that account 0xa300000000000000000000000000000000000000 does exist and simply has no code, 0 nonce, 0 balance, empty storage. In which case I would expect c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470 to be written to storage position 50, not 0.

It seems to me that either this test has incorrect expected output, or else the EIP needs to be updated to clarify that an account with no code, 0 balance, 0 nonce, and empty storage counts as not existing for the purposes of EXTCODEHASH.

[winsvega]

Storage position 0x50 has contract code in it. Did you mean 0x32 ? It has 0

[dwightguth]

Sorry I meant decimal 50 (0x32), not 0x50.

[gumb0]

@dwightguth Aleth returning 0 for an empty account comes from the following rule of EIP-158

3. Whenever the EVM checks if an account exists, emptiness is treated as equivalent to nonexistence. Particularly, note that this implies that, once this change is enabled, there is no longer a meaningful difference between emptiness and nonexistence from the point of view of EVM execution.

[lithp]

@dwightguth I ran into the same problem with this newest test release in trinity. I can confirm that both geth and parity (and now trinity) treat the empty account as if it doesn't exist, in accordance with EIP-158.

the EIP needs to be updated to clarify that an account with no code, 0 balance, 0 nonce, and empty storage counts as not existing for the purposes of EXTCODEHASH.

I agree that the EIP should be updated, this is confusing

[dwightguth]

KEVM now also has the same behavior of treating this in accordance with eip 161. It seems like the best path forward at this point is to update the spec as you say.