¿Qué son las user operations?

Las user operations son objetos que contienen los detalles de una transacción que se ejecutará en nombre de la cuenta de contrato inteligente del remitente. Las user operations son un objeto de pseudo-transacción que permite que Account Abstraction funcione sin requerir cambios en la capa de consenso de Ethereum y las blockchains de layer 2 que soportan ERC-4337.

Para desarrollar smart contract wallets (SCWs) o hacer que una aplicación descentralizada sea compatible con SCWs, es útil entender los parámetros que definen una user operation, cómo se completan los campos de la user op durante el proceso de construcción, cómo un bundler las agrupa, y cómo un paymaster las valida y ejecuta.

VIDEO: construir y ejecutar user operations en Solidity

¿Cuáles son los campos que contiene una user operation?

Las user operations (UOs) contienen campos similares a los de las transacciones comunes (por ejemplo, sender, to, calldata, maxFeePerGas, maxPriorityFee, signature y nonce), pero también tienen campos nuevos específicos de la estructura de la user operation, incluyendo callGasLimit, verificationGasLimit, preVerificationGas y paymasterAndData.

Las definiciones de los campos de las UO se encuentran en la especificación oficial de ERC-4337. Aquí se resumen:

• callGasLimit: el gas que se usará en la llamada de ejecución principal
• verificationGasLimit: el gas que se usará para completar el paso de verificación
• preVerificationGas: el gas que se paga al bundler para cubrir la ejecución previa a la verificación y los costos de calldata
• paymasterAndData: la dirección del paymaster que patrocina la operación más los datos que se enviarán al paymaster

Se puede leer una explicación de el diseño y la arquitectura de las user operations en la parte 1 de la serie "You Could Invented Account Abstraction" escrita por David Philipson, ingeniero del equipo de infraestructura de AA de Alchemy.

A continuación, veamos el flujo estándar para completar correctamente los campos dentro de una user operation.

¿Cuál es el flujo para enviar una user operation?

El flujo típico para enviar una user operation (user op) a un bundler consta de varios pasos:

1. Construir una user op parcial con sender, nonce, initCode y callData completados
2. Estimar el gas de la user op parcial mediante un RPC de bundler usando eth_estimateUserOperationGas
3. Completar preVerificationGas, verificationGasLimit, callGasLimit
4. Si se usa un paymaster que no depende del contenido de la user op, como un paymaster ERC20, paymasterAndData puede completarse en este punto.
5. Estimar las tarifas de gas requeridas para la operación y completar maxFeePerGas y maxPriorityFeePerGas
6. (Opcional) Enviar la user op a un paymaster patrocinador para que la firme, y completar paymasterAndData
7. Esto debe hacerse en este paso, ya que la firma del paymaster requiere que todos los campos anteriores estén completados.
8. Firmar la user op, completar signature, y enviar la user op a un bundler mediante eth_sendUserOperation

Si bien los desarrolladores pueden usar ethers.js nativo para obtener los valores de cada campo de la user operation, existen herramientas de desarrollo web3 que facilitan la construcción de UOs.

¿Qué herramienta pueden usar los desarrolladores para construir user operations?

Las herramientas de construcción de user operations como el AA SDK de código abierto de Alchemy facilitan la construcción de user operations en comparación con hacerlo con ethers.js nativo.

AA SDK de Alchemy

El AA SDK de Alchemy está construido con viem para brindarles a los desarrolladores un bundle liviano. El aa-sdk en GitHub también soporta signers y providers de ethers.js a través de la librería aa-ethers.

Uno de los principales beneficios de usar el aa-sdk para construir user operations son dos métodos utilitarios:

1. sendUserOperation: maneja la estimación de gas, la solicitud de paymasterAndData, la firma y más
2. sendTransaction: convierte los datos de un objeto de transacción (from, to, data y value) en una user operation

El orden de las operaciones para construir una user operation es complicado, y el AA-SDK de Alchemy simplifica la construcción de UOs ejecutando una serie de operaciones: getDummyPaymasterData, estimar el gas con estimateGas, luego getFeeData, y finalmente getPaymasterAndData.

Después de obtener los valores de los campos de la user op, toma el target, el callData y un value opcional para construir y firmar la user operation. Luego envía la user op a un bundler y recibe un hash de la user op.

Si querés usar el paymaster de Alchemy, otro paymaster distinto, o planeás agregar soporte para tus propios SmartAccounts, lee la documentación del AA SDK de Alchemy para una explicación completa de cómo crear UOs fácilmente.

¿Cómo se agregan las user operations al mempool de user ops?

Antes de que una user op pueda agregarse al mempool, debe pasar una serie de verificaciones para asegurar que sigue el comportamiento esperado según lo establecido en la especificación de ERC-4337. La user op también debe pasar una verificación de simulación de validación para asegurar que es válida y puede pagar su gas (ya sea con la wallet del remitente o mediante una política de patrocinio de un paymaster).

1. Se verifica la validez de las user ops

La serie inicial de verificaciones se explica en la sección "Client behavior upon receiving a UserOperation" de la especificación de ERC-4337, y se resumen a continuación:

• El sender es un contrato existente, o el initCode (que se usa para crear un contrato) no está vacío (pero no ambos)
• Si el initCode no está vacío (porque la user op crea una cuenta), se determina si la factory tiene stake o no
• El verificationGasLimit es lo suficientemente bajo (menor o igual a MAX_VERIFICATION_GAS)
• El preVerificationGas es lo suficientemente alto para pagar el gas de calldata y las tarifas de gas por overhead
• El paymasterAndData está vacío, o comienza con la dirección del paymaster
• Si existe un paymaster, este debe tener código no vacío en la cadena, fondos para pagar la user op, y no estar baneado
• El callgas es al menos el costo de un CALL con valor distinto de cero
• El maxFeePerGas y maxPriorityFeePerGas están por encima del valor mínimo que el cliente aceptará
• El sender no tiene otra user op en el pool (o la user op está construida para reemplazar una entrada existente)

Hay muchas reglas que pueden afectar estas verificaciones, y se explican completamente en la especificación.

Para esta introducción a las user operations, simplemente buscamos comunicar las verificaciones de alto nivel que se realizan para calificar la validez de una user op.

2. Se simula la user operation

Una vez que una user op pasa estas verificaciones fundamentales, el cliente necesita simular la user operation para validar que es capaz de pagar su ejecución, ya sea usando sus propios fondos o con un paymaster.

Para simular una user op, un bundler llama al método simulateValidation(), que a su vez llama a la función validateUserOp en la cuenta del sender o a validatePaymasterUserOp en la cuenta de contrato del paymaster, si se usará un paymaster para patrocinar las tarifas de gas de la ejecución de la user op.

Después de que se llama al método simulateValidation(), este revierte con una respuesta ValidationResult. Que la función revierta es el comportamiento esperado, y esto se considera un resultado exitoso.

Si ValidationResult revierte con un error diferente, entonces la user op no pasó la simulación de validación y no se agrega al mempool. Las user ops se excluyen del mempool si devuelven sigFail, y las UOs también pueden omitirse del mempool si la respuesta validUntil expira.

Nota: Si initCode está presente en la user op, una account factory creará una cuenta, y luego el proceso de simulación continuará usando la cuenta recién creada.

Ahora que la user operation fue construida, verificada, simulada y agregada al mempool, ¡puede enviarse al entry point contract para su validación y ejecución!

¿Cómo se validan y ejecutan las user operations?

Para que los detalles de la transacción dentro de una user operation se publiquen onchain, el entry point contract necesita validar la user operation, y si la UO pasa la validación, entonces el entry point contract ejecutará la transacción y luego le reembolsará al bundler las tarifas de gas.

Los pasos básicos de la validación y ejecución de una user op son:

1. El bundler envía las user ops al singleton entry point contract mediante el método handleOps()
2. Para cada op, el entry point llama a validateOp en la wallet del sender de la op*
3. Si alguna op falla el paso de validación, se descarta
4. A continuación, se llama a executeOp para cada op en la wallet del sender de la op, registrando cuánto gas se usó
5. Se transfiere ETH desde la wallet del sender o desde un paymaster hacia el bundler para pagar el gas usado en la ejecución de cada op

*Todas las validaciones se ejecutan primero, y solo después se ejecutan todas las ejecuciones de las user ops validadas.

Aquí hay un diagrama que muestra cómo el entry point contract valida y ejecuta las user operations en nombre de las smart contract wallets del remitente:

Las user operations son los objetos de pseudo-transacción que permiten que las smart contract wallets actúen como la wallet principal de un usuario en Ethereum y las L2s equivalentes. Las smart contract wallets introducen beneficios de UX de web3 para hacer que blockchain sea más accesible, y esto es posible gracias a los proveedores de infraestructura de AA en Ethereum y L2s.

Si tu producto web3 soporta smart contract wallets, explorá la infraestructura de AA de Alchemy, incluyendo nuestras Gas Manager API y Bundler API para Ethereum, Polygon, Arbitrum, Optimism, y testnets populares como Sepolia.