O Ethereum adotou o Keccak antes de o NIST finalizar o SHA-3. Depois, o FIPS 202 acrescentou bits de separação de domínio ao padding da mensagem (o primeiro byte de padding é 0x06 no SHA3-256 e 0x01 no Keccak-256), de modo que as duas funções compartilham a permutação e os parâmetros, mas produzem digests sem nenhuma relação entre si. O Keccak-256 da string vazia é c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470, enquanto o SHA3-256 da mesma entrada é a7ffc6f8…f8434a.
O Ethereum o usa em endereços (os últimos 20 bytes do hash de uma chave pública de 64 bytes), em seletores de função da ABI (os 4 primeiros bytes do hash de transfer(address,uint256) são a9059cbb), em tópicos de eventos, em slots de armazenamento, em hashes de assinatura EIP-191 e EIP-712 e nas entradas do ecrecover. O keccak256 do Solidity e o método RPC web3_sha3 calculam o Keccak-256, apesar do nome deste último.
O bug clássico é chamar o sha3_256 (FIPS) de uma biblioteca quando o Ethereum espera o Keccak-256: todos os digests, endereços e verificações de assinatura saem errados, sem nenhum erro. Use funções chamadas keccak256 ou keccak_256.