Autor: Dan Robinson, Dave White

Compilado por: Joyce, BlockBeats

introducir

En este artículo, presentamos el impuesto MEV, un mecanismo mediante el cual cualquier aplicación puede capturar su propio MEV. Este mecanismo ahora está disponible en OP Stack L2, como OP Mainnet, Base y Blast, ya que los proponentes de bloques en estas cadenas siguen un conjunto de reglas que llamamos priorización competitiva.

Para imponer un impuesto MEV a una de las cadenas, el contrato inteligente cobra una tarifa que es función de la tarifa de prioridad de la transacción. Si una aplicación cobra un impuesto MEV de $99 por cada $1 de tarifas de prioridad del buscador, captura el 99% del MEV competitivo para esa transacción.

La tributación MEV es una técnica simple que abre un vasto espacio de diseño. Se puede considerar que permiten que cualquier aplicación de la cadena ejecute su propia subasta MEV personalizada sin su propia infraestructura fuera de la cadena, simplemente conectándose a una única subasta compartida realizada por el proponente del bloque.

Ilustramos cómo se puede utilizar un impuesto MEV para abordar tres preguntas principales en la investigación de MEV:

Los enrutadores de intercambio descentralizado (DEX) optimizan los precios que reciben los intercambiadores;

Creadores de Mercado Automatizados (AMM) que minimizan las pérdidas y el reequilibrio (LVR) experimentados por los proveedores de liquidez;

Carteras que permiten a los usuarios capturar cualquier MEV "en ejecución" creado por sus transacciones;

Pero hay un problema. El impuesto MEV solo es efectivo si los proponentes de bloques se adhieren estrictamente a las reglas de priorización competitiva, que incluyen ordenar las transacciones según tarifas de prioridad sin censurar, espiar ni retrasar ninguna transacción. Si los proponentes de bloques se desvían de estas reglas, pueden evadir el impuesto MEV y capturar valor para ellos mismos. Por lo tanto, hoy en día, los impuestos MEV dependen de ordenantes L2 confiables y es posible que no funcionen en absoluto en Ethereum L1, donde la construcción de bloques está dominada por subastas competitivas de constructores que maximizan los ingresos de las personas propuestas.

No obstante, el poder y la flexibilidad de los impuestos a los MEV sugieren que la priorización puede ser la opción correcta para las plataformas que actualmente pueden ofrecer este servicio. La relativa simplicidad de la priorización competitiva sugiere que puede haber una manera factible de hacerla cumplir de manera descentralizada sin tener que confiar en un solo secuenciador. Esperamos que este artículo estimule más investigaciones sobre este tema.

priorizar

Cuando alguien envía una transacción en Ethereum L1 o L2, asigna una tarifa de prioridad y la paga al proponente del bloque. Puede imaginar que esto se especifica como PriorityFeePerGas, un número multiplicado por el gas utilizado en la transacción para obtener BuilderPriorityFee: el pago total en ETH.

No existe ninguna disposición en el protocolo Ethereum que indique que las transacciones en un bloque deban ordenarse con avidez por prioridadFeePerGas en orden descendente. Sin embargo, es una forma popular de construir bloques; por ejemplo, es el ordenador de la cadena OP Stack y el algoritmo predeterminado utilizado por geth y reth. La priorización no solo permite a los comerciantes expresar efectivamente la urgencia de sus transacciones, sino que también, naturalmente, pasa ciertos tipos de MEV para bloquear a los proponentes.

Esto sucede porque la priorización convierte la competencia por los MEV en una subasta de gas priorizada. Cuando surgen oportunidades para beneficiarse de las interacciones con una cadena, como el arbitraje con intercambios centralizados a través de AMM, los buscadores corren para ser los primeros en hacerlo. Si la cadena utiliza la priorización para determinar la inclusión y el orden de las transacciones, los buscadores compiten estableciendo tarifas de alta prioridad para sus transacciones.

En un escenario competitivo con competencia sin beneficios y sin riesgos, el buscador ganador debería, en última instancia, pagar la tarifa de prioridad MEV completa. Entonces, si hay disponible una ganancia de 100 ETH al interactuar con el contrato, la primera transacción que reclame esa ganancia tendrá una tarifa de prioridad establecida de 100 ETH. (Discutimos algunas advertencias en la sección Limitaciones).

impuesto MEV

Supongamos que un contrato inteligente quiere capturar MEV de cualquier transacción con la que interactúa. Hay mucha investigación sobre diferentes formas de aplicaciones específicas en las que los contratos inteligentes pueden intentar capturar su propio MEV.

Pero, de hecho, no necesariamente necesitamos saber nada sobre la aplicación. Si sabemos que el bloque se construyó mediante priorización competitiva, entonces tenemos una señal universal sobre la cantidad de MEV en la transacción: la tarifa de prioridad.

Proponemos que un contrato inteligente podría considerar la tarifa de prioridad de una transacción y cobrar su propia tarifa como una función incremental de la misma. Por ejemplo, el contrato puede requerir que la persona que llama transfiera applicationPriorityFee = 99 * proponerPriorityFee en ETH al contrato.

Esta nueva tarifa la paga el buscador que envió la transacción, por lo que afecta el comportamiento de ese buscador. Si hay 100 MEV en la oportunidad, la transacción ganadora ahora solo establecerá una tarifa de prioridad de 1 ETH, ya que esto resultará en un pago total de 100 ETH (1 ETH para el proponente del bloque y 99 ETH para el contrato inteligente). Cualquier tarifa de prioridad más alta hará que la transacción no sea rentable; cualquier tarifa de prioridad más baja resultará en la pérdida de oportunidades para los competidores que establezcan tarifas más altas. Esto significa que el contrato inteligente capturó el 99% del MEV en la transacción.

A esta tarifa adicional impuesta por los contratos inteligentes la llamamos impuesto MEV. El impuesto MEV permite que una aplicación se apodere de la priorización para su propio beneficio, lo que le permite recuperar MEV para sus usuarios en lugar de filtrarlo para bloquear a los proponentes.

Si la tarifa crece lo suficientemente rápido en función de la prioridad FeePerGas, el proponente sólo recibirá un MEV insignificante. Dado que el PriorityFeePerGas está denominado en wei (milmillonésimas de 1 ETH), debemos trabajar con mucha precisión. Por ejemplo, siempre que el impuesto MEV sea lo suficientemente sensible como para que una tarifa por gas prioritaria de 50 000 resulte en un impuesto excesivo, entonces el monto total pagado al proponente sería inferior a $0,01. (5)

Sin embargo, hay una advertencia importante. Como se analizó en la sección “Limitaciones”, los impuestos MEV solo funcionan si los proponentes de bloques siguen ciertas reglas (lo que llamamos “priorización competitiva”) y no se desvían para maximizar sus propios ingresos. Hacer cumplir estas reglas sin confianza es una cuestión abierta.

Captura MEV de aplicación única

Aquí, describimos cómo se pueden usar los impuestos MEV para mitigar tres problemas importantes en MEV en cadenas que garantizan la construcción de bloques usando precedencia competitiva: permitir que las interfaces DEX mejoren la ejecución comercial de los intercambiadores y permitir que los AMM reduzcan las pérdidas de arbitraje en ellos LP, y permitir la billetera para reducir la fuga de MEV del usuario mediante la venta de los derechos de ejecución inversa del usuario.

Enrutador de intercambio descentralizado

En los protocolos de enrutamiento DEX basados ​​en intenciones, 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 para Alice al mejor precio.

La versión actual de UniswapX utiliza dos mecanismos para competir: una subasta holandesa, donde el precio límite de Alice cambia con el tiempo hasta que los buscadores lo llenan y una subasta inicial de solicitud de cotización (RFQ) fuera de la cadena, que establece la subasta holandesa; El precio inicial de la subasta.

En una plataforma que garantice una priorización competitiva, UniswapX puede reemplazar estos mecanismos con un único mecanismo: el impuesto MEV. Para ello, permite a los usuarios firmar órdenes que cualquiera puede ejecutar de inmediato, pero con el precio de ejecución establecido en función de la prioridad de la operación.

Por ejemplo, si Alice tiene una orden UniswapX para vender 1 ETH, puede definir el precio de ejecución de la orden como Precio mínimo + ($0,01 * tarifa de prioridadPorGas). El precio mínimo puede ser un valor fijo que espera que sea significativamente más bajo que el precio actual.

Los buscadores competirán para completar el pedido de Alice mediante el envío de transacciones. La orden se cumplirá independientemente de qué acuerdo tenga la tarifa de prioridad más alta y no se restablezca, lo que debería garantizar que el intercambiador obtenga el mejor precio que el buscador pueda encontrar. (Algunas excepciones se analizan en la sección Limitaciones).

Si el precio mínimo de Alice es de $3000 y el precio actual de ETH es de $3500, la prioridad FeePerGas en la transacción ganadora es de aproximadamente 50 000. (Tenga en cuenta que en una transacción que cueste 200.000 Gas, esto daría como resultado que se pagaran ~10 mil millones de wei (~$0,000035) solo al proponente del bloque).

Esto tiene algunos beneficios potenciales en comparación con el mecanismo existente utilizado en UniswapX.

Los pedidos que utilizan el impuesto MEV se pueden ejecutar más rápido y a un mejor precio que los pedidos que utilizan una subasta holandesa. Como se analiza en este artículo, las subastas holandesas en cadena pierden algo de valor hacia MEV debido a los cambios de precios entre bloques, y pueden tardar muchos bloques en completarse. Por el contrario, los pedidos que utilizan impuestos MEV a menudo se pueden completar en el siguiente bloque y capturar la gran mayoría de MEV.

A diferencia de las RFQ fuera de la cadena, las subastas de órdenes que utilizan el impuesto MEV se realizarán automáticamente cuando se ejecuten las transacciones dentro de la cadena. Esto significa que se garantiza que el postor ganador se comprometerá a completar el pedido solo si la transacción en cadena tiene éxito. Esto puede facilitar que la liquidez dentro de la cadena, como los AMM, compita con la liquidez fuera de la cadena, lo que significa que UniswapX puede servir como un enrutador más eficiente para sistemas de grupos múltiples como Uniswap v4.

AMM

Por lo general, los AMM pierden valor a los arbitrajistas que operan en función de precios obsoletos en la parte superior de los bloques, como se analiza en el documento sobre pérdidas y reequilibrio. Podemos utilizar el impuesto MEV para permitir que AMM capture MEV. En aras de la simplicidad, analizaremos cómo funcionar en AMM sin liquidez centralizada. (Si está interesado en cómo resolver estos problemas reuniendo liquidez, Sorella lanzará una solución pronto).

Un AMM puede capturar MEV cobrando una tarifa adicional en función de una tarifa de prioridad de transacción, lo que le permite subastar el derecho a ser el primero en una transacción en un bloque. Existen varias formas de calcular y valorar esta tarifa. Analizaremos uno que posiblemente sea neutral: en unidades de liquidez del pool, sqrt(xy). La operación ganadora será la que aumente más la liquidez del pool.

Al ejecutar la primera transacción en el grupo en un bloque, en lugar de hacer cumplir la condición x_end * y_end > x_start * y_start , el grupo puede hacer cumplir la condición (a como una constante):

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

Esta fórmula incentivará a los operadores de arbitraje a negociar al precio real y, después de esa operación, el precio medio en el grupo debería ser el precio real.

Después de la primera operación, las operaciones pueden continuar como en Uniswap v2, con tarifas de intercambio fijas. Los comerciantes desinformados que quieran operar en el grupo sin pagar el impuesto MEV adicional tendrán establecida una tarifa de prioridad más baja.

Hay muchas otras formas de implementar un impuesto MEV a las AMM, que tendrán diferentes efectos. Por ejemplo, un impuesto MEV podría denominarse en los tokens de entrada o salida de un swap, podría afectar el porcentaje de las tarifas de swap aplicadas por un pool o podría determinar el precio mínimo para las transacciones de los usuarios. Creemos que este es un espacio de diseño interesante que vale la pena explorar.

subasta retrógrada

La descripción anterior muestra cómo se pueden diseñar ciertas aplicaciones para evitar fugas de MEV. Sin embargo, ¿qué pasa si una billetera quiere intentar ayudar a los usuarios a capturar el MEV que crean a partir de cualquier transacción con la que interactúan con cualquier aplicación, incluso aquellas que no incluyen impuestos MEV?

Por ejemplo, cuando Alice realiza grandes operaciones en AMM, a veces crea oportunidades de arbitraje para que los "backrunners" reduzcan el precio. Normalmente, esto se filtraría a MEV, no a Alice.

MEV-Share y MEVBlocker son dos protocolos que permiten a los usuarios capturar MEV de las transacciones, pero dependen de complejos sistemas de subasta fuera de la cadena. El espacio de diseño de subastas de flujo de pedidos describe algunas otras soluciones.

El impuesto MEV, combinado con una billetera de contrato inteligente basada en intención, nos permite construir un sistema alternativo para capturar MEV ejecutándose en segundo plano para Alice. Supongamos que Alice no crea una transacción para realizar transacciones en AMM, sino que firma una intención que cualquiera puede enviar a la billetera de contrato inteligente de Alice para que realice esa acción. La billetera de contrato inteligente de Alice cobra un impuesto MEV a cualquiera que envíe la transacción, y el impuesto se paga a Alice.

Los buscadores que envíen la intención de Alice tendrán el derecho exclusivo de contrarrestarla, ya que pueden hacerlo automáticamente dentro de la misma transacción. Por lo tanto, si la búsqueda es competitiva, todas las ganancias de Alice deberían ir a parar a Alice a través del impuesto MEV.

Tenga en cuenta que este sistema no necesariamente protege a los usuarios de ataques que involucran transacciones realizadas por un usuario front-run, ya que las transacciones realizadas por un usuario front-run pueden evitar pagar el impuesto MEV a ese usuario. Este problema (y algunas posibles mitigaciones) se analizan con más detalle en la sección Limitaciones a continuación. Aun así, esto podría al menos ser una mejora con respecto a los sistemas que utilizan un grupo de memoria común sin mitigaciones.

Otros casos de uso

Además de estos ejemplos, otros usos potenciales de los impuestos MEV podrían incluir casi cualquier cosa que actualmente utilice subastas holandesas o fuera de la cadena, como:

Protocolos donde los oráculos capturan valor extraíble por los oráculos que crean, como Oval;

Subastas de refinanciación de protocolos hipotecarios NFT como Blend;

El valor de fuga de la liquidación de un contrato de préstamo es inferior al de una subasta holandesa;

Captura MEV entre aplicaciones

La solución anterior está diseñada para capturar interacciones MEV con una sola aplicación. Pero a veces los buscadores pueden obtener más valor interactuando con múltiples aplicaciones en la misma transacción.

Si solo una de estas aplicaciones tiene un impuesto MEV, todos los MEV en la transacción deben transferirse a la aplicación con un impuesto MEV, independientemente de qué tan alto o bajo sea el impuesto MEV.

Pero, ¿qué pasa si la transacción del buscador interactúa con dos aplicaciones que utilizan el impuesto MEV? Por ejemplo, ¿qué pasa si hay algún MEV que solo se puede capturar completando una de las órdenes UniswapX que pagan impuestos MEV anteriores contra un AMM que paga impuestos MEV?

En este caso, la cantidad relativa de MEV excedente capturada por cada aplicación depende de cómo esas aplicaciones establecen sus impuestos MEV. Si el valor app_i recaudado 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 siguiente ecuación de prioridad:

impuesto_1(prioridadPorGas) + impuesto_2(prioridadPorGas) = ​​MEV total

(Técnicamente, podríamos agregar un tercer término a prioridadPerGas * gasUtilizado para contabilizar la tarifa de prioridad pagada al proponente del bloque, pero lo ignoraremos, probablemente sea insignificante en circunstancias normales)

En el caso simple en el que el impuesto MEV es lineal en prioridadPerGas (por lo tanto, impuesto_1(prioridadPerGas) = ​​​​a_1 * prioridadPerGas), puede resolver la proporción de MEV recibida por cada aplicación:

a_1 * prioridadPorGas + a_2 * prioridadPorGas = MEV prioridadPorGas = MEV/(a_1 + a_2) impuesto_1(prioridadPorGas) = ​​(a_1/(a_1+a_2))*MEV impuesto_2(prioridadPorGas) = ​​(a_2/(a_1+a_2))*MEV

Las aplicaciones se enfrentan a una compensación al establecer su propio impuesto MEV: un impuesto más alto les otorga una mayor proporción del MEV entre aplicaciones cuando ocurre, pero significa que pueden perder algunos MEV entre aplicaciones si hay una forma competitiva de extraerlo. eso. Por ejemplo, si hay un AMM que cobra el impuesto MEV en cada transacción, entonces es más probable que el pedido UniswapX del impuesto MEV sea completado por un AMM diferente o un llenador fuera de la cadena.

En muchos casos, puede haber un equilibrio en el que dos aplicaciones diseñan sus impuestos MEV de manera que compartan el MEV de una manera que maximice sus respectivas ganancias. Por ejemplo, un AMM con impuesto MEV podría querer capturar valor de un único comerciante informado cerca de la parte superior del bloque, pero luego querer proporcionar liquidez a una tasa fija más baja a otros comerciantes y aplicaciones (incluidas las aplicaciones que utilizan el impuesto MEV). costo. En este caso, el AMM podría establecer un impuesto MEV relativamente bajo (por ejemplo, $0,00001 * PriorityFeePerGas) para que el comercio de arbitraje (si lo hay) ocurra temprano en el bloque, y luego no imponer ningún impuesto MEV a las transacciones posteriores en el bloque. Las aplicaciones como UniswapX que desean interactuar con AMM pueden establecer un impuesto MEV más alto (por ejemplo, $0,01 * prioridadFeePerGas) para garantizar que sus transacciones se incluyan después de que el grupo ya haya arbitrado. Dados estos impuestos relativos, incluso si solo hubiera $1 MEV y $50,000 MEV en el pedido de UniswapX, el AMM terminaría siendo arbitrado primero.

Creemos que este es un amplio espacio de diseño digno de futuras investigaciones.

limitación

Los impuestos a los MEV tienen algunas complejidades e inconvenientes, que creemos que son áreas interesantes para investigaciones futuras.

Incompatibilidad de incentivos

Los impuestos a los MEV no son incentivos compatibles para los proponentes de bloques monopolísticos. Solo funcionan si existe igualdad de condiciones para la inclusión de transacciones, lo cual solo ocurre si los proponentes de bloques siguen lo que llamamos reglas de "priorización competitiva" en lugar de maximizar sus propios ingresos. Una lista informal de reglas sugeridas incluye, entre otras, las siguientes:

Priorizar. Las transacciones dentro del bloque deben ordenarse por prioridadFeePerGas en orden descendente.

Resiste la censura. Si el proponente del bloque recibe la transacción t1 durante el bloque y el bloque no está lleno o contiene alguna transacción t2, como t2.priorityFeePerGas < t1.priorityFeePerGas, entonces el bloque debe contener la transacción t1.

Privacidad previa a la transacción. Los proponentes de bloques deben aceptar transacciones a través de un punto final privado y no pueden compartir dichas transacciones con nadie más antes de enviarlas a un bloque, ni utilizar el contenido de estas transacciones como entrada para crear sus propias transacciones.

No hay revisión final. Los proponentes de bloqueo deben establecer un tiempo de bloqueo claro. Antes de este tiempo, aceptarán solicitudes de transacción de cualquier persona; después de este tiempo, ya no aceptarán solicitudes de transacción de nadie.

Una violación de uno o más de estos atributos podría socavar la efectividad del impuesto MEV. Los proponentes de bloques que violan la censura pueden evitar la mayoría de los impuestos MEV excluyendo transacciones competidoras y presentando transacciones de prioridad cero que se aprovechan de sí mismas. Los proponentes de bloques que violen la privacidad previa a la transacción pueden robar MEV de otras transacciones o consultar sus tarifas de prioridad para saber exactamente qué tan altas deben establecer sus tarifas, mientras que los proponentes de bloques que puedan enviar transacciones más tarde que otros obtendrán "Finalmente mirar gratis". sobre si desea pagar un precio más alto que otros para tener la oportunidad, lo cual puede crear problemas de selección adversa que, en última instancia, obstaculizan la competencia.

Desafortunadamente, si bien la primera propiedad se aplica fácilmente en la capa de protocolo, hacer cumplir las otras propiedades sin confianza es un problema abierto.

En ausencia de aplicación en la capa de protocolo, se debe confiar en que un único secuenciador que se comprometa con estas reglas no se desvíe de estas reglas, y si los proponentes subcontratan la construcción de bloques a subastas competitivas que maximicen los ingresos (por ejemplo, MEV-Boost de Ethereum L1), los bloques pueden no seguirlos.

Estos problemas pueden "resolverse" con un único secuenciador confiable que prometa utilizar un orden de prioridad competitivo para la construcción de bloques. También pueden resolverse mediante mecanismos descentralizados utilizando alguna combinación de consenso, criptografía y/o un entorno de ejecución confiable, como Angstrom de Sorella, SUAVE de Flashbots, subastas sin líderes o multiplicidad.

bloque completo

Una excepción al funcionamiento normal del impuesto MEV se produce cuando un bloque está completamente lleno. En este caso, es posible que el proponente del bloque tenga que abandonar transacciones de menor prioridad en lugar de simplemente incluirlas en el bloque. Debido a que las transacciones que interactúan con aplicaciones de impuestos MEV pueden tener tarifas de prioridad muy bajas, estas aplicaciones pueden verse desplazadas por aplicaciones que no utilizan impuestos MEV o tienen impuestos MEV muy bajos. Sin embargo, en una cadena que utiliza un mecanismo como EIP-1559 para establecer una tarifa base separada, debería ser relativamente raro que los bloques se llenen por completo. Además, dado que ciertas transacciones deben retrasarse cuando un bloque está lleno, retrasar las transacciones que representan una menor urgencia estableciendo un impuesto MEV más alto podría ser un resultado razonable.

Transacciones restauradas

El impuesto MEV en realidad se basa en subastas de bloque único, donde cada “oferta” es una transacción. Una desventaja de estas subastas es que las ofertas fallidas a menudo resultan en que las transacciones restauradas se incluyan en la cadena, pagando algunas tarifas base y causando congestión en la cadena.

Esto aliviaría este problema si el clasificador pudiera excluir completamente las transacciones fallidas, aunque esto sería difícil de lograr incluso con un clasificador centralizado. (Tampoco se adheriría estrictamente a las propiedades resistentes a la censura mencionadas anteriormente, aunque esa definición podría modificarse). Los secuenciadores más sofisticados podrían optimizar este proceso al permitir que las transacciones especifiquen en qué subastas disputadas están participando, permitiendo al secuenciador obtener información suficiente. para omitir transacciones posteriores que sabe que fallarán.

Revelar la intención del usuario

El impuesto MEV sólo funciona si hay competencia entre los buscadores, lo que significa que es necesario conocer la oportunidad hasta cierto punto. Para aplicaciones como AMM, donde las oportunidades son visibles en la cadena, esto debería suceder de forma natural. Pero para aplicaciones como el enrutamiento basado en la intención o las subastas en segundo plano, esto significa que es posible que la aplicación necesite compartir la intención del usuario con el buscador.

En algunos casos, la pérdida temporal de privacidad causada por la propagación de la intención del usuario antes de que se realice puede perder valor de una manera que el impuesto MEV no puede recuperar.

Por ejemplo, supongamos que Alice quiere comprar tokens de baja liquidez utilizando el protocolo de subasta backend descrito anteriormente. Ella publica la intención firmada de la billetera de contrato inteligente para comprar el token en el AMM y establece una cierta tolerancia de deslizamiento. Un buscador puede competir en una operación de alta prioridad para elevar el precio de ese token hasta su tolerancia de deslizamiento sin completar el pedido del usuario. El ganador Bob puede entonces satisfacer las intenciones de Alice de una manera no competitiva incluyéndola en una transacción de baja prioridad y ejecutándola a la inversa, intercalando así la transacción de Alice y dándole un peor precio mientras evita su impuesto MEV. Pueden surgir problemas similares al comprar NFT.

Cabe señalar que tal ataque es riesgoso para Bob porque no puede garantizar la atomicidad entre comprar el token y venderlo a Alice. Un Bob ingenuo puede caer en una trampa de "abrazar y desgarrar": Alice primero anuncia su intención de comprarse una ficha sin valor y Bob compra la ficha para flanquear su transacción, pero antes de que Bob complete el flanqueo, Alice retira su intención. .

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

También es posible combinar los impuestos MEV con funciones de creación conscientes de la privacidad, como lo que Flashbots imagina para su diseño SUAVE.

Finalmente, si Alice decide que el costo de compartir la intención supera los beneficios de la búsqueda competitiva, puede construir la transacción ella misma y enviarla directamente al bloque. Como se mencionó anteriormente, una implementación ideal de priorización competitiva proporcionaría a los proponentes de bloques privacidad previa a la transacción.

Discusiones relacionadas

Subasta de gas prioritario. El artículo Flash Boys 2.0, que acuñó el término "valor extraíble minero", examina algunas de las dinámicas de priorización en cadenas de bloques descentralizadas. El documento afirma que los mineros de Ethereum (cuando la red utilizaba prueba de trabajo) ya priorizaban las transacciones, y que los arbitrajistas se basaban en este comportamiento para participar en "subastas de gas prioritario" en las que pujaban por el derecho a ser incluidos en la primera zona. bloques, lo que da como resultado que la mayoría de los MEV arbitrados por intercambios descentralizados sean propiedad de mineros.

El primero en llegar es el primero en ser atendido. Algunos intentos de mitigar el MEV a través de reglas de ordenamiento de transacciones, como el ordenador actual de Themis o Arbitrum One (7), se centran en hacer cumplir una regla de ordenamiento diferente, por orden de llegada (a veces llamado "ordenamiento justo"), en el que los proponentes de bloques deben ordenar las transacciones en el orden en que los ven.

La priorización adopta un enfoque diferente: las transacciones que llegan dentro de un tiempo determinado se tratan por igual y se ordenan según su prioridad declarada.

El primero en llegar, el primero en ser atendido es difícil de aplicar o incluso definir en un entorno de red real con múltiples validadores. Incluso con un único secuenciador confiable, puede generar spam y contiendas de latencia inútiles. Por último, un impuesto a los MEV podría eliminar ciertos tipos de MEV que las órdenes por orden de llegada no pueden eliminar, como las ganancias de arbitraje derivadas de “saltos” discretos en los precios de los activos. Las ventajas potenciales del ordenamiento prioritario sobre el ordenamiento por orden de llegada están relacionadas hasta cierto punto con las ventajas del intercambio en tiempo discreto sobre el intercambio en tiempo continuo analizadas en Budish, Cramton, Shim (2015).

Al mismo tiempo, aunque la priorización parece perder valor a MEV de forma predeterminada, esta publicación muestra cómo diseñar su aplicación para recuperarlo.

Compratir costos. Blast es Ethereum L2 y comparte una parte de las tarifas base y de prioridad con los contratos inteligentes a los que se accede en las transacciones.

El impuesto MEV permite algo similar (al menos para tarifas prioritarias), pero puede implementarse en la capa de aplicación en cualquier cadena utilizando una priorización competitiva sin requerir un soporte especial para compartir tarifas. También permiten que las aplicaciones definan su propio impuesto como una función personalizada de la tarifa de prioridad, lo que proporciona una mayor flexibilidad y potencialmente mejora la componibilidad de las aplicaciones compatibles con MEV.

Solución sin confianza. Este artículo se centra en las motivaciones de las plataformas para utilizar prioridades competitivas y formas de explotar la plataforma, en lugar de cómo hacerlas cumplir de manera desconfiada.

Cada una de las otras propiedades requeridas para la priorización competitiva se ha discutido ampliamente anteriormente. Por ejemplo, en Fox, Pai, Resnick (2023), los autores analizan las vulnerabilidades de las subastas en cadena en ausencia de resistencia a la censura y describen el diseño de subastas resistentes a la censura utilizando múltiples proponentes simultáneos. Sin embargo, no sugirieron una secuencia específica de transacciones.

Hay otras investigaciones sobre la creación de mecanismos de construcción de bloques que minimicen la confianza, incluido SUAVE de Flashbots, Angstrom de Sorella, Leaderless Auctions, Timeboost descentralizado de Espresso y Offchain Labs, y la inclusión forzada de transacciones públicas de Péter Szilági.

Esperamos que este artículo anime a L2 a considerar el uso de la priorización (compatible de forma predeterminada con la pila OP) y aliente a las aplicaciones a probar los impuestos MEV cuando sean compatibles. También esperamos que inspire más investigaciones sobre protocolos de priorización competitiva que minimicen la confianza en L1 y L2.