¿Qué son las transacciones frame de Ethereum?

Si eres principiante y te encuentras con el concepto de “Transacciones Frame” en debates sobre Ethereum y Hegotá, piensa en ellas como transacciones formadas por varios pasos coordinados. Un frame puede verificar al remitente, otro autorizar el pago y los siguientes llevar a cabo la acción del usuario. Este artículo se centra en esa estructura básica y no en la propuesta completa de EIP-8141.

Puntos clave:

• EIP-8141 introduce un nuevo tipo de Transacción Frame, asignado actualmente al tipo de transacción 0x06.

• Una transacción puede contener hasta 64 frames, cada uno con su propio modo de ejecución y límites de gas.

• Los frames separan la validación de la transacción, el pago de gas y la ejecución del usuario.

• El opcode APPROVE permite autorizar ejecución, pago o ambos de forma independiente.

• La abstracción de frames habilita la abstracción nativa de cuentas, agrupación atómica, patrocinio de gas y verificación programable de firmas.

¿Qué es una Transacción Frame EIP-8141?

La especificación oficial de la Transacción Frame EIP-8141 define una nueva transacción cuya validez y pago de gas se pueden establecer de manera abstracta. Especificación EIP-8141

La carga útil de la transacción contiene la dirección del remitente, firmas, comisiones y una lista de frames. Cada frame indica su modo, flags, destino, límites de ejecución y gas de estado, valor y datos. La especificación vigente fija MAX_FRAMES en 64 y FRAME_TX_TYPE en 0x06.

En términos simples, una transacción tradicional sigue un esquema fijo donde el remitente firma y paga. La abstracción de frames convierte esa estructura en una secuencia programable.

¿Cómo funcionan los modos de ejecución en las Transacciones Frame?

Cada frame EIP-8141 puede operar en uno de tres modos de ejecución:

El modo de ejecución define el contexto de cada frame. Un frame VERIFY puede ejecutar la lógica de verificación antes que los frames de remitente, mientras que el modo SENDER permite operaciones autorizadas como llamadas desde la dirección del remitente. El modo DEFAULT ofrece una identidad neutral a nivel de protocolo.

Esta estructura modular es clave para la abstracción nativa de cuentas, ya que la validación no depende de una única clave privada o esquema de firma.

¿Para qué sirve el opcode APPROVE?

EIP-8141 incorpora el opcode APPROVE, que actualiza el contexto de aprobación de la transacción.

La validación puede tener distintos ámbitos de aprobación:

• APPROVE_PAYMENT autoriza el pago de gas.

• APPROVE_EXECUTION autoriza los frames de remitente posteriores.

• APPROVE_EXECUTION_AND_PAYMENT autoriza ambos aspectos.

El destino resuelto del frame debe ser el caller de APPROVE, limitando quién puede conceder la autorización. Una vez aprobada la ejecución, los frames SENDER siguientes pueden operar con el contexto del remitente.

Esta separación permite que un contrato patrocinador o paymaster autorice el coste máximo de gas, mientras que la lógica de validación del usuario autoriza la ejecución de manera independiente.

¿Cuáles son los siete opcodes Frame de EIP-8141?

La especificación actual define siete instrucciones relacionadas con frames:

Por ejemplo, TXPARAM revela datos como remitente, comisión máxima, hash de firma y número de frames. FRAMEPARAM muestra información del frame como modo de ejecución, flags, gas usado y si existe flag de agrupación atómica. Las operaciones básicas de consulta tienen un coste de gas de 2.

¿Cómo funcionan el pago y la contabilidad del gas?

Las Transacciones Frame separan el pago de gas del remitente. Un frame VERIFY puede autorizar a otra cuenta o contrato patrocinador para pagar, lo que habilita el patrocinio nativo de gas.

Por ejemplo, un usuario puede tener stablecoins mientras otra cuenta actúa como pagador de gas. La Transacción Frame puede transferir tokens ERC-20 para compensar al patrocinador, mientras el coste de la transacción de Ethereum se liquida a través del pagador designado.

Cada frame tiene límites de ejecución y gas de estado. El gas no usado reduce el monto final a cobrar al pagador, en vez de aumentar la capacidad de ejecución para los frames restantes.

¿Cómo garantiza la agrupación atómica que los frames sean todo o nada?

Una agrupación atómica vincula varios frames de ejecución para que sean exitosos o reviertan de forma conjunta.

Por ejemplo, una aprobación ERC-20 seguida de un swap: si el flag de agrupación atómica está activado y el frame de swap revierte, la aprobación previa también se revierte. Así se evita que quede una autorización de tokens no deseada tras el fallo de la transacción.

Esto facilita la interacción con contratos inteligentes de varios pasos mediante Transacciones Frame.

¿Por qué las Transacciones Frame son relevantes para la abstracción de cuentas?

El framework ERC-4337 de abstracción de cuentas de Ethereum usa cuentas inteligentes, agrupadores, UserOperations y paymasters para habilitar billeteras programables. Las Transacciones Frame llevan esa flexibilidad directamente a la capa de protocolo.

La validación programable de EIP-8141 soporta distintos esquemas de firma, rotación de claves, futura agregación de firmas y abre el camino a la preparación post-cuántica. El código predeterminado permite que cuentas sin contratos desplegados participen, mientras un frame de despliegue facilita la creación de cuentas antes de la verificación.

La flexibilidad implica riesgos. La validación arbitraria puede causar denegación de servicio o invalidaciones masivas en el pool de transacciones, por lo que las reglas públicas del mempool restringen el prefijo de validación y la gestión de Transacciones Frame pendientes.

Conclusión

Una Transacción Frame de Ethereum es, en esencia, una transacción formada por varios frames programables. En vez de codificar validación, pago de gas y ejecución en un solo rol, EIP-8141 permite que diferentes frames realicen cada tarea.

Esa definición marca la diferencia: EIP-8141 es la propuesta de protocolo; las Transacciones Frame son el nuevo formato de transacción que introduce. Su estructura modular posibilita patrocinio de gas, agrupación atómica, validación programable, firmas flexibles y abstracción nativa de cuentas, sin convertir cada función en un sistema de transacciones independiente.

Preguntas frecuentes

¿El modo VERIFY es solo lectura en una Transacción Frame?

Sí. El modo VERIFY sirve para validar la transacción y está diseñado para funcionar sin modificar el estado de forma persistente. Esto permite que los nodos simulen la validación de manera segura antes de decidir si una Transacción Frame pendiente debe entrar o permanecer en el mempool público.

¿Puede Ethereum identificar al pagador de gas antes de ejecutar una Transacción Frame?

No siempre. En EIP-8141, el pagador se selecciona mediante lógica de validación programable, así que no se puede determinar estáticamente solo con los datos de la transacción. La autorización del pago se establece durante el proceso de validación.

¿Cuándo se autoriza al pagador en una Transacción Frame EIP-8141?

Primero se autoriza al remitente y luego se confirma la autorización de pago para la cuenta o paymaster que cubre el coste de gas. Esta separación permite que una parte autorice la ejecución y otra el pago de gas.

¿Puede una Transacción Frame usar el gas restante de otro frame?

No. La contabilidad de gas en las Transacciones Frame impide que un frame tome prestado el gas no utilizado de otro. Cada frame tiene límites definidos de ejecución y gas de estado; el límite total de gas de la transacción incluye el gas intrínseco y los límites de ejecución de los frames implicados.

¿Cuál es la diferencia entre paymasters canónicos y no canónicos?

Un paymaster canónico sigue una implementación definida por el protocolo, cuyo código de contrato debe ajustarse a lo esperado. Los nodos pueden rastrear sus compromisos de gas pendientes de forma predecible. Los paymasters no canónicos tienen restricciones más estrictas en el mempool, como el límite de una sola transacción pendiente, para reducir riesgos de invalidación masiva y denegación de servicio.

Este contenido es solo para fines educativos. EIP-8141 sigue siendo parte de la hoja de ruta del protocolo Ethereum y los detalles de la especificación pueden cambiar antes de su activación en la red principal.