--- title: "¿Qué es un ABI de un smart contract?" description: "Ejemplos y uso para desarrolladores" --- # ¿Qué es un ABI de un smart contract? La Application Binary Interface (ABI) de un smart contract le da al contrato la capacidad de comunicarse e interactuar con aplicaciones externas y otros smart contracts. Recibir datos de fuentes externas puede ser fundamental para cumplir los objetivos de la aplicación y del usuario. En el desarrollo web tradicional, el intercambio de datos ocurre entre aplicaciones y servidores a través de API's (Application Program Interface). Los servidores actúan como fuentes centralizadas de información que envían datos a la aplicación cuando se solicitan. En una blockchain, no existe esa centralización de datos. Los nodos funcionan esencialmente como servidores y los smart contracts son funciones "alojadas" on-chain. Las aplicaciones fuera de la blockchain (y otros smart contracts) necesitan una forma de comunicarse con los smart contracts que están on-chain. Aquí es donde entra en juego el ABI. ## **¿Por qué ABI?** Antes de entrar en más detalles sobre qué es el ABI, conviene entender por qué existe. Los smart contracts son las aplicaciones centrales de la [EVM (Ethereum Virtual Machine)](https://www.alchemy.com/overviews/what-is-the-ethereum-virtual-machine-evm). El propósito de los smart contracts es ejecutar transacciones cuando se cumplen ciertas condiciones definidas en el contrato. Estas condiciones pueden ser eventos tanto on-chain como off-chain. Los smart contracts se escriben en lenguajes de alto nivel como [Solidity](https://www.alchemy.com/overviews/solidity), pero se almacenan en la EVM como bytecode ejecutable, es decir, en formato binario. Dado que este bytecode no es legible para humanos, requiere interpretación para poder entenderlo. El ABI le permite a cualquier persona que escriba un smart contract comunicarse entre una aplicación web escrita en un lenguaje de alto nivel como Javascript y el bytecode que entiende la EVM. ## **¿Qué es un ABI?** Al igual que su prima en Web2, la API, el ABI actúa como un selector de funciones, definiendo los métodos específicos que se pueden invocar en un smart contract para su ejecución. Estos métodos específicos y sus tipos de datos asociados se listan en un archivo JSON RPC generado. A diferencia de una API, no podemos simplemente enviar una solicitud directamente en formato JSON a un smart contract y esperar una respuesta, ya que un contrato solo se comunica en bytecode. Para traducir esto en algo que la EVM entienda, esta información se codifica mediante ABI encoding. Estas codificaciones incluyen firmas de función y declaraciones de variables, de modo que la EVM sepa exactamente qué función ejecutar dentro del smart contract. Las respuestas también están en bytecode, por lo que se requiere interpretación antes de que una aplicación web pueda procesarlas. La ventaja de usar bytecode en la respuesta es que también podemos esperar cierta estructura al llamar a una función de un contrato. ## **¿Cómo usar el ABI?** ### Generación Si estás usando herramientas como Hardhat/Truffle o un IDE como [Remix](https://remix.ethereum.org/#optimize=false&runs=200&evmVersion=null&version=soljson-v0.8.7+commit.e28d00a7.js), el ABI del contrato se genera automáticamente. También puedes crear el ABI manualmente usando el [paquete NPM del compilador de Solidity](https://www.npmjs.com/package/solc). Después de instalar el paquete, puedes ejecutar el comando '`solcjs contractname.sol --abi`' en una terminal. Esto generará un archivo .abi si se ejecuta correctamente. Ahora que tienes un ABI generado, veamos algunos de los elementos de este archivo: ### **Ejecución** Dado que el ABI funciona como intérprete entre el bytecode de la EVM y el Javascript de un sitio web, es necesario siempre que se quiera ejecutar cualquier función de un smart contract. Además del ABI, se requiere la dirección del contrato en la blockchain. Aquí hay un pequeño fragmento de código Javascript que muestra cómo se hace esto: Si te interesa encontrar el ABI de un contrato ya desplegado, puedes buscarlo en [Etherscan](https://www.alchemy.com/dapps/etherscan) usando la dirección del contrato. Por ejemplo [aquí](https://etherscan.io/address/0xb4eaf48bd7f72356e1019c157e91b81a1c541073#code): ### Codificación Dado que toda la comunicación se hace en bytecode, sería difícil esperar que los desarrolladores codifiquen estos mensajes por su cuenta. Por suerte, compiladores populares como Remix también pueden encargarse de la codificación por ti. Estas codificaciones siguen un patrón determinado, así que se puede entender mejor qué está pasando revisando la [Especificación ABI](https://docs.soliditylang.org/en/v0.8.11/abi-spec.html). Los primeros cuatro bytes son la firma de la función, que indica qué tipo de función del smart contract se está ejecutando. Un identificador de función popular es a9059cbb, que indica que se trata de una transferencia [ERC20](https://www.alchemy.com/overviews/erc20-solidity). Existe un [directorio de base de datos](https://www.4byte.directory/) de firmas de función donde puedes explorar más. A partir del quinto byte en adelante es donde se codifican los argumentos. Las respuestas siguen una estructura similar, pero sin incluir la firma de la función. ## **Conclusión** El ABI a menudo puede ser un aspecto que se pasa por alto al trabajar con smart contracts, pero cumple un rol importante en la usabilidad de esta tecnología. Practicar con [tutoriales de smart contracts](https://www.alchemy.com/docs/how-to-deploy-a-smart-contract-to-the-sepolia-testnet) es una excelente manera de entender el poder de este trabajador silencioso y de aplicar lo aprendido.