¿Qué son las user operations?

Las operaciones de usuario son objetos que contienen los detalles de una transacción para ser ejecutada en nombre de la cuenta de contrato inteligente del emisor. Las operaciones de usuario 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 capa 2 compatibles con ERC-4337.

Para desarrollar billeteras de contrato inteligente (SCWs) o para hacer que una aplicación descentralizada sea compatible con SCWs, es útil entender los parámetros que definen una operación de usuario, cómo se completan los campos de la operación de usuario durante el proceso de construcción, cómo un bundler agrupa las operaciones de usuario, y cómo un paymaster las valida y ejecuta.

VIDEO: construye y ejecuta operaciones de usuario en Solidity

¿Cuáles son los campos que contiene una operación de usuario?

Las operaciones de usuario (UOs) contienen campos similares a las transacciones normales (por ejemplo, sender, to, calldata, maxFeePerGas, maxPriorityFee, signature y nonce), pero también tienen nuevos campos específicos de la estructura de operación de usuario, incluyendo callGasLimit, verificationGasLimit, preVerificationGas y paymasterAndData.

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

• callGasLimit - el gas que se usará para la llamada de ejecución principal
• verificationGasLimit - el gas que se usará para completar el paso de verificación
• preVerificationGas - el gas para pagarle al bundler y así cubrir los costos de ejecución previa a la verificación y de calldata
• paymasterAndData - la dirección del paymaster que patrocina la operación, más los datos que se le envían al paymaster

Se puede leer una explicación del diseño y arquitectura de las operaciones de usuario 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 operación de usuario.

¿Cuál es el flujo para enviar una operación de usuario?

El flujo típico para enviar una operación de usuario (user op) a un bundler consiste en varios pasos:

1. Construir una user op parcial con sender, nonce, initCode y callData completados
2. Estimar el gas para la user op parcial a través de un RPC del bundler mediante eth_estimateUserOperationGas
3. Completar preVerificationGas, verificationGasLimit y callGasLimit
4. Si se usa un paymaster que no depende del contenido de la user op, como un paymaster de ERC20, paymasterAndData se puede completar en este punto.
5. Estimar los fees de gas requeridos 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 completos.
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 operación de usuario, existen algunas herramientas de desarrollo web3 que facilitan la construcción de UOs.

¿Qué herramienta pueden usar los desarrolladores para construir operaciones de usuario?

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

AA SDK de Alchemy

El AA SDK de Alchemy está construido con viem para ofrecer a los desarrolladores un bundle liviano. El aa-sdk en GitHub también admite 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 operaciones de usuario son dos métodos de utilidad:

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

El orden de las operaciones para construir una operación de usuario es complicado, y el AA-SDK de Alchemy simplifica la construcción de UOs ejecutando una serie de operaciones para 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, callData, y un value opcional para construir y firmar la operación de usuario. Luego envía la user op a un bundler y recibe un hash de la user op.

Si quieres usar el paymaster de Alchemy, un paymaster separado, o planeas agregar soporte para tus propias 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 operaciones de usuario al mempool de user ops?

Antes de que una user op se pueda agregar al mempool, debe pasar una serie de verificaciones para asegurar que sigue el comportamiento esperado según lo establecido en la especificación 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 billetera del emisor 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 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 suficientemente bajo (menor o igual a MAX_VERIFICATION_GAS)
• El preVerificationGas es suficientemente alto para pagar el gas de calldata y los fees de gas de overhead
• El paymasterAndData está vacío, o comienza con la dirección del paymaster
• Si existe un paymaster, 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)

Existen muchas reglas que pueden afectar estas verificaciones, y están completamente explicadas en la especificación.

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

2. La operación de usuario se simula

Una vez que una user op pasa estas verificaciones fundamentales, el cliente necesita simular la operación de usuario para validar que la user op puede pagar por 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(), el cual 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 los fees de gas de la ejecución de la user op.

Después de llamar al método simulateValidation(), este revertirá con una respuesta ValidationResult. Que la función se revierta es el comportamiento intencional, y 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 retornan sigFail, y también pueden ser omitidas del mempool si la respuesta validUntil expira.

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

Ahora que la operación de usuario ha sido construida, verificada, simulada y agregada al mempool, ¡puede enviarse al contrato entry point para su validación y ejecución!

¿Cómo se validan y ejecutan las operaciones de usuario?

Para que los detalles de la transacción dentro de una operación de usuario se publiquen onchain, el contrato entry point necesita validar la operación de usuario, y si la UO pasa la validación, entonces el contrato entry point ejecutará la transacción y luego le reembolsará al bundler los fees 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 contrato entry point singleton mediante el método handleOps()
2. Para cada op, el entry point llama a validateOp en la billetera sender de la op*
3. Si alguna op falla el paso de validación, se descarta
4. Luego, se llama a executeOp para cada op en la billetera sender de la op, registrando cuánto gas se usó
5. Se transfiere ETH desde la billetera del sender o 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.

A continuación, un diagrama que muestra cómo se validan y ejecutan las operaciones de usuario en nombre de las billeteras de contrato inteligente del emisor por parte del contrato entry point:

Las operaciones de usuario son los objetos de pseudo-transacción que permiten que las billeteras de contrato inteligente actúen como la billetera principal de un usuario en Ethereum y en L2s equivalentes. Las billeteras de contrato inteligente 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 admite billeteras de contrato inteligente, explora la infraestructura de AA de Alchemy, incluyendo nuestra Gas Manager API y Bundler API para Ethereum, Polygon, Arbitrum, Optimism, y testnets populares como Sepolia.