Introducción

En esta publicación, presentamos los impuestos de MEV, un mecanismo que las aplicaciones arbitrarias pueden usar para capturar su propio MEV.

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

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 de MEV son una técnica sencilla que abre un vasto espacio de diseño. Puedes pensar en ellos como permitir que cualquier aplicación en la cadena ejecute su propia subasta personalizada de MEV, sin necesidad de ninguna infraestructura fuera de la cadena, simplemente conectándose a una única subasta compartida ejecutada por el proponente de bloques.

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

• Enrutadores de intercambio descentralizado (DEX) que optimizan el precio recibido por el intercambiador
• Los creadores de mercado automatizados (AMM) que minimizan la pérdida frente al reequilibrio (LVR) experimentada por los proveedores de liquidez
• Monederos que permiten a sus usuarios capturar cualquier MEV de 'backrunning' creado por sus transacciones

Pero hay un problema. Los impuestos de MEV solo funcionan si los proponentes de bloques siguen estrictamente las reglas de orden de prioridad competitiva, que incluyen ordenar las transacciones por tarifa de prioridad sin censurar, espiar o retrasar cualquier transacción. Si los proponentes de bloques se desvían de esas reglas, pueden evadir los impuestos de MEV para capturar el valor para sí mismos. Hoy en día, por lo tanto, los impuestos de MEV dependen de confiar en los secuenciadores de L2, y es probable que no funcionen en absoluto en Ethereum L1, donde la construcción de bloques está dominada por un subasta competitiva de constructoresque maximiza los ingresos para el proponente.

Sin embargo, el poder y la flexibilidad de los impuestos de MEV sugieren que el orden de prioridad puede ser la elección correcta para las plataformas que pueden proporcionarlo hoy en día. Y la simplicidad relativa del orden de prioridad competitivo sugiere que puede haber una forma viable de hacer cumplirlo de manera descentralizada, sin tener que confiar en un solo secuenciador. Esperamos que esta publicación motive más trabajo sobre ese problema.

Orden de prioridad

Cuando alguien envía una transacción en Ethereum L1 o L2, especifican una tarifa de prioridad que pagan al proponente del bloque.1Puede 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 una regla en el protocolo Ethereum que establezca que las transacciones en un bloque deben ser ordenadas por orden de prioridadFeePerGas descendente. Sin embargo, esa es una forma popular de construir bloques, por ejemplo, es el algoritmo predeterminado utilizado por los secuenciadores de Pila OPcadenas, así como geth y reth. No solo permite a los transactores expresar eficientemente la urgencia de sus transacciones mediante el orden de prioridad, sino que también canaliza naturalmente ciertos tipos de MEV al proponente del bloque.

Eso sucede porque el orden de prioridad convierte la competencia por MEV en una subasta de gas prioritario. Cuando hay una oportunidad de obtener ganancias al interactuar con la cadena, como arbitrar entre un AMM y un intercambio centralizado, los buscadores compiten para reclamar esa oportunidad primero. Si la cadena utiliza un orden de prioridad para determinar la inclusión y el orden de las transacciones, los buscadores compiten estableciendo altas tarifas de prioridad en sus transacciones.

En un escenario competitivo en el que las ganancias libres de riesgo se reducen a cero, el buscador ganador debería terminar pagando la cantidad completa de MEV en tarifas de prioridad.3Así que si hay 100 ETH de beneficio que se puede obtener al interactuar con un contrato, la primera transacción para reclamarlo establecerá una tarifa de prioridad de 100 ETH. (Discutimos algunas advertencias sobre esto en la sección de Limitaciones).

Impuestos de MEV

Supongamos que un contrato inteligente desea capturar el MEV de cualquier transacción que interactúe con él. Existe una amplia biblioteca de investigaciones sobre las diferentes formas específicas de aplicaciones 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 ver la tarifa prioritaria de la transacción y cobrar su propia tarifa como alguna función creciente de ella. Por ejemplo, el contrato podría requerir que quien lo llame transfiera applicationPriorityFee = 99 * proposerPriorityFee en ETH al contrato.4

Esta nueva tarifa la paga 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 solo establecerá ahora una tarifa prioritaria de 1 ETH, ya que eso dará como resultado un pago total de 100 ETH (1 ETH al proponente del bloque y 99 ETH al contrato inteligente). Cualquier tarifa prioritaria más alta haría que la transacción no fuera rentable; cualquier tarifa prioritaria más baja resultaría en perder la oportunidad frente a un competidor que estableció una tarifa más alta. Esto significa que el contrato inteligente ha capturado el 99% de los 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 orden de prioridad para su propio beneficio, lo que le permite recapturar MEV para sus usuarios en lugar de filtrarlo al proponente del bloque.

Si esta tarifa aumenta lo suficientemente rápido en función de priorityFeePerGas, entonces solo una cantidad insignificante de MEV se acumulará para el proponente. Dado que priorityFeePerGas está denominado en wei (una milmillonésima de una milmillonésima de un ETH), tenemos mucha precisión con la que trabajar. Por ejemplo, siempre y cuando el impuesto MEV sea lo suficientemente sensible como para que un priorityFeePerGas de 50,000 resulte en un impuesto prohibitivamente alto, entonces el pago total al proponente sería inferior a $0.01.5

Sin embargo, hay un importante inconveniente. Como se discute en la sección de Limitaciones, los impuestos de MEV solo funcionan si los proponentes de bloques siguen ciertas reglas, a las que llamamos "orden de prioridad competitiva", en lugar de desviarse de esas reglas para maximizar sus propios ingresos. Hacer cumplir estas reglas de manera 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 el orden de prioridad competitivo para la construcción de bloques, los impuestos de MEV podrían usarse para mitigar tres problemas importantes en MEV: permitir que las interfaces de DEX mejoren la ejecución del comercio para los intercambiadores, permitir que los AMM reduzcan las pérdidas por arbitraje para sus LP y permitir que las carteras reduzcan la fuga de MEV para sus usuarios vendiendo el derecho a retroceder al usuario.

ruteadores DEX

En los protocolos de enrutamiento DEX basados en intenciones, comoUniswapXyFusión de 1 pulgada, un usuario (Alice) firma una intención de intercambio, y los buscadores compiten para enrutarse 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 donde el precio límite de Alice cambia con el tiempo hasta que un buscador lo completa, y una subasta inicial de solicitud de cotización (RFQ) fuera de la cadena para establecer el precio de inicio de esa subasta holandesa.

En una plataforma que garantiza el orden de prioridad competitivo, UniswapX podría reemplazar esto con un mecanismo único: un impuesto de MEV. Podría implementar esto haciendo que el usuario firme una orden que pueda ser llenada inmediatamente por cualquier persona, pero con un precio de ejecución que se establezca como una función de la prioridad de la transacción.

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

Los buscadores competirían para completar el pedido de Alice enviando transacciones. La transacción que tenga la tarifa de prioridad más alta y no se revierta sería la que completaría el pedido, lo que debería garantizar que el intercambiador obtenga el mejor precio que los buscadores puedan encontrar. (Algunas excepciones a esto se discuten en la sección de Limitaciones).

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

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

Las órdenes que utilizan impuestos MEV podrían completarse más rápido y a un precio mejor que las órdenes que utilizan subastas holandesas. Como se discutió en este papel, las subastas holandesas onchain filtran algo de valor a MEV debido a movimientos de precios entre bloques, y pueden tardar muchos bloques en completarse. En contraste, las órdenes que utilizan impuestos de MEV podrían completarse típicamente en el siguiente bloque mientras capturan la gran mayoría de su MEV.

A diferencia de un RFQ fuera de la cadena, la subasta para llenar una orden que utiliza impuestos MEV sucedería atómicamente con la ejecución de la transacción en la cadena. Esto significa que un postor ganador podría estar seguro de que solo se comprometen a llenar la orden si su transacción en la cadena tiene éxito. Eso podría hacer que sea más fácil para la liquidez en la cadena, como los AMM, competir con la liquidez fuera de la cadena, lo que significa que UniswapX podría servir como un enrutador aún más efectivo para sistemas de múltiples piscinas como Uniswap v4.

AMMs

Normalmente, los AMM pierden valor frente a los arbitrajistas que operan con precios desactualizados en la parte superior del bloque, como se discutió en el pérdida vs reequilibrio papeles. Podemos utilizar impuestos MEV para que los AMM capturen ese MEV. Para mantener las cosas simples, discutiremos cómo esto podría funcionar en un AMM sin liquidez concentrada. (Si estás interesado en cómo se podría resolver este tipo de problema con liquidez concentrada, Sorellapronto publicará una solución.)

Un AMM puede capturar MEV cobrando una tarifa adicional en función de la tarifa de prioridad de la transacción, lo que le permite subastar el derecho a comerciar primero en el bloque. Hay muchas formas de calcular y denominar esa tarifa. Discutiremos una forma posiblemente neutral: denominándola en unidades de liquidez de la piscina, sqrt(xy). La transacción ganadora sería aquella que aumenta la liquidez de la piscina en mayor medida.

Cuando se ejecuta la primera transacción en un grupo en un bloque, en lugar de cumplir con la condición x_endy_end > x_starty_start, el grupo podría hacer cumplir la condición (con a como una constante):

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

Esta fórmula incentivaría al trader de arbitraje a comerciar al precio real, y después de ese comercio, el precio intermedio en la 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 intercambio fijas. Las transacciones no informadas que deseen operar en el pool 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 comisión de intercambio aplicado por el grupo, o podrían determinar el precio mínimo del intercambio del usuario. Creemos que este es un espacio de diseño interesante para explorar.

Subastas de retroceso

Las descripciones anteriores muestran cómo ciertas aplicaciones podrían diseñarse para evitar la fuga de MEV. Sin embargo, ¿qué sucede si una billetera desea intentar ayudar a sus usuarios a capturar el MEV que crean a partir de transacciones arbitrarias que interactúan con cualquier aplicación, incluso aquellas que no incorporan impuestos de 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-ShareyMEVBlockerson dos protocolos que permiten a los usuarios capturar MEV de sus transacciones, pero dependen de un sistema de subastas fuera de la cadena complejo.El espacio de diseño de subasta del flujo de pedidosdescribe algunas otras soluciones.

Los impuestos MEV, combinados con una billetera de contrato inteligente basada en intenciones, podrían permitirnos construir un sistema alternativo para capturar el MEV de backrunning para Alice. Supongamos que, en lugar de crear una transacción que negocie en el AMM, Alice firma una intención que cualquier persona puede enviar a la billetera de contrato inteligente de Alice para que tome 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 presente la intención de Alice tendrá el derecho exclusivo de correr detrás de ella, ya que puede hacerlo atómicamente en la misma transacción. Como resultado, si la búsqueda es competitiva, todas las ganancias de correr detrás de Alice deberían acumularse en Alice a través de su impuesto MEV.

Tenga en cuenta que este sistema no necesariamente protege a los usuarios de ataques que involucran transacciones de usuario de frontrunning, porque 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 discute con más detalle en la sección de Limitaciones a continuación. Sin embargo, esto al menos podría ser una mejora en los sistemas que utilizan mempools públicos sin ninguna mitigación.

Otros casos de uso

Además de estos ejemplos, otros posibles usos de los impuestos MEV podrían incluir casi cualquier cosa que actualmente use una subasta fuera de la cadena o una subasta holandesa, como:

• Protocolos para oráculos para capturar el valor extraíble del oráculo que crean, como Óvalo
• Subastas de refinanciamiento en protocolos de préstamos colateralizados por NFT como Mezcla
• Liquidaciones de protocolos de préstamos quevalor que no pierdeque las subastas holandesas

Captura de MEV entre aplicaciones

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

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

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

En ese caso, la cantidad relativa de MEV excedente capturada por cada aplicación se determina por cómo esas aplicaciones establecen sus impuestos MEV. Si el valor que la aplicación_i cobra como impuesto MEV está dado por la función impuesto_i(prioridad), entonces la prioridad de la transacción ganadora puede determinarse resolviendo para 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 tener en cuenta la tarifa de prioridad pagada al proponente del bloque, pero lo ignoraremos ya que, como se discute en el Apéndice A, probablemente sea insignificante en condiciones normales).

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

a_1prioridadPorGas + a_2priorityPerGas = 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 un dilema: los impuestos más altos le permiten capturar una mayor parte del MEV entre aplicaciones cuando ocurre, pero significa que podría perderse parte del MEV entre aplicaciones si existen formas competitivas de extraerlo. Por ejemplo, si existe un AMM que cobra un impuesto MEV en cada operación, es más probable que se complete un pedido de MEV-tax UniswapX por un AMM diferente o un completador externo.

En muchos casos, puede haber un equilibrio en el que dos aplicaciones diseñen sus impuestos de MEV para compartir el MEV de manera que maximice el bienestar de cada una. Por ejemplo, una AMM con impuestos de MEV probablemente querría capturar valor de un único trader informado cerca de la parte superior del bloque, pero luego querría proporcionar liquidez a otros traders y aplicaciones (incluidas aquellas que utilizan impuestos de MEV) con una tarifa fija baja. En ese caso, es probable que la AMM establezca un impuesto de MEV relativamente bajo (digamos, $0.00001).priorityFeePerGas), para que la transacción de arbitraje (si la hay) suceda temprano en el bloque, y luego no cobrar impuestos MEV en transacciones posteriores en el bloque. Aplicaciones como UniswapX que desean interactuar con el AMM pueden establecer un impuesto MEV mucho más alto (digamos $0.01).priorityFeePerGas), para asegurarse de que sus transacciones se incluyan después de que el grupo ya haya sido arbitrado. Con esos impuestos relativos, el AMM terminaría siendo arbitrado primero incluso si solo hubiera $1 de MEV en él y $50,000 de MEV en una orden UniswapX.

Creemos que este es un amplio espacio de diseño que merece ser estudiado en el futuro.

Limitaciones

Los impuestos de MEV tienen algunas complicaciones y desventajas. Creemos que cada una de ellas es un área interesante para futuras investigaciones.

Incompatibilidad de incentivos

Los impuestos de MEV no son compatibles con incentivos para un proponente de bloque monopolístico. Solo funcionan si hay una competencia justa para la inclusión de transacciones, lo cual solo puede suceder si el proponente de bloque sigue reglas que llamaremos 'orden de prioridad competitiva', en lugar de maximizar sus propios ingresos. Informalmente y de manera no exhaustiva, sugerimos que estas reglas deben incluir:

• Orden de prioridad. Las transacciones dentro de un bloque deben estar ordenadas en orden descendente de priorityFeePerGas.
• Resistencia a la censura. 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 pre-transacción. El proponente del bloque debe aceptar transacciones a través de un punto final privado y no debe compartir dichas transacciones con nadie más antes de comprometerse con el bloque, o utilizar el contenido de esas transacciones como entrada en la construcción de sus propias transacciones.
• Sin mirada final. El proponente del bloque debe establecer un tiempo definido blockTime antes del cual aceptan transacciones de cualquier persona, y después del cual no aceptan 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 hacer cumplir a nivel del protocolo, hacer cumplir las otras propiedades sin confianza es un problema abierto.

En ausencia de la aplicación de medidas de cumplimiento en la capa del protocolo, se necesita confiar en un único secuenciador que se comprometa a seguir estas reglas y no desviarse de ellas, y si los proponentes subcontratan la construcción de bloques a una subasta competitiva que maximice los ingresos (como la de Ethereum L1).MEV-Boost), es probable que los bloques no los sigan.

Estos problemas pueden ser “resueltos” con un único secuenciador de confianza que se comprometa a utilizar una ordenación de prioridades competitiva para la construcción de bloques. También pueden ser resolubles con un mecanismo descentralizado que utilice alguna combinación de consenso, criptografía y/o entornos de ejecución de confianza, como el Angstrom de Sorella, el SUAVE de Flashbots,Subastas sin líder, o Multiplicidad.

Bloques llenos

Una excepción a la operación normal de las tasas de MEV ocurre cuando los bloques están completamente llenos. En ese caso, los proponentes de bloques pueden tener que dejar fuera transacciones de baja prioridad en lugar de simplemente incluirlas tarde en el bloque. Dado que las transacciones que interactúan con aplicaciones gravadas con MEV probablemente 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 transacciones que expresan menor urgencia al establecer impuestos MEV más altos puede ser un resultado razonable.

Transacciones revertidas

Los impuestos MEV dependen efectivamente de subastas de un solo bloque en las que cada "oferta" es una transacción. Uno de los inconvenientes de esas subastas es que las ofertas perdedoras generalmente resultarán en transacciones revertidas que se incluirán en la cadena, pagando alguna basefee y congestionando la cadena.

Si un secuenciador puede excluir completamente 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 resistencia a la censura descrita anteriormente, aunque esa definición podría ajustarse.) Un secuenciador más sofisticado podría optimizar este proceso al permitir que las transacciones especifiquen en qué subastas conflictivas participan, lo que le daría al secuenciador suficiente información para omitir transacciones posteriores que sabe que fallarían.

Filtración de intenciones del usuario

Los impuestos de MEV solo funcionan si existe competencia entre los buscadores, lo que significa que la oportunidad debe ser algo ampliamente conocido. Para aplicaciones como los AMM, donde la oportunidad es visible en cadena, eso debería ocurrir de forma natural. Pero para aplicaciones como el enrutamiento basado en intenciones o subastas de backrunning, eso significa que la aplicación puede necesitar compartir la intención del usuario con los buscadores.

En algunos casos, la pérdida temporal de privacidad al difundir la intención del usuario antes de que se cumpla puede filtrar valor de una manera que no puede ser recuperada por un impuesto de MEV.

Por ejemplo, supongamos que Alice quiere comprar un token de baja liquidez utilizando el protocolo de subasta de backrunning descrito anteriormente. Publica una intención firmada para que su billetera de contrato inteligente compre ese token en un AMM, estableciendo una tolerancia al deslizamiento. Los buscadores podrían competir para empujar el precio de ese token hasta su tolerancia al deslizamiento en una transacción de alta prioridad, sin llenar la orden del usuario. El ganador, Bob, podría luego llenar no competitivamente la intención de Alice incluyéndola y retrocediéndola en una transacción de baja prioridad, lo que sándwich Alice's comercio y dándole un peor precio mientras evita su impuesto MEV. Un problema similar podría ocurrir con las compras de NFTs.

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 su venta a Alice. Un Bob ingenuo podría caer víctima de una trampa de "sandwich ripping" en la que Alice publica la intención de comprar un token sin valor de sí misma, haciendo que Bob lo compre anticipando intercalar su operación, pero Alice revoca su intención antes de que Bob pueda completar el intercalado.

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

También puede ser posible combinar impuestos MEV con características de construcción conscientes de la privacidad como se prevé en los diseños de Flashbots para SUAVE.

Finalmente, en casos en los que Alice decida que los costos de compartir su intención superan el beneficio de la búsqueda competitiva, ella 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 competitiva proporcionaría privacidad previa a la transacción del proponente del bloque.

Discusión y trabajo previo

Subastas de gas prioritario. Se estudiaron algunas de las dinámicas de ordenamiento prioritario en blockchains descentralizados en el Flash Boys 2.0paper, que acuñó el término 'valor extraíble por mineros'. Ese documento observó que los mineros de Ethereum (cuando esa red utilizaba la prueba de trabajo) ya estaban ordenando las transacciones por prioridad, y que los arbitrajistas se basaban en ese comportamiento para participar en 'subastas de gas de prioridad' en las que pujaban por el derecho a ser incluidos primero en un bloque, lo que llevó a que gran parte del MEV del arbitraje en los intercambios descentralizados fuera a parar a los mineros.

El primero en llegar, será el primero en ser servido. Algunos intentos de mitigación de MEV a través de reglas de ordenación de transacciones, como ThemisoEl secuenciador actual de Arbitrum One,7Me he centrado en hacer cumplir una regla de ordenación diferente, primero en llegar, primero en ser servido (a veces llamado “ordenación justa”) donde los proponentes de bloque deben ordenar las transacciones en el orden en que las ven.

El orden de prioridad toma un enfoque diferente, tratando las transacciones que llegan dentro de un período dado por igual, y ordenándolas en su lugar 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 que se analizan en Budish, Cramton, Shim (2015).

Mientras tanto, aunque el pedido prioritario parece filtrar valor a MEV por defecto, esta publicación muestra cómo las aplicaciones pueden ser diseñadas para recuperarlo.

Compartir tarifas. Blast, un Ethereum L2, accionesuna parte tanto de las tarifas prioritarias como de las tarifas base con los contratos inteligentes a los que se accede en una transacción.

Los impuestos de MEV permiten algo similar (al menos para las tarifas prioritarias), pero se pueden implementar en la capa de aplicación en cualquier cadena que utilice un orden de prioridad competitivo, sin necesidad de un soporte especial para el reparto de tarifas. También permiten a las aplicaciones definir sus propios impuestos como funciones personalizadas de la tarifa prioritaria, lo que proporciona más flexibilidad y posiblemente resulte en una mayor composabilidad de aplicaciones conscientes de MEV.

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

Ha habido una discusión previa significativa de cada una de las otras propiedades requeridas para la ordenación de prioridades competitivas. Por ejemplo, en Fox, Pai, Resnick (2023)Los autores hablan de 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 que utiliza varios proponentes concurrentes. 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 con minimización de confianza, incluido el de Flashbots.SUAVE, SorellaAngstrom de Subastas sin líder, Espresso y Offchain Labs'@espressosys/espresso-systems-and-offchain-labs-release-r-d-roadmap-for-decentralized-timeboost-5d0007dff66d">decentralized Timeboost, and inclusión obligatoria de transacciones públicaspor Péter Szilági.

Conclusión

Esperamos que esta publicación anime a los L2 a considerar el uso de la ordenación prioritaria (como es compatible de forma predeterminada en OP Stack) e inspire a las aplicaciones a probar los impuestos MEV donde estén soportados.

También esperamos que motive una mayor investigación sobre protocolos para el orden de prioridad competitivo con confianza minimizada 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 MEV con Dan. O siéntase libre de contactar dan@paradigm.xyzydave@paradigm.xyzcon ideas!

Notas al pie

1. En esta publicación, usamos el término “proposer” para referirnos al actor o proceso que determina qué transacciones se incluyen en un bloque particular. En Ethereum L2s, este papel suele ser desempeñado por un “secuenciador”. En Ethereum L1, lo desempeña 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 no está realmente especificada explícitamente en la transacción, pero puede ser calculada en ella. La transacción especifica un precio del gas, pero Ethereum también cobra una tarifa base, que se resta del precio del gas y se quema. La tarifa base debe ignorarse con fines de impuestos MEV, ya que no está bajo el control del transactor. La tarifa de prioridad por gas, es decir, el precio de la parte de la tarifa de transacción que va al proponente del bloque, puede ser calculada en Solidity como priorityGasPrice = tx.gasprice - block.basefee.↩
3. Alternativamente, podríamos simplemente definir “MEV” para excluir cualquier beneficio del buscador y referirnos solo al valor que iría al validador.↩
4. Tenga en cuenta que proposerPriorityFee, que es igual a priorityFeePerGas multiplicado por el total de gas utilizado en la transacción, no se puede calcular realmente durante el contrato, ya que no hay forma de saber cuánto gas terminará utilizando 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, alrededor de $0.006 a un precio de ETH de $4000.↩
6. En el caso en que priorityFeePerGas esté configurado de manera que la ganancia del arbitrajista sea cero, el arbitraje de maximización de ganancias debería corresponder al mismo comercio en el AMM de maximización de funciones. Demostrar esto se deja como ejercicio para el lector. ↩
7. Arbitrum tienediscutidoreemplazando esto con una forma de ordenación de prioridad llamada Timeboost, pero eso no se ha puesto en producción hasta el momento de escribir esto.

Descargo de responsabilidad:

1. Este artículo ha sido reimpreso de [ paradigma], Todos los derechos de autor pertenecen al autor original [Dan Robinson, Dave White]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo y lo resolverá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, está prohibido copiar, distribuir o plagiar los artículos traducidos.