core/vm, params: implement EXTCODEHASH opcode

[rjl493456442]

Implements EIP1052.

[holiman]

From eip:

In case the account does not have code the keccak256 hash of empty data (i.e. c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470) is pushed to the stack. In case the account does not exist 0 is pushed to the stack.

I don't see the check for existence, as implemented it will set zero for both non-existent and no-code ( I may be wrong...?)

[karalabe]

Martin is right here, if the code does have a hash, you can return it. If there is no code however, 3 scenarios can happen:

• The account is a plain account: the returned code hash should be Keccak256("") (ie. c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470)
• The account is a precompile, this is an interesting case, but I think Keccak256("") would be the correct one.
• The account does not exist: 00...0

Please see https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1052.md#test-cases for details

[karalabe]

I think you could simplify this code via:

slot := stack.peek()
slot.SetBytes(evm.StateDB.GetCodeHash(common.BigToAddress(slot)))

I.e. Your optimization of slot.SetUint64(0) is not worth it, because it entails the hash == (common.Hash{}) comparison, which in theory should be equivalent runtime wise to slot.SetBytes(hash.Bytes()).

[rjl493456442]

@holiman @karalabe This PR relays everything to state.GetCodeHash function.
For example:

• if an account is not exist, this function will return common.Hash{}, zero result will be set.
• if an account is exist but no code, this function will return emptyCodeHash, emptyCodeHash will be set.
• if an account is marked as deleted, this function will return common.Hash{}, zero result will be set.
• if an account is marked as suicide(has not been deleted yet), this function will return the code hash.

All things will keep continuous with statedb.

[karalabe]

Nitpick, this was correct, because this is EIP155 and EIP158 combo :)

[karalabe]

But maybe we can correct it to EIP155/EIP158

[karalabe]

@rjl493456442 You are right with regard to the behavior. I stand corrected, code LGTM, just please fix the two issues I've raised just now.

[rjl493456442]

@karalabe Updated

[karalabe]

Ah, sorry for a followup nitpick. Could you add your comment (#17202 (comment)) into that method's description just so any reviewer will know why it works correctly?

[karalabe]

LGTM

[holiman]

Lgtm