Ist Keccak-256 dasselbe wie SHA3-256?

Nein. Keccak-256 ist die NIST-Einreichung; SHA3-256 ergänzte vor der Finalisierung zwei Padding-Bits. Gleicher Input, anderer Output. Ethereum und EVM nutzen das originale Keccak-256.

Wo taucht er in Ethereum auf?

In Function Selectors, der Ableitung von Storage Slots, EIP-55-Checksum-Adressen, deterministischen Adressen aus CREATE2 und den meisten Signaturschemas mit 256-Bit-Digest.

Ist die Ausgabe für denselben Input deterministisch?

Ja. Keccak-256 ist eine reine Funktion. Dieselbe UTF-8-Byte-Folge liefert immer denselben 32-Byte-Digest, unabhängig vom Browser oder Lauf.

Speichert Toova den Input?

Nein. Der Hash wird lokal in diesem Tab gerechnet. String und Digest reisen nicht zu einem Server.

Kann ich das für ABI-Encoding nutzen?

Bilden Sie Keccak-256 über die kanonische Funktionssignatur, z. B. transfer(address,uint256), genau wie es Selectors erwarten, und übernehmen Sie die ersten 4 Bytes.

Keccak-256-Hash — von Ethereum verwendet (EIP-55)

Fügen Sie einen beliebigen UTF-8-Text in das Eingabefeld ein und sehen Sie den 32 Byte langen Keccak-256-Digest. Genau das ist der Algorithmus, den Ethereum überall nutzt: EIP-55-Checksum-Adressen, Function Selectors, Ableitung von Storage Slots und Contract-Adressen via CREATE2.

Keccak-256 vs. SHA3-256

Keccak-256 war Keccaks Einreichung beim NIST, bevor sie zum SHA3 wurde. Der finale SHA3-Standard änderte die Padding-Regel (Multi-Rate-Padding bekam zwei zusätzliche Bits), deshalb unterscheiden sich SHA3-256 und Keccak-256 desselben Inputs. Ethereum hielt am ursprünglichen Keccak fest, damit On-Chain-Hashes zu Wallets, Indexern und Explorern passen, die alle Keccak-256 verwenden.

Wo Ethereum ihn einsetzt

Function Selectors sind die ersten 4 Bytes von keccak256("transfer(address,uint256)") und vergleichbaren kanonischen Signaturen. Storage Slots für Mappings leiten sich aus keccak256(abi.encode(key, slot)) ab. EIP-55 mischt die Groß-/Kleinschreibung anhand des Keccak-256 der Kleinbuchstaben-Adresse. Contract-Adressen aus CREATE2 entstehen aus Keccak-256 über Deployer, Salt und Bytecode.

Wie die Implementierung läuft

Die Seite liefert eine schlanke Keccak-f[1600]-Permutation in JavaScript mit; Web Crypto kennt sie nicht. Sie können sie prüfen, indem Sie mit dem bekannten Leerstring-Digest c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470 vergleichen. Eingaben und Ausgaben verlassen den Tab nicht.

Häufig gestellte Fragen

Ist Keccak-256 dasselbe wie SHA3-256?: Nein. Keccak-256 ist die NIST-Einreichung; SHA3-256 ergänzte vor der Finalisierung zwei Padding-Bits. Gleicher Input, anderer Output. Ethereum und EVM nutzen das originale Keccak-256.
Wo taucht er in Ethereum auf?: In Function Selectors, der Ableitung von Storage Slots, EIP-55-Checksum-Adressen, deterministischen Adressen aus CREATE2 und den meisten Signaturschemas mit 256-Bit-Digest.
Wie verifiziere ich die Implementierung?: Hashen Sie den leeren String und vergleichen Sie mit c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470. Jede Abweichung deutet auf falsches Padding oder einen anderen Algorithmus hin.
Ist die Ausgabe für denselben Input deterministisch?: Ja. Keccak-256 ist eine reine Funktion. Dieselbe UTF-8-Byte-Folge liefert immer denselben 32-Byte-Digest, unabhängig vom Browser oder Lauf.
Speichert Toova den Input?: Nein. Der Hash wird lokal in diesem Tab gerechnet. String und Digest reisen nicht zu einem Server.
Kann ich das für ABI-Encoding nutzen?: Bilden Sie Keccak-256 über die kanonische Funktionssignatur, z. B. transfer(address,uint256), genau wie es Selectors erwarten, und übernehmen Sie die ersten 4 Bytes.