Funktions-Selektor und Event-Topic berechnen, auch rückwärts

02 / REGEL

So entsteht ein Selektor

Eine Transaktion an einen Vertrag beginnt mit 4 Byte. Der Vertrag vergleicht sie am Anfang seines Codes mit den Selektoren seiner Funktionen und springt zur passenden; die Argumente folgen danach. Woher die 4 Byte kommen, legt die ABI-Spezifikation von Solidity fest: Man schreibt die Signatur in eine feste Form, hasht sie mit Keccak-256 und nimmt den Anfang. Weil dieser Vergleich im Bytecode steht, lassen sich die Selektoren eines Vertrags auch ohne Quelltext auslesen Grech u. a. 2019.

Abb. 1 · Keccak-256 über die kanonische Signatur, gerechnet mit demselben Code wie das Werkzeug.

Die kanonische Form

Kanonisch heißt: Name, Klammer, die Typen mit genau einem Komma dazwischen. Parameternamen, memory und calldata, Sichtbarkeit, Modifier und der Rückgabetyp gehören nicht dazu. Ein einziges Leerzeichen ergibt einen ganz anderen Hash. Dazu kommen Ersetzungen, weil das ABI manche Solidity-Typen nicht kennt:

Regeln nach der Solidity-ABI-Spezifikation, Abschnitte „Types" und „Mapping Solidity to ABI types", Stand 14. November 2026.

Gleichnamige Funktionen mit anderen Typen sind verschiedene Funktionen. ERC-721 hat zwei safeTransferFrom: mit Datenfeld 0xb88d4fde, ohne 0x42842e0e. Eine öffentliche Zustandsvariable bekommt einen Getter mit eigenem Selektor; mapping(address => uint256) public balanceOf ergibt balanceOf(address) und damit 0x70a08231, genau wie die Funktion aus ERC-20. Bibliotheken bilden Selektoren für storage-Zeiger und structs nach einer eigenen Regel mit Typnamen; solche Funktionen rechnet das Werkzeug nicht und sagt das auch.

03 / EVENTS UND FEHLER

Topic0 für Events, Selektoren für Fehler

Ein Log-Eintrag trägt bis zu vier Topics. Das erste ist der volle Hash der Event-Signatur, die übrigen sind die indexierten Parameter, höchstens drei. Die nicht indexierten stehen im Datenteil. Wer Logs abfragt, filtert deshalb über das Topic0: Studien zum Token-Ökosystem bauen ihre Daten genau so aus den Event-Logs auf Chen u. a. 2020.

• Gleicher Name, gleicher Hash. Transfer aus ERC-20 und Transfer aus ERC-721 haben beide das Topic0 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef. Ob ein Parameter indexiert ist, ändert die Signatur nicht. Unterscheiden lassen sich die beiden an der Zahl der Topics: drei bei ERC-20, vier bei ERC-721.
• Indexierte Texte und Arrays. Bei string, bytes, Arrays und structs steht im Topic nur der Keccak-Hash des Werts. Den Text selbst bekommen Sie aus dem Log nicht zurück.
• Anonyme Events. Mit anonymous entfällt das Topic0, dafür darf ein vierter Parameter indexiert sein. Filtern geht dann nur über die Adresse und die Werte.

Fehler beim Abbruch

Bricht ein Vertrag ab, beginnen die Rückgabedaten mit einem Fehler-Selektor, gebildet wie bei Funktionen. Zwei sind fest eingebaut: 0x08c379a0 steht für Error(string) aus require oder revert mit Text, 0x4e487b71 für Panic(uint256) mit einem Code. Seit Solidity 0.8.4 gibt es eigene Fehler wie error ERC20InsufficientBalance(address,uint256,uint256), Selektor 0xe450d38c. Die Werte 0x00000000 und 0xffffffff sind reserviert; trifft ein eigener Fehler einen davon, warnt der Rechner.

04 / RÜCKWÄRTS

Was ein Selektor verrät und was nicht

Einen Hash kann man nicht umkehren. Man kann nur nachsehen, ob eine bekannte Signatur denselben Wert ergibt. Genau das tut die Rückwärtssuche, mit einer eigenen Liste von 263 Funktionen, 69 Events und 69 Fehlern aus den Standards und den Bibliotheken, die fast jeder Vertrag nutzt. Dass so eine Liste weit trägt, liegt am Ökosystem: Über 96 Prozent der untersuchten Verträge hatten Duplikate He u. a. 2020, und mehr als 80 Prozent der Teilverträge stammen aus fremden Quellen, ein gutes Drittel davon sind Interfaces für Standards Sun u. a. 2023.

Ein Treffer heißt trotzdem nur: Diese Signatur passt. Öffentliche Datenbanken mit Millionen Einträgen sind unvollständig, deshalb lesen Forscher Selektor und Parametertypen direkt aus dem Bytecode, mit 98,7 Prozent Trefferquote Chen u. a. 2022. Auch Decompiler leiten die Argumente ab Grech u. a. 2022, sind aber nicht fehlerfrei Liu u. a. 2023. Und ein Vertrag, der alle ERC-20-Selektoren hat, ist noch kein ordentlicher Token: Die Erkennung am Interface findet die Standard-Token zuverlässig, Token, die den Standard bewusst meiden, aber nur über ihr Verhalten Fröwis u. a. 2019. Welche Standards ein Vertrag erfüllt, lässt sich aus dem Bytecode prüfen di Angelo und Salzer 2020; die Interface-IDs nach ERC-165 rechnet der Rechner dafür mit.

Vier Byte sind schnell gefunden

Ein Selektor hat 2³² mögliche Werte, rund 4,3 Milliarden. Das klingt nach viel, reicht aber nicht gegen Absicht. Schon bei etwa 77.163 beliebigen Signaturen liegt die Wahrscheinlichkeit für irgendein Paar mit gleichem Selektor bei 50 Prozent. Wer gezielt einen bestimmten Selektor treffen will, probiert Namen durch, bis es passt. Das ist für heutige Rechner keine Hürde:

Beim Angriff auf Poly Network im August 2021 hat der Angreifer genau so einen Funktionsnamen gesucht: Sein Aufruf landete bei putCurEpochConPubKeyBytes(bytes), weil beide 0x41973cd9 ergeben (Vorfallsbericht bei rekt.news). Der Rechner warnt deshalb, wenn ein eingegebener Selektor in der Liste zu einer anderen Signatur gehört, und meldet gleiche Selektoren innerhalb Ihrer Eingabe. Wer wissen will, was eine konkrete Transaktion tut, liest die Calldata mit dem Calldata-Decoder und prüft die Zieladresse mit dem Ethereum-Adress-Prüfer.

05 / PROXY

Proxys: wenn zwei Verträge sich einen Selektor teilen

Viele Verträge lassen sich austauschen. Ein Proxy hält die Daten und reicht jeden Aufruf per delegatecall an eine Implementierung weiter, die sich später ersetzen lässt. Gemessen wurden 1,4 Millionen solcher Proxys, und rund die Hälfte ließ sich von einer einzelnen Adresse umstellen Salehi u. a. 2023. Eine Folgestudie beschreibt sechs gängige Muster und fand über 10.000 Ketten tatsächlicher Austausche Li u. a. 2024. Zur Einordnung: Über alle Verträge gerechnet sind nur 3 Prozent austauschbar, und davon wurden nur 0,34 Prozent je ausgetauscht Qasse u. a. 2025. Für die Selektoren heißt das: Hinter derselben Adresse können morgen andere Funktionen stehen.

Haben Proxy und Implementierung eine Funktion mit demselben Selektor, läuft die des Proxys, und die der Implementierung ist von außen nicht erreichbar. Das Transparent-Muster trennt deshalb Admin und Nutzer, beim UUPS-Muster liegt die Upgrade-Funktion in der Implementierung. Eine Messung über 36 Millionen Verträge fand 54,2 Prozent Proxys und rund 1,5 Millionen Verträge mit mindestens einer Kollision von Funktionen oder Speicher Chen u. a. 2025. Fügen Sie Proxy und Implementierung zusammen in den Rechner ein; gleiche Selektoren meldet er über Vertragsgrenzen hinweg.

Speicherplätze nach EIP-1967

Teilen sich zwei Verträge den Speicher und deuten ihn verschieden, entstehen Speicherkollisionen Ruaro u. a. 2024. EIP-1967 legt die Adresse der Implementierung deshalb an einen Platz, der aus einem Hash entsteht und mit keiner normalen Variable zusammenfällt: keccak256("eip1967.proxy.implementation") − 1. Wer einen 32-Byte-Wert nachschlägt, bekommt diese Plätze und die Upgrade-Events angezeigt.

Diamanten nach EIP-2535 gehen weiter: Ein Vertrag ordnet jeden Selektor einzeln einer Facette zu. Die Funktion dafür nimmt ein Array von structs mit einem enum, kanonisch diamondCut((address,uint8,bytes4[])[],address,bytes), Selektor 0x1f931c1c. Ein gutes Beispiel dafür, warum der Rechner structs und enums selbst auflöst: Von Hand vertippt man sich hier leicht.

06 / LISTE

Die Liste bekannter Signaturen

401 Signaturen in 48 Gruppen, jede mit Quelle und Version. Die Signaturen stammen aus den Quelldateien selbst, gelesen mit dem Parser dieses Werkzeugs; jeder Wert unten ist gerechnet. Wo eine Gruppe ein Interface genau abbildet, steht die Interface-ID nach ERC-165 dabei. Stand 14. November 2026.

07 / VORGEHEN

So prüfen Sie Selektoren in der Praxis

1. Signatur aus dem verifizierten Quelltext nehmen. Nicht aus einem Forum und nicht aus einer Datenbank. Ganze Dateien samt struct- und enum-Definitionen können Sie direkt einfügen.
2. Selektor im Bytecode suchen. Steht der Wert nicht im Code des Vertrags, hat er die Funktion nicht, egal was die Oberfläche sagt.
3. Bei Proxys die Implementierung lesen. Ihre Adresse steht im EIP-1967-Speicherplatz. Proxy und Implementierung zusammen in den Rechner geben, Kollisionen prüfen.
4. Events über das Topic0 filtern und an der Zahl der Topics prüfen, welcher Standard dahintersteht.
5. Fehler entschlüsseln. Die ersten 4 Byte der Rückgabe nachschlagen; Text und Argumente zeigt der Calldata-Decoder.

Wo der Rechner aufhört

• Keine Blockchain. Er rechnet aus Text. Ob ein Vertrag eine Funktion hat, zeigt erst sein Bytecode.
• Unbekannte Typen. Ist ein struct oder enum nicht mit eingefügt, rechnet er die Signatur nicht. Namen nach dem Muster IName wertet er als Interface und sagt das dazu.
• Bibliotheken. Externe Bibliotheksfunktionen mit storage-, struct- oder enum-Parametern folgen einer eigenen Regel und bleiben außen vor.
• Rückwärtssuche als Kandidat. Die Liste ist kuratiert, nicht vollständig. Ein Treffer ist eine passende Signatur, kein Beweis.

Mehr Werkzeuge rund um Verträge und Wallets stehen in der Web3-Übersicht, darunter der Gas-Rechner. Wie wir Smart Contracts und die Oberflächen dazu bauen, steht unter Web3-Entwicklung.

08 / FORSCHUNG

Was die Forschung dazu sagt

Fünf Befunde, die das Werkzeug prägen. Die vollständige Liste mit Prüfvermerk steht weiter unten.

• Selektoren stecken im Bytecode. Decompiler lesen über 99,98 Prozent der Verträge Grech u. a. 2019, Signaturen samt Typen lassen sich zu 98,7 Prozent zurückgewinnen Chen u. a. 2022. Darum verweist der Rechner bei jeder Unsicherheit auf den Bytecode.
• Wenige Standards decken viel ab. Verträge sind stark kopiert He u. a. 2020 und bestehen großteils aus fremden Bausteinen Sun u. a. 2023. Deshalb ist die Liste nach Bibliotheken gegliedert und nennt die Version.
• Selektoren beweisen keinen Standard. Token lassen sich am Interface erkennen, solche ohne Standard nur am Verhalten Fröwis u. a. 2019.
• Proxys sind häufig, Kollisionen auch. Mehr als jeder zweite aktive Vertrag ist ein Proxy, rund 1,5 Millionen zeigen eine Kollision Chen u. a. 2025. Der Rechner prüft deshalb über Vertragsgrenzen hinweg.
• Speicher braucht feste Plätze. Speicherkollisionen sind ein eigenes Risiko Ruaro u. a. 2024; die EIP-1967-Plätze erkennt der Rechner beim Nachschlagen.

09 / FÜR KI-ASSISTENTEN

Dieses Werkzeug aus einem KI-Assistenten nutzen

Assistenten wie Claude oder ChatGPT, die das Model Context Protocol (MCP) sprechen, können die Rechnung dieser Seite direkt aufrufen, statt sie nachzubauen. Der Server ist öffentlich, braucht keine Anmeldung und speichert nichts. Die Antwort enthält immer den Link auf diese Seite, den Stand der Daten und die Grenzen des Ergebnisses.

Endpunkt

https://aureum-tech.com/mcp

Werkzeug

werkzeug_selektor_rechner

Transport

Streamable HTTP, nur lesend

Fragen, bei denen ein Assistent es aufrufen sollte

• „Welcher Funktions-Selektor gehört zu transfer(address,uint256)?"
• „Zu welcher Funktion gehört der Selektor 0x095ea7b3?"
• „Wie lautet das Topic0 für event Transfer(address indexed from, address indexed to, uint256 value)?"
• „Rechne mir aus dieser ABI alle Selektoren aus und prüfe, ob zwei Funktionen kollidieren."
• „Welche Interface-ID nach ERC-165 hat dieses Solidity-Interface?"

Wie die Anbindung funktioniert und was MCP im eigenen Betrieb leisten kann, steht auf der Seite zu MCP-Integrationen.

10 / HÄUFIGE FRAGEN

Häufige Fragen zu Selektoren und Topics