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 remetente. User operations são um objeto de pseudo-transação que permite que a Account Abstraction funcione sem exigir mudanças na camada de consenso do Ethereum e das 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 da user op, como as user ops são agrupadas por um bundler, e validadas e executadas 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 possuem novos campos 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 o bundler para cobrir os custos de execução de 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 da equipe de infra de AA da Alchemy.

Em seguida, 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 uma user op parcial com sender, nonce, initCode e callData preenchidos
2. Estimar o gas para a user op parcial em um bundler RPC via eth_estimateUserOperationGas
3. Preencher preVerificationGas, verificationGasLimit, callGasLimit
4. Se estiver usando um paymaster que não depende do conteúdo da user op, como um paymaster ERC20, o 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 a user op a um paymaster patrocinador para assinatura, e preencher paymasterAndData
7. Isso deve ser feito nesta etapa, já que a assinatura do paymaster requer que todos os campos acima já estejam preenchidos.
8. Assinar a user op, preencher signature, e enviar a 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 tornam a construção de UOs mais fácil.

Qual 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 são dois métodos utilitários:

1. sendUserOperation - lida com a estimativa de gas, solicitação de paymasterAndData, 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 finalmente getPaymasterAndData.

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

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

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

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

1. A validade das user ops é verificada

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

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

Existem muitas regras que podem impactar essas verificações, e elas sã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 uma user op.

2. A user operation é simulada

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

Para simular uma user op, um bundler chama o método simulateValidation(), que então chama a função validateUserOp na conta do remetente ou validatePaymasterUserOp na conta de contrato do paymaster, se um paymaster for usado para patrocinar as taxas de gas para executar a user op.

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

Se ValidationResult reverter com um erro diferente, então a user op não passou na simulação de validação e não é adicionada ao mempool. As user ops são excluídas do mempool se retornarem sigFail, e as UOs também podem ser omitidas do mempool se a resposta validUntil expirar.

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

Agora que a user operation foi construída, verificada, simulada e adicionada ao mempool, ela pode ser enviada ao contrato entry point 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 contrato entry point precisa validar a user operation, e se a UO passar na validação, então o contrato entry point executará a transação e depois reembolsará o bundler pelas taxas de gas.

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

1. O bundler envia user ops ao contrato entry point singleton via o método handleOps()
2. Para cada op, o entry point chama validateOp na wallet do remetente da op*
3. Se alguma op falhar na etapa de validação, ela é descartada
4. Em seguida, chama executeOp para cada op na wallet do remetente da op, rastreando quanto gas foi usado
5. Transfere ETH da wallet do remetente ou de um paymaster para o bundler para pagar o gas usado para executar cada op

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

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

User operations são os objetos de pseudo-transação que permitem que smart contract wallets atuem como a wallet primária de um usuário no Ethereum e L2s equivalentes. Smart contract wallets introduzem benefícios de UX web3 para tornar a blockchain mais acessível, e isso é possibilitado por provedores de infraestrutura de AA no Ethereum e 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!