---
title: "Firmas dummy y transferencias de gas tokens en ERC-4337"
description: "Aprende a obtener los campos preVerificationGas y verificationGasLimit durante el proceso de estimación de gas de la user operation, usando un valor dummy de firma y de paymasterAndData."
---
# Firmas dummy y transferencias de gas tokens en ERC-4337
En [ERC-4337 Gas Estimation](https://www.alchemy.com/blog/erc-4337-gas-estimation) hablamos sobre cómo funciona el gas en ERC-4337 y nuestro método para la estimación de gas. Con este método, deberíamos poder proporcionar a los usuarios valores precisos para enviar sus user operations. Sin embargo, no siempre es tan simple.
Veamos algunos otros problemas que complican la estimación de gas en ERC-4337.
## ¿Qué son los valores dummy de `signature`?
En la mayoría de las implementaciones de smart contract accounts, el campo signature se calcula off-chain hasheando una user operation y firmando ese hash usando algún esquema de firma \(siendo ECDSA el más popular\). Esta firma se verifica onchain por el contrato de la account durante la fase de verificación.
Por ejemplo, `SimpleAccount` [usa](https://github.com/eth-infinitism/account-abstraction/blob/d1333cf58c17d5cc84e830f3fc3a69081c777979/contracts/samples/SimpleAccount.sol#L93) un esquema de firma [EIP-191](https://eips.ethereum.org/EIPS/eip-191) sobre el hash que se valida onchain durante su función `validateUserOp` usando la [librería ECDSA](https://docs.openzeppelin.com/contracts/2.x/api/cryptography#ECDSA-toEthSignedMessageHash-bytes32-) de [OpenZeppelin](https://www.alchemy.com/dapps/openzeppelin).
Esta firma debe calcularse después de estimar el gas, ya que esos campos están incluidos en el hash.
Sin embargo, hay partes del paso de estimación de gas que requieren que el campo signature esté completo: `preVerificationGas` y `verificationGasLimit `.
### preVerificationGas
En la sección sobre la estimación de `preVerificationGas` en la primera parte de esta serie, hablamos de tres cálculos que usa el bundler para contabilizar el gas no medido.
Nótese que los pasos 2 y 3 \(calcular la parte del costo de gas de calldata que corresponde a la user op y la parte del overhead de gas de ejecución que corresponde a la user op\) dependen directamente de la longitud y el contenido de una user operation, incluyendo el campo `signature`.
### verificationGasLimit
Casi todas las implementaciones útiles de smart contract accounts requerirán algún tipo de verificación de firma. ¡Este gas debe estimarse! Este proceso de estimación no puede revertir, o de lo contrario no se podría implementar el verification gas.
¿Cómo elegimos qué firma usar?
## Cómo calcular valores dummy signature
Para resolver estos problemas, muchos [bundlers de ERC-4337](https://www.alchemy.com/overviews/what-is-a-bundler) usan una "Dummy Signature" que debe ser proporcionada por quien llama a `eth\_estimateUserOperationGas` según el tipo específico de account.
### Restricciones
Esta dummy signature tiene algunas restricciones:
1. La longitud del valor dummy debe ser igual a la longitud máxima de la signature y debe contener el número máximo de bytes distintos de cero válidos para la account.
a. Esto asegura que los cálculos de `preVerificationGas` puedan contabilizar la contribución de la signature en el peor caso a los costos de overhead de calldata y del entry point.
1. El valor dummy debe, al proporcionarse a la función de validación de la account, provocar el uso de gas en el peor caso y no debe provocar un revert.
1. El valor dummy no debe ser una signature válida para ninguna user operation válida.
Puede encontrarse un valor dummy `signature` para `SimpleAccount` en nuestra documentación del método [eth_estimateUserOperationGas](https://www.alchemy.com/docs/wallets/api-reference/bundler-api/bundler-api-endpoints/eth-estimate-user-operation-gas).
**Esta dummy signature tiene las siguientes propiedades:**
1. Tiene la longitud exacta de una signature ECDSA
1. Tiene el número máximo de bytes distintos de cero permitidos en una signature ECDSA
1. Es una signature ECDSA válida \(para que la llamada `.recover\(\)` no revierta\)
1. No es una signature para ninguna user operation conocida, así que `SimpleAccount` siempre devolverá `SIG\_VALIDATION\_FAILED`
Los implementadores de accounts deben asegurarse de escribir sus funciones de validación de manera que sea posible proporcionar una dummy signature.
**Esto significa:**
1. Usar `REVERT` únicamente en signatures que no puedan ser la dummy signature. Devolver `SIG\_VALIDATION\_FAILED` cuando se proporcione la dummy signature.
1. Tener cuidado de no hacer "short-circuit" del fallo para la dummy signature. Es decir, el valor dummy debe recorrer toda la función de validación y usar la cantidad máxima de gas.
1. En la práctica, esto significa eliminar cualquier retorno anticipado. Una función de validación de account puede determinar tempranamente que la signature es inválida, pero debe seguir ejecutando la lógica de la función y devolver el fallo al final.
## Cómo calcular valores dummy de `paymasterAndData`
Los mismos requisitos anteriores aplican al campo `paymasterAndData` durante la estimación de gas: para cualquier implementación de paymaster que dependa de los valores de los campos de gas \(por ejemplo, para calcular una signature\), debemos resolver el mismo problema de proporcionar un valor dummy.
### Restricciones
Este `paymasterAndData` dummy tiene algunas restricciones:
1. La longitud del valor dummy debe ser igual a la longitud máxima de `paymasterAndData` y debe contener el número máximo de bytes distintos de cero válidos para la account.
a. Esto asegura que los cálculos de `preVerificationGas` puedan contabilizar la contribución de `paymasterAndData` en el peor caso a los costos de overhead de calldata y del entry point.
1. El valor dummy debe, al proporcionarse a la función de validación del paymaster, provocar el uso de gas en el peor caso y no debe provocar un revert.
1. El valor dummy no debe ser un `paymasterAndData` válido para ninguna user operation válida.
Por ejemplo, un [sponsoring paymaster](https://www.alchemy.com/overviews/what-is-a-paymaster) que depende de la verificación de una signature de patrocinio sobre el hash de la user operation necesitará proporcionar un valor dummy de `paymasterAndData` durante la estimación con propiedades similares a las descritas anteriormente:
1. El valor dummy debe contener una dirección de contrato de paymaster válida
1. Longitud máxima y valores de byte máximos para los cálculos de `preVerificationGas`
1. Al proporcionarse a la función de validación del paymaster, debe consumir el máximo de gas y resultar en un valor de retorno `SIG\_VALIDATION\_FAILED`
Los implementadores de paymasters deben asegurarse de escribir sus funciones de validación de manera que sea posible proporcionar un `paymasterAndData` dummy.
**Esto significa:**
1. Usar `revert` únicamente en datos que no puedan formar parte del dummy. Devolver ` SIG\_VALIDATION\_FAILED` en su lugar.
1. Tener cuidado de no hacer "short-circuit" del fallo para el dummy. Es decir, el dummy debe recorrer toda la función de validación y usar la cantidad máxima de gas.
a. En la práctica, esto significa eliminar cualquier retorno anticipado. Una función de validación de paymaster puede determinar tempranamente que la signature es inválida, pero debe seguir ejecutando la lógica de la función y devolver el fallo al final.
## Transferencias de gas token
La estimación de `verificationGasLimit` debe tener en cuenta el costo de gas de cualquier transferencia de tokens durante la fase de validación. Muchas [user ops](https://www.alchemy.com/overviews/user-operations) implican una transferencia de tokens durante la validación para pagar el gas por adelantado, con un reembolso al final de la operación por cualquier gas que no se haya consumido.
Hay dos casos:
1. Sin Paymaster: esta es una transferencia de ETH del sender al contrato entry point.
1. Con un Paymaster: esto puede ser cualquier cosa \(dentro de las reglas permitidas por la especificación\), pero a menudo toma la forma de una transferencia de token ERC-20 del sender al paymaster.
#### ¿Qué sucede si la account no tiene fondos suficientes?
Si `maxFeePerGas` se establece con un valor distinto de cero, la transferencia durante la validación revertirá si la account no tiene suficientes tokens para pagar la fee. Esto significa que los usuarios deben fondear sus accounts antes de intentar estimar el gas.
**Un flujo de trabajo deseado que actualmente no es posible:**
1. Estimar el gas
1. Fondear la account para el gas
1. Enviar la operación
Una posible solución aquí es indicarle al usuario que deje `maxFeePerGas` sin establecer, o en cero, al llamar a `eth\_estimateUserOperationGas`. Sin embargo, esto hará que el costo de gas sea cero y, por lo tanto, un valor de cero para cualquier transferencia de token que deba ocurrir. En [muchos tipos de account/paymaster](https://github.com/eth-infinitism/account-abstraction/blob/d1333cf58c17d5cc84e830f3fc3a69081c777979/contracts/core/BaseAccount.sol#L101), un costo de gas de cero omitirá la llamada a `transfer`. Esto lleva a una subestimación de gas cuando se usa un `maxFeePerGas` igual a cero.
Otro problema tiene que ver con usar un `maxFeePerGas` distinto de cero e intentar el enfoque de estimación por búsqueda binaria definido en "[Attempt 3: Binary Search](https://www.alchemy.com/blog/erc-4337-gas-estimation)", de la primera parte de esta serie.
El primer paso en ese enfoque es asegurarse de que la operación sea posible usando un valor de gas máximo. El sender puede no tener suficientes activos para pagar el gas en ese valor máximo, y el bundler no siempre tiene suficiente información para determinar el balance del fee token \(por ejemplo, en el caso de un paymaster ERC-20\) y así determinar el límite superior correcto.
### ¿Cómo resuelve el bundler de Alchemy la estimación de gas con la transferencia de tokens?
El enfoque adoptado por Rundler para `eth\_estimateUserOperationGas` es el siguiente:
#### Caso sin paymaster
- Rundler siempre ignorará `maxFeePerGas` y `maxPriorityFeePerGas` y los establecerá en 0.
- Rundler siempre añadirá un valor estático de 10K de gas a `verificationGasLimit` para contabilizar la transferencia del depósito de ETH del sender al entry point.
- No se requieren cambios del lado del cliente.
💡 El punto #1 es una desviación de la especificación ERC-4337, que establece que "los parámetros de límites de gas \(y precios\) son opcionales, pero se usan si se especifican"
#### Caso con paymaster
- Rundler siempre ignorará `maxFeePerGas` y `maxPriorityFeePerGas` y los establecerá en 0.
- El `verificationGasLimit` de Rundler siempre se subestimará si alguna lógica del paymaster depende del valor de la fee \(como sería el caso de una transferencia ERC-20\)
- Los usuarios de estos paymasters deben contabilizar del lado del cliente cualquier gas adicional que se genere por una fee distinta de cero.
Por ejemplo, si se usa un paymaster ERC-20 que realiza una transferencia durante la fase de validación, siempre hay que añadir un valor estático de 75K de gas al valor de retorno de `verificationGasLimit` de `eth\_estimateUserOperationGas`. Esto requiere que los clientes conozcan el contrato de paymaster al que están llamando y tengan conocimiento previo de los costos de gas subestimados debido a las transferencias.
💡 El [aa-sdk](https://github.com/alchemyplatform/aa-sdk) de Alchemy permite que el middleware del paymaster [modifique este límite de gas en consecuencia](https://github.com/alchemyplatform/aa-sdk/blob/56bc34be3a50a2709ca546ed90a980f3c489cbbe/packages/core/src/provider/types.ts#L43).
## ¿Qué significa esto para los desarrolladores?
Los valores dummy y el problema de la transferencia de tokens afectan a los desarrolladores que construyen smart contract accounts, paymasters y account clients.
### Desarrolladores de smart contract accounts
Los desarrolladores de smart contract accounts deben asegurarse de que siempre sea posible determinar un valor de dummy signature del lado del cliente, según cómo vaya a ejecutarse la función de validación de la account. Esta signature no debe provocar un revert y debe resultar en una estimación de gas máxima.
### Desarrolladores de paymasters
Los desarrolladores de paymasters deben asegurarse de que siempre sea posible determinar un valor dummy de `paymasterAndData` según cómo vaya a ejecutarse la función de validación del paymaster. Este valor no debe provocar un revert y debe resultar en una estimación de gas máxima.
💡 Alchemy simplifica esto para los usuarios en su sponsoring paymaster combinando el proceso de estimación de gas y el proceso de simulación mediante [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)
### Desarrolladores de account clients
Los desarrolladores de account clients que se integran con un paymaster que realiza transferencias durante la fase de validación \(o cualquier otra lógica basada en el valor de la fee\), y que usan los endpoints de Alchemy para la estimación, deben añadir cualquier gas potencial asociado con la transferencia al `verificationGasLimit` devuelto por la estimación.
¡Estén atentos a una próxima publicación que describirá más complicaciones de la estimación de gas en ERC-4337!
🦀
## Continuar leyendo
Los siguientes artículos de esta serie de 4 partes exploran los desafíos de estimar el gas en blockchains de layer 2 como Optimism y Arbitrum, y los signature aggregators.
La serie concluye con un recorrido por el proceso de estimación de la fee de las user operations. Si te perdiste la primera parte, ¡aprende cómo funciona la estimación de gas en 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)