Codificador / Decodificador ABI

O que é Codificador / Decodificador ABI?

Codificador/Decodificador ABI (Application Binary Interface) é uma ferramenta gratuita para codificar e decodificar dados de chamada de função de contratos inteligentes Ethereum. Converte assinaturas de função legíveis e parâmetros em calldata hexadecimal que pode ser enviado para contratos inteligentes, e vice-versa.

Esta ferramenta é essencial para desenvolvedores blockchain trabalhando com contratos inteligentes, depurando transações ou construindo dApps em Ethereum e cadeias compatíveis com EVM.

O que é ABI no Ethereum?

ABI (Application Binary Interface) é uma especificação que define como interagir com contratos inteligentes Ethereum. Descreve as funções disponíveis em um contrato, seus parâmetros e tipos de retorno. O codificador ABI converte chamadas de função em bytecode que a EVM pode executar.

O que é calldata?

Calldata são os dados codificados enviados com uma transação para um contrato inteligente. Consiste em um seletor de função de 4 bytes (primeiros 8 caracteres hex após 0x) seguido por parâmetros codificados em ABI. Por exemplo, chamar transfer(address,uint256) gera calldata como 0xa9059cbb000000...

Como codifico uma chamada de função?

Insira a assinatura da função (ex: transfer(address,uint256)) e parâmetros como um array JSON. A ferramenta gerará o calldata completo incluindo o seletor de função e parâmetros codificados. Este calldata pode ser usado em transações web3 ou para depuração.

Como decodifico dados de entrada de transação?

Cole os dados de entrada da transação (calldata) de qualquer transação EVM. Se você conhece a assinatura da função, forneça-a para decodificação detalhada de parâmetros. Caso contrário, a ferramenta mostrará o seletor de função e dados brutos. Isso é útil para analisar transações em exploradores de blocos.

Quais blockchains são suportados?

Esta ferramenta funciona com todos os blockchains compatíveis com EVM incluindo Ethereum, BSC, Polygon, Arbitrum, Optimism, Avalanche e qualquer outra cadeia que use a Ethereum Virtual Machine e siga padrões de codificação ABI.

Como o selector de 4 bytes é calculado a partir da assinatura?

Pegue a assinatura como transfer(address,uint256), aplique Keccak-256 (NÃO SHA-256 comum) e pegue os 4 primeiros bytes. A assinatura NÃO pode ter espaços e deve usar nomes canônicos: address, uint256 não uint, bytes32 não bytes. transfer(address,uint256) gera 0xa9059cbb...

Como ABI lida com tipos dinâmicos como string e bytes?

Tipos dinâmicos usam esquema head/tail: head contém offsets (32 bytes cada), tail contém comprimento + dados com padding. Para transfer(address,uint256) todos são estáticos e empacotam direto. Para setMessage(string), a string emite seu offset no head e o comprimento UTF-8 + conteúdo padded a 32 bytes no tail.

Posso decodificar calldata sem conhecer a assinatura?

Parcialmente. Os primeiros 4 bytes são o selector — consulte em bases abertas como 4byte.directory ou Openchain.xyz para achar assinaturas candidatas. Sem a assinatura não dá para decodificar parâmetros com confiabilidade porque ABI conhece os tipos. A ferramenta linka para essas bases.

Por que meu calldata difere do output do ethers.js?

Ethers.js usa aliases canônicos (uint -> uint256, int -> int256, bytes dinâmico) e pode diferir se você passar tipos não canônicos. Verifique a ordem dos parâmetros — arrays JSON devem casar com a assinatura. Ethers também codifica function() como selector 0x sem args; algumas tools omitem os bytes zero finais.

Casos de Uso Comuns

• Codificar transferências de tokens ERC20 para interações de contrato
• Decodificar dados de entrada de transação do Etherscan ou exploradores de blocos
• Testar chamadas de função de contrato inteligente antes da implantação
• Depurar transações falhas analisando calldata
• Construir transações personalizadas para carteiras multisig
• Analisar interações de protocolo DeFi (swaps Uniswap, etc.)