--- title: "O que é uma ABI de um smart contract?" description: "Exemplos e uso para desenvolvedores" --- # O que é uma ABI de um smart contract? A Application Binary Interface \(ABI\) de um smart contract dá ao contrato a capacidade de se comunicar e interagir com aplicações externas e outros smart contracts. Receber dados de fontes externas pode ser fundamental para atingir os objetivos da aplicação e do usuário. No desenvolvimento web tradicional, as trocas de dados acontecem entre aplicações e servidores por meio de API's \(Application Program Interface\). Servidores atuam como fontes centralizadas de informação que fornecem dados para a aplicação mediante requisição. Em uma blockchain, essa centralização de dados não existe. Os nodes basicamente atuam como servidores e os smart contracts são funções "hospedadas" on-chain. Aplicações fora da blockchain \(e outros smart contracts\) precisam de uma forma de se comunicar com smart contracts que estão on-chain. É aí que entra o ABI. ## **Por que ABI?** Antes de entrar em mais detalhes sobre o que é ABI, é bom entender por que ele existe. Smart contracts são as aplicações centrais da [EVM \(Ethereum Virtual Machine\)](https://www.alchemy.com/overviews/what-is-the-ethereum-virtual-machine-evm). O propósito dos smart contracts é executar transações quando certas condições definidas no contrato são atendidas. Essas condições podem ser eventos on-chain ou off-chain. Smart contracts são escritos em linguagens de alto nível como [Solidity](https://www.alchemy.com/overviews/solidity), mas são armazenados na EVM como bytecode executável, que está em formato binário. Como esse bytecode não é legível por humanos, é preciso interpretá-lo para entendê-lo. O ABI permite que qualquer pessoa que escreva um smart contract consiga se comunicar entre uma aplicação web escrita em uma linguagem de alto nível como Javascript e o bytecode que a EVM entende. ## **O que é um ABI?** Assim como sua prima do Web2, a API, o ABI atua como um seletor de funções, definindo os métodos específicos que podem ser chamados em um smart contract para execução. Esses métodos específicos e seus tipos de dados associados são listados em um arquivo JSON RPC gerado. Diferente de uma API, não podemos simplesmente enviar uma requisição diretamente em formato JSON para um smart contract e esperar uma resposta, já que um contrato só se comunica em bytecode. Para traduzir isso em algo que a EVM entenda, essa informação é codificada via ABI encoding. Essas codificações incluem assinaturas de função e declarações de variáveis, de forma que a EVM saiba exatamente qual função executar dentro do smart contract. As respostas também estão em bytecode, então é necessária interpretação antes de serem processadas por uma aplicação web. A vantagem de usar bytecode na resposta é que também podemos esperar uma certa estrutura sendo retornada após chamar a função de um contrato. ## **Como usar o ABI?** ### Geração Se você estiver usando ferramentas como Hardhat/Truffle ou uma IDE como [Remix](https://remix.ethereum.org/#optimize=false&runs=200&evmVersion=null&version=soljson-v0.8.7+commit.e28d00a7.js), o ABI do contrato é gerado automaticamente para você. Você também pode criar o ABI manualmente usando o [pacote NPM Solidity Compiler](https://www.npmjs.com/package/solc). Depois de instalar o pacote, você pode rodar o comando '`solcjs contractname.sol --abi`' em um terminal. Isso vai gerar um arquivo .abi caso seja executado com sucesso. Agora que você tem um ABI gerado, vamos ver alguns dos elementos desse arquivo: ### **Executando** Como o ABI funciona como o intérprete entre o bytecode da EVM e o Javascript de um site, ele é necessário quando você quer executar qualquer função de um smart contract. Além do ABI, o endereço do contrato na blockchain também é necessário. Aqui está um pequeno trecho de código Javascript para mostrar como isso é feito: Se você tiver interesse em encontrar o ABI de um contrato já implantado, pode achá-lo pesquisando no [Etherscan](https://www.alchemy.com/dapps/etherscan) com o endereço do contrato. Por exemplo [aqui](https://etherscan.io/address/0xb4eaf48bd7f72356e1019c157e91b81a1c541073#code): ### Codificação Como toda a comunicação é feita em bytecode, seria difícil esperar que os desenvolvedores codificassem essas mensagens manualmente. Felizmente, compiladores populares como o Remix também conseguem fazer essa codificação para você. Essas codificações seguem um certo padrão, então é possível ter uma ideia melhor do que está acontecendo revisando a [ABI Specification](https://docs.soliditylang.org/en/v0.8.11/abi-spec.html). Os primeiros quatro bytes são a assinatura da função, que indica qual tipo de função no smart contract está sendo executada. Um identificador de função popular é a9059cbb, que indica que se trata de uma transferência [ERC20](https://www.alchemy.com/overviews/erc20-solidity). Há um [diretório de banco de dados](https://www.4byte.directory/) de assinaturas de função aqui, onde você pode explorar mais. A partir do quinto byte em diante é onde os argumentos são codificados. As respostas seguem uma estrutura parecida, mas sem a assinatura da função incluída. ## **Conclusão** O ABI é, muitas vezes, um aspecto negligenciado ao trabalhar com smart contracts, mas ele desempenha um papel importante na usabilidade dessa tecnologia. Construir com base em [tutoriais de smart contract](https://www.alchemy.com/docs/how-to-deploy-a-smart-contract-to-the-sepolia-testnet) é uma ótima forma de entender o poder desse cavalo de batalha silencioso e uma ótima forma de aplicar seu conhecimento.