Czy Keccak-256 to to samo co SHA3-256?

Nie. Keccak-256 to wersja przesłana do NIST; SHA3-256 dodał dwa bity paddingu przed finalizacją. Wynik dla tego samego wejścia jest inny. Ethereum i EVM używają oryginalnego Keccak-256.

Gdzie pojawia się w Ethereum?

W selektorach funkcji, wyliczaniu storage slotów, checksumach EIP-55, deterministycznych adresach CREATE2 oraz w większości schematów podpisów wymagających 256-bitowego digestu.

Czy wynik jest deterministyczny dla tego samego wejścia?

Tak. Keccak-256 to funkcja czysta. Ten sam ciąg bajtów UTF-8 zawsze daje ten sam 32-bajtowy digest, niezależnie od przeglądarki czy sesji.

Czy Toova zapisuje moje wejście?

Nie. Hash liczony jest lokalnie w tej karcie. Ciąg ani digest nigdy nie trafiają na serwer.

Czy mogę użyć tego do kodowania ABI?

Zhashuj Keccak-256 kanoniczną sygnaturę funkcji, np. transfer(address,uint256) — to dokładnie 4-bajtowy prefiks, którego oczekują selektory — i weź pierwsze 4 bajty wyniku.

Hash Keccak-256 — używany przez Ethereum (EIP-55)

Hash Keccak-256

Prywatne z założenia — działa w całości w Państwa przeglądarce

Wrzuć dowolny ciąg UTF-8 do pola wejścia, a otrzymasz 32-bajtowy digest Keccak-256. Tego algorytmu Ethereum używa wszędzie: adresy z checksumem EIP-55, selektory funkcji, wyliczanie storage slotów oraz adresy kontraktów z CREATE2.

Keccak-256 a SHA3-256

Keccak-256 był propozycją Keccaka dla NIST, zanim stał się SHA3. Ostateczny standard SHA3 zmienił regułę paddingu (multi-rate padding dostał dwa dodatkowe bity), więc SHA3-256 i Keccak-256 dla tego samego wejścia różnią się. Ethereum został przy oryginalnym Keccaku, aby hash on-chain pasował do portfeli, indeksatorów i eksploratorów, które również używają Keccak-256.

Gdzie używa go Ethereum

Selektory funkcji to pierwsze 4 bajty keccak256("transfer(address,uint256)") i podobnych kanonicznych sygnatur. Storage sloty dla mappingów są wyznaczane przez keccak256(abi.encode(key, slot)). EIP-55 przełącza wielkość liter na podstawie keccak256 adresu zapisanego małymi literami. Adresy kontraktów z CREATE2 to keccak256 obejmujące deployera, salt i bytecode.

Jak działa implementacja

Strona dostarcza krótką permutację Keccak-f[1600] napisaną w JavaScript. Web Crypto nie udostępnia Keccak-256. Sprawdzisz implementację, porównując z digestem pustego stringa c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470. Wejście i wyjście nie opuszczają tej karty.

Najczęściej zadawane pytania

Czy Keccak-256 to to samo co SHA3-256?: Nie. Keccak-256 to wersja przesłana do NIST; SHA3-256 dodał dwa bity paddingu przed finalizacją. Wynik dla tego samego wejścia jest inny. Ethereum i EVM używają oryginalnego Keccak-256.
Gdzie pojawia się w Ethereum?: W selektorach funkcji, wyliczaniu storage slotów, checksumach EIP-55, deterministycznych adresach CREATE2 oraz w większości schematów podpisów wymagających 256-bitowego digestu.
Jak zweryfikować implementację?: Hashuj pusty string i porównaj z c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470. Każda różnica oznacza zły padding albo algorytm.
Czy wynik jest deterministyczny dla tego samego wejścia?: Tak. Keccak-256 to funkcja czysta. Ten sam ciąg bajtów UTF-8 zawsze daje ten sam 32-bajtowy digest, niezależnie od przeglądarki czy sesji.
Czy Toova zapisuje moje wejście?: Nie. Hash liczony jest lokalnie w tej karcie. Ciąg ani digest nigdy nie trafiają na serwer.
Czy mogę użyć tego do kodowania ABI?: Zhashuj Keccak-256 kanoniczną sygnaturę funkcji, np. transfer(address,uint256) — to dokładnie 4-bajtowy prefiks, którego oczekują selektory — i weź pierwsze 4 bajty wyniku.