Assinaturas dummy e transferências de tokens de gas no ERC-4337

Em 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 um esquema de assinatura EIP-191 sobre o hash, que é validado onchain durante sua função validateUserOp usando a biblioteca ECDSA da 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 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.
2. 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.
3. 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.

Essa dummy signature tem as seguintes propriedades:

1. Tem exatamente o tamanho de uma assinatura ECDSA
2. Tem o número máximo de bytes não zero permitidos em uma assinatura ECDSA
3. É uma assinatura ECDSA válida (para que a chamada .recover\(\) não reverta)
4. 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.
2. 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.
3. 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.
2. 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.
3. O valor dummy não deve ser um paymasterAndData válido para nenhuma user operation válida.

Por exemplo, um sponsoring 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
2. Tamanho e valores de bytes máximos para os cálculos de preVerificationGas
3. 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.
2. 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 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.
2. 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
2. Financiar a conta para o gas
3. 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, 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," 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.

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 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.

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
• L2 Gas and Signature Aggregators
• User Operation Fee Estimation