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.

EIPS/eip-1014.md

@@ -10,14 +10,14 @@ 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
 
 Allows interactions to (actually or counterfactually in channels) be made with addresses that do not exist yet on-chain but can be relied on to only possibly eventually contain code that has been created by a particular piece of init code. Important for state-channel use cases that involve counterfactual interactions with contracts.
 
 #### 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.