You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 6, 2020. It is now read-only.
The specification of EIP 86 suggests that new contracts be created using the semantics of the CREATE2(value, salt, mem_start, mem_size) opcode. Primarily, this requires new contract addresses be created from hash(sender + salt + code_hash).
Currently it seems that Parity does not match the spec since:
salt is added after EIP-86 is implemented in Parity. That's why we didn't have it. I'll fix this.
One thing we need to take note is that this would break backward compatibility -- for current chain specs with eip86Transition implemented, it will no longer work. One way to fix this is to introduce a new flag (i.e. to support two different versions of EIP-86). I think that maintenance cost is high and I'm not sure whether there are actually chains using this feature right now. So I think I'm going to create the PR using the breaking backward compatibility route.
The specification of EIP 86 suggests that new contracts be created using the semantics of the
CREATE2(value, salt, mem_start, mem_size)
opcode. Primarily, this requires new contract addresses be created fromhash(sender + salt + code_hash)
.Currently it seems that Parity does not match the spec since:
FromSenderAndCodeHash
does not include a salt, which prevents a contract from callingCREATE2
multiple timescreate_address_scheme
usesFromCodeHash
as its post-eip86 defaultHopefully I'm not missing something very basic here.
The text was updated successfully, but these errors were encountered: