Ethereum adoptó Keccak antes de que el NIST publicara la versión final de SHA-3. Después, FIPS 202 añadió bits de separación de dominio al relleno del mensaje (el primer byte de relleno es 0x06 en SHA3-256 y 0x01 en Keccak-256), así que las dos funciones comparten la permutación y los parámetros, pero producen resúmenes sin ninguna relación entre sí. Keccak-256 de la cadena vacía es c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470, mientras que SHA3-256 de la misma entrada es a7ffc6f8…f8434a.
Ethereum lo usa para las direcciones (los últimos 20 bytes del hash de una clave pública de 64 bytes), los selectores de función de la ABI (los primeros 4 bytes del hash de transfer(address,uint256) son a9059cbb), los topics de los eventos, las ranuras de almacenamiento, los hashes de firma de EIP-191 y EIP-712 y las entradas de ecrecover. Tanto keccak256 de Solidity como el método RPC web3_sha3 calculan Keccak-256, pese al nombre de este último.
El error clásico es llamar a la función sha3_256 (FIPS) de una biblioteca cuando Ethereum espera Keccak-256: todos los resúmenes, las direcciones y las verificaciones de firma salen mal sin que aparezca ningún error. Usa funciones llamadas keccak256 o keccak_256.