Sélecteur de Fonction Solidity
Générez les selectors de fonction Solidity et hashes Topic0 d'événement depuis les signatures. Encodez selectors 4 octets, recherchez signatures ERC20.
À 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.
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é
