Merge pull request #1247 from chfast/eip-1014-keccak256

EIP-1014: Use keccak256 name instead of sha3
This commit is contained in:
Martin Holst Swende 2018-09-26 00:14:02 +02:00 committed by GitHub
commit 822bc28f66
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -10,7 +10,7 @@ created: 2018-04-20
### Specification
Adds a new opcode at 0xf5, which takes 4 stack arguments: endowment, memory_start, memory_length, salt. Behaves identically to CREATE, except using `sha3(msg.sender ++ salt ++ init_code)[12:]` instead of the usual sender-and-nonce-hash as the address where the contract is initialized at.
Adds a new opcode at 0xf5, which takes 4 stack arguments: endowment, memory_start, memory_length, salt. Behaves identically to CREATE, except using `keccak256(msg.sender ++ salt ++ init_code)[12:]` instead of the usual sender-and-nonce-hash as the address where the contract is initialized at.
### Motivation
@ -18,6 +18,6 @@ Allows interactions to (actually or counterfactually in channels) be made with a
#### Option 2
Use `sha3(0xff ++ msg.sender ++ salt ++ init_code)[12:]`
Use `keccak256(0xff ++ msg.sender ++ salt ++ init_code)[12:]`
Rationale: ensures that addresses created with this scheme cannot collide with addresses created using the traditional `sha3(rlp([sender, nonce]))` formula, as 0xff can only be a starting byte for RLP for data many petabytes long.
Rationale: ensures that addresses created with this scheme cannot collide with addresses created using the traditional `keccak256(rlp([sender, nonce]))` formula, as 0xff can only be a starting byte for RLP for data many petabytes long.