Explicación de EIPs: EIP-2612

Conéctese con nosotros en afterdarklabs.xyz o @afterdark_labs

Contexto

La EIP-2612 fue creada específicamente para permitir la aprobación de un token ERC20 en la misma transacción en la que es consumido. Esto se basa en dos estándares anteriores: EIP-20 y EIP-712. Vamos a cubrir brevemente algunos de los aspectos importantes de estos dos estándares, pero si no estás familiarizado con ninguno de ellos, te recomendamos que los revises antes de continuar con este artículo.

Resumen de la EIP

La EIP-2612 puede considerarse como una extensión de la EIP-20. Para aquellos que no están familiarizados con la EIP-20, es el estándar que describe los requisitos de la API para tokens ERC-20 no fungibles. La EIP-2612 añade 3 nuevas funciones al estándar de tokens ERC-20: permit(),nonces() y DOMAIN_SEPARATOR().

La mayor parte de la funcionalidad agregada se encuentra en la función permit() de esta EIP. Esta función lleva el propietario de los tokens ERC-20 (owner), la cuenta que recibirá permiso para gastar en nombre del propietario (spender), la cantidad para definir la aprobación (value), una fecha límite (deadline) y una firma para actualizar el mapeo de aprobación del token ERC-20 (v,ry s).

Echemos un vistazo práctico a cómo funciona la función permit() analizando una implementación de la misma por parte de la popular biblioteca OpenZeppelin:

Función permit() como se ve en el contrato ERC20Permit.sol de OpenZeppelin

Dividamos esto en tres secciones:

Aplicación del Plazo

En esta primera línea vemos que se está aplicando el plazo comparándolo con la marca de tiempo (timestamp). Si la marca de tiempo del bloque actual es mayor que la fecha límite, sabemos que el límite de tiempo ha pasado y revertimos la transacción. Esta verificación permite a los usuarios proporcionar una fecha de vencimiento para su aprobación firmada.

Codificación del Hash de Firma

En estas dos líneas se está configurando el hash de los parámetros para que a partir de él se pueda recuperar una firma. Tenga en cuenta que contiene toda la información relevante mencionada en la EIP: el propietario, el gastador, el valor y la fecha límite. El uso del contenedor _useNonce() es una forma elegante de incrementar el nonce inmediatamente después de haber sido consumido. Construir el hash de esta manera implica que el firmante original debe haber firmado toda esta misma información para que la recuperación de la firma funcione correctamente. El hash EIP-712, codificado correctamente para este dominio, se construye utilizando la estructura hasheada y el separador de dominio.

Ahora es un buen momento para salir de la funciónpermit() y discutir el separador de dominio. El separador de dominio se utiliza para limitar una firma a un dominio. Esto es útil para asegurar que los usuarios no estén firmando un cheque en blanco. Al incorporar información como el nombre del token ERC-20 y el chainID en el dominio, la firma no debería aplicarse ampliamente a otros aplicativos y cadenas.

Recuperación de Firma

Finalmente, recuperamos la dirección del firmante utilizando el hash firmado y los valores que representan la firma y el identificador de recuperación. La llamada ECDSA.recover es un envoltorio alrededor de la precompilación ecrecover. Esta precompilación devuelve la clave pública de una firma, el identificador de recuperación y un mensaje firmado. Si la clave pública coincide con la del propietario, entonces sabemos que el propietario firmó originalmente este mensaje y se realizará la aprobación.

¡Y esta es la mayor parte de la funcionalidad añadida! Ahora abordaremos algunos casos de uso y consideraciones de seguridad para aquellos que estén considerando utilizar la funcionalidad EIP-2612 en su protocolo.

Casos de uso

Transacciones sin Gas

Un uso muy popular de la EIP-2612 es para realizar transacciones sin gas. Dado que las firmas al estilo EIP-712 pueden recopilarse fuera de la cadena, no se espera que el usuario sea la parte que publica la transacción que contiene la llamada a permit(). Por lo tanto, los protocolos pueden ofrecer transacciones sin gas a sus usuarios, quienes de otra manera requerirían interactuar directamente con una aplicación.

Huella de aprobación reducida

Como se abordó en 'Top 5 Smart Contracts Vulnerabilities of 2023', las aprobaciones no revocadas son una gran fuente de fondos perdidos para usuarios en DeFi. Al utilizar EIP-2612 para recolectar firmas localmente para aprobaciones, es factible que los protocolos ofrezcan a sus usuarios una experiencia continua sin requerir una aprobación máxima permanente. Esto puede ayudar a los usuarios a reducir su huella de aprobación y potencialmente mantenerlos seguros durante ataques a protocolos.

Transacciones Agrupadas

Las interacciones en aplicaciones que manejan tokens que utilizan EIP-2612 pueden ser agrupadas. La agrupación puede mejorar la composabilidad dentro de las transacciones, permitiendo que los usuarios interactúen con varios protocolos y potencialmente sean menos susceptibles a ataques de ordenación de transacciones. Las transacciones agrupadas también pueden beneficiarse de la capacidad de realizarse sin gas para los usuarios.

Consideraciones de Seguridad

Protección contra Reproducción

Es importante que el dominio de la firma sea único, de lo contrario, las firmas podrían reproducirse en otros dominios. En la práctica, las bibliotecas EIP-712 populares se encargan en gran medida de esto por ti. Recomendamos utilizar nombres y/o versiones únicas al construir cada uno de tus tokens para mejorar la solidez de la protección contra reproducción.

Maleabilidad de la Firma

La maleabilidad de la firma ocurre cuando firmas no únicas pueden considerarse válidas para la misma salida firmada. El código de operación ecrecover en sí mismo en la EVM puede devolver la misma dirección para firmas no únicas. Al igual que con problemas de reproducción, gran parte de esto puede ser mitigado usando bibliotecas populares que rechazan un segundo conjunto de firmas que ecrecoveraceptaría.

Falla Silenciosa del ecrecover

Como se menciona en la propia EIP-2612, la precompilación ecrecover falla silenciosamente y devuelve la dirección 0 para el firmante en caso de error. Esto significa que es importante verificar que el firmante no sea la dirección 0 al realizar un permit(). La mayoría de las bibliotecas conocidas tienen esto en cuenta al lanzar un error cuando ecrecover devuelve 0.

Complejidad del protocolo

Agregar la funcionalidad EIP-2612 a un protocolo puede aumentar la complejidad. Además de añadir capacidades de frontend para recopilar firmas, los propios contratos generalmente requieren tanto la funcionalidad de permisos como la funcionalidad tradicional no basada en firmas. Por lo tanto, los protocolos deben tener en cuenta el potencial aumento en los costos de implementación, así como la complejidad al elegir agregar la funcionalidad EIP-2612.

Potencial de Censura

Es común que los protocolos que implementan la funcionalidad EIP-2612 también envíen las transacciones en nombre del usuario. Esto significa que el usuario depende del protocolo para enviar su transacción para interactuar con sus aplicaciones

Pensamientos Finales

La EIP-2612 ofrece funcionalidades adicionales útiles para los protocolos que desean ofrecer transacciones sin gas o agrupadas. Si se implementa correctamente, también puede ayudar a los usuarios a reducir su huella de aprobación y permitirles interactuar con dApps de manera más segura. El uso de bibliotecas existentes puede ayudar a los equipos de desarrollo a evitar trampas criptográficas comunes, y la implementación de métodos tradicionales para interactuar con sus dApps, además de los métodos EIP-2612, puede limitar el riesgo de problemas de censura.

Si está interesado en una auditoría de contrato inteligente u otros servicios de seguridad, inicie el proceso visitando afterdarklabs.xyz o comunicándose directamente con [email protected].

Artículo original publicado por AfterDark Labs. Traducido por Juliana Cabeza.