Que fait vraiment cette transaction Ethereum ?
Vous regardez une transaction de smart contract (un programme qui tourne sur la blockchain Ethereum) et vous voyez quelque chose comme 0xa9059cbb000000...0de0b6b3a7640000. Les dix premiers caractères ne sont pas aléatoires. C'est le function selector, un court identifiant qui dit au contrat : *« appelle la fonction transfer »*.
Cet outil fait deux choses. Un : saisissez une signature de fonction comme transfer(address,uint256) et obtenez son identifiant de 4 octets (0xa9059cbb). Ce sont les 4 octets qui apparaissent au début de chaque transaction appelant cette fonction.
Deux : collez un blob de calldata brut (l'hex d'une transaction), l'outil extrait le selector, le cherche dans un registre intégré d'environ 30 fonctions courantes (ERC-20, NFTs, Uniswap, WETH, proxies, ENS), et vous montre quels arguments ont été passés.
Tout tourne localement dans votre navigateur, sans appel d'API, sans données qui quittent l'appareil. Parfait pour déboguer des transactions de wallet, lire des transactions en attente sur Etherscan, ou juste apprendre comment fonctionne l'ABI de l'EVM.
Mode d'emploi
- Choisissez un mode en haut : Compute selector (vous connaissez le nom de la fonction, vous voulez l'identifiant) ou Decode calldata (vous avez un blob hex et voulez savoir ce qu'il fait).
- En mode Compute selector : saisissez la signature de fonction du type functionName(argType1,argType2). Pas d'espaces, pas de noms d'arguments, juste les types. Le résultat de 4 octets apparaît instantanément.
- En mode Decode calldata : collez l'hex complet de la transaction (avec 0x ou sans). L'outil lit les 4 premiers octets et les cherche dans le registre intégré. S'il les trouve, il affiche le nom de la fonction et un tableau de paramètres. Sinon, vous pouvez saisir la signature à la main.
- Cliquez sur les pastilles d'exemple sous le champ (transfer, approve, swap) pour voir à quoi ressemblent les opérations courantes.
- La liste en bas est le registre intégré de selectors (environ 30 courants). Cliquez sur n'importe quelle entrée pour pré-remplir le champ.
- Les arguments string, bytes et tableaux sont marqués *« (type dynamique) »* et sautés, le décodage complet exige une logique d'offset complexe (hors scope ici). Les adresses et entiers se décodent très bien.
Quand c'est utile
Six situations typiques où le selector vous donne une réponse concrète :
- Déboguer une transaction wallet bizarre. Quelque chose a disparu de votre wallet et vous ne savez plus ce que vous avez cliqué. Copiez la calldata depuis Etherscan, collez ici, vous voyez immédiatement : *« ah, c'était un approve pour de l'USDT illimité vers un contrat random »*. Vous savez maintenant quoi révoquer.
- Lire une transaction en attente sur Etherscan. Vous voulez savoir ce que le contrat va faire avant de signer dans MetaMask. Collez le champ *« Input Data »*, vous voyez : *« swapExactTokensForTokens, un swap DEX »*. Cerveau apaisé.
- Construire une intégration avec un smart contract. Vous devez construire la calldata à la main (par exemple pour un multicall ou un framework non standard). Vous calculez le selector pour chaque fonction, concaténez avec les arguments. C'est l'étape un.
- Apprendre comment l'ABI fonctionne. Premier jour avec Solidity et quelqu'un vous lance *« function selector »*. Saisissez transfer(address,uint256), vous obtenez 0xa9059cbb, changez en Transfer(...) (T majuscule), selector totalement différent. Donc même la casse compte. Leçon retenue.
- Revue de sécurité d'un contrat. Vous avez une transaction suspecte qui aurait appelé *« claimAirdrop »*, mais quelque chose cloche. Calculez le selector pour claimAirdrop() et vérifiez s'il correspond aux 4 premiers octets de la calldata. Sinon, quelqu'un a essayé de vous duper.
- Écrire des tests Foundry / Hardhat. Vous devez hardcoder un selector dans un test (par exemple pour expectRevert(bytes4)). Calculez ici, copiez, collez dans le test. Pas besoin d'installer cast ni de monter une toolchain à part.