Los mecanismos de comisión de transacción se han convertido en los modelos fundamentales para entender la intermediación de los productores de bloques entre los usuarios que desean realizar transacciones y “la cadena” (o “el protocolo”) en el que los usuarios realizan transacciones. Dada la capacidad de utilizar parte del suministro proporcionado por la cadena, los productores de bloques deben arbitrar qué usuarios tendrán la capacidad de utilizar el recurso escaso de ejecución en cadena, y a qué costo. En Ethereum, para la cuestión del costo, los productores de bloques están limitados por el mecanismo de comisión EIP-1559, que establece dinámicamente un precio de reserva de bloque a bloque, llamado “tarifa base”. La tarifa base es un precio, expresado por unidades de gas, que una transacción de usuario debe pagar para ser incluida y ejecutada. El usuario puede proporcionar los llamados “honorarios prioritarios” más allá de la tarifa base, para incentivar aún más a los productores de bloques en momentos de congestión.

En esta nota, investiGateamos la cuestión de los mercados de comisiones integrados, es decir, los mercados de comisiones que "viven" dentro de otros mercados de comisiones. Esta cuestión fue discutida en un contexto diferente en un artículo reciente de Maryam Bahrani, Pranav Garimidi y Tim Roughgarden, "Diseño del mecanismo de tarifas de transacción en un mundo post-MEV 9En este documento, los autores modelan el uso de buscadores, intermediando aún más el acceso a la cadena entre los usuarios y los productores de bloques. Los productores de bloques reciben "pistas" de los buscadores, encarnadas por paquetes atómicos de transacciones que deben ser incluidos por la cadena. El mercado de tarifas de los buscadores está impulsado por el objetivo de maximización de una cantidad conocida como MEV, o valor extraíble máximo.

En nuestra configuración, los usuarios desean acceder a la cadena pero no expresan su demanda utilizando transacciones legibles por el protocolo. En lugar de eso, los usuarios producen “operaciones”, que deben ser agrupadas por entidades conocidas como “agrupadores”, quienes luego originan una transacción legible por el protocolo que empaqueta las operaciones juntas hacia la ejecución. De esta manera, para el mecanismo de tarifas EIP-1559, los agrupadores son los usuarios de la cadena, pero los usuarios reales deben obtener primero la inclusión en el grupo de un agrupador antes de poder obtener la inclusión en la cadena. En otras palabras, podemos ver esta configuración como parte de la pregunta más amplia deco-creación de bloques, que surge con (parciales) constructores/buscadores y listas de inclusión.

Nuestra esperanza es que estas dinámicas sean lo más transparentes posible, de manera que no haya una sobrecarga cognitiva adicional o oportunidades para que el usuario sea explotado indebidamente por el agrupador, en comparación con ir directamente a la cadena. Esperamos obtener resultados aún más sólidos, casos en los que los usuarios realmente se beneficien de la intermediación del agrupador, cuando los costos amortizados permitan a los usuarios disfrutar de un mayor bienestar.

Para investiGate la distinción entre los mercados de tarifas directas y sus (sub-)mecanismos integrados, debemos precisar las restricciones económicas a las que se somete un agrupador. En la siguiente sección, ofrecemos un modelo simple de la función de costos del agrupador motivado por la práctica, en particular los agrupadores que participan en el protocolo ERC-4337, que recapitulamos brevemente.

Modelo

Agrupación en ERC-4337

Un usuario que desea realizar alguna actividad en la cadena a través de empaquetadores emite una operación de usuario (UserOp u operación). Este UserOp se emite desde la billetera del usuario, por ejemplo, después de interactuar con una DApp. Una vez que se difunde el UserOp, es posible que algún agrupador que reciba la operación decida incluirlo en un paquete. Un paquete es una metatransacción de "cuenta de propiedad externa" (EOA), que escribe los datos de las UserOps incluidas en su campo bundle.calldata. El empaquetador emite el paquete para su inclusión en un bloque por parte de un productor de bloques (discutiremos la relación entre el empaquetador y el productor de bloques en una nota futura).

Una vez que el paquete se incluye en el bloque, y el bloque se mueve hacia la cadena, el paquete se ejecuta junto con otras transacciones en el bloque. Básicamente, los pasos de ejecución del paquete son los siguientes:

• Pre-verificación: La transacción EOA de un agrupador consumirá 21,000 gas, y la llamada al contrato de Punto de Entrada establecerá variables clave para hacer un seguimiento de la ejecución de las operaciones en el bucle de operaciones.
• Operación bucle 3: Para cada operación incluida en el paquete, se llevan a cabo los siguientes dos pasos:
  • Paso de verificación: UserOps realiza operaciones que contienen un paso de verificación, que está codificado en una "billetera de contrato inteligente" implementada inicialmente por el usuario (durante un UserOp inicial). El paso de verificación puede simplemente verificar una firma, o realizar operaciones más complejas para "otorgar" el derecho para que UserOp proceda con su ejecución. El paso de verificación está medido por op.verificationGasLimit.
  • Paso de ejecución: El núcleo del UserOp, el paso de ejecución realiza la operación descrita en op.callData. Este paso también se mide, utilizando op.callGasLimit.

Como se desprende de la descomposición anterior, el paso de preverificación se ejecuta una vez, ofreciendo la posibilidad de amortizar los costos de preverificación en todos los usuarios incluidos. Cuando se ejecuta el paquete, todos los costos (por ejemplo, block.basefee + tarifas prioritarias pagadas por el agrupador al productor de bloques, incluyéndolos) se cobran al agrupador, quien debe asegurarse de que las operaciones de los usuarios le compensen lo suficiente por los costos incurridos. Precisamos estas afirmaciones en la siguiente sección.

Modelo de mercado de tarifas para paquetes

Intentamos ser consistentes con los modelos clásicos de mercados de tarifas. Un usuario t que desea emitir una operación tiene algún valor vt para la ejecución de la operación. Suponemos que todas las operaciones tienen el mismo tamaño S (es decir, el mismo gas utilizado para las etapas de verificación y ejecución) y, por lo tanto, expresamos todas las cantidades como precios por unidad de gas.

Los usuarios expresan su deseo de ser incluidos emitiendo una oferta bt junto con su operación. Por ahora, no asumimos una gramática específica para que el usuario exprese su oferta de inclusión, por ejemplo, la capacidad de expresar una tarifa máxima y una tarifa de prioridad junto con su operación, como lo harían con EIP-1559. Las operaciones de los usuarios se recopilan en un mempool M, que representa el estado pendiente de estas operaciones hasta su inclusión.

El mercado de tarifas EIP-1559 expone un precio de reserva r conocido como "tarifa base", que los agrupadores deben asumir cuando se ejecuta su paquete. Si el paquete contiene n operaciones, el agrupador debe gastar al menos n × S × r. Además, dado que el paquete consume "gas de preverificación", digamos, una cantidad F, el agrupador también pagará F × r

. Las operaciones incluidas en el paquete son proporcionadas por el conjunto B.

Funciones de costo del empaquetador

Ahora consideramos los costos incurridos por los agrupadores para la inclusión de sus paquetes en el bloque.

Función de coste en cadena: Un agrupador emitiendo el paquete B cuando la tarifa base es r gasta un costo:

El problema del agrupador refleja el problema del productor de bloques expresado en[Roughgarden 2021] 3. Allí, el productor de bloques tuvo que asegurar la provisión de algún valor μ que la compensara por el costo de incluir una transacción adicional en su bloque (por ejemplo, μ puede compensar la carga adicional del bloque, que retrasa su propagación y aumenta así el riesgo de reorganización). El mercado de tarifas a nivel de bloque debe asegurar entonces que el productor de bloques sea compensado al menos por el costo total n × S × μ, si el productor de bloques incluye n transacciones en su bloque. El mercado de tarifas a nivel de agrupador requerirá compensar al menos al agrupador por costos exógenos

Con-chain(B,r) que incurren en el mercado de tarifas más grande en el que están integrados.

ERC-4337 ofrece la posibilidad de amortizar los costos más allá de compartir los costos de gas de verificación previa. En caso de que todas las operaciones empleen el mismo esquema de firma para su fase de verificación, las firmas de estas operaciones podrán ser agregado 2por el agrupador, de modo que en lugar de verificar n firmas en la cadena, se puede verificar una única firma. En este caso, la función de costo del agrupador deberá tener en cuenta los costos fuera de la cadena que el agrupador incurre al realizar la agregación. A continuación, asumimos que dichos costos son lineales en el número de operaciones, una suposición similar a [Wang et al., 2024] 2, a un costo marginal ω.

También tenemos en cuenta el consumo reducido de gas de cada operación, debido a los ahorros por la agregación. Cuando se agregan, las operaciones no necesitan publicar su firma, pero sí requieren una operación adicional de emparejamiento. En cadenas donde el costo de calldata es caro, pero las operaciones de emparejamiento/cómputo son baratas, la agregación proporciona ahorros por operación. En este caso, denotamos por S' < S el tamaño reducido de una transacción. También necesitamos tener en cuenta el aumento del uso de gas de preverificación F' > F, que ahora contiene la publicación y verificación de la única firma agregada en cadena.

Función de costo agregada: Un agrupador que emite el paquete B con firmas agregadas cuando la tarifa base es r incurre en un costo:

En esta nota, no profundizaremos más, pero uno también puede considerar los costos de publicación de datos que un agrupador puede necesitar gastar cuando su paquete se resuelva en un rollup. Sugerimos dos formas de modelar esto y dejamos esta pregunta para trabajos futuros:

• La propia persona que realiza el empaquetado es responsable de la publicación de datos (por ejemplo, como un secuenciador) y, por lo tanto, necesita obtener de los usuarios la cantidad necesaria de fondos para pagar los eventuales costos de publicación de datos.
• O el mercado de tarifas a nivel de paquete está integrado en un mercado de tarifas a nivel de lote más grande, a través del cual el rollup expone a los usuarios del rollup (incluido el agrupador) la cantidad que deben pagar debido a la congestión (por ejemplo, una tarifa base) y los costos de publicación de datos eventuales. En este caso, el rollup es responsable de equilibrar sus propios costos futuros con sus ingresos actuales.

Revisando las cantidades del mercado de tarifas

Ahora podemos expresar formalmente los conceptos relevantes para el mercado de tarifas a nivel de paquete, derivándolos directamente de la literatura anterior, teniendo en cuenta la incrustación.

Regla de asignación a nivel de paquete: Una asignación (a nivel de paquete) x decide el conjunto de operaciones de usuario que el agrupador incluye en su paquete, dada la mempool actual M y la tarifa base r.

Regla de pago a nivel de paquete: Dado el conjunto de operaciones seleccionadas B, una regla de pago asigna a cada usuario incluido una tarifa:

Función de utilidad del usuario:

En principio, podríamos permitir la existencia de una regla de quemado qt(B) que exprese el hecho de que el agrupador no pueda recibir la totalidad de todos los pagos de usuarios incluidos. Sin embargo, no lo consideramos en esta nota.

(Miopic) función de utilidad de agrupación:

Un TFM de nivel de paquete (x, p) es compatible con incentivos para los agrupadores miope (MBIC) si, para cada Mempool M y tarifa base r, un agrupador miope maximiza su utilidad siguiendo la sugerencia de la regla de asignación x (es decir, estableciendo B = x (M, r)).

Formación de múltiples paquetes

En la sección anterior, solo hemos considerado la posibilidad de que el agrupador emita un solo paquete. Sin embargo, puede que estemos interesados en la posibilidad de que el agrupador haga más de un paquete con las operaciones disponibles en el mempool. Dado el mempool M, dejemos que P(M) represente el conjunto de particiones del mempool, asignando cada operación a un solo paquete (podemos asumir que para cada partición, hay un conjunto indexado como 0 que contiene todas las operaciones no asignadas a un paquete para su inclusión). La regla de asignación luego devuelve el índice del conjunto en la partición al que se asigna la operación.

Podemos escribir el conjunto de paquetes emitidos por la partición x(M,β) como B(x(M,r)). Intuitivamente, estos paquetes se componen de las operaciones que no pertenecen al conjunto indexado 0. Dado un conjunto de paquetes B, la regla de pago es entonces:

La función de utilidad del usuario se convierte en:

y la función de utilidad del agrupador se convierte en:

El juego de agrupador

La inclusión de transacciones en bloques debe remunerar alguna cantidad μ a los productores de bloques, que se supone que es lineal en el tamaño de la transacción en por ejemplo, [Roughgarden, 2021] 3. Esta cantidad denota el costo de oportunidad para el productor de bloque de agregar una transacción adicional a su bloque, por ejemplo, aumentando su retraso de chismes y, por lo tanto, aumentando sus posibilidades de que el bloque sea reorganizado. En la prueba de participación, aunque el cronograma del protocolo permite suficiente tiempo para propaGate un bloque completo, juegos de tiempohan inducido dinámicas de propagación de “último segundo” que una vez más han hecho relevante este parámetro μ.

En cualquier caso, podemos observar que el problema de compartir costos a nivel de bloque y a nivel de paquete son muy diferentes. A nivel de bloque, una transacción no necesita saber qué más está sucediendo dentro del bloque para idear su oferta de inclusión según EIP-1559 (puede querer saber qué está sucediendo con respecto a MEV [Bahrani et al., 2024] 9, pero por ahora lo consideraremos como un problema separado). A nivel de paquete, los costos generales del paquete ya no son lineales en el número de transacciones, sino que un costo fijo puede ser amortizado por muchas transacciones. Además, si el costo de agregación de las operaciones del usuario no es lineal en el número de transacciones (por ejemplo, algunas pruebas son efectivamente sub-lineales en el tamaño que se está probando), ofreciendo la posibilidad de amortizar el costo total en muchos usuarios.

Esto lleva al siguiente juego: El integrador desea que los usuarios coloquen sus ofertas como si estuvieran pujando por el peor caso, donde el usuario está solo en el paquete y debe compensar por sí mismos el gas completo F de sobrecarga. En la práctica, el usuario se enfrentaría al problema de establecer tres parámetros relevantes en su operación:

• op.maxPriorityFeePerGas y op.maxFeePerGas pueden establecerse de acuerdo con la heurística que un usuario usaría bajo EIP-1559, es decir, dado cierta cantidad estimada de gas que su operación planea consumir, el usuario establecería estos atributos para calibrar cuánto está dispuesto a pagar en el peor de los casos (maxFee) y cuánto está dispuesto a agregar para pagar al productor de bloques eventual (maxPriority). ¿Pero cómo debería el usuario estimar el gas?
• op.preVerificationGas es un atributo de UserOperation que debe establecerse para indicar la cantidad de "gas adicional" que la operación del usuario planea consumir. En nuestro modelo, dejamos
• F denota este “gasto fijo general”. Si n usuarios estuvieran incluidos en el paquete, cada usuario debería establecer preVerificationGas = F / n. Sin embargo, si el usuario prepara su operación teniendo en cuenta un escenario de peor caso, establecerá preVerificationGas = F.

preVerificationGas es entonces el vector principal a través del cual los usuarios median su oferta e intentan contabilizar la amortización de los costes por parte del empaquetador. Supongamos que n usuarios llegan al mercado con sus operaciones, y todos son convencidos por el empaquetador para ofertar en el peor de los casos de estar solos en el paquete. También supondremos que los usuarios están estableciendo su maxPriorityFeePerGas en cero por el bien de este ejemplo. Entonces, todos estos n usuarios configuran preVerificationGas = F, y el empaquetador puede generar un paquete que los remunera con:

mientras deben incurrir en un costo:

una vez que publican el paquete que agrupa todas las n operaciones juntas en un bloque. Esto le proporciona al agrupador una ganancia π = (n−1)×F×r.

Esta situación puede ser representada por un juego de dos etapas, donde los usuarios primero realizan sus operaciones de usuario, y el agrupador posteriormente decide agruparlas. Asumimos que los usuarios no poseen información sobre la cantidad actual de usuarios pendientes, y por lo tanto no pueden estimar la verdadera capacidad del agrupador para amortizar sus costos fijos.

En la primera etapa, los usuarios envían sus operaciones, que se comprometen con sus atributos como preVerificationGas. En la segunda etapa, el agrupador, después de recibir todas las transacciones de usuarios, decide generar un paquete o conjunto de paquetes. Curiosamente, incluso si los usuarios saben cuántos otros usuarios jugarán en la primera etapa, es decir, incluso si n es un conocimiento común entre todos los usuarios, el agrupador puede obligar a los usuarios a establecer el peor caso de preVerificationGas = F amenazando con jugar.

, es decir, amenazando con mantener a cada usuario en su propio paquete separado y cobrándoles la cantidad máxima de gas F.

Tenga en cuenta que esta amenaza puede que no sea creíble, ya que los usuarios esperarían que el agrupador prefiera jugar

, es decir, producir un solo paquete con todas las operaciones incluidas allí, logrando π. Sin embargo, los usuarios pueden no tener acceso al valor real de n y, por lo tanto, no pueden establecer su preVerificationGas de manera que obligue al agrupador a agrupar idealmente todos ellos.

Caso ideal: los costos se dividen entre los usuarios en el paquete. Caso pesimista: los usuarios pagan de más y los costos no se dividen.731×755 77.6 KB

Una extensión de este modelo puede considerar el caso bayesiano, donde los usuarios tienen acceso a una distribución sobre n, es decir, pueden anticipar que algunos valores aleatorios n usuarios aparezcan en cualquier paso de tiempo, de acuerdo con alguna distribución (por ejemplo, llegadas de Poisson), incluso si no conocen de antemano el resultado de la variable aleatoria. Esto puede llevar a resultados ineficientes, como muestra el siguiente ejemplo:

Alice espera que aparezcan otros 9 usuarios además de ella, por lo que establece su preVerificationGas en 1, ya que sabe que F = 10. El valor de Alice y el valor de todos los demás usuarios es compatible con la configuración de preVerificationGas = 3, pero intenta pagar la menor cantidad posible por su inclusión. Resulta que solo aparecen 5 usuarios en el mercado, que también han configurado su preVerificationGas en 1. El empaquetador no será compensado por F = 10 unidades de gas, por lo que el empaquetador no genera un paquete y los usuarios reciben 0 utilidad. Obviamente, esto no es óptimo, ya que los usuarios podrían haber configurado preVerificationGas = 2, por ejemplo, y recibir 1 utilidad (el preVerificationGas máximo que estaban dispuestos a establecer menos el preVerificationGas real que pagaron para ser incluidos).

Trabajo futuro

Como muestra el juego del agrupador, el usuario que desea ser incluido por el agrupador se enfrenta a un problema de asignación. En la próxima nota, abordaremos diferentes enfoques para recuperar una “buena experiencia de usuario” para evitar que paguen en exceso a un agrupador que está mejor informado sobre la demanda de su capacidad de agrupación. La próxima exploración requerirá una comprensión de la estructura del mercado que une a los usuarios, los agrupadores y los constructores/productores de bloques.

Renuncia:

1. Este artículo es una reimpresión de [Gate]ethresear], Todos los derechos de autor pertenecen al autor original [DavideRezzoli]. Si hay objeciones a esta reimpresión, por favor contacte alGate Learnequipo, y ellos lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione lo contrario, está prohibido copiar, distribuir o plagiar los artículos traducidos.