Seletor de Função Solidity

Sobre Seletor de Função Solidity

A ferramenta Seletor de Função Solidity ajuda desenvolvedores a trabalhar com seletores de função de contratos inteligentes Ethereum e assinaturas de eventos. Seletores de função são os primeiros 4 bytes do hash Keccak256 de uma assinatura de função e são usados para identificar qual função chamar em um contrato inteligente. Assinaturas de evento (Topic0) são o hash Keccak256 completo de 32 bytes da assinatura do evento. Esta ferramenta gera seletores a partir de assinaturas e consulta seletores comuns em um banco de dados integrado.

O que é um seletor de função?

Um seletor de função é um identificador de 4 bytes usado no Ethereum para especificar qual função chamar em um contrato inteligente. É calculado como os primeiros 4 bytes do hash Keccak256 da assinatura da função. Por exemplo, a assinatura de função 'transfer(address,uint256)' gera o seletor '0xa9059cbb'.

Como são calculados seletores de função?

Seletores de função são calculados:
1. Criando a assinatura da função (ex: 'transfer(address,uint256)')
2. Computando o hash Keccak256 da assinatura
3. Pegando os primeiros 4 bytes (8 caracteres hex) do hash
4. Adicionando prefixo '0x' para criar o seletor

O que é uma assinatura de evento (Topic0)?

Uma assinatura de evento, também conhecida como Topic0, é o hash Keccak256 completo de 32 bytes de uma assinatura de evento. Diferente de seletores de função que usam apenas 4 bytes, assinaturas de evento usam o hash completo. Isso é usado para identificar eventos em logs de transação. Por exemplo, 'Transfer(address,address,uint256)' gera um Topic0 único de 32 bytes.

Por que consultar seletores de função?

Ao analisar contratos inteligentes ou transações, você frequentemente encontra seletores de função brutos (como 0xa9059cbb) sem saber qual função eles representam. Consultar seletores ajuda você a entender quais funções estão sendo chamadas. Isso é especialmente útil para depuração, auditoria ou entender contratos desconhecidos.

Qual é a diferença entre seletores de função e evento?

Seletores de função são 4 bytes (8 caracteres hex) e identificam chamadas de função, enquanto assinaturas de evento são 32 bytes (64 caracteres hex) e identificam eventos em logs. Seletores de função são usados em dados de entrada de transação, enquanto assinaturas de evento aparecem como Topic0 em logs de transação.

Qual a diferença entre selector de função e Topic0 de evento?

Selector de função são os 4 PRIMEIROS BYTES de Keccak256(funcName(types)) usados em calldata. Topic0 de evento são os 32 BYTES completos de Keccak256(EventName(types)) usados como primeiro topic em logs. Funções são compactas (4 bytes) porque calldata custa gas; eventos usam hash completo para indexação off-chain.

Por que usar Keccak-256 em vez de SHA3-256 para Ethereum?

Ethereum padronizou na versão pré-NIST de Keccak-256 ANTES de NIST ajustar para o SHA3 final (que adicionou padding). Muitas bibliotecas chamam keccak256 a variante Ethereum para distinguir. SHA3-256 e Keccak-256 produzem hashes DIFERENTES para o mesmo input — usar SHA3 dá selectors errados.

Duas funções diferentes podem acidentalmente compartilhar o mesmo selector 4 bytes?

Sim, chama-se colisão de selector. A chance é ~1 em 4,3 bilhões por par de funções (2^32). A famosa colisão Solidity 0x42966c68: burn(uint256) e burn_uint256_(uint256). Compiladores modernos avisam de colisões em um contrato. O risco maior está em proxy patterns onde você controla o delegatecall routing.

Como buscar um selector 4 bytes desconhecido visto no Etherscan?

Cole em bases como 4byte.directory ou Openchain.xyz — hospedam milhões de assinaturas canonizadas via crowdsource de contratos verificados. Esta ferramenta linka para ambas. Se o selector não está na base, a função provavelmente veio de contrato não verificado ou estratégia DEX privada; às vezes dá para casar pelo padrão calldata.

Quais são as regras de assinatura canônica e por que 'uint' gera um seletor diferente de 'uint256'?

O Solidity faz hash de uma forma canônica estrita: SEM espaços, cada tipo escrito por extenso. 'uint' é alias de 'uint256', 'int' de 'int256' e 'byte' de 'bytes1' — mas o seletor é o Keccak-256 da string literal, então 'transfer(address, uint256)' com espaço, ou 'transfer(address,uint)', gera um valor que NUNCA vai casar com o contrato implantado. Tuplas (structs) são escritas como listas de tipos entre parênteses, ex. exactInputSingle((address,address,uint24,...)), e sufixos de array como [] ou [3] são mantidos. Esta ferramenta normaliza sua entrada e mostra a assinatura canônica exata que recebeu hash, para você verificar antes de assinar uma transação.

Como o seletor de 4 bytes se relaciona com o calldata de uma transação?

Os dados de entrada da transação = o seletor de 4 bytes seguido dos argumentos codificados em ABI, cada um preenchido até uma palavra de 32 bytes (64 hex). Tipos estáticos (address, uint256, bool) ficam inline no seu espaço de cabeçalho; tipos dinâmicos (bytes, string, T[]) colocam um DESLOCAMENTO de 32 bytes no cabeçalho que aponta para tamanho+dados na cauda. Então ler o calldata é: remover os 4 primeiros bytes para identificar a função e depois fatiar o restante em palavras de 32 bytes conforme a assinatura. O Modelo de Calldata desta ferramenta dá esse esqueleto (seletor + uma palavra zerada por argumento de nível superior) para colar em eth_call ou cast e preencher.

Recursos Principais

• Gerar seletores de função (4 bytes) a partir de assinaturas
• Gerar assinaturas de evento (Topic0, 32 bytes)
• Exibir hash Keccak256 completo
• Consultar seletores de função comuns em banco de dados integrado
• Validar formatos de assinatura e seletor
• Carregar exemplos aleatórios para teste
• Links para bancos de dados de assinatura externos (4byte.directory, Openchain)
• Inclui mais de 30 seletores comuns de ERC20, DeFi e governança
• Computação no lado do cliente para privacidade