Firmas dummy y transferencias de gas tokens en ERC-4337

En 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 un esquema de firma EIP-191 sobre el hash que se valida onchain durante su función validateUserOp usando la librería ECDSA de 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 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.
2. 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.
3. 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.

Esta dummy signature tiene las siguientes propiedades:

1. Tiene la longitud exacta de una signature ECDSA
2. Tiene el número máximo de bytes distintos de cero permitidos en una signature ECDSA
3. Es una signature ECDSA válida (para que la llamada .recover\(\) no revierta)
4. 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.
2. 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.
3. 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.
2. 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.
3. El valor dummy no debe ser un paymasterAndData válido para ninguna user operation válida.

Por ejemplo, un sponsoring 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
2. Longitud máxima y valores de byte máximos para los cálculos de preVerificationGas
3. 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.
2. 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 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.
2. 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
2. Fondear la account para el gas
3. 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, 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", 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.

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.

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

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