core, tests: implement Metropolis EIP 684

[karalabe]

Implements ethereum/EIPs#684.

Note, this PR is retroactively activated for all past transactions too. Please take care reviewing it.

[fjl]

Keccak256Hash

[fjl]

Why is this not env.StateDB.Exist?

[karalabe]

That results in a lot of test failures.

[karalabe]

I'm guessing it's some complexity with suicides within create.

[fjl]

Does it work with !env.StateDB.Empty(contractAddr)? Trying to avoid the complicated condition here.

[karalabe]

Empty also requires balance == 0. That's not the case here, balance is allowed to be > 0.

[fjl]

right

[holiman]

If you check the nonce first, you may not even need to get the contractHash from the db.

[karalabe]

Well, true, but the nonce and hash retrieval should cost the same. I.e. retrieving the nonce pulls in the account node from the trie, which also contains the contract hash, so it shouldn't matter much. But that's just my 2c.

[holiman]

Still, I prefer the less assuming kind of defensive programming:

	contractAddr = crypto.CreateAddress(caller.Address(), nonce)

	if existingHash := evm.StateDB.GetCodeHash(contractAddr); (existingHash != (common.Hash{}) && existingHash != emptyCodeHash) {
		if evm.StateDB.GetNonce(contractAddr) != 0 {
			return nil, common.Address{}, 0, ErrContractAddressCollision
		}
	}

But I can live with it anyway...

[karalabe]

It's a bit messier than that. Your code requires both the nonce and the code hash to be zero for the error to trigger. The true intent is either cases triggers it.

[karalabe]

But yeah, I do see your point.

[holiman]

At this point, the caller nonce is already incremented. Is that correct behaviour? Just want to double-check.

[holiman]

in exactly the same way as it would fail if the sender address did not have enough balance to create the contract with the given initial wei value.

Sounds like not incrementing nonce (?)

[karalabe]

Well yes, but the nonce is retrieved already in nonce. If you're asking whether a failure should increment the nonce or not, currently the tests expect it incremented. Not incrementing it would mean that Create transactions might have a new invalidity possibility which the txpool needs to handle.