O que são user operations?

User operations são objetos que contêm detalhes de transação a serem executados em nome da smart contract account do sender. User operations são um objeto pseudo-transação que permite que Account Abstraction funcione sem exigir mudanças na camada de consenso do Ethereum e de blockchains de camada 2 que suportam ERC-4337.

Para desenvolver smart contract wallets (SCWs) ou tornar uma aplicação descentralizada compatível com SCWs, é útil entender os parâmetros que definem uma user operation, como os campos de um user op são preenchidos durante o processo de construção do user op, como os user ops são agrupados por um bundler, e validados e executados por um paymaster.

ASSISTA: construa e execute user operations em Solidity

Quais são os campos contidos em uma user operation?

User operations (UOs) contêm campos semelhantes aos de transações comuns (por exemplo, sender, to, calldata, maxFeePerGas, maxPriorityFee, signature e nonce), mas também têm campos novos específicos da struct de user operation, incluindo callGasLimit, verificationGasLimit, preVerificationGas e paymasterAndData.

As definições dos campos de UO podem ser encontradas na especificação oficial do ERC-4337. Elas estão resumidas aqui:

• callGasLimit - o gas a ser usado pela chamada de execução principal
• verificationGasLimit - o gas a ser usado para completar a etapa de verificação
• preVerificationGas - o gas para pagar ao bundler cobrir os custos de execução pré-verificação e de calldata
• paymasterAndData - o endereço do paymaster patrocinador mais os dados a serem enviados ao paymaster

Uma explicação sobre o design e a arquitetura das user operations pode ser lida na parte 1 da série "You Could Invented Account Abstraction" escrita por David Philipson, engenheiro do time de infra de AA da Alchemy.

A seguir, vamos aprender o fluxo padrão para preencher corretamente os campos dentro de uma user operation.

Qual é o fluxo de envio de uma user operation?

O fluxo típico para enviar uma user operation (user op) a um bundler consiste em várias etapas:

1. Construir um user op parcial com sender, nonce, initCode e callData preenchidos
2. Estimar o gas para o user op parcial em uma bundler RPC via eth_estimateUserOperationGas
3. Preencher preVerificationGas, verificationGasLimit, callGasLimit
4. Se estiver usando um paymaster que não depende do conteúdo do user op, como um paymaster ERC20, paymasterAndData pode ser preenchido aqui.
5. Estimar as taxas de gas necessárias para a operação e preencher maxFeePerGas e maxPriorityFeePerGas
6. (Opcional) Enviar o user op a um paymaster patrocinador para assinatura, e preencher paymasterAndData
7. Isso deve ser feito nesta etapa, já que a assinatura do paymaster exige que todos os campos acima estejam preenchidos.
8. Assinar o user op, preencher signature, e enviar o user op a um bundler via eth_sendUserOperation

Embora os desenvolvedores possam usar o ethers.js nativo para obter os valores de cada campo da user operation, existem algumas ferramentas de desenvolvimento web3 que facilitam a construção de UOs.

Que ferramenta os desenvolvedores podem usar para construir user operations?

Ferramentas de construção de user operation como o AA SDK open-source da Alchemy tornam a construção de user operations mais fácil do que fazer user ops com ethers.js nativo.

AA SDK da Alchemy

O AA SDK da Alchemy é construído com viem para fornecer aos desenvolvedores um bundle leve. O aa-sdk no GitHub também suporta signers e providers do ethers.js através da biblioteca aa-ethers.

Um dos principais benefícios de usar o aa-sdk para construir user operations é dois métodos utilitários:

1. sendUserOperation - lida com a estimativa de gas, a solicitação de paymasterAndData, a assinatura e mais
2. sendTransaction - converte dados de objeto de transação (from, to, data e value) em uma user operation

A ordem das operações para construir uma user operation é complicada, e o AA-SDK da Alchemy simplifica a construção de UOs executando uma pilha de operações para getDummyPaymasterData, estimar o gas com estimateGas, depois** getFeeData**, e por fim** getPaymasterAndData**.

Depois de obter os valores para os campos do user op, ele pega o target, callData e um value opcional para construir e assinar a user operation. Em seguida, envia o user op a um bundler e recebe um hash do user op.

Se você quiser usar o paymaster da Alchemy, um paymaster separado, ou planeja adicionar suporte para seus próprios SmartAccounts, leia a documentação do Alchemy AA SDK para uma explicação completa de como criar UOs facilmente.

Como as user operations são adicionadas ao mempool de user op?

Antes que um user op possa ser adicionado ao mempool, ele precisa passar por uma série de verificações para garantir que segue o comportamento esperado conforme descrito na especificação ERC-4337. O user op também precisa passar por uma verificação de simulação de validação para garantir que é válido e pode pagar pelo seu gas (seja pela wallet do sender ou através de uma política de patrocínio de um paymaster).

1. A validade dos user ops é verificada

A série inicial de verificações é explicada na seção "Client behavior upon receiving a UserOperation" da especificação ERC-4337, e estão resumidas abaixo:

• O sender é um contrato existente, ou o initCode (usado para criar um contrato) não está vazio (mas não os dois)
• Se o initCode não estiver vazio (porque o user op cria uma account), determinar se a factory tem stake ou não
• O verificationGasLimit é suficientemente baixo (menor ou igual a MAX_VERIFICATION_GAS)
• O preVerificationGas é alto o suficiente para pagar pelo gas de calldata e pelas taxas de gas de overhead
• O paymasterAndData está vazio, ou começa com o endereço do paymaster
• Se existir um paymaster, ele precisa ter código não vazio onchain, fundos para pagar pelo user op, e não estar banido
• O callgas é pelo menos o custo de uma CALL com valor diferente de zero
• O maxFeePerGas e o maxPriorityFeePerGas estão acima do valor mínimo que o client vai aceitar
• O sender não tem outro user op no pool (ou o user op é construído para substituir uma entrada existente)

Existem muitas regras que podem afetar essas verificações, e elas estão totalmente explicadas na especificação.

Para esta introdução às user operations, buscamos apenas comunicar as verificações de alto nível feitas para qualificar a validade de um user op.

2. A user operation é simulada

Assim que um user op passa por essas verificações fundamentais, o client precisa simular a user operation para validar que o user op é capaz de pagar pela sua execução, seja usando seus próprios fundos ou com um paymaster.

Para simular um user op, um bundler chama o método simulateValidation(), que então chama a função validateUserOp na account do sender ou validatePaymasterUserOp no contract account do paymaster, caso um paymaster seja usado para patrocinar as taxas de gas para executar o user op.

Após o método simulateValidation() ser chamado, ele fará revert com uma resposta ValidationResult. A função ser revertida é o comportamento intencional, e isso é considerado um resultado bem-sucedido.

Se ValidationResult fizer revert com um erro diferente, então o user op não passou pela simulação de validação e não é adicionado ao mempool. Os user ops são excluídos do mempool se retornarem sigFail, e UOs também podem ser omitidos do mempool se a resposta** validUntil** expirar.

Nota: Se initCode estiver presente no user op, uma account será criada por uma account factory, e então o processo de simulação prosseguirá usando a account recém-criada.

Agora que a user operation foi construída, verificada, simulada e adicionada ao mempool, ela pode ser enviada ao entry point contract para validação e execução!

Como as user operations são validadas e executadas?

Para que os detalhes de transação dentro de uma user operation sejam publicados onchain, o entry point contract precisa validar a user operation, e se a UO passar na validação, o entry point contract vai executar a transação e depois reembolsar o bundler pelas taxas de gas.

As etapas básicas de validação e execução de um user op são:

1. O bundler envia user ops ao singleton entry point contract via o método handleOps()
2. Para cada op, o entry point chama validateOp na wallet do sender do op*
3. Se algum op falhar na etapa de validação, ele é descartado
4. Em seguida, chama executeOp para cada op na wallet do sender do op, registrando quanto gas foi usado
5. Transfere ETH da wallet do sender ou de um paymaster para o bundler para pagar o gas usado na execução de cada op

*Todas as validações são executadas e só então todas as execuções dos user ops validados são executadas.

Aqui está um diagrama mostrando como as user operations são validadas e executadas em nome das smart contract wallets do sender pelo entry point contract:

User operations são os objetos pseudo-transação que permitem que smart contract wallets atuem como a wallet principal de um usuário no Ethereum e em L2s equivalentes. Smart contact wallets introduzem benefícios de UX web3 para tornar o blockchain mais acessível, e isso é possível graças a provedores de infraestrutura de AA no Ethereum e em L2s.

Se o seu produto web3 suporta smart contract wallets, explore a infraestrutura de AA da Alchemy, incluindo nossa Gas Manager API e Bundler API para Ethereum, Polygon, Arbitrum, Optimism e testnets populares como Sepolia!