Cómo se estiman y cobran las tarifas de las user operations

En nuestra serie de publicaciones sobre estimación de gas en ERC-4337, comenzando con cómo funciona la estimación de gas en ERC-4337, hemos discutido el paso 2 del “Flujo de User Operation”, eth\_estimateUserOperationGas, y sus complicaciones, incluyendo el problema de la transferencia de tokens de gas y los desafíos de estimar el gas en L2. Esta publicación se enfocará en el paso 3 del flujo, detallando cómo se estiman y cobran las tarifas de gas.

Para los fines de esta publicación, asumiremos que estamos trabajando con una chain que soporta EIP-1559. Es necesario entender EIP-1559 como contexto previo para comprender los campos de tarifas en una user operation.

Las user operations tienen los mismos campos de tarifas que las transacciones EIP-1559:

• maxFeePerGas: el monto total máximo que un usuario está dispuesto a pagar (tarifa base + tarifa de prioridad)
• maxPriorityFeePerGas: la tarifa de prioridad máxima o “propina” que el usuario ofrece

El entry point usa la siguiente fórmula para calcular el precio de gas resultante a partir de estos dos campos:

Como se puede ver, maxFeePerGas actúa como un tope absoluto sobre el precio de gas, mientras que maxPriorityFeePerGas actúa como una propina adicional sobre la tarifa base del bloque.

Transacciones de bundle

Cuando los bundlers envían transacciones de bundle al entry point, también están sujetos a un precio de gas derivado de la dinámica de EIP-1559. Los Bundlers definen un maxFeePerGas y un maxPriorityFeePerGas. El precio de gas final se calcula a partir de estos y de la tarifa base del bloque en el que se incluye la transacción.

Los Bundlers envían una transacción a un precio de gas determinado, y luego reciben una compensación a un precio de gas potencialmente distinto, definido por cada user operation en el bundle. Si el precio de gas de la user operation es más alto, el Bundler obtiene una ganancia; de lo contrario, el Bundler incurre en una pérdida en esa user operation. El maxPriorityFeePerGas no es solo una propina para el Bundler, también le ayuda a compensar la propina que tuvo que pagar al block builder para lograr que su transacción de bundle fuera incluida (a menos que el Bundler sea un builder en sí mismo).

¿Cómo se incentiva financieramente a los bundlers?

El bundling puede ser una tarea costosa, principalmente debido a las simulaciones complejas necesarias para garantizar la seguridad del Bundler. Para permitir que los Bundlers recuperen estos costos de cómputo, y para incentivar un mercado saludable de user operations (lo que mejora la UX al reducir el tiempo de inclusión), es necesario que existan incentivos financieros para los Bundlers en forma de ingresos adicionales.

Estos ingresos pueden tomar varias formas: tarifas de prioridad, MEV y acuerdos fuera de la cadena.

1. Tarifas de prioridad

Los Bundlers pueden requerir que los remitentes incluyan en sus operaciones una tarifa de prioridad mayor a la que el Bundler pagó en su propia transacción. Los remitentes que quieran mejorar sus posibilidades de ser incluidos en un bundle durante períodos de alta congestión pueden aumentar su oferta de tarifa de prioridad.

2. Ingresos por MEV

Los Bundlers pueden extraer MEV de las operaciones en el mempool, ya que tienen derechos de ordenamiento dentro del bundle. Son libres de hacer back-run y sandwich de operaciones para quedarse con esta ganancia.

3. Fuera de la cadena

Los Bundlers pueden operar mempools privados (con funciones como protección contra MEV) y hacer acuerdos fuera de la cadena con los remitentes de user operations. Las tarifas se harían cumplir mediante algún mecanismo fuera de la cadena.

Para garantizar una red saludable, argumentaríamos que la opción (1) es necesaria para la mayoría de las user operations.

No todo tipo de user operation permite extraer MEV positivo. Si dependiéramos únicamente de este incentivo, los Bundlers no tomarían la mayoría de las user operations. Los acuerdos fuera de la cadena tienden a centralizar, y muchos usuarios querrán evitar este vector. Esto deja las tarifas de prioridad.

El Rundler de Alchemy actualmente define una tarifa de prioridad dinámica requerida para el bundling. Esta tarifa se basa en las tarifas de red estimadas actuales. Si una user operation ofrece menos que la tarifa de red estimada, más una pequeña propina adicional para el Bundler, no será incluida en un bundle y quedará en el mempool.

¿Cómo estiman los bundlers las tarifas de gas?

Antes del bundling, el Bundler debe realizar su propia estimación de las tarifas que enviará para garantizar la inclusión de la transacción de bundle a través del mercado de bundles. Típicamente, un Bundler construirá para su inclusión en el próximo bloque, y ofrecerá un precio razonable para asegurar su inclusión.

Para estimar las tarifas base, el Bundler puede consultar la red por la tarifa base del bloque actual. Normalmente es conveniente agregar al menos un 25% de margen (el monto máximo en que la tarifa puede aumentar en los siguientes 2 bloques) para asegurar que la transacción no quede atascada.

Para estimar la tarifa de prioridad, el Bundler puede usar eth\_maxPriorityFeePerGas. Al igual que con la tarifa base, es conveniente agregar un porcentaje de margen para asegurar que la transacción sea tomada.

Con estas tarifas estimadas, el Bundler puede entonces consultar el mempool y filtrar las user operations que ofrezcan lo suficiente para ser incluidas (incluyendo la pequeña “propina” del Bundler).

¿Cómo deberían los remitentes estimar las tarifas de las user operations?

Del lado del cliente, los remitentes deben estimar las tarifas necesarias para el bundling. Si las estiman demasiado bajas, su user operation puede quedar atascada en el mempool. Si las estiman demasiado altas, específicamente en el caso de la tarifa de prioridad, pueden estar pagando de más por su inclusión.

Recomendamos el siguiente enfoque al interactuar con Rundler antes de la red p2p:

1. Estimar la tarifa base. Agregar un margen con el que se sientan cómodos para asegurar la inclusión si el precio se mueve en contra. Recomendamos al menos un 25%.
2. Estimar la tarifa de prioridad usando eth\_maxPriorityFeePerGas. Agregar un margen con el que se sientan cómodos. Recomendamos al menos un 10%.
3. Agregar el margen de “propina” del Bundler, dependiente de la red, a la tarifa de prioridad.
4. Sumar la tarifa de prioridad a la tarifa base para obtener maxFeePerGas, donde maxPriorityFeePerGas es la tarifa estimada en el paso 2.

Estimación de tarifas en Arbitrum

El secuenciador de Arbitrum ignora las tarifas de prioridad y eth\_maxPriorityFeePerGas siempre devuelve 0. Para compensar al Bundler, requerimos una tarifa de prioridad que sea un porcentaje fijo de la tarifa base máxima estimada por el Bundler. Actualmente cobramos un 5%.

Estimación de tarifas en Optimism

Optimism tiene un caso especial, descrito en nuestra publicación anterior sobre estimar el gas en L2, que afecta la estimación de tarifas.

En Optimism definimos maxPriorityFeePerGas = l1\_gas / l2\_base\_fee. Sin embargo, dado que en una transacción normal de Optimism las tarifas de prioridad solo aplican al componente de gas L2, estas pueden ser órdenes de magnitud más altas que la tarifa base L2. Por lo tanto, requerimos que la tarifa de prioridad de un bundle sea un porcentaje fijo de la tarifa base estimada. Actualmente cobramos un 5%.

Mempool P2P

Una vez que el mempool P2P esté en funcionamiento, surgirá un mercado separado para las tarifas de las user operations. Esto podría simplificar considerablemente la estimación de tarifas para las user operations. En lugar de realizar cálculos estáticos para la tarifa de prioridad como se describió anteriormente, el usuario podrá usar el historial de tarifas para estimar su oferta. Ya no importará el criterio que un Bundler en particular utilice para elegir user operations, sino solamente que algún Bundler considere que una user operation es lo suficientemente valiosa como para incluirla en un bundle.

Rundler soportará un método rundler\_userOperationFeeHistory (o algo similar, que podría estandarizarse), similar a eth\_feeHistory, que los usuarios podrán consultar para estimar sus ofertas en función de operaciones incluidas en bundles previamente.

🦀

Continúa leyendo

Si te perdiste los primeros tres artículos de esta exploración técnica sobre la estimación de gas en ERC-4337, aprende cómo funciona la estimación de gas en ERC-4337 y cómo superamos las complicaciones para ofrecer estimaciones de gas precisas para las user operations.

• Cómo funciona la estimación de gas en ERC-4337
• Firmas ficticias y transferencias de tokens de gas
• Gas en L2 y agregadores de firmas