¿Qué es una ABI y por qué es necesaria para interactuar con los contratos?

ABI significa interfaz binaria de aplicación .

En general, una ABI es la interfaz entre dos módulos de programa, uno de los cuales suele estar a nivel de código de máquina. La interfaz es el método de facto para codificar/descodificar datos dentro/fuera del código de máquina.

En Ethereum, es básicamente cómo puede codificar las llamadas de contrato de Solidity para el EVM y, al revés, cómo leer los datos de las transacciones.

La ABI, interfaz binaria de aplicación, es básicamente cómo llamar a funciones en un contrato y recuperar datos .

Una ABI determina detalles tales como cómo se llaman las funciones y en qué formato binario se debe pasar la información de un componente del programa al siguiente...

Un contrato inteligente de Ethereum es un código de bytes implementado en la cadena de bloques de Ethereum. Puede haber varias funciones en un contrato. Se necesita una ABI para que pueda especificar qué función en el contrato invocar, así como obtener una garantía de que la función devolverá los datos en el formato que espera.

De la especificación ABI de Ethereum , un ejemplo:

contract Foo {
  function bar(real[2] xy) {}
  function baz(uint32 x, bool y) returns (bool r) { r = x > 32 || y; }
  function sam(bytes name, bool z, uint[] data) {}
}

Si quisiéramos llamar a baz con los parámetros 69 y true, pasaríamos 68 bytes en total, que se pueden descomponer en:

0xcdcd77c0: el selector de funciones . Esto se deriva como los primeros 4 bytes del hash Keccak-256 de la forma ASCII de la Firma de Función baz(uint32,bool). 0x0000000000000000000000000000000000000000000000000000000000000045: the first parameter, a uint32 value 69 padded to 32 bytes 0x0000000000000000000000000000000000000000000000000000000000000001: the second parameter - boolean true, padded to 32 bytes

Los 68 bytes es lo que se especificaría en el datacampo de una transacción, también llamado calldata : una nota de seguridad sobre eso está aquí . (Para resumir, tenga cuidado con lo que ingresa en el campo de datos, ya que puede tener efectos secundarios no deseados y posiblemente maliciosos al pasarlo al contrato de llamada).

Para evitar un escollo común al derivar el Selector de funciones, se deben usar los tipos canónicos, por ejemplo, en uint256lugar deuint .

Aquí hay un ejemplo en Solidity de calcular un selector de funciones para samlo anterior:

bytes4(keccak256("sam(bytes,bool,uint256[])")

El uso de una biblioteca de nivel superior como web3.js abstrae la mayoría de estos detalles, pero aún se debe proporcionar el ABI en formato JSON a web3.js.

Nota: el ABI es una abstracción que no forma parte del protocolo central de Ethereum . Cualquiera puede definir su propia ABI para sus contratos ( ejemplo inicial ), y cualquier persona que llame a dichos contratos tendría que cumplir con esa ABI para obtener resultados significativos. Sin embargo, es más sencillo para todos los desarrolladores usar compiladores actuales (por ejemplo, Solidity) y bibliotecas (por ejemplo, web3.js, ethers.js) que cumplen con la ABI anterior.

Definición de contrato : definición formal en código de alto nivel (por ejemplo, solidez).

Contrato compilado : el contrato convertido a código de bytes para ejecutarse en la máquina virtual Ethereum (EVM), de acuerdo con la especificación . Tenga en cuenta que los nombres de las funciones y los parámetros de entrada se codifican durante la compilación. Por lo tanto, para que otra cuenta llame a una función, primero se le debe dar el nombre de la función y los argumentos, de ahí el ABI.

Interfaz binaria de la aplicación - ABI: una lista de las funciones y los argumentos del contrato (en formato JSON ¹ ). Una cuenta que desee utilizar la función de un contrato inteligente utiliza la ABI para codificar la definición de la función, de modo que pueda crear el código de bytes EVM necesario para llamar a la función. Esto luego se incluye en el campo de datos, T _d , de una transacción y la EVM lo interpreta con el código en la cuenta de destino (la dirección del contrato).

¹ El uso de JSON es un estándar de facto ; no está en la especificación formal, pero cambiarla resultaría en la necesidad de modificar muchas de las herramientas.

piense en "ABI" como una "API" en un nivel bajo.

Piense en ello como la versión compilada de una API (o como una API de bajo nivel). Como sabe, los contratos se almacenan como códigos de bytes en formato binario en la cadena de bloques bajo una dirección específica. Nadie entiende el binario, por lo que ABI define las estructuras y los métodos que usará para interactuar con ese contrato binario (tal como lo hizo la API), solo que en un nivel inferior. La ABI indica a la persona que llama la información necesaria (firmas de funciones y declaraciones de variables) para codificar una llamada significativa (entendida por la máquina virtual) al código de bytes (contrato).

información adicional "del documento oficial"

Una interfaz binaria de aplicación (ABI) está destinada a servir como el método de facto para codificar y decodificar datos dentro y fuera de las transacciones.

.

Afirmamos que todos los contratos tendrán las definiciones de interfaz de cualquier contrato que llamen disponibles en tiempo de compilación.

En caso de que quiera usar una herramienta en línea simple para codificar parámetros, puede usar https://abi.hashex.org

Inserta el código abi para analizar automáticamente los tipos de parámetros o simplemente ingresarlos manualmente. En el constructor del selector de tipo de función, se debe elegir.

Aquí hay un ejemplo, en la parte inferior hay parámetros codificados en abi que ingresa en la entrada del campo de parámetros del constructor etherscan.io.

Me estaba costando mucho entender el por qué de esta pregunta, así que me gustaría agregar una cosa gracias a esta excelente respuesta :

"La forma en que estos bytes se interpretan en datos estructurados depende del programa y, por lo tanto, del lenguaje de programación utilizado. Para hacer posible que dos programas escritos en diferentes lenguajes de programación se llamen entre sí, los compiladores de dichos lenguajes deben implementar el serialización y deserialización de datos de la misma manera, es decir, deben implementar la especificación ABI, pero no es necesario".

tl;dr un contrato escrito en Solidity puede interactuar con un contrato escrito en Viper o Bamboo porque todos implementan y se adhieren a la especificación ABI.

Solo copia este json. Este es el contrato ABI

ABI (Application Binary Interface) en el contexto de la informática es una interfaz entre dos módulos de programa, a menudo entre sistemas operativos y programas de usuario.

EVM (Ethereum Virtual Machine) es el componente central de la red Ethereum, y el contrato inteligente son fragmentos de código almacenados en la cadena de bloques de Ethereum que se ejecutan en EVM. Los contratos inteligentes escritos en lenguajes de alto nivel como Solidity o Vyper deben compilarse en código de bytes ejecutable EVM; cuando se implementa un contrato inteligente, este código de bytes se almacena en la cadena de bloques y se asocia con una dirección. Para Ethereum y EVM, un contrato inteligente es solo esta secuencia de código de bytes. Para acceder a funciones definidas en lenguajes de alto nivel, los usuarios deben traducir nombres y argumentos en representaciones de bytes para que el código de bytes funcione con ellos. Para interpretar los bytes enviados en respuesta, los usuarios deben volver a convertir a la tupla de valores de retorno definidos en lenguajes de nivel superior. Los lenguajes que compilan para EVM mantienen convenciones estrictas sobre estas conversiones, pero para poder realizarlas, uno debe conocer los nombres y tipos precisos asociados con las operaciones. El ABI documenta estos nombres y tipos con precisión, en un formato fácilmente analizable, haciendo traducciones entre las llamadas de método previstas por humanos y las operaciones de contratos inteligentes detectables y confiables.

Es muy similar a la API (interfaz de programa de aplicación), una representación legible por humanos de la interfaz de un código. ABI define los métodos y las estructuras que se utilizan para interactuar con el contrato binario, al igual que API, pero en un nivel inferior. El ABI indica la persona que llama a la función para codificar la información necesaria, como firmas de funciones y declaraciones de variables en un formato que el EVM puede entender para llamar a esa función en código de bytes; esto se llama codificación ABI. La codificación ABI está mayormente automatizada, a cargo de compiladores como REMIX o billeteras que interactúan con la cadena de bloques. El contrato ABI se representa en formato JSON. Hay especificaciones claras de cómo codificar y decodificar un contrato ABI.

Fuente

Una ABI es como otros dijeron que la interfaz binaria de la aplicación: es una interfaz de nivel inferior pero no tiene que ser inaccesible para los programadores, por ejemplo en Linux: /sys/bus/usb/devices/.../power/persist
es un ejemplo de una ABI. Puede acceder a muchas otras ABI de Linux a través de/sys/bus/

Consulte: https://www.kernel.org/doc/Documentation/ABI/

Introducción La interfaz binaria de aplicaciones (ABI) de un contrato inteligente le da a un contrato la capacidad de comunicarse e interactuar con aplicaciones externas y otros contratos inteligentes. Recibir datos de fuentes externas puede ser fundamental para completar los objetivos de la aplicación y del usuario.

En el desarrollo web tradicional, las conversaciones sobre datos ocurren entre aplicaciones y servidores a través de API (interfaz de programa de aplicación). Los servidores actúan como fuentes centralizadas de información que alimentan datos a la aplicación por solicitud.

En una cadena de bloques, no existe tal centralización de datos. Los nodos actúan esencialmente como servidores y los contratos inteligentes están en funciones "alojadas" en cadena. Las aplicaciones fuera de la cadena de bloques (y otros contratos inteligentes) necesitan una forma de comunicarse con los contratos inteligentes que están en la cadena. Aquí es donde ABI entra en juego.

‍

¿Por qué ABI? Antes de entrar en más detalles sobre qué es ABI, es bueno entender por qué lo tenemos.

Los contratos inteligentes son las aplicaciones principales de EVM (Ethereum Virtual Machine). El propósito de los contratos inteligentes es ejecutar transacciones cuando se cumplen ciertas condiciones definidas en el contrato. Estas condiciones pueden ser eventos dentro o fuera de la cadena. Los contratos inteligentes están escritos en lenguajes de alto nivel como Solidity, pero se almacenan en el EVM como código de bytes ejecutable, que está en formato binario.

Fuente: https://hackernoon.com/hn-images/1*Sz1a7G2pQ62UnkHoieve4w.jpeg

Dado que este código de bytes no es legible por humanos, requiere interpretación para ser entendido. ABI permite que cualquiera que escriba un contrato inteligente pueda comunicarse entre una aplicación web escrita en un lenguaje de alto nivel como Javascript y el código de bytes que entiende el EVM. ‍

¿Qué es un ABI? Al igual que su primo Web2, la API, ABI actúa como un selector de funciones, definiendo los métodos específicos que se pueden llamar a un contrato inteligente para su ejecución. Estos métodos específicos y sus tipos de datos conectados se enumeran en un archivo JSON RPC generado.

Fuente: https://static.packt-cdn.com/products/9781789954111/graphics/assets/fe0f2ffc-2f3c-4615-9cb5-43c8e036239b.png

A diferencia de una API, no podemos simplemente enviar una solicitud directamente en formato JSON a un contrato inteligente y esperar una respuesta, ya que un contrato solo se comunica en código de bytes. Para traducir esto en algo que el EVM entienda, esta información se codifica a través de la codificación ABI. Estas codificaciones incluyen firmas de funciones y declaraciones de variables para que el EVM sepa exactamente qué función ejecutar dentro del contrato inteligente.

Las respuestas también están en el código de bytes, por lo que se requiere interpretación antes de que una aplicación web las procese. La ventaja de usar bytecode en la respuesta es que también podemos esperar que se devuelva cierta estructura después de llamar a la función de un contrato.

‍

¿Cómo usar ABI?

Generación Si está utilizando herramientas como Hardhart/Truffle o un IDE como Remix, el contrato ABI se genera automáticamente para usted. También puede crear manualmente la ABI utilizando el paquete NPM de Solidity Compiler. Después de instalar el paquete, puede ejecutar el comando 'solcjs contractname.sol --abi' en una terminal. Esto generará un archivo .abi si se realiza correctamente.

Ahora que tiene una ABI generada, veamos algunos de los elementos de este archivo:

Ejecutar Como ABI funciona como intérprete entre el código de bytes de EVM y Javascript de un sitio web, es necesario cuando desea ejecutar cualquier función de un contrato inteligente. Además del ABI, se requiere la dirección del contrato en la cadena de bloques. Aquí hay un pequeño fragmento de código Javascript para mostrar cómo se hace esto:

Si está interesado en encontrar el ABI de un contrato ya implementado, puede encontrarlo buscando en Etherscan con la dirección del contrato. Por ejemplo aquí:

Codificación Dado que toda la comunicación se realiza en bytecode, sería difícil esperar que los desarrolladores codificaran estos mensajes por sí mismos. Afortunadamente, los compiladores populares como Remix también pueden manejar la codificación por usted. Estas codificaciones siguen un cierto patrón, por lo que uno puede tener una mejor idea de lo que está pasando al revisar la especificación ABI.

Los primeros cuatro bytes son la firma de la función que indica qué tipo de función en el contrato inteligente se está ejecutando. Un identificador de función popular es a9059cbb, que indica que se trata de una transferencia ERC20. Hay un directorio de bases de datos de firmas de funciones aquí donde puede explorar más.

Fuente: https://miro.medium.com/max/1400/1*YDi7sDUmAc3wjN8TcIBrog.png

A partir del quinto byte es donde se codifican los argumentos. Las respuestas siguen esta estructura similar pero sin incluir la firma de la función.

‍

Conclusión ABI a menudo puede ser un aspecto pasado por alto del trabajo con contratos inteligentes, pero juega un papel importante en la usabilidad de esta tecnología. Desarrollar tutoriales de contratos inteligentes es una excelente manera de comprender el poder de este caballo de batalla silencioso y una excelente manera de aplicar su conocimiento.

Fuente de este artículo: https://www.alchemy.com/overviews/what-is-an-abi-of-a-smart-contract-examples-and-usage