Cuentas inteligentes de Ethereum: UserOperations, bundlers y gas patrocinado
Sigue una UserOperation de ERC-4337 a través del bundler y EntryPoint; descubre el patrocinio del gas y cómo se relaciona la recuperación con la custodia.
En esta guíaUna cuenta inteligente incorpora reglas de autorización programables
Resumen breve
ERC-4337 permite que una cuenta de contrato envíe UserOperations según sus reglas, por una vía distinta de las transacciones EOA. Los bundlers llaman a EntryPoint; un paymaster puede patrocinar el gas. No garantiza recuperación, gratuidad ni ausencia de custodia.
Una cuenta inteligente incorpora reglas de autorización programables
Una cuenta externa (EOA) acredita el control mediante una firma de clave privada y su nonce ordena las transacciones. Es un modelo sencillo, pero normalmente la misma clave autoriza todas las acciones.
Cada transacción EOA contiene una única acción de nivel superior; un contrato llamado aún puede ejecutar llamadas internas adicionales.
Una cuenta inteligente es un contrato que puede guardar activos y ejecutar llamadas. Su código de validación puede exigir una firma, un umbral de varias firmas o permisos que caduquen.
ERC-4337 define una interfaz para autorizar y ejecutar operaciones; no impone una cartera ni una política de recuperación.
Ethereum.org describe claves de respaldo, permisos limitados y gas patrocinado como posibles funciones, no universales. El nombre «cartera inteligente» no revela quién la controla.
Comprueba qué contrato guarda los activos, qué código y EntryPoint acepta la cuenta y qué firmantes autorizan llamadas. Si la lógica se puede actualizar, los administradores y el proceso de cambios también importan.
Una UserOperation todavía no es una transacción incluida en un bloque
Una UserOperation describe lo que quiere hacer una cuenta inteligente. Suele incluir la dirección de la cuenta emisora, un nonce propio, los datos de llamada, una firma, límites de gas y condiciones de comisión.
También puede llevar datos de una fábrica para crear la cuenta o información de un paymaster. Los campos exactos varían según la versión de EntryPoint.
En vez de usar directamente eth_sendTransaction, la cartera la envía a un bundler o relay con métodos ERC-4337 como eth_sendUserOperation. La solicitud pasa por un pool de UserOperations, separado del pool de transacciones EOA.
El hash de UserOperation identifica esa solicitud; la transacción en cadena creada por el bundler tiene su propio hash y recibo. ERC-7769 define métodos RPC para enviarla y consultar sus resultados.
Una respuesta puede indicar que ese bundler aceptó la solicitud tras sus comprobaciones. No demuestra que un bloque la incluyera ni que la acción de la app tuviera éxito. La propagación a otros bundlers depende de su infraestructura y políticas.
Separa el acuse del proveedor del resultado registrado en cadena.
El bundler simula la validación y prepara la llamada en cadena
El bundler recibe la operación, comprueba si es compatible con su versión de EntryPoint y simula la validación de la cuenta y del paymaster. Revisa la firma, la confianza en EntryPoint, el nonce, el gas y las condiciones de patrocinio.
Puede rechazar operaciones que no pasen estas reglas. La guía de bundlers de ERC-4337 explica la simulación y el envío agrupado.
Después reúne una o más operaciones válidas y crea una transacción Ethereum normal que llama a handleOps de EntryPoint.
Que esa transacción entre en un bloque depende de los productores de bloques y del estado de la red. Recibir un hash de UserOperation no demuestra que la operación se ejecutara en la cadena canónica.
El pool de UserOperations es distinto del pool EOA, y no todos los proveedores tienen necesariamente las mismas solicitudes. Un bundler puede rechazarla o dejarla esperando; las cadenas, versiones y reglas compatibles varían.
Para comprobar el estado, distingue la vista de la cartera, el recibo de la operación y el recibo en cadena de la transacción agrupada.
ERC-4337 separa la solicitud firmada, el envío agrupado, la validación de la cuenta y el patrocinio opcional del gas
EntryPoint comprueba la autorización y después llama a la cuenta
EntryPoint recibe la llamada handleOps del bundler e invoca la función de validación de cada cuenta inteligente.
La cuenta comprueba el EntryPoint de confianza, la firma y sus propias reglas de autorización. El nonce combina una clave de 192 bits y una secuencia de 64 bits.
EntryPoint valida e incrementa la secuencia por cuenta y clave; la cuenta puede asignar un significado propio a la clave o añadir comprobaciones. Un paymaster opcional también comprueba si patrocina la operación.
Si la validación pasa, EntryPoint llama a la función de ejecución de la cuenta para realizar lo codificado en callData y liquida el coste. EntryPoint es el contrato común que permite estos flujos sin cambiar el protocolo para cada diseño de cartera.
La guía de EntryPoint de ERC-4337 explica sus funciones de validación y liquidación. Comprueba su dirección, versión y red reales.
La simulación ayuda a anticipar el resultado, pero no promete inclusión.
Mientras espera, pueden cambiar el estado de la cadena, las comisiones, el plazo de validez o un contrato externo. Aunque la validación pase, la llamada de la app puede fallar o revertirse.
La inclusión no demuestra que la transferencia o acción prevista se completara.
Un paymaster patrocina gas solo si acepta la operación
Si la UserOperation incluye datos de paymaster, EntryPoint pregunta a ese contrato si quiere patrocinarla. Así, una app puede asumir la comisión o permitir que el usuario empiece sin ETH en la cuenta.
Algunos diseños permiten pagar con tokens o aplican otras condiciones; depende de la cartera y del paymaster. El patrocinio no hace desaparecer el coste.
El paymaster puede limitar las apps, usuarios, cantidades o número de operaciones, revisar la solicitud y rechazarla. Su depósito en EntryPoint paga los costes.
Si se exige un stake aparte, sirve como garantía bajo ciertas reglas y no es el depósito disponible para gas. La guía de paymasters y EIP-4337 explican este flujo.
Que la app muestre una comisión cero no significa que no haya coste.
El patrocinador puede pagar primero y recuperar valor mediante una suscripción, tokens o condiciones del servicio. Comprueba quién termina asumiéndolo, si el patrocinio tiene límites y si una operación fallida puede generar comisión.
Evalúa por separado las llamadas agrupadas y sus comisiones
Si la cartera lo permite, una UserOperation puede incluir la aprobación de una app y un intercambio. Ambas acciones pasan por EntryPoint como una sola operación.
Esto difiere tanto de una transacción EOA normal como de que el bundler agrupe varias UserOperations distintas en una transacción de cadena. Revisa la vista previa de la cartera.
Supongamos, solo como ejemplo, que una operación patrocinada aprobada termina costando 0,0012 ETH en gas. El coste podría liquidarse desde el depósito del paymaster en EntryPoint y no desde el saldo del usuario. Esa cifra es ilustrativa, no una cotización actual.
El importe real depende del gas usado, las condiciones de comisión y la red. Agrupar no siempre abarata ni hace más segura la operación.
La atomicidad depende de cómo la cuenta gestione los fallos: comprueba si una llamada fallida revierte todo el lote o deja otras acciones completadas, y quién paga el gas. Una estimación deficiente puede causar rechazo o fallo.
La recuperación depende de la cuenta, no de ERC-4337
Una cuenta puede admitir firmantes de respaldo o permitir que guardianes de confianza sustituyan una clave al alcanzar cierto umbral. Algunos diseños añaden un plazo para que una clave existente se oponga.
Si siempre se necesita una sola firma, perder esa clave puede dejarte sin recuperación. ERC-4337 permite reglas propias, pero no activa claves de respaldo ni recuperación social en todas las cuentas. Pocos guardianes o reglas débiles pueden facilitar un ataque.
Demasiados guardianes o requisitos exigentes pueden retrasar al propietario legítimo. Revisa el umbral, el plazo, la posibilidad de cancelar y dónde se guardan las claves de recuperación.
Las reglas determinan quién puede bloquear una operación, además de quién puede aprobarla. Una cartera de contrato no es automáticamente custodial ni no custodial.
El control depende de quién tiene las claves, de los permisos de administrador o actualización y de lo que puede autorizar un firmante alojado o servicio de recuperación. Examina por separado el contrato que guarda activos y las claves o servicios que lo controlan.
En la vista previa, revisa la red, la dirección de cuenta, los contratos de destino, los datos de llamada, el alcance de las aprobaciones de tokens y cuántas llamadas se incluyen. Una firma puede autorizar más de la acción destacada por la interfaz.
Si no entiendes los datos firmados, consulta la documentación oficial de la app y la cartera. Para entender el patrocinio, lee los requisitos, límites, formas de pago alternativas y reglas de coste ante fallos; no te fíes solo del nombre del paymaster.
Una etiqueta de patrocinio activa no hace que la app sea siempre gratuita, y el paymaster puede rechazar la operación. La congestión y la demora de inclusión son asuntos separados.
Si una UserOperation tarda, no apliques sin más «acelerar» o «cancelar» de una operación EOA. Busca primero su hash y recibo. Si tienes el hash de la transacción agrupada, comprueba también el recibo del bloque y el resultado.
El recibo RPC puede distinguir coste y éxito de una operación del recibo de todo el lote.
Preguntas frecuentes
Q1¿Una UserOperation es lo mismo que una transacción Ethereum?
No. Es una solicitud de cuenta inteligente enviada por un pool separado. Cuando el bundler la incluye en una llamada a EntryPoint, la cadena registra la transacción agrupada y el resultado de cada operación.
Q2Si hay un paymaster, ¿el usuario no paga gas?
Quizá no pague ETH directamente desde su cuenta, pero el coste de red existe. Puede haber límites, pagos con tokens o condiciones del servicio; una operación fallida también puede generar costes.
Q3¿Puedo recuperar una cartera ERC-4337 si pierdo una clave?
Solo si la cuenta incorpora firmantes de respaldo o reglas de recuperación. Comprueba el umbral, el plazo, quién puede sustituir la clave y qué controla cualquier servicio de recuperación.
