Sélecteur de Fonction Solidity

À propos du Sélecteur de Fonction Solidity

L'outil Sélecteur de Fonction Solidity aide les développeurs à travailler avec les sélecteurs de fonction et les signatures d'événements de smart contracts Ethereum. Les sélecteurs de fonction sont les 4 premiers octets du hachage Keccak256 d'une signature de fonction et sont utilisés pour identifier quelle fonction appeler dans un smart contract. Les signatures d'événements (Topic0) sont le hachage Keccak256 complet de 32 octets de la signature d'événement. Cet outil génère des sélecteurs à partir de signatures et recherche des sélecteurs communs dans une base de données intégrée.

Qu'est-ce qu'un sélecteur de fonction ?

Un sélecteur de fonction est un identifiant de 4 octets utilisé dans Ethereum pour spécifier quelle fonction appeler dans un smart contract. Il est calculé comme les 4 premiers octets du hachage Keccak256 de la signature de fonction. Par exemple, la signature de fonction 'transfer(address,uint256)' génère le sélecteur '0xa9059cbb'.

Comment les sélecteurs de fonction sont-ils calculés ?

Les sélecteurs de fonction sont calculés en :
1. Créant la signature de fonction (ex: 'transfer(address,uint256)')
2. Calculant le hachage Keccak256 de la signature
3. Prenant les 4 premiers octets (8 caractères hex) du hachage
4. Ajoutant '0x' au début pour créer le sélecteur

Qu'est-ce qu'une signature d'événement (Topic0) ?

Une signature d'événement, également appelée Topic0, est le hachage Keccak256 complet de 32 octets d'une signature d'événement. Contrairement aux sélecteurs de fonction qui n'utilisent que 4 octets, les signatures d'événements utilisent le hachage complet. Ceci est utilisé pour identifier les événements dans les logs de transaction. Par exemple, 'Transfer(address,address,uint256)' génère un Topic0 unique de 32 octets.

Pourquoi rechercher des sélecteurs de fonction ?

Lors de l'analyse de smart contracts ou de transactions, vous rencontrez souvent des sélecteurs de fonction bruts (comme 0xa9059cbb) sans savoir quelle fonction ils représentent. La recherche de sélecteurs vous aide à comprendre quelles fonctions sont appelées. C'est particulièrement utile pour le débogage, l'audit ou la compréhension de contrats inconnus.

Quelle est la différence entre les sélecteurs de fonction et d'événement ?

Les sélecteurs de fonction font 4 octets (8 caractères hex) et identifient les appels de fonction, tandis que les signatures d'événements font 32 octets (64 caractères hex) et identifient les événements dans les logs. Les sélecteurs de fonction sont utilisés dans les données d'entrée de transaction, tandis que les signatures d'événements apparaissent comme Topic0 dans les logs de transaction.

Quelle est la différence entre selector de fonction et Topic0 d'événement ?

Le selector de fonction est les 4 PREMIERS OCTETS de Keccak256(funcName(types)) utilisés dans le calldata. Le Topic0 d'événement est les 32 OCTETS complets de Keccak256(EventName(types)) utilisés comme premier topic dans les logs. Les fonctions sont compactes (4 octets) car le calldata coûte du gas ; les événements utilisent le hash complet pour l'indexation off-chain.

Pourquoi utiliser Keccak-256 au lieu de SHA3-256 pour Ethereum ?

Ethereum s'est standardisé sur la version pré-NIST de Keccak-256 AVANT que NIST ne l'ajuste en SHA3 final (qui a ajouté du padding). Beaucoup de bibliothèques appellent keccak256 la variante Ethereum pour distinguer. SHA3-256 et Keccak-256 produisent des hashes DIFFÉRENTS pour la même entrée — utiliser SHA3 donne des selectors erronés.

Deux fonctions différentes peuvent-elles partager accidentellement le même selector 4 octets ?

Oui, on appelle ça une collision de selector. La chance est ~1 sur 4,3 milliards par paire de fonctions (2^32). La fameuse collision Solidity 0x42966c68 : burn(uint256) et burn_uint256_(uint256). Les compilateurs modernes alertent sur les collisions dans un contrat. Le risque est surtout avec les proxy patterns où vous contrôlez le routage delegatecall.

Comment chercher un selector 4 octets inconnu vu sur Etherscan ?

Collez-le dans des bases comme 4byte.directory ou Openchain.xyz — elles hébergent des millions de signatures canonisées crowdsourcées de contrats vérifiés. Cet outil pointe vers les deux. Si le selector n'est pas dans la base, la fonction vient probablement d'un contrat non vérifié ou d'une stratégie DEX privée ; on peut parfois matcher par motif calldata.

Quelles sont les règles de signature canonique, et pourquoi 'uint' donne-t-il un sélecteur différent de 'uint256' ?

Solidity hache une forme canonique stricte : AUCUN espace, chaque type écrit en entier. 'uint' est un alias de 'uint256', 'int' de 'int256' et 'byte' de 'bytes1' — mais le sélecteur est le Keccak-256 de la chaîne littérale, donc 'transfer(address, uint256)' avec un espace, ou 'transfer(address,uint)', produit une valeur qui ne correspondra JAMAIS au contrat déployé. Les tuples (structs) s'écrivent en listes de types entre parenthèses, ex. exactInputSingle((address,address,uint24,...)), et les suffixes de tableau comme [] ou [3] sont conservés. Cet outil normalise votre entrée et affiche la signature canonique exacte qu'il a hachée, pour que vous puissiez la vérifier avant de signer une transaction.

Quel est le lien entre le sélecteur 4 octets et le calldata d'une transaction ?

Les données d'entrée de la transaction = le sélecteur 4 octets suivi des arguments encodés en ABI, chacun complété jusqu'à un mot de 32 octets (64 caractères hex). Les types statiques (address, uint256, bool) sont en ligne dans leur emplacement d'en-tête ; les types dynamiques (bytes, string, T[]) placent un DÉCALAGE de 32 octets dans l'en-tête qui pointe vers la longueur+données en fin. Lire le calldata consiste donc à : retirer les 4 premiers octets pour identifier la fonction, puis découper le reste en mots de 32 octets selon la signature. Le Modèle de calldata de cet outil fournit ce squelette (sélecteur + un mot à zéro par argument de premier niveau) à coller dans eth_call ou cast et à compléter.

Fonctionnalités clés

• Générer des sélecteurs de fonction (4 octets) depuis les signatures
• Générer des signatures d'événements (Topic0, 32 octets)
• Afficher le hachage Keccak256 complet
• Rechercher les sélecteurs de fonction communs dans la base de données intégrée
• Valider les formats de signature et de sélecteur
• Charger des exemples aléatoires pour les tests
• Liens vers bases de données de signatures externes (4byte.directory, Openchain)
• Inclut plus de 30 sélecteurs communs ERC20, DeFi et gouvernance
• Calcul côté client pour la confidentialité