EIP-8141 vs. ERC-4337: ¿Cuál es la diferencia?

La diferencia esencial entre EIP-8141 y ERC-4337 reside en su arquitectura. ERC-4337 implementa la abstracción de cuentas sobre el sistema de transacciones de Ethereum mediante billeteras de contratos inteligentes, UserOperations, bundlers, un contrato inteligente único denominado EntryPoint y, opcionalmente, paymasters. Por su parte, EIP-8141 propone la Frame Transaction en la capa de protocolo, permitiendo que la validación, el pago de gas, el despliegue y la ejecución se gestionen mediante múltiples frames dentro de una única transacción.

Ambos estándares buscan las mismas funciones clave de abstracción de cuentas: transacciones patrocinadas, operaciones por lotes, firmas flexibles, mecanismos de recuperación y experiencias simplificadas de billetera. La diferencia radica en el grado de integración de estas capacidades en Ethereum.

Puntos clave:

• ERC-4337 opera sin modificar el tipo de transacción nativo de Ethereum; EIP-8141 introduce Frame Transactions directamente en el protocolo.

• ERC-4337 utiliza UserOperations, bundlers, un contrato EntryPoint y contratos paymaster.

• EIP-8141 emplea VERIFY, SENDER y otros frames para segmentar la validación, el pago de gas, el despliegue y la ejecución.

• Ambos estándares permiten la abstracción de gas, el procesamiento por lotes, firmas alternativas y transacciones patrocinadas.

• EIP-7702 ofrece una vía de migración para que los EOA existentes accedan a la funcionalidad de contratos inteligentes y puede interoperar con ambos modelos de abstracción de cuentas.

EIP-8141 vs. ERC-4337: abstracción de cuentas

ERC-4337 define la UserOperation como una seudotransacción. Incluye campos como call data, límites de gas, tarifa máxima, firma y datos del paymaster, pero finalmente es el bundler quien la agrupa en una transacción estándar de Ethereum dirigida a EntryPoint.

EIP-8141 modifica la propia transacción tradicional. Su payload integra múltiples frames, firmas, parámetros de tarifas y la dirección del remitente, permitiendo que cada frame defina su modo de ejecución y límites de gas específicos.

Cómo funcionan las billeteras de contratos inteligentes en ERC-4337

Con ERC-4337, el usuario interactúa o crea un contrato de cuenta inteligente en lugar de depender solo de una cuenta controlada externamente.

El usuario firma una UserOperation con los datos de la llamada prevista. Un bundler recolecta UserOperations pendientes y las envía mediante el contrato EntryPoint, encargado de validar cada cuenta y coordinar la ejecución. Un contrato paymaster puede patrocinar el coste de gas, permitiendo que aplicaciones definan políticas de pago condicional o que los usuarios paguen indirectamente con tokens ERC-20.

Como el campo de firma es gestionado por la cuenta inteligente y no por las reglas de consenso de Ethereum, ERC-4337 admite claves de sesión, políticas multifirma, lógica de recuperación y cuentas inteligentes modulares.

La arquitectura actual de abstracción de cuentas de ERC-4337 aporta una funcionalidad avanzada de contratos inteligentes sin requerir actualizaciones en el protocolo.

Cómo la Frame Transaction de EIP-8141 transforma el modelo

EIP-8141 traslada más funcionalidades al flujo de transacciones nativo de Ethereum.

Un verify frame gestiona la validación. Un sender frame ejecuta la operación del usuario en su contexto de ejecución. Un deploy frame puede instalar el código de cuenta antes de la validación si es necesario, y frames adicionales gestionan el pago o lógica post-ejecución.

El opcode APPROVE permite que la validación establezca un alcance de aprobación para ejecución, pago o ambos. Una vez autorizada la ejecución, los frames restantes ejecutan las operaciones multi-etapa solicitadas.

Esta es la diferencia clave entre Frame Transactions y ERC-4337: el protocolo procesa estos pasos de forma nativa, sin depender de un pipeline externo de UserOperations.

Pagos y contabilidad del gas

Ambos sistemas permiten que usuarios sin ETH en cada transacción participen en la red.

En ERC-4337, un contrato paymaster cubre el gas y puede recuperar el coste en otro token. El proveedor de la billetera o la dApp pueden definir las condiciones de patrocinio.

Con EIP-8141, el pago del gas se integra en la secuencia de validación de la transacción. Un contrato patrocinador autoriza el pago, mientras el remitente autoriza la ejecución por separado. Así, el pagador puede no ser el mismo que el remitente.

EIP-8141 emplea un modelo de gas más explícito. Cada frame recibe límites específicos de gas de ejecución y de estado, y la transacción tiene un coste máximo global. El gas no utilizado en un frame no se transfiere al siguiente, lo que limita el coste de simulación y el trabajo de validación.

Transacciones por lotes y operaciones múltiples

Las cuentas inteligentes bajo ERC-4337 ya permiten transacciones por lotes, ejecutando varias operaciones con una sola acción de cuenta.

EIP-8141 define de forma explícita las operaciones por lotes mediante múltiples frames. Un lote atómico agrupa acciones consecutivas para que tengan éxito o fallen en conjunto; si un frame relevante revierte, todo el grupo revierte.

Por ejemplo, la aprobación de un token y un swap pueden procesarse como una secuencia todo-o-nada, evitando aprobaciones no utilizadas si el swap falla.

Este enfoque nativo para operaciones multi-etapa es una de las razones por las que EIP-8141 pretende simplificar el diseño de cuentas inteligentes.

EIP-7702 y el camino de migración para cuentas controladas externamente

EIP-7702 permite que un EOA delegue la ejecución en código de contrato sin cambiar su dirección, sirviendo de puente entre cuentas convencionales y la funcionalidad de cuentas inteligentes.

ERC-4337 puede aprovechar cuentas compatibles con EIP-7702, evitando la migración forzada a nuevas direcciones de contrato.

EIP-8141 añade el código por defecto, otorgando a la cuenta un comportamiento base de Frame Transaction incluso si almacena vacío o carece de código desplegado. Un deploy frame podrá instalar o delegar código cuando se requiera funcionalidad adicional.

Por ello, EIP-7702, ERC-4337 y EIP-8141 son etapas conectadas en la migración hacia la abstracción de cuentas en Ethereum, no sistemas mutuamente excluyentes.

Abstracción nativa de cuentas: cambios en la capa de protocolo

La integración profunda de EIP-8141 puede reducir la dependencia de bundlers y otras infraestructuras de procesamiento off-chain en la mayoría de operaciones estándar de abstracción de cuentas.

Además, acerca la validación programable al modelo transaccional a nivel de consenso. Distintas lógicas de validación permiten políticas de recuperación, agregación de firmas, permisos de tipo sesión o autenticación post-cuántica.

El coste es la complejidad: los nodos públicos deben evaluar con seguridad una Frame Transaction pendiente antes de incluirla. EIP-8141 define un prefijo de validación restringido, limita el acceso al estado, acota el trabajo de validación y diferencia entre paymasters canónicos y no canónicos para minimizar riesgos de invalidez masiva y ataques de denegación de servicio.

La arquitectura general de abstracción de cuentas en Ethereum ilustra por qué la experiencia de usuario en billeteras ha evolucionado de soluciones en la aplicación a un soporte profundo en el protocolo.

Conclusión

En resumen, ERC-4337 construye la abstracción de cuentas alrededor de Ethereum, mientras que EIP-8141 la integra en el propio núcleo de Ethereum.

ERC-4337 emplea billeteras de contratos inteligentes, UserOperations, bundlers, EntryPoint y paymasters. EIP-8141 utiliza Frame Transactions con etapas específicas para verificación, remitente, despliegue, pago y ejecución.

ERC-4337 es valioso porque ya aporta una infraestructura madura de abstracción de cuentas sin depender de actualizaciones de protocolo. La ventaja de EIP-8141 es que la abstracción de gas, la validación programable, las operaciones por lotes y las transacciones patrocinadas se vuelven nativas y menos dependientes de pipelines externos.

Preguntas frecuentes

¿EIP-8141 reemplaza a ERC-4337?

No necesariamente. ERC-4337 ya soporta cuentas inteligentes desplegadas e infraestructura consolidada. EIP-8141 introduce cambios en las capacidades nativas de Ethereum, y las billeteras pueden seguir utilizando componentes de ERC-4337 donde resulten útiles.

¿EIP-8141 requiere un contrato EntryPoint?

No existe un contrato EntryPoint equivalente requerido para el flujo principal de Frame Transaction. La validación y ejecución se gestionan directamente mediante frames en la transacción, no mediante UserOperations canalizadas a través de EntryPoint.

¿Ambos sistemas admiten pagos de gas patrocinados?

Sí. ERC-4337 utiliza paymasters para patrocinar UserOperations. EIP-8141 permite autorizar por separado remitente y pagador en la validación, haciendo posible que un contrato patrocinador cubra el gas.

¿ERC-4337 es compatible con EOAs existentes?

Sí, especialmente mediante EIP-7702. Un EOA puede delegar funcionalidad de contrato inteligente y conservar su dirección, evitando una migración completa de cuenta.

¿Por qué EIP-8141 se considera abstracción nativa de cuentas?

Porque la validación, la autorización de pago, el despliegue y la ejecución se integran en un nuevo formato de transacción de Ethereum, en vez de depender principalmente de la infraestructura externa de UserOperation.

Este contenido es solo para fines educativos. Los estándares de Ethereum, las actualizaciones de protocolo, las implementaciones de billeteras y las especificaciones de los EIP pueden modificarse.