---
title: "Assinaturas dummy e transferências de tokens de gas no ERC-4337"
description: "Saiba como obter os campos preVerificationGas e verificationGasLimit durante o processo de estimativa de gas da user operation usando uma assinatura dummy e um valor dummy de paymasterAndData."
---
# Assinaturas dummy e transferências de tokens de gas no ERC-4337
Em [ERC-4337 Gas Estimation](https://www.alchemy.com/blog/erc-4337-gas-estimation) discutimos como o gas funciona no ERC-4337 e nosso método de estimativa de gas. Com esse método, devemos conseguir fornecer aos usuários valores precisos para o envio de suas user operations. Só que nem sempre é tão simples assim.
Vamos explorar alguns outros problemas que complicam a estimativa de gas do ERC-4337.
## O que são valores `signature` dummy?
Na maioria das implementações de contas de contrato inteligente, o campo de assinatura é computado off-chain, fazendo o hash de uma user operation e assinando esse hash usando algum esquema de assinatura \(ECDSA sendo o mais popular\). Essa assinatura é verificada onchain pelo contrato da conta durante a fase de verificação.
Por exemplo, `SimpleAccount` [usa](https://github.com/eth-infinitism/account-abstraction/blob/d1333cf58c17d5cc84e830f3fc3a69081c777979/contracts/samples/SimpleAccount.sol#L93) um esquema de assinatura [EIP-191](https://eips.ethereum.org/EIPS/eip-191) sobre o hash, que é validado onchain durante sua função `validateUserOp` usando a [biblioteca ECDSA](https://docs.openzeppelin.com/contracts/2.x/api/cryptography#ECDSA-toEthSignedMessageHash-bytes32-) da [OpenZeppelin](https://www.alchemy.com/dapps/openzeppelin).
Essa assinatura precisa ser computada depois que o gas é estimado, já que esses campos estão incluídos no hash.
No entanto, há partes da etapa de estimativa de gas que exigem que o campo de assinatura esteja preenchido: `preVerificationGas` e `verificationGasLimit `.
### preVerificationGas
Na seção sobre a estimativa de `preVerificationGas` na primeira parte desta série, discutimos três cálculos que o bundler usa para contabilizar o gas não medido.
Note que os passos 2 e 3 \(calcular a parcela da user op no custo de gas do calldata e a parcela da user op em qualquer overhead de gas de execução\) dependem diretamente do tamanho e do conteúdo de uma user operation, incluindo o campo `signature`.
### verificationGasLimit
Quase todas as implementações úteis de contas de contrato inteligente exigirão alguma verificação de assinatura. Esse gas precisa ser estimado! Esse processo de estimativa não pode reverter, senão o verification gas não pode ser implementado.
Como escolhemos qual assinatura usar?
## Como calcular valores dummy de assinatura
Para resolver esses problemas, muitos [bundlers ERC-4337](https://www.alchemy.com/overviews/what-is-a-bundler) usam uma "Dummy Signature", que deve ser fornecida por quem chama `eth\_estimateUserOperationGas` com base no tipo específico de conta.
### Restrições
Essa dummy signature tem algumas restrições:
1. O tamanho do valor dummy deve ser igual ao tamanho máximo de assinatura e deve conter o número máximo de bytes não zero válidos para a conta.
a. Isso garante que os cálculos de `preVerificationGas` possam contabilizar a contribuição da assinatura no pior caso para os custos de overhead de calldata e de entry point.
1. O valor dummy deve, quando fornecido à função de validação da conta, causar o uso de gas no pior caso e não deve causar reversão.
1. O valor dummy não deve ser uma assinatura válida para nenhuma user operation válida.
Um valor dummy de `signature` para `SimpleAccount` pode ser encontrado em nossa documentação para o método [eth_estimateUserOperationGas](https://www.alchemy.com/docs/wallets/api-reference/bundler-api/bundler-api-endpoints/eth-estimate-user-operation-gas).
**Essa dummy signature tem as seguintes propriedades:**
1. Tem exatamente o tamanho de uma assinatura ECDSA
1. Tem o número máximo de bytes não zero permitidos em uma assinatura ECDSA
1. É uma assinatura ECDSA válida \(para que a chamada `.recover\(\)` não reverta\)
1. Não é uma assinatura para nenhuma user operation conhecida, então `SimpleAccount` sempre retornará `SIG\_VALIDATION\_FAILED`
Os implementadores de contas precisam garantir que escrevem suas funções de validação de forma que fornecer uma dummy signature seja possível.
**Isso significa:**
1. Usar `REVERT` somente em assinaturas que não podem ser a dummy signature. Retornar `SIG\_VALIDATION\_FAILED` quando a dummy signature for fornecida.
1. Tomar cuidado para não "encurtar" a falha para a dummy signature. Ou seja, o valor dummy deve percorrer toda a função de validação e usar a quantidade máxima de gas.
1. Na prática, isso significa remover qualquer retorno antecipado. Uma função de validação de conta pode determinar cedo que a assinatura é inválida, mas deve continuar executando a lógica da função e retornar a falha somente no final.
## Como calcular valores dummy de `paymasterAndData`
Os mesmos requisitos acima se aplicam ao campo `paymasterAndData` durante a estimativa de gas: para qualquer implementação de paymaster que dependa dos valores dos campos de gas \(por exemplo, para computar uma assinatura\), precisamos resolver o mesmo problema de fornecer um valor dummy.
### Restrições
Esse `paymasterAndData` dummy tem algumas restrições:
1. O tamanho do valor dummy deve ser igual ao tamanho máximo de `paymasterAndData` e deve conter o número máximo de bytes não zero válidos para a conta.
a. Isso garante que os cálculos de `preVerificationGas` possam contabilizar a contribuição de `paymasterAndData` no pior caso para os custos de overhead de calldata e de entry point.
1. O valor dummy deve, quando fornecido à função de validação do paymaster, causar o uso de gas no pior caso e não deve causar reversão.
1. O valor dummy não deve ser um `paymasterAndData` válido para nenhuma user operation válida.
Por exemplo, um [sponsoring paymaster](https://www.alchemy.com/overviews/what-is-a-paymaster) que depende da verificação de uma assinatura de patrocínio sobre o hash da user operation precisará fornecer um valor dummy de `paymasterAndData` durante a estimativa, com propriedades semelhantes às descritas acima:
1. O valor dummy deve conter um endereço de contrato paymaster válido
1. Tamanho e valores de bytes máximos para os cálculos de `preVerificationGas`
1. Quando fornecido à função de validação do paymaster, deve consumir gas máximo e resultar em um valor de retorno `SIG\_VALIDATION\_FAILED`
Os implementadores de paymaster precisam garantir que escrevem suas funções de validação de forma que fornecer um `paymasterAndData` dummy seja possível.
**Isso significa:**
1. Usar `revert` somente em dados que não podem fazer parte do dummy. Retornar ` SIG\_VALIDATION\_FAILED` em vez disso.
1. Tomar cuidado para não "encurtar" a falha para o dummy. Ou seja, o dummy deve percorrer toda a função de validação e usar a quantidade máxima de gas.
a. Na prática, isso significa remover qualquer retorno antecipado. Uma função de validação de paymaster pode determinar cedo que a assinatura é inválida, mas deve continuar executando a lógica da função e retornar a falha somente no final.
## Transferências de token de gas
A estimativa de `verificationGasLimit` precisa levar em conta o custo de gas de quaisquer transferências de token durante a fase de validação. Muitas [user ops](https://www.alchemy.com/overviews/user-operations) envolvem uma transferência de tokens durante a validação para pagar antecipadamente o gas, com reembolso ao final da operação para qualquer gas que não tenha sido consumido.
Há dois casos:
1. Sem Paymaster - esta é uma transferência de ETH do sender para o contrato entry point.
1. Com um Paymaster - isso pode ser qualquer coisa \(dentro das regras permitidas pela especificação\), mas frequentemente assume a forma de uma transferência de token ERC-20 do sender para o paymaster.
#### O que acontece se a conta não tiver fundos suficientes?
Se `maxFeePerGas` for definido com um valor diferente de zero, a transferência durante a validação vai reverter se a conta não tiver tokens suficientes para pagar a taxa. Isso significa que os usuários precisam financiar suas contas antes de tentar estimar o gas.
**Um fluxo de trabalho desejado que não é possível agora:**
1. Estimar o gas
1. Financiar a conta para o gas
1. Enviar a operação
Uma solução possível aqui é dizer ao usuário para deixar `maxFeePerGas` não definido, ou definido como zero, ao chamar `eth\_estimateUserOperationGas`. No entanto, isso vai definir o custo de gas como zero e, portanto, um valor zero para qualquer transferência de token que precise ocorrer. Em [muitos tipos de conta/paymaster](https://github.com/eth-infinitism/account-abstraction/blob/d1333cf58c17d5cc84e830f3fc3a69081c777979/contracts/core/BaseAccount.sol#L101), um custo de gas zero vai pular a chamada para `transfer`. Isso leva a uma subestimativa de gas quando um `maxFeePerGas` zero é usado.
Outro problema tem a ver com o uso de um `maxFeePerGas` diferente de zero e a tentativa da abordagem de estimativa por busca binária definida em "[Attempt 3: Binary Search](https://www.alchemy.com/blog/erc-4337-gas-estimation)," da primeira parte desta série.
O primeiro passo nessa abordagem é garantir que a operação seja possível usando um valor máximo de gas. O sender pode não ter ativos suficientes para pagar o gas nesse valor máximo, e o bundler nem sempre tem informação suficiente para determinar o saldo do token de taxa \(por exemplo, no caso do paymaster ERC-20\) e assim determinar o limite superior correto.
### Como o bundler da Alchemy resolve a estimativa de gas com a transferência de tokens?
A abordagem adotada pelo Rundler para `eth\_estimateUserOperationGas` é a seguinte:
#### Caso sem paymaster
- O Rundler sempre ignora `maxFeePerGas` e `maxPriorityFeePerGas` e define como 0.
- O Rundler sempre adiciona um valor estático de 10K de gas a `verificationGasLimit` para contabilizar a transferência de depósito de ETH do sender para o entry point.
- Nenhuma mudança do lado do cliente é necessária.
💡 O item \#1 é um desvio da especificação ERC-4337, que estabelece que "gas limits \(and prices\) parameters are optional, but are used if specified"
#### Caso com paymaster
- O Rundler sempre ignora `maxFeePerGas` e `maxPriorityFeePerGas` e define como 0.
- O `verificationGasLimit` do Rundler sempre será subestimado se qualquer lógica do paymaster for condicional ao valor da taxa \(como seria uma transferência ERC-20\)
- Os usuários desses paymasters precisam contabilizar do lado do cliente qualquer gas extra que seria incorrido por uma taxa diferente de zero.
Por exemplo, ao usar um paymaster ERC-20 que faz uma transferência durante a fase de validação, sempre adicione um valor estático de 75K de gas ao valor de retorno de `verificationGasLimit` de `eth\_estimateUserOperationGas`. Isso exige que os clientes estejam cientes do contrato paymaster que estão chamando e tenham conhecimento prévio dos custos de gas subestimados devido a transferências.
💡 O [aa-sdk](https://github.com/alchemyplatform/aa-sdk) da Alchemy permite que o middleware de paymaster [ajuste esse limite de gas de acordo](https://github.com/alchemyplatform/aa-sdk/blob/56bc34be3a50a2709ca546ed90a980f3c489cbbe/packages/core/src/provider/types.ts#L43).
## O que isso significa para os desenvolvedores?
Valores dummy e o problema da transferência de tokens impactam desenvolvedores que constroem contas de contrato inteligente, paymasters e clientes de conta.
### Desenvolvedores de contas de contrato inteligente
Os desenvolvedores de contas de contrato inteligente precisam garantir que um valor de dummy signature possa sempre ser determinado do lado do cliente, com base em como a função de validação da conta vai rodar. Essa assinatura não deve causar reversão e deve resultar em uma estimativa máxima de gas.
### Desenvolvedores de paymaster
Os desenvolvedores de paymaster precisam garantir que um valor dummy de `paymasterAndData` possa sempre ser determinado com base em como a função de validação do paymaster vai rodar. Esse valor não deve causar reversão e deve resultar em uma estimativa máxima de gas.
💡 A Alchemy simplifica isso para os usuários em seu sponsoring paymaster, combinando o processo de estimativa de gas e o processo de simulação via [alchemy_requestGasAndPaymasterAndData](https://www.alchemy.com/docs/wallets/api-reference/gas-manager-admin-api/gas-abstraction-api-endpoints/alchemy-request-gas-and-paymaster-and-data)
### Desenvolvedores de account client
Os desenvolvedores de account client que estão integrando com um paymaster que realiza transferências durante a fase de validação \(ou qualquer outra lógica baseada no valor da taxa\), e que estão usando os endpoints da Alchemy para estimativa, precisam somar qualquer gas potencial associado à transferência ao `verificationGasLimit` retornado pela estimativa.
Fique atento para um próximo post detalhando mais complicações da estimativa de gas do ERC-4337!
🦀
## Continue lendo
Os próximos artigos desta série de 4 partes exploram os desafios de estimar gas em blockchains de layer 2 como Optimism e Arbitrum, além de signature aggregators.
A série se encerra com um passo a passo do processo de estimativa de taxa da user operation. Se você perdeu a primeira parte, saiba como funciona a estimativa de gas do ERC-4337!
- [How ERC-4337 Gas Estimation Works](https://www.alchemy.com/blog/erc-4337-gas-estimation)
- [L2 Gas and Signature Aggregators](https://www.alchemy.com/blog/l2-gas-and-signature-aggregators)
- [User Operation Fee Estimation](https://www.alchemy.com/blog/user-operation-fee-estimation)