EIP-1014: Use keccak256 name instead of sha3

Do not refer to the hash function as `sha3` because it is SHA3. Use more precise `keccak256` name.
This commit is contained in:
Paweł Bylica 2018-07-23 16:44:29 +02:00
parent 7dbcbc35e4
commit 5d9f96ac3e
No known key found for this signature in database
GPG Key ID: 7A0C037434FE77EF
1 changed files with 3 additions and 3 deletions

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.