Add EIP-1014 transition config flag

[sorpaas]

rel #8427

[Tbaut]

Can we also update the doc please? https://github.com/paritytech/wiki/blob/master/Chain-specification.md

[andresilva]

Unfortunately I don't think the CREATE2 opcode from EIP1014 is compatible with EIP86. The opcode is represented by a different hexcode and the order of arguments in the stack is different.

[andresilva]

Maybe the EIPs should be updated so that both interfaces are compatible?

[sorpaas]

Hmm indeed. I apparently missed this important difference. I added a comment on ethereum/EIPs#1014. Let me put this on ice until the spec is cleared out.

[sorpaas]

Per discussion during the last AllCoreDevs, the issue is that even if we keep EIP-86, it will need to be vastly changed. So it was decided to deprecate EIP-86:

• I removed all EIP-86 related flags.
• Null signed transaction functionalities are kept. We're still using null signed transactions some places in our code. In execution context, the old config eip86 is only used to know whether we should keep null signed address nonce unchanged. So I renamed it to keep_unsigned_nonce.
• Comply the CREATE2 definition with the current EIP-1014 (Option 2). This also affects KIP-4, but I guess that's unreleased feature so it should be okay.

[cheme]

The PR seems fine (until next change of the eip formula (I hope not), still a few minor points :

• I spotted two others deprecated comments (reference to eip86 on enum we are using) at https://github.com/paritytech/parity-ethereum/blob/9fcc6b02e3562ebfb25f43aa572f81fd8a7b9346/ethcore/vm/src/ext.rs#L56 and two lines bellow.

• Also, if I understood correctly keep_unsigned_nonce is only here for deprecating a functionality in the future, but not related to this EIP (it will not be set to true at constantinople release) ?

• Lastly at https://github.com/paritytech/parity-ethereum/blob/9fcc6b02e3562ebfb25f43aa572f81fd8a7b9346/ethcore/src/externalities.rs#L208 (from eip86 initial code), we can try to avoid the call to nonce for our new opcode by changing contract_address function prototype a bit. I am not sure that this refactoring is worth it.

[sorpaas]

we can try to avoid the call to nonce for our new opcode by changing contract_address function prototype a bit.

Can't think of a good way to refactor that right now. I think it would need to give a state reference to contract_address fn but that'll certainly not worth it. I'll keep thinking though. :)

if I understood correctly keep_unsigned_nonce is only here for deprecating a functionality in the future, but not related to this EIP

keep_unsigned_nonce is for null signed transaction, which was a part of EIP-86. I think that's a generally useful feature even though we don't want EIP-86 itself any more (for example, the old Casper spec needs null signed transaction). And yes, that change is not related to EIP-1014.

[sorpaas]

Ooops! I apparently forgot to push the fix commit for @cheme's grumbles. Sorry!

[cheme]

I also forgot the 'grumble' tag, I am glad I understand correctly the keep_unsigned_once, seems like I do not have other comments.

[cheme]

Sorry for the misclick (I accidently close the pr).

[andresilva]

LGTM! Is the EIP discussion finalized? This PR implements the address derivation as sha3(0xff ++ msg.sender ++ salt ++ sha3(init_code))) which is different from the EIP but seems to be what's settled in the EIP issue for now. Do you think we should merge this PR or wait to make sure the discussion is over? Also, should we update pwasm create2 defition?

[sorpaas]

Yeah I think let's just wait till this Friday's meeting (ethereum/pm#55), and merge this if there's no other issues.

With this PR, create2 also uses the sha3(0xff ++ msg.sender ++ salt ++ sha3(init_code))). I'll get the spec update done soon.

[5chdn]

Putting this on ice till Friday.