EIP-2612: Cómo ERC-20 Permite Aprobaciones sin Gas

Claro, aquí tienes la traducción al español del artículo, manteniendo el formato Markdown y utilizando expresiones idiomáticas:

Las tarifas de gas son la mayor fuente de fricción en DeFi. Antes de poder intercambiar, prestar o hacer staking con un token ERC-20, a menudo necesitas enviar una transacción de "aprobar" —y pagar gas— solo para permitir que la dApp mueva tus tokens. EIP-2612 cambia eso. Introduce "permit", un flujo de aprobación basado en firmas que mueve la aprobación fuera de la cadena y permite que un contrato inteligente o un relayer patrocine el gas en la cadena. El resultado es una experiencia de usuario más fluida, menos transacciones y aprobaciones más seguras cuando se implementan correctamente.

Este artículo explica cómo funciona EIP-2612, por qué es importante en 2025 y qué deben tener en cuenta los usuarios y desarrolladores.

Qué Es Realmente EIP-2612

EIP-2612 extiende el estándar de tokens ERC-20 con una nueva función: permit. En lugar de llamar a approve(spender, amount) en la cadena, los usuarios firman un mensaje tipado fuera de la cadena que incluye los parámetros de aprobación y una fecha límite. Luego, un contrato inteligente envía permit en la cadena utilizando esa firma, estableciendo la asignación sin que el usuario pague gas.

• Conceptos básicos de ERC-20: las aprobaciones y transferencias siguen el estándar definido en la especificación ERC-20.
• Especificación EIP-2612: el formato de la firma, los nonces y la función permit se formalizan en la propuesta EIP-2612.
• Datos tipados: las firmas utilizan datos estructurados según EIP-712, lo que hace que lo que estás firmando sea legible para humanos y esté ligado al dominio.

En resumen, EIP-2612 permite "aprobaciones sin gas" porque el usuario solo firma fuera de la cadena; una dApp, relayer o contrato paga para transmitir el permit en la cadena.

Por Qué Importa en 2025

• Menos clics, menos transacciones: Una sola firma puede establecer la aprobación y ejecutar inmediatamente una acción (intercambio, depósito, staking) en una única llamada en cadena.
• Experiencia de usuario "L2-first": Con el auge de las L2, muchos protocolos patrocinan el gas para incorporar usuarios. Las aprobaciones EIP-2612 encajan perfectamente en esos patrones. Consulta la descripción general de Ethereum sobre gas y los modelos de cuentas para comprender la dinámica de costos.
• Abstracción de cuentas y patrocinadores (paymasters): Los flujos de billetera potenciados por ERC-4337 facilitan que los servicios patrocinen el gas o acepten tarifas en tokens. EIP-2612 complementa estas mejoras en la experiencia de usuario: apruebas mediante firma y tu transacción puede ser patrocinada.
• Cambios de protocolo con visión de futuro: Las discusiones sobre la autorización nativa de billeteras como EIP-3074 y EIP-7702 resaltan una tendencia más amplia hacia operaciones impulsadas por firmas. Incluso a medida que estas evolucionan, EIP-2612 sigue siendo una herramienta práctica y ampliamente implementada para las aprobaciones hoy en día.

Cómo Funcionan las Aprobaciones sin Gas (Paso a Paso)

1. Inicias una acción (por ejemplo, intercambiar un token) en una dApp.
2. La dApp prepara un mensaje tipado EIP-712 con los campos: propietario (owner),  gastador (spender), valor (value), nonce, fecha límite (deadline) y el separador de dominio del token (nombre, versión, chainId, dirección del contrato).
3. Firmas el mensaje con tu billetera, aprobando los parámetros exactos.
4. La dApp o el relayer envía permit(owner, spender, value, deadline, v, r, s) en la cadena y, en la misma transacción, llama a la acción de la dApp que utiliza la asignación.
5. El contrato del token verifica la firma, comprueba el nonce y la fecha límite, y luego establece la asignación.

La idea clave: tú no pagas gas por la aprobación. Solo firmas.

Permit Nativo vs. Permit2

No todos los tokens implementan EIP-2612. Para resolver las interfaces fragmentadas y mejorar la seguridad, Uniswap introdujo Permit2, un sistema de aprobación generalizado que estandariza las aprobaciones de firmas y la gestión de asignaciones entre tokens.

• Descripción general de Permit2 e implementación de referencia: Uniswap Permit2

Cuando un token admite permit nativo, las dApps pueden usarlo directamente. Cuando no lo hace, Permit2 proporciona una interfaz coherente al tiempo que restringe las asignaciones al contrato Permit2, lo que a menudo mejora el control y la experiencia de usuario para la revocación.

Consideraciones de Seguridad Que Debes Tener en Cuenta

Sin gas no significa sin riesgo. Las firmas son potentes; trátalas como transacciones.

• Verifica el gastador (spender): Comprueba siempre qué contrato recibirá la asignación. Los datos tipados de EIP-712 deben mostrar claramente la dirección del gastador. Aprende cómo funcionan los datos tipados en EIP-712.
• Limita la cantidad y establece una fecha límite razonable: Evita aprobaciones ilimitadas a menos que confíes profundamente en el protocolo. Las fechas límite reducen la ventana de ataque.
• Comprueba chainId y dominio: Las firmas solo son válidas en la red y el contrato de token previstos a través del separador de dominio. Ten cuidado con los intentos de repetición entre cadenas o el phishing.
• Gestiona los nonces: EIP-2612 utiliza nonces para prevenir la repetición. Confía en implementaciones de tokens de buena reputación, idealmente auditadas y que utilicen bibliotecas bien probadas como ERC20Permit de OpenZeppelin.
• Revoca asignaciones: Revisa y revoca regularmente las aprobaciones no utilizadas en la interfaz de tu billetera o a través del contrato del token.
• Confianza en las meta-transacciones: Si un relayer envía tu permit, asegúrate de confiar en el backend de la dApp. Para patrones de meta-transacciones, consulta EIP-2771 (Trusted Forwarder).

Las buenas implementaciones ayudan a mitigar problemas, pero la vigilancia del usuario es esencial. Para prácticas recomendadas generales, la documentación de OpenZeppelin es un buen punto de partida: Contratos de OpenZeppelin.

Notas para Desarrolladores: Implementación y Uso de Permit

• Utiliza una implementación probada en batalla: ERC20Permit y draft-EIP712 de OpenZeppelin reducen los errores y se alinean con la especificación. Referencia: ERC20Permit.
• Agrupa la ejecución: Diseña tu dApp para que acepte una firma permit y realice la acción en la misma transacción para una experiencia de usuario de un solo clic.
• Soporta ambos flujos: Prefiere permit nativo cuando esté disponible; recurre a Permit2 si el token carece de él. Referencia: Uniswap Permit2.
• Maneja fechas límite y nonces de forma robusta: Rechaza firmas caducadas y confirma el nonce esperado antes de enviarlo en cadena.
• Considera el patrocinio: Combina EIP-2612 con los patrocinadores (paymasters) de ERC-4337 para crear flujos verdaderamente fluidos y patrocinados. Referencia: ERC-4337.

Preguntas Frecuentes

• ¿Es esto "gratis"? El usuario no paga gas por la aprobación; lo paga otra persona. La dApp aún puede cobrar tarifas a través de su lógica de contrato inteligente.

• ¿Qué pasa si un token no soporta EIP-2612? Utiliza Permit2, o recurre a un flujo de approve estándar con indicaciones claras en la experiencia de usuario.

• ¿Funciona permit entre cadenas? No. Las firmas se acotan a través de EIP-712 a un dominio (contrato de token + chainId). Debes firmar para la red específica.

• ¿Son compatibles las billeteras de hardware? Cualquier billetera que admita datos tipados EIP-712 puede mostrar mensajes permit. Las buenas billeteras muestran claramente el gastador, la cantidad y la fecha límite.

Reflexiones Finales

EIP-2612 es una de esas mejoras pequeñas pero cruciales que hacen que DeFi se sienta instantánea. Al convertir las aprobaciones en firmas, elimina un obstáculo común en la experiencia de usuario y se alinea de forma natural con los flujos modernos en L2 y la abstracción de cuentas.

Si dependes de flujos de trabajo basados en permit, elige una billetera que muestre los mensajes EIP-712 de forma transparente y mantenga las claves sin conexión. Las billeteras de hardware OneKey se centran en previsualizaciones EIP-712 claras en el dispositivo (gastador, cantidad, fecha límite, cadena), firmware de código abierto y un amplio soporte EVM/L2, lo cual es útil cuando deseas la comodidad de las aprobaciones sin gas sin comprometer la seguridad de las firmas.