Introducción

En esta publicación, presentamos MEV impuestos, un mecanismo que las aplicaciones arbitrarias pueden usar para capturar sus propios MEV.

Este mecanismo podría usarse hoy en día en OP Stack L2 como OP Mainnet, Base y Blast, porque los proponentes de bloques en esas cadenas siguen un conjunto de reglas que llamamos orden de prioridad competitivo.

Para implementar un impuesto MEV en una de estas cadenas, un contrato inteligente cobra una tarifa que es una función de la tarifa de prioridad de la transacción. Mostramos que si una aplicación cobra a los buscadores un impuesto MEV de (digamos) $ 99 por cada $ 1 de tarifa de prioridad, puede capturar el 99% del MEV competitivo para esa transacción.

Los impuestos MEV son una técnica simple que abre un vasto espacio de diseño. Puede pensar en ellos como permitir que cualquier aplicación en la cadena ejecute su propia subasta MEV personalizada, sin necesidad de ninguna infraestructura fuera de la cadena propia, simplemente conectándose a una sola subasta compartida ejecutada por el proponente de bloques.

Mostramos cómo los impuestos MEV podrían usarse para resolver tres problemas principales en la investigación MEV:

• Routers de intercambio descentralizado (DEX) que optimizan el precio recibido por el DEX
• Creadores de mercado automatizados (AMM) que minimizan la pérdida frente al reequilibrio (LVR) experimentada por los proveedores de liquidez
• Carteras que permiten a sus usuarios capturar cualquier MEV "backrunning" creado por sus transacciones

Pero hay una trampa. Los impuestos MEV solo funcionan si los proponentes de bloques siguen estrictamente las reglas de orden de prioridad competitiva, que incluyen clasificar las transacciones por tarifa de prioridad sin censurar, mirar o retrasar ninguna. Si los proponentes de bloques se desvían de esas reglas, pueden evadir los impuestos MEV para capturar el valor por sí mismos. Hoy en día, por lo tanto, MEV impuestos dependen de la confianza en los secuenciadores L2, y probablemente no funcionarían en absoluto en Ethereum L1, donde la construcción de bloques está dominada por una subasta de constructores competitiva que maximiza los ingresos para el proponente.

Aún así, el poder y la flexibilidad de los impuestos MEV sugieren que el pedido prioritario puede ser la opción correcta para las plataformas que pueden proporcionarlo hoy. Y la relativa simplicidad del orden de prioridad competitivo sugiere que puede haber una forma viable de aplicarlo de forma descentralizada, sin tener que confiar en un solo secuenciador. Esperamos que esta publicación motive a seguir trabajando en ese problema.

Ordenamiento prioritario

Cuando alguien envía una transacción en una Ethereum L1 o L2, especifica una tarifa de prioridad, que paga al proponente de bloques.1 Puedes imaginar que esto se especifica como priorityFeePerGas, un número que se multiplica por el gas utilizado en la transacción para obtener builderPriorityFee, el pago total en ETH. 2

No hay ninguna regla en el Ethereum protocolo que diga que las transacciones en un bloque deben ordenarse con avidez descendiendo priorityFeePerGas. Sin embargo, esa es una forma popular de construir bloques, por ejemplo, es el algoritmo predeterminado utilizado por los secuenciadores de OP cadenas Stack, así como geth y reth. El orden de prioridad no solo permite a los transactores expresar de manera eficiente la urgencia de sus transacciones, sino que también canaliza naturalmente ciertos tipos de MEV al proponente de bloques.

Esto sucede porque el orden de prioridad convierte la competencia por MEV en una subasta gas priority. Cuando existe la oportunidad de beneficiarse de la interacción con la cadena, como arbitrar un AMM contra un intercambio centralizado, los buscadores compiten para reclamar esa oportunidad primero. Si la cadena utiliza el orden de prioridad para determinar la inclusión y el orden de las transacciones, los buscadores compiten estableciendo tarifas de alta prioridad en sus transacciones.

En un escenario competitivo donde las ganancias libres de riesgo se reducen a cero, el buscador ganador debería terminar pagando el monto total de MEV en tarifas de prioridad. 3 Por lo tanto, si hay 100 ETH de ganancias que se pueden obtener al interactuar con un contrato, la primera transacción que lo reclame establecerá una tarifa de prioridad de 100 ETH. (Discutimos algunas advertencias a esto en la sección Limitaciones).

MEV taxes

Supongamos que un contrato inteligente quiere capturar el MEV de cualquier transacción que interactúe con él. Existe una vasta biblioteca de investigación sobre diferentes formas específicas de la aplicación en que los contratos inteligentes podrían intentar capturar su propio MEV.

Pero, de hecho, no necesariamente tenemos que saber nada sobre la aplicación. Si sabemos que el bloque se está construyendo a través de un orden de prioridad competitivo, entonces tenemos una señal universal para la cantidad de MEV en la transacción: la tarifa de prioridad.

Proponemos que el contrato inteligente pueda considerar la tarifa de prioridad de la transacción y cobrar su propia tarifa como una función creciente de la misma. Por ejemplo, el contrato podría requerir que quien lo llame transfiera applicationPriorityFee = 99 * proposerPriorityFee en ETH al contrato. 4

Esta nueva tarifa es pagada por el buscador que envía la transacción, por lo que afecta el comportamiento de ese buscador. Si hay 100 MEV en una oportunidad, la transacción ganadora ahora solo establecerá una tarifa de prioridad de 1 ETH, ya que eso resultará en un pago total de 100 ETH (1 ETH al proponente del bloque y 99 ETH al contrato inteligente). Cualquier comisión de mayor prioridad haría que la transacción no fuera rentable; Cualquier tarifa de prioridad más baja resultaría en la pérdida de la oportunidad frente a un competidor que estableciera una tarifa más alta. Esto significa que el contrato inteligente ha capturado el 99% del MEV en la transacción.

Llamamos a esta tarifa adicional impuesta por el contrato inteligente un impuesto MEV. Los impuestos MEV permiten que una aplicación secuestre el pedido prioritario para su propio beneficio, lo que le permite recuperar MEV para sus usuarios en lugar de filtrarlo al proponente del bloque.

Si esta tarifa aumenta lo suficientemente rápido como una función de priorityFeePerGas, entonces solo se acumulará una cantidad insignificante de MEV para el proponente. Dado que priorityFeePerGas se denomina en wei (una milmillonésima parte de una milmillonésima parte de un ETH), tenemos mucha precisión con la que trabajar. Por ejemplo, tan largo como el impuesto MEV es lo suficientemente sensible como para que una prioridad FeePerGas de 50,000 resultaría en un impuesto prohibitivamente alto, entonces el pago total al proponente sería inferior a $ 0.01. 5

Sin embargo, hay una advertencia importante. Como se discutió en la sección Limitaciones, los impuestos MEV solo funcionan si los proponentes de bloques siguen ciertas reglas, lo que llamamos "orden de prioridad competitiva", en lugar de desviarse de esas reglas para maximizar sus propios ingresos. Hacer cumplir estas reglas de una manera poco confiable es un problema abierto.

Captura de MEV de una sola aplicación

Aquí esbozamos cómo, en una cadena que está garantizada para usar un orden de prioridad competitivo para la construcción de bloques, los impuestos MEV podrían usarse para mitigar tres problemas importantes en MEV: permitir que las interfaces DEX mejoren la ejecución comercial para los intercambiadores, permitir que los AMM reduzcan las pérdidas por arbitraje para sus LP y permitir que las billeteras reduzcan MEV fuga para sus usuarios vendiendo el derecho a ejecutar el usuario.

DEX routers En los

protocolos de enrutamiento de DEX basados en la intención, como UniswapX y 1inch Fusion, un usuario (Alice) firma una intención de intercambio, y los buscadores compiten para enrutar o completar esa intención al mejor precio posible para Alice.

Las versiones actuales de UniswapX utilizan dos mecanismos para llevar a cabo esa competencia: una subasta holandesa en la que el precio límite de Alice cambia con el tiempo hasta que un buscador lo llena, y una subasta inicial de solicitud de cotización (RFQ) fuera de la cadena para establecer el precio inicial de esa subasta holandesa.

En una plataforma que garantice pedidos prioritarios competitivos, UniswapX podría reemplazarlos con un mecanismo único: un impuesto MEV. Podría implementar esto haciendo que el usuario firme un orden que puede ser completado inmediatamente por cualquier persona, pero con un precio de ejecución que se establece en función de la prioridad de la transacción.

Por ejemplo, si Alice tiene una orden UniswapX para vender 1 ETH, podría definir que el precio de ejecución de la orden sea minimumPrice + ($0.01 * priorityFeePerGas). minimumPrice podría ser algún valor fijo que espera que sea significativamente más bajo que el precio actual.

Los buscadores competirían para llenar el orden de Alice mediante el envío de transacciones. Cualquiera que sea la transacción que tenga la tarifa de prioridad más alta y no se revierta podría completar el orden, lo que debería garantizar que el intercambiador obtenga el mejor precio que los buscadores puedan encontrar. (Algunas excepciones a esto se analizan en la sección Limitaciones).

Si el precio mínimo de Alice es de $ 3,000 y el precio actual de ETH es de $ 3,500, priorityFeePerGas en la transacción ganadora sería de aproximadamente 50,000. (Observe que en una transacción que cuesta 200,000 gases, esto resultará en un pago de solo alrededor de 10 mil millones de wei, alrededor de $ 0.000035, al proponente del bloque).

Esto tiene algunos beneficios potenciales sobre los mecanismos existentes utilizados en UniswapX.

Los pedidos que utilizan impuestos MEV podrían completarse más rápido y a un mejor precio que los pedidos que utilizan subastas holandesas. Como se discutió en este documento, las subastas holandesas en cadena pierden algo de valor a MEV debido a los movimientos de precios entre bloques, y pueden tardar muchos bloques en completarse. Por el contrario, los pedidos que utilizan impuestos MEV generalmente podrían completarse en el siguiente bloque mientras capturan la gran mayoría de su MEV.

A diferencia de una RFQ fuera de la cadena, la subasta para completar un orden que utiliza impuestos MEV ocurriría atómicamente con la ejecución de transacciones en la cadena. Esto significa que un postor ganador podría tener la garantía de que solo se compromete a cumplir con el orden si su transacción en cadena tiene éxito. Eso podría facilitar que la liquidez onchain, como los AMM, compita con la liquidez offchain, lo que significa que UniswapX podría servir como un router aún más eficaz para sistemas multipool como Uniswap v4.

AMMs

Normalmente, los AMM pierden valor a los arbitrajistas que operan contra precios obsoletos en la parte superior del bloque, como se discute en los documentos loss-vs-rebalancing papers. Podemos usar los impuestos MEV para que los AMM capturen ese MEV. Para simplificar las cosas, discutiremos cómo podría funcionar esto en un AMM sin liquidez concentrada. (Si está interesado en cómo se podría resolver este tipo de problema con liquidez concentrada, Sorella pronto publicará una solución).

Un AMM puede capturar MEV cobrando una tarifa adicional en función de la tarifa de prioridad en la transacción, lo que le permite subastar el derecho a operar primero en el bloque. Hay muchas formas de calcular y denominar esa tarifa. Discutiremos uno posiblemente neutral, que se denomina en unidades de liquidez del grupo, sqrt(xy). La transacción ganadora sería la que más aumente la liquidez del pool.

Al ejecutar la primera transacción en un grupo en un bloque, en lugar de aplicar la condición x_end y_end > x_start y_start, el grupo podría aplicar la condición (con una constante como alguna):

x_end y_end > (sqrt(x_start y_start) + a*priorityFeePerGas)^2

Esta fórmula incentivaría al trader de arbitraje a operar al precio real, y después de esa operación, el precio del punto medio en el pool debería ser el precio real. 6

Después de esa primera transacción, las operaciones podrían funcionar como lo hacen en Uniswap v2, con tarifas de swap fijas. Las transacciones no informadas que desean comerciar en el grupo sin pagar un impuesto MEV adicional establecerían una tarifa de prioridad baja.

Hay muchas otras formas de implementar impuestos MEV en un AMM que tendrían diferentes efectos. Por ejemplo, los impuestos MEV podrían estar denominados en el token de entrada o salida del intercambio, podrían afectar el porcentaje de la tarifa de intercambio aplicado por el grupo o podrían determinar el precio mínimo de la operación del usuario. Creemos que este es un espacio de diseño interesante para explorar.

Backrunning auctions

Las descripciones anteriores muestran cómo se podrían diseñar ciertas aplicaciones para evitar fugas de MEV. Sin embargo, ¿qué pasa si una billetera quiere intentar ayudar a sus usuarios a capturar el MEV que crean a partir de transacciones arbitrarias que interactúan con cualquier aplicación, incluso las que no incorporan impuestos MEV?

Por ejemplo, cuando Alice realiza una transacción grande en un AMM, a veces crea una oportunidad de arbitraje para que los "backrunners" muevan el precio hacia atrás. Esto normalmente se filtra a MEV, en lugar de ir a Alice.

MEV-Share y MEVBlocker son dos protocolos que permiten a los usuarios capturar MEV de sus transacciones, pero se basan en un complejo sistema de subastas fuera de la cadena. El espacio de diseño de subastas de Orderflow describe algunas otras soluciones.

Los impuestos MEV, cuando se combinan con una billetera de contrato inteligente basada en la intención, podrían permitirnos construir un sistema alternativo para capturar MEV en retroceso para Alice. Supongamos que en lugar de crear una transacción que se negocia en el AMM, Alice firma una intención de que cualquiera puede enviar a la billetera de contrato inteligente de Alice para hacer que realice esa acción. La billetera de contrato inteligente de Alice cobra a quien envía esa transacción un impuesto MEV, que se paga a Alice.

El buscador que envíe la intención de Alice tendrá el derecho exclusivo de retrotraerla, ya que puede hacerlo de forma atómica en la misma transacción. Como resultado, si la búsqueda es competitiva, todas las ganancias de la recuperación de Alice deberían acumularse para Alice a través de su impuesto MEV.

Tenga en cuenta que es posible que este sistema no proteja necesariamente a los usuarios de ataques que impliquen transacciones de usuario anticipadas, ya que una transacción que adelanta a un usuario puede evitar pagar un impuesto MEV a ese usuario. Este problema (y algunas posibles mitigaciones para él) se analiza con mayor detalle en la sección Limitaciones a continuación. Sin embargo, esto podría ser al menos una mejora en los sistemas que utilizan mempools públicos sin ninguna mitigación.

Otros casos de uso

Además de estos ejemplos, otros usos potenciales de MEV impuestos podrían incluir casi cualquier cosa que actualmente utilice una subasta offchain u holandesa, como:

• Protocolos para que los oráculos capturen el valor extraíble del oráculo que crean, como Oval
• Subastas de refinanciación en protocolos de préstamos con garantía NFT como Blend
• Lending protocolo liquidaciones que filtran menos valor de las subastas holandesas

Captura de MEV entre aplicaciones

Las soluciones anteriores están diseñadas para capturar el MEV de interactuar con una sola aplicación. Pero a veces puede ser posible que un buscador capture aún más valor al interactuar con varias aplicaciones en la misma transacción.

Si solo una de esas aplicaciones tiene un impuesto MEV, entonces todo el MEV de la transacción debe ir a la aplicación con el impuesto MEV, independientemente de cuán alto o bajo sea ese impuesto MEV.

Pero, ¿qué pasa si la transacción de un buscador interactúa con dos aplicaciones que utilizan impuestos MEV? Por ejemplo, ¿qué pasa si hay algún MEV que solo se puede capturar completando una de las órdenes UniswapX gravadas por MEV descritas anteriormente contra un AMM gravado por MEV?

En ese caso, la cantidad relativa de exceso de MEV capturada por cada solicitud está determinada por la forma en que esas aplicaciones establecen sus impuestos MEV. Si el valor app_i cobra como impuesto MEV viene dado por la función tax_i(prioridad), entonces la prioridad de la transacción ganadora se puede determinar resolviendo la prioridad en esta ecuación:

tax_1(priorityPerGas) + tax_2(priorityPerGas) = total MEV

(Técnicamente, podríamos agregar un tercer término para priorityPerGas * gasUsed para cuentas de la tarifa de prioridad pagada al proponente del bloque, pero lo ignoraremos ya que, como se discute en el Apéndice A, probablemente será insignificante en condiciones normales).

En el caso simple de MEV impuestos que son lineales en priorityPerGas (por lo que tax_1(priorityPerGas) = a_1 * priorityPerGas), puede resolver la parte de MEV recibida por cada aplicación:

a_1 priorityPerGas + a_2 priorityPerGas = MEV

priorityPerGas = MEV/(a_1 + a_2)

tax_1(priorityPerGas) = (a_1/(a_1+a_2))*MEV

tax_2(priorityPerGas) = (a_2/(a_1+a_2))*MEV

Al establecer su propio impuesto MEV, una aplicación se enfrenta a una compensación: los impuestos más altos le permiten capturar una mayor proporción de MEV de aplicación cruzada cuando ocurre, pero significan que podría perder algo de MEV de aplicación cruzada si hay formas competitivas de extraerlo. Por ejemplo, si hay una AMM que cobra un impuesto MEV en cada operación, entonces es más probable que una orden UniswapX con impuestos MEV sea llenada por un AMM diferente o un relleno fuera de la cadena.

En muchos casos, puede haber un equilibrio en el que dos aplicaciones diseñan sus impuestos MEV en orden para compartir MEV de una manera que maximice cada uno de su bienestar. Por ejemplo, un AMM con impuestos MEV probablemente querría capturar valor de un solo operador informado cerca de la parte superior del bloque, pero luego querría proporcionar liquidez a otros operadores y aplicaciones (incluidos los que usan impuestos MEV) con una tarifa fija baja. En ese caso, es probable que el AMM establezca un impuesto MEV relativamente bajo (por ejemplo, $ 0.00001 priorityFeePerGas), de modo que la transacción de arbitraje (si la hay) ocurra al principio del bloque, y luego no cobre ningún impuesto MEV en las transacciones posteriores en el bloque. Las aplicaciones como UniswapX que desean interactuar con el AMM pueden establecer un impuesto MEV mucho más alto (digamos $ 0.01 priorityFeePerGas), para garantizar que sus transacciones se incluyan después de que el grupo ya esté arbitrado. Con esos impuestos relativos, el AMM terminaría siendo el primero, incluso si solo hubiera $ 1 de MEV y $ 50,000 de MEV en un orden de UniswapX.

Creemos que este es un espacio de diseño amplio digno de estudio futuro.

Las limitaciones

MEV los impuestos tienen algunas complicaciones e inconvenientes. Creemos que cada una de ellas es un área interesante para futuras investigaciones.

La incompatibilidad de incentivos

MEV los impuestos no son compatibles con los incentivos para un proponente de bloques monopolísticos. Solo funcionan si existe una competencia justa para la inclusión de transacciones, lo que solo puede suceder si el proponente de bloques sigue reglas que llamaremos "orden de prioridad competitiva", en lugar de maximizar sus propios ingresos. De manera informal y no exhaustiva, sugerimos que estas reglas incluyan:

• Ordenamiento prioritario. Las transacciones dentro de un bloque deben ordenarse en orden descendente de priorityFeePerGas.
• Censura-resistencia. Si el proponente de bloque recibe una transacción t1 durante el bloque, y el bloque no está lleno o incluye alguna transacción t2 tal que t2.priorityFeePerGas < t1.priorityFeePerGas, entonces el bloque debe incluir la transacción t1.
• Privacidad previa a la transacción. El proponente de bloque debe aceptar transacciones a través de un punto de conexión privado y no debe compartir dichas transacciones con nadie más antes de comprometerse con el bloque, ni utilizar el contenido de esas transacciones como entrada en la construcción de sus propias transacciones.
• No hay último vistazo. El proponente de bloque debe establecer un tiempo definido blockTime antes del cual acepta transacciones de cualquier persona y después del cual no acepta transacciones de nadie.

Si se viola una o más de estas propiedades, puede debilitar la efectividad de los impuestos MEV. Un proponente de bloques que viola la resistencia a la censura puede evitar la mayoría de los impuestos MEV excluyendo las transacciones competidoras y presentando una transacción de prioridad cero que aproveche la oportunidad para sí misma. Un proponente de bloques que viola la privacidad previa a la transacción podría robar MEV de otras transacciones o echar un vistazo a sus tarifas de prioridad para saber exactamente qué tan alto necesita establecer las suyas, mientras que uno que pueda enviar transacciones más tarde que nadie tendría una "última mirada" gratuita sobre si superar la oferta de otros por una oportunidad, Cualquiera de los dos podría crear problemas de selección adversa que, en última instancia, desincentiven la competencia.

Desafortunadamente, mientras que la primera propiedad sería fácil de aplicar en la capa de protocolo, aplicar las otras propiedades sin confianza es un problema abierto.

En ausencia de aplicación al capa de protocolo, se debe confiar en que un solo secuenciador que se comprometa con estas reglas no se desvíe de ellas, y si los proponentes subcontratan la construcción de bloques a una subasta competitiva que maximice los ingresos (como Ethereum MEV-Boost de L1), es probable que los bloques no las sigan.

Estos problemas se pueden "resolver" con un único secuenciador de confianza que se comprometa a utilizar un orden de prioridad competitivo para la construcción de bloques. También pueden resolverse con un mecanismo descentralizado utilizando alguna combinación de consenso, criptografía y/o entornos de ejecución confiables, como Angstrom de Sorella, SUAVE de Flashbots, Leaderless Auctions, o Multiplicity.

Bloques completos

Una excepción al funcionamiento normal de MEV impuestos ocurre cuando los bloques están completamente llenos. En ese caso, es posible que los proponentes de bloques tengan que omitir las transacciones de menor prioridad, en lugar de simplemente incluirlas al final del bloque. Dado que es probable que las transacciones que interactúan con las aplicaciones gravadas por MEV tengan tarifas de prioridad extremadamente bajas, es probable que esas aplicaciones sean desplazadas por aplicaciones que no usan impuestos MEV o que tienen impuestos MEV extremadamente bajos. Sin embargo, en una cadena que utiliza un mecanismo similar a EIP-1559 para establecer una tarifa base separada, debería ser relativamente raro que los bloques estén completamente llenos. Además, dado que algunas transacciones deben retrasarse cuando los bloques están llenos, retrasar las transacciones que expresan una menor urgencia al establecer impuestos MEV más altos puede ser un resultado razonable.

Las transacciones revertidas

MEV los impuestos se basan efectivamente en subastas de un solo bloque en las que cada "oferta" es una transacción. Una desventaja de esas subastas es que la pérdida de ofertas generalmente dará lugar a que las transacciones revertidas se incluyan en la cadena, pagando una tarifa base y congestionando la cadena.

Si un secuenciador puede excluir por completo las transacciones fallidas, eso aliviaría este problema, aunque puede ser difícil de implementar incluso con un secuenciador centralizado. (Tampoco obedecería estrictamente la propiedad de censura-resistencia descrita anteriormente, aunque esa definición podría ajustarse). Un secuenciador más sofisticado puede optimizar este proceso al permitir que las transacciones especifiquen en qué subastas contenciosas están participando, lo que le da al secuenciador suficiente información para omitir transacciones posteriores que sabe que fallarán.

La filtración de las intenciones de los usuarios

MEV los impuestos solo funciona si hay competencia entre los buscadores, lo que significa que la oportunidad debe ser algo ampliamente conocida. Para aplicaciones como los AMM, donde la oportunidad es visible en la cadena, eso debería suceder de forma natural. Pero en el caso de aplicaciones como el enrutamiento basado en la intención o las subastas de retroceso, eso significa que es posible que la aplicación tenga que compartir la intención del usuario con los buscadores.

En algunos casos, la privacidad temporal perdida por la transmisión de la intención del usuario antes de que se cumpla puede perder valor de una manera que no puede ser recuperada por un impuesto MEV.

Por ejemplo, supongamos que Alice desea comprar un token de baja liquidez utilizando el protocolo de subasta de backrunning descrito anteriormente. Ella publica una intención firmada para que su billetera de contrato inteligente compre ese token en un AMM, estableciendo cierta tolerancia de deslizamiento. Los buscadores podrían competir para empujar el precio de ese token a su tolerancia de deslizamiento en una transacción de alta prioridad, sin llenar el orden del usuario. El ganador, Bob, podría entonces cumplir de manera no competitiva la intención de Alice incluyéndola y ejecutándola en una transacción de baja prioridad, intercalando así el comercio de Alice y dándole un precio peor mientras evadía su impuesto MEV. Un problema similar podría ocurrir con las compras de NFT.

Tenga en cuenta que tal ataque sería arriesgado para Bob, ya que no podría garantizar la atomicidad entre la compra del token y la venta a Alice. Un Bob ingenuo podría caída víctima de un trampa de "desgarro de sándwiches" en el que Alice publica su intención de comprarse a sí misma una ficha sin valor, lo que hace que Bob la compre en previsión de intercalar su intercambio, pero Alice revoca su intención antes de que Bob pueda completar el sándwich.

Las aplicaciones también pueden mitigar esto limitando el conjunto de buscadores con los que comparten intenciones y supervisando su comportamiento, como hacen muchas subastas de flujo de pedidos existentes.

También puede ser posible combinar MEV impuestos con funciones de creación conscientes de la privacidad, como las previstas en los diseños de Flashbots para SUAVE.

Finalmente, en los casos en que Alice decida que los costos de compartir su intención superan el beneficio de la búsqueda competitiva, podría construir una transacción ella misma y enviarla directamente al bloque. Como se discutió anteriormente, una implementación ideal del orden de prioridad competitivo proporcionaría privacidad previa a la transacción del proponente de bloques.

Discusión y trabajo previo

Subastas de gas prioritarias. Algunas de las dinámicas del orden de prioridad en las cadenas de bloques descentralizadas se estudiaron en el artículo Flash Boys 2.0, que acuñó el término "valor extraíble del minero". Ese documento observó que los mineros de Ethereum (cuando esa red usaba proof-of-work) ya estaban ordenando transacciones por prioridad, y que los arbitrajistas confiaban en ese comportamiento para participar en "subastas de gas prioritarias" en las que pujaban por el derecho a ser incluidos primero en un bloque, lo que llevó a gran parte del MEV del arbitraje de intercambio descentralizado que se acumulaba para los mineros.

Por orden de llegada. Algunos intentos de mitigación de MEV a través de reglas de ordenación de transacciones, como Themis o El secuenciador actual de Arbitrum One,7 se han centrado en hacer cumplir una regla de ordenación diferente, por orden de llegada (a veces llamada "orden justa") donde los proponentes de bloques deben orden transacciones en el orden en que las ven.

El orden de prioridad adopta un enfoque diferente: tratar las transacciones que llegan dentro de un período determinado de manera equitativa y, en su lugar, ordenarlas por su prioridad declarada.

El orden de llegada es difícil de aplicar o incluso definir en un entorno de red real con más de un validador. También puede resultar en carreras de latencia inútiles y spam incluso con un solo secuenciador de confianza. Finalmente, los impuestos MEV pueden eliminar ciertos tipos de MEV que los pedidos por orden de llegada no pueden, como las ganancias de arbitraje de los "saltos" discontinuos en los precios de los activos. Las ventajas potenciales de los pedidos prioritarios sobre los pedidos por orden de llegada están relacionadas de alguna manera con las ventajas de los intercambios de tiempo discreto sobre los de tiempo continuo discutidas en Budish, Cramton, Shim (2015).

Mientras tanto, mientras que el orden de prioridad parece filtrar valor a MEV de forma predeterminada, esta publicación muestra cómo se pueden diseñar aplicaciones para recuperarlo.

Reparto de honorarios. Blast, un Ethereum L2, comparte una parte de las tarifas de prioridad y base con el contratos inteligentes al que se accede en una transacción.

Los impuestos MEV permiten algo similar (al menos para las tarifas de prioridad), pero se pueden implementar en la capa de aplicación en cualquier cadena que utilice pedidos de prioridad competitivos, sin soporte especial para compartir tarifas. También permiten que las aplicaciones definan sus propios impuestos como funciones personalizadas de tarifa de prioridad, lo que proporciona más flexibilidad y potencialmente resulta en una mayor componibilidad de las aplicaciones compatibles con MEV.

Soluciones sin confianza. Esta publicación se centra en la motivación de las plataformas para utilizar el orden de prioridad competitivo, y las formas de aprovechar las plataformas que lo hacen, en lugar de discutir cómo aplicarlo sin confianza.

Ha habido una discusión previa significativa de cada una de las otras propiedades requeridas para el pedido de prioridad competitiva. Por ejemplo, en Fox, Pai, Resnick (2023), los autores discuten las vulnerabilidades en las subastas onchain en ausencia de resistencia a la censura y describen un diseño para una subasta resistente a la censura utilizando múltiples proponentes simultáneos. Sin embargo, no sugieren un orden específico para las transacciones.

Ha habido otras investigaciones sobre la construcción de mecanismos para la construcción de bloques minimizados por la confianza, incluyendo SUAVE" de Flashbots, Angstrom de Sorella, Leaderless Auctions, Espresso y Offchain Labs' @espressosys/espresso-systems-and-offchain-labs-release-r-d-roadmap-for-decentralized-timeboost-5d0007dff66d">decentralized Timeboost, y inclusión obligatoria de transacciones públicas por parte Péter Szilági.

Conclusión

Esperamos que esta publicación anime a los L2 a considerar el uso del orden de prioridad (como se admite de forma predeterminada en la pila de OP) e inspire a las aplicaciones a probar MEV impuestos donde sea compatible.

También esperamos que motive una mayor investigación sobre protocolos para pedidos de prioridad competitiva minimizados por la confianza tanto en L1 como en L2. Si estás interesado en colaborar en ese problema, y estás leyendo esto antes del jueves 6 de junio, aún puedes solicitar una beca TLDR para trabajar en secuenciadores L2 resistentes a < href="https://www.tldresear.ch/tldr/tldr-request-for-papers/mev-resistant-l2-sequencers">MEV con Dan. ¡O siéntete libre de ponerte en contacto con dan@paradigm.xyz y dave@paradigm.xyz con ideas!

Footnotes

1. En esta publicación, usamos "proponente" para referirnos al actor o proceso que determina qué transacciones se incluyen en un bloque en particular. En Ethereum L2s, este rol generalmente es ocupado por un "secuenciador". En Ethereum L1, es llenado por un validador específico de Ethereum llamado proponente, aunque a menudo el proponente subcontrata la tarea de construir el bloque a una subasta competitiva en la que participan "relayers" y "builders". Los detalles de cómo se dividen estas responsabilidades están fuera del alcance de esta publicación. ↩
2. La tarifa de prioridad por gas en realidad no se especifica explícitamente en la transacción, pero se puede calcular en ella. La transacción especifica un precio del gas, pero Ethereum también cobra una tarifa base, que se saca del precio del gas y se quema. La tarifa base debe ignorarse a los efectos de los impuestos MEV, ya que no está bajo el control del transactor. La tarifa de prioridad por gas (el precio de la parte de la tarifa de transacción que va al proponente del bloque) se puede calcular en Solidity como priorityGasPrice = tx.gasprice - block.basefee. ↩
3. Alternativamente, podríamos simplemente definir "MEV" para excluir cualquier beneficio del buscador y solo referirnos al valor que iría al validador. ↩
4. Tenga en cuenta que proposerPriorityFee, igual a priorityFeePerGas multiplicado por el gas total utilizado en la transacción, en realidad no se puede calcular durante el contrato, ya que no hay forma de saber cuánto gas terminará usando la transacción. Sin embargo, esto generalmente no importará, ya que todo lo que necesitamos es un límite superior para ello. Para estar seguro, podría multiplicar priorityFeePerGas por 30 millones, el gas máximo actual en un bloque de Ethereum. Sobreestimar este valor simplemente significará que el impuesto MEV captura un porcentaje aún mayor de MEV. ↩
5. Suponiendo que una transacción no puede ser de más de 30 millones de gas, un priorityFeePerGas de 50,000 resultaría en un pago de gas de 1500 gwei, aproximadamente $ 0.006 a un precio ETH de $ 4000. ↩
6. En el caso de que priorityFeePerGas se establezca de modo que el beneficio del arbitrajista sea cero, la operación de arbitraje que maximiza el beneficio debe corresponder a la misma operación en el AMM de maximización de la función . Demostrar esto queda como un ejercicio para el lector. ↩
7. Arbitrum ha discutido reemplazar esto con una forma de orden de prioridad llamada Timeboost, pero eso no se ha puesto en producción al momento de escribir este artículo. ↩

Disclaimer:

1. Este artículo es una reimpresión de [paradigm]. Todos los derechos de autor pertenecen al autor original [Dan Robinson & Dave White]. Si hay objeciones a esta reimpresión, póngase en contacto con el equipo de Gate Learn, y ellos se encargarán de ello con prontitud.

2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los 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, está prohibido copiar, distribuir o plagiar los artículos traducidos.