Este artículo es de "La prioridad es todo lo que necesitas"
Autor original: Dan Robinson, Dave White
Compilado por: Odaily Planet Daily ¿Cómo está tu marido?
Paradigm publicó el artículo "La prioridad es todo lo que necesita" el 4 de junio, que presenta en detalle el nuevo mecanismo del impuesto MEV.
El impuesto MEV es un mecanismo novedoso que permite a las aplicaciones capturar el MEV que generan en lugar de filtrarlo a los proponentes de bloqueo (consulte la nota al pie al final del artículo para obtener más información sobre los proponentes de bloqueo). Este mecanismo aprovecha la priorización competitiva en el proceso de construcción de bloques. En este método de clasificación, las transacciones se organizan en orden descendente de costo de prioridad y las transacciones con mayor prioridad se empaquetan primero en bloques. El impuesto MEV se implementa agregando una tarifa adicional a la tarifa de prioridad de la transacción. Las aplicaciones pueden capturar la mayor parte o incluso la totalidad del MEV estableciendo sus propias tarifas basadas en las tarifas de prioridad de la transacción. Esto significa que las aplicaciones pueden ejecutar sus propias subastas MEV personalizadas sin la necesidad de ninguna infraestructura fuera de la cadena al participar en una única subasta compartida realizada por el proponente del bloque.
El nacimiento del mecanismo fiscal MEV puede tener un impacto en el ecosistema DeFi existente:
Cambiar la forma en que se distribuye el MEV tradicional: Tradicionalmente, el MEV se ha destinado principalmente a bloquear a los proponentes, y el impuesto MEV permite que las aplicaciones capturen este valor y lo redistribuyan entre sus usuarios o lo utilicen para otros fines.
Ingresos de aplicaciones y experiencia de usuario mejorados: las aplicaciones pueden aumentar sus ingresos implementando el impuesto MEV y al mismo tiempo brindar una mejor experiencia de usuario, ya que los usuarios pueden lograr una mayor eficiencia en la ejecución de transacciones y mejores precios de transacción.
Se resolvieron algunos problemas en DeFi: M, como optimizar el enrutamiento DEX, reducir las pérdidas de AMM en arbitraje, reducir la fuga de MEV para los usuarios de billeteras, etc. Al introducir impuestos MEV, las aplicaciones pueden mejorar sus productos y servicios, aumentando así la eficiencia y sostenibilidad del ecosistema DeFi.
citación
En este artículo, presentamos el impuesto MEV, un mecanismo que permite que cualquier aplicación capture su propio MEV (Valor máximo extraíble).
Este mecanismo está disponible de inmediato en las cadenas 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 implementar el impuesto MEV en estas cadenas, un contrato inteligente cobra una tarifa basada en la tarifa de prioridad de la transacción. Mostramos que si una aplicación impone un impuesto MEV de $99 por cada dólar de prioridad pagado por un buscador, puede capturar el 99% del MEV competitivo de esa transacción.
El impuesto MEV es una tecnología simple que abre un vasto espacio de diseño. Puede considerarlo como permitir que cualquier aplicación de la cadena ejecute su propia subasta MEV personalizada sin ninguna infraestructura propia fuera de la cadena, simplemente conectándose a una subasta compartida realizada por el proponente del bloque.
Mostramos cómo se puede utilizar un impuesto MEV para abordar tres preguntas principales en la investigación de MEV:
Un enrutador de intercambio descentralizado (DEX) que optimiza los precios recibidos por los intercambiadores
Creador de mercado automatizado (AMM) que minimiza las pérdidas incurridas por los proveedores de liquidez debido al reequilibrio (LVR)
Una billetera que permite a los usuarios capturar cualquier MEV "revertido" generado 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, incluida la ordenación de transacciones por tarifa de prioridad sin censura, miradas indiscretas ni demoras. Si los proponentes de bloques se desvían de estas reglas, pueden eludir el impuesto MEV para capturar valor. Por lo tanto, el impuesto MEV actual se basa en confiar en los secuenciadores L2 y puede no funcionar en absoluto en Ethereum L1, porque en la red principal de Ethereum, la construcción de bloques está dominada principalmente por subastas competitivas de constructores para maximizar los ingresos de las personas propuestas.
No obstante, las capacidades y flexibilidad del impuesto MEV sugieren que la priorización puede ser la opción correcta para las plataformas que actualmente pueden ofrecer pedidos prioritarios. Y la relativa simplicidad de la priorización competitiva sugiere que puede haber una manera viable de hacerla cumplir de manera descentralizada sin confiar en un solo secuenciador. Esperamos que este artículo estimule más investigaciones sobre este tema.
orden de prioridad
Cuando alguien envía una transacción en la red principal de Ethereum o L2, especifica una tarifa de prioridad que se paga al proponente del bloque. Puede imaginar que esto se especifica a través de PriorityFeePerGas, un número multiplicado por el gas utilizado en la transacción para obtener BuilderPriorityFee, el monto total pagado en ETH.
No existe ningún requisito en el protocolo Ethereum de que las transacciones en un bloque deban ordenarse con avidez en orden de prioridad descendente FeePerGas. Sin embargo, esta es una forma popular de construir bloques. Por ejemplo, este es el algoritmo predeterminado utilizado por el secuenciador de la cadena OP Stack y geth y reth. La priorización no sólo permite a los comerciantes expresar efectivamente la urgencia de sus transacciones, sino que también, naturalmente, dirige ciertos tipos de MEV a bloquear a los proponentes.
Esto sucede porque la priorización convierte la competencia por los MEV en subastas de gas priorizadas. Cuando existe la oportunidad de beneficiarse de la interacción con la cadena, como mediante el arbitraje entre AMM e intercambios centralizados, los buscadores compiten para ser los primeros en aprovechar la oportunidad. Si la cadena utiliza la priorización para determinar el empaquetado y orden de las transacciones, los buscadores competirán estableciendo tarifas de alta prioridad para sus transacciones.
En un escenario competitivo donde la competencia reduce a cero las ganancias libres de riesgo, el buscador ganador debería en última instancia pagar el MEV completo como tarifa de prioridad. Por lo tanto, si se puede obtener una ganancia de 100 ETH al interactuar con el contrato, la primera transacción que aproveche la oportunidad establecerá una tarifa de prioridad de 100 ETH. (Discutimos algunas consideraciones para esto en la sección Limitaciones).
Impuesto MEV
Supongamos que un contrato inteligente quiere capturar el MEV en cualquier transacción con la que interactúa. Existe una extensa literatura de investigación sobre varias formas específicas de aplicaciones en las que los contratos inteligentes intentan capturar su propio MEV.
Pero en realidad, no necesariamente necesitamos saber nada específico sobre la aplicación. Si sabemos que los bloques se construyen mediante priorización competitiva, entonces tenemos una señal unificada para la cantidad de MEV en una transacción: la tarifa de prioridad.
Proponemos que los contratos inteligentes puedan observar la tarifa de prioridad de una transacción y cobrar su propia tarifa en función de ella, tarifa que es una función creciente de la tarifa de prioridad. Por ejemplo, el contrato puede requerir que la persona que lo llama transfiera applicationPriorityFee = 99 * proponerPriorityFee 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 una oportunidad tiene un MEV de 100 ETH, 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 dará como resultado que un competidor que establezca una tarifa más alta le quite la oportunidad. Esto significa que el contrato inteligente captura el 99% del MEV en la transacción.
A esta tarifa adicional impuesta por el contrato inteligente la llamamos impuesto MEV. El impuesto MEV permite a las aplicaciones secuestrar la priorización para su propio beneficio, permitiéndoles recuperar MEV para los 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 PriorityFeePerGas tiene un precio en wei (una milmillonésima parte de ETH), tenemos mucha precisión que aprovechar. Por ejemplo, siempre que la sensibilidad del impuesto MEV sea lo suficientemente alta como para que una tarifa por gas prioritaria de 50 000 resulte en un impuesto prohibitivamente alto, entonces el monto total pagado al proponente será inferior a $0,01.
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 (que llamamos “priorización competitiva”) y no se desvían de estas reglas para maximizar sus propios ingresos. Hacer cumplir estas reglas sin confianza es una cuestión abierta.
Captura MEV para una sola aplicación
En una cadena donde se garantiza que los bloques se construirán mediante una priorización competitiva, el impuesto MEV se puede utilizar para aliviar tres problemas importantes con MEV: permitir que las interfaces DEX mejoren la ejecución comercial para los intercambiadores, permitir que los AMM reduzcan las pérdidas de arbitraje en sus LP; billeteras para pasar Vender los derechos a los usuarios de runback para reducir la fuga de MEV de los usuarios.
Buscador de enrutadores DEX
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 al mejor precio.
La versión actual de UniswapX utiliza dos mecanismos para ejecutar esta competencia: una subasta holandesa, donde el precio límite de Alice cambia con el tiempo hasta que lo llena un buscador, y una subasta inicial de solicitud de cotización (RFQ) fuera de la cadena para establecer el precio inicial para esa competencia. Subasta holandesa .
En una plataforma que garantiza una priorización competitiva, UniswapX puede reemplazarlos con un mecanismo: el impuesto MEV. Funciona permitiendo a los usuarios firmar una orden que cualquiera puede completar instantáneamente, pero el precio de ejecución es una función de la tarifa de prioridad de la transacció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 * prioridadFeePerGas). 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. Cualquier operación con la tarifa de prioridad más alta y sin respaldo completará la orden, lo que debería garantizar que el comerciante obtenga el mejor precio que el buscador pueda encontrar. (Algunas excepciones a esto se analizan en la sección Limitaciones).
Si el precio más bajo de Alice es $3000 y el precio actual de ETH es $3500, la prioridad FeePerGas en la transacción ganadora es de aproximadamente 50 000. (Tenga en cuenta que en una transacción que cuesta 200.000 gas, esto daría como resultado que solo se pagaran ~10 mil millones de wei (~$0,000035) al proponente del bloque.
Esto tiene algunas ventajas potenciales sobre los mecanismos existentes utilizados en UniswapX.
Los pedidos que utilizan el impuesto MEV se pueden ejecutar más rápido y a mejores precios que los pedidos que utilizan las subastas holandesas. Como se describe en este artículo, las subastas holandesas en cadena pierden algo de valor hacia MEV debido a cambios de precios entre bloques y pueden requerir varios bloques para completarse. Por el contrario, los pedidos que utilizan un impuesto MEV generalmente se pueden completar en el siguiente bloque y capturar la gran mayoría de su MEV.
A diferencia de las RFQ fuera de la cadena, las subastas que utilizan impuestos MEV para ejecutar pedidos se producirán de forma atómica cuando se ejecuten las transacciones dentro de la cadena. Esto significa que el postor ganador tiene la garantía de que la orden solo se ejecutará si su transacción en cadena tiene éxito. Esto puede facilitar que la liquidez dentro de la cadena (como AMM) compita con la liquidez fuera de la cadena, lo que significa que UniswapX puede servir como un enrutador más eficiente para subsistemas de grupos múltiples (como Uniswap v4).
Creador de mercado automatizado (AMM)
A menudo, los AMM pierden valor debido a que los arbitrajistas negocian a precios obsoletos en la parte superior de los bloques, como se analiza en el documento sobre pérdida versus reequilibrio. Podemos utilizar el impuesto MEV para permitir que AMM capture estos MEV. En aras de la simplicidad, analizaremos cómo implementar esto en una AMM sin liquidez centralizada. (Si está interesado en cómo resolver este tipo de problema con liquidez centralizada, Sorella lanzará una solución pronto).
Los AMM pueden capturar MEV cobrando una tarifa adicional según la prioridad de la transacción, lo que les permite subastar los derechos para priorizar las transacciones en un bloque. Hay muchas formas de calcular y valorar esta tarifa. Analizaremos un enfoque que podría decirse que es neutral: expresado en unidades de liquidez del pool sqrt(xy). Las operaciones ganadoras serán aquellas que aumenten más la liquidez del pool.
Al ejecutar la primera transacción en el grupo en un bloque, x_end * y_end > x_start * y_start el grupo puede imponer una condición (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, después de lo cual el precio medio del pool debería ser el precio real.
Después de esa primera transacción, las transacciones pueden funcionar como en Uniswap v2, utilizando tarifas de cambio fijas. Los comerciantes desinformados que deseen operar sin pagar impuestos MEV adicionales establecerán tarifas de prioridad más bajas.
Hay muchas otras formas de implementar el impuesto MEV a AMM, que tendrán diferentes efectos. Por ejemplo, los impuestos MEV pueden expresarse en tokens de entrada o salida del intercambio, pueden afectar el porcentaje de la tarifa de intercambio aplicado por el grupo o pueden 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.
Subastas retrasadas
La descripción anterior muestra cómo se pueden diseñar ciertas aplicaciones para evitar fugas de MEV. Pero, ¿qué pasa si una billetera quiere ayudar a sus usuarios a capturar el MEV que generan a partir de cualquier transacción con la que interactúan con cualquier aplicación, incluso si esas aplicaciones no incluyen impuestos MEV?
Por ejemplo, cuando Alice realiza una gran operación en AMM, a veces crea una oportunidad de arbitraje para que los "backrunners" recuperen el precio a la normalidad. Normalmente, estas oportunidades se filtran a MEV en lugar de ser propiedad de Alice.
MEV-Share y MEVBlocker son dos protocolos que permiten a los usuarios capturar MEV de sus transacciones, pero dependen de complejos sistemas de subasta fuera de la cadena. "El espacio de diseño de subastas Orderflow" describe algunas otras soluciones.
Cuando el impuesto MEV se combina con una billetera de contrato inteligente basada en la intención, podemos construir un sistema alternativo para capturar el MEV final de Alice. Supongamos que Alice no crea una transacción para negociarse 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 a la persona que realizó la transacción un impuesto MEV, que se paga a Alice.
El buscador que envió la intención de Alice tiene el derecho exclusivo de seguirla porque puede hacerlo de forma atómica dentro de la misma transacción. Por lo tanto, si la búsqueda es altamente competitiva, todas las ganancias derivadas del seguimiento de Alice deberían ir a parar a Alice a través de su impuesto MEV.
Es importante tener en cuenta que es posible que este sistema no proteja completamente a los usuarios de los ataques de ejecución anticipada, ya que la ejecución anticipada puede evitar el pago de impuestos MEV a los usuarios. Este problema (y algunas de sus posibles mitigaciones) se analiza en detalle en la sección Limitaciones a continuación. Aún así, esto es al menos una mejora con respecto a un sistema de grupo de memoria público sin mitigaciones.
Otros casos de uso
Además de estos ejemplos, otros usos potenciales del impuesto MEV incluyen casi todos los escenarios en los que actualmente se utilizan subastas holandesas o fuera de la cadena, como por ejemplo:
Los protocolos como Oval funcionan capturando el valor extraíble de Oracle (OEV) que crean.
Subastas de refinanciación en protocolos de préstamos hipotecarios NFT como Blend.
La liquidación de un contrato de préstamo pierde menos valor que una subasta holandesa.
Captura MEV entre aplicaciones
La solución anterior está diseñada para capturar el MEV generado al interactuar con una sola aplicación. Sin embargo, a veces un buscador puede capturar más valor interactuando con múltiples aplicaciones en la misma transacción.
Si solo una de estas aplicaciones utiliza el impuesto MEV, entonces todos los MEV de la transacción deben atribuirse a la aplicación que utiliza el impuesto MEV, independientemente del impuesto MEV.
Pero, ¿qué pasa si la transacción del buscador interactúa con dos aplicaciones que utilizan el impuesto MEV? Por ejemplo, si ciertos MEV solo se pueden capturar completando una orden UniswapX gravada con MEV contra un AMM gravado con MEV.
En este caso, el monto relativo del exceso de MEV capturado por cada aplicación está determinado por el impuesto MEV establecido por esas aplicaciones. Si el valor del impuesto app_i como 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 para la prioridad: tax_ 1(priorityPerGas) + tax_ 2(priorityPerGas) = MEV total
(Técnicamente, podríamos agregar un tercer término prioridadPerGas * gasSe utiliza para contabilizar la tarifa de prioridad pagada al proponente del bloque, pero ignoraremos esto porque, como se analiza en el Apéndice A, en circunstancias normales, el costo de prioridad probablemente sea insignificante).
En el caso simple de un impuesto MEV lineal en prioridadPerGas (por lo tanto, tax_ 1(priorityPerGas) = a_ 1 * prioridadPerGas), puede resolver la participación de MEV que recibe 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
Una aplicación se enfrenta a una compensación al establecer su propio impuesto MEV: una tasa impositiva más alta le permite capturar una mayor proporción del MEV entre aplicaciones a medida que ocurre, pero significa que puede perder algunos MEV entre aplicaciones si hay competidores. métodos de extracción. Por ejemplo, si hay un AMM que cobra el impuesto MEV en cada transacción, entonces el pedido UniswapX del impuesto MEV puede ser 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 para compartir el MEV de una manera que maximice su bienestar respectivo. Por ejemplo, un AMM de Impuestos MEV podría querer capturar valor de un único comerciante informado cerca de la parte superior del bloque, pero luego querer ponerlo a disposición de otros comerciantes y aplicaciones (incluidos aquellos que utilizan Impuestos MEV) con una fluidez de tarifa fija más baja. En este caso, el AMM podría establecer un impuesto MEV relativamente bajo (por ejemplo, $0,00001 * prioridadFeePerGas) para que las transacciones de arbitraje (si las hay) se realicen al principio del bloque y luego en las transacciones posteriores del bloque no se cobre ningún impuesto MEV. Las aplicaciones como UniswapX que desean interactuar con AMM pueden establecer un impuesto MEV más alto (como $0,01 * prioridadFeePerGas) para garantizar que sus transacciones se incluyan después de que el grupo ya haya arbitrado. Con estos impuestos relativos, incluso si solo hay $1 MEV y $50,000 MEV en el pedido de UniswapX, el AMM eventualmente será arbitrado en primer lugar.
Creemos que este es un amplio espacio de diseño digno de futuras investigaciones.
limitación
El impuesto MEV tiene algunas complejidades y trampas. Creemos que estas son áreas interesantes para futuras investigaciones.
Incompatibilidad de incentivos
Los impuestos a los MEV son incompatibles con los incentivos para los proponentes de bloques monopolísticos. Sólo funcionan si existe una competencia justa para la inclusión de transacciones, lo que sólo ocurre si los proponentes de bloques siguen reglas que llamamos “priorización competitiva” en lugar de maximizar sus propios ingresos. Recomendamos que estas reglas incluyan:
Priorización: las transacciones en un bloque deben ordenarse en orden descendente de prioridadFeePerGas.
Resistencia a la censura: si el proponente del bloque recibe la transacción t 1 al construir el bloque, y el bloque no está lleno o contiene la transacción t 2 y t 2.priorityFeePerGas < t 1.priorityFeePerGas, entonces el bloque debe contener la transacción t 1.
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 estas transacciones con nadie antes de enviar el bloque, ni pueden usar el contenido de estas transacciones para construir sus propias transacciones.
No se ha fijado ningún momento. Los proponentes de bloques deben establecer un tiempo claro (blockTime) antes del cual aceptan transacciones de cualquier persona y después del cual no aceptan transacciones de nadie.
Si se viola uno o más de estos atributos, la efectividad del impuesto MEV puede verse disminuida. Los proponentes de bloques que violan la resistencia a la censura pueden aprovechar la oportunidad excluyendo transacciones competidoras y presentando una transacción de prioridad cero para evitar la mayoría de los impuestos MEV. Un proponente de bloqueo que viola la privacidad previa a la transacción puede robar MEV de otras transacciones, o echar un vistazo a sus tarifas de prioridad y saber qué tan alta debe establecerse una tarifa de prioridad para superar a los demás, mientras que un proponente que puede enviar transacciones más tarde que otros es La libertad de “decidir finalmente” si superar la oferta de otros crea problemas de selección adversa que, en última instancia, sofocan 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 a nivel de protocolo, se debe confiar en que un secuenciador comprometido con estas reglas no se desvíe de estas reglas si el proponente subcontrata la construcción del bloque a una subasta competitiva que maximiza los ingresos (como MEV-Boost de Ethereum mainnet), bloquea puede que no los siga.
Estos problemas pueden ser "resueltos" por un único ordenante confiable que se comprometa a construir bloques utilizando una priorización competitiva. También se puede resolver con un mecanismo descentralizado mediante el uso de alguna combinación de consenso, criptografía y/o un entorno de ejecución confiable, como Angstrom de Sorella, SUAVE de Flashbots, Leaderless Auctions o Multiplicity.
bloque completo
Existen excepciones al funcionamiento normal del impuesto MEV cuando un bloque está completamente lleno. En este caso, es posible que el proponente del bloque tenga que excluir transacciones de baja prioridad en lugar de simplemente incluirlas más adelante en el bloque. Dado que es probable que las transacciones que interactúan con aplicaciones que utilizan impuestos MEV tengan tarifas de prioridad muy bajas, estas aplicaciones pueden verse desplazadas por aplicaciones que no utilizan impuestos MEV o aplicaciones que utilizan 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 raro que un bloque esté completamente lleno. Además, dada la necesidad de retrasar algunas transacciones cuando un bloque está lleno, retrasar las transacciones que expresan menor urgencia estableciendo un impuesto MEV más alto puede ser un resultado razonable.
Transacción de reversión
El impuesto MEV se basa esencialmente en subastas de un solo bloque, donde cada “oferta” es una transacción. Una desventaja de este tipo de subasta es que las ofertas fallidas a menudo resultan en la inclusión de transacciones de reversión en la cadena, el pago de algunas tarifas básicas y la congestión de la cadena.
Esto aliviaría este problema si el secuenciador pudiera excluir por completo las transacciones fallidas, aunque esto sería difícil de lograr incluso con un secuenciador centralizado. (Esto tampoco se adhiere completamente a las propiedades resistentes a la censura descritas anteriormente, aunque esa definición puede modificarse). Un secuenciador más sofisticado podría optimizar este proceso al permitir que las transacciones especifiquen en qué subastas de disputas participan, permitiendo así la secuenciador omita lo que sabe que las transacciones posteriores fallarán.
Revelar la intención del usuario
El impuesto MEV sólo funciona si hay competencia entre los buscadores, lo que significa que la oportunidad debe ser bien conocida 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 ofertas finales, esto significa que es posible que la aplicación necesite compartir la intención del usuario con el buscador.
En algunos casos, la privacidad temporal que se pierde al transmitir la intención del usuario antes de que se implemente puede perder valor de una manera que el impuesto MEV no puede recuperar.
Por ejemplo, supongamos que Alice quiere comprar un token de baja liquidez utilizando el protocolo de subasta final descrito anteriormente. Publica una intención firmada en su billetera de contrato inteligente para comprar el token en AMM y establece cierta tolerancia de deslizamiento. El buscador puede competir en transacciones 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 la intención de Alice de manera no competitiva al incluir y revertir la intención de Alice en una transacción de baja prioridad, 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.
Tenga en cuenta que tal ataque es riesgoso para Bob porque no puede garantizar la atomicidad entre comprar el token y venderlo a Alice. El ingenuo Bob puede ser víctima de la trampa de la "desgarro del sándwich", en la que Alice publica su intención de comprarse una ficha sin valor, lo que hace que Bob la compre con la esperanza de intercalar su transacción, pero Alice rescinde su intención antes de que Bob pueda terminar la transacción. sándwich.
Las aplicaciones también pueden mitigar esto limitando el conjunto de buscadores con los que comparten intenciones y monitoreando su comportamiento, como es el caso de muchas subastas de flujo de órdenes existentes.
También es posible combinar los impuestos MEV con funciones de creación conscientes de la privacidad, como las previstas en el diseño SUAVE de Flashbots.
Finalmente, si Alice decide que el costo de compartir sus intenciones supera los beneficios de la búsqueda competitiva, puede construir una transacción ella misma y enviarla directamente al bloque. Como se mencionó anteriormente, una implementación ideal de priorización competitiva proporcionaría privacidad previa a la transacción para los proponentes de bloques.
Discusión y trabajo preliminar.
Subasta de Gas Prioritario. El artículo de Flash Boys 2.0 examina algunas de las dinámicas de priorización en cadenas de bloques descentralizadas, acuñando el término "valor extraíble por minero". El documento observa que los mineros de Ethereum (cuando la red usaba prueba de trabajo) habían priorizado transacciones, y que los arbitrajistas se basaron en este comportamiento para participar en una "subasta de gas prioritario" en la que pujaron por el derecho a ser incluidos primero en un bloque. , lo que hace que la mayor parte del MEV del arbitraje de intercambio descentralizado se acumule en los mineros.
El primero en llegar es el primero en ser atendido. Algunos intentos de mitigar MEV a través del orden de transacciones (como el secuenciador actual de Themis o Arbitrum One) se centran en hacer cumplir una regla de orden diferente, por orden de llegada (a veces llamado "orden justo"), donde los proponentes de bloques deben ordenar como lo ven. transacciones por orden de llegada.
La priorización adopta un enfoque diferente: las transacciones que llegan dentro de un período de tiempo determinado se tratan de la misma manera y se clasifican según su prioridad declarada.
El "orden justo" es difícil de aplicar o incluso definir en un entorno de red real con múltiples validadores. También puede provocar carreras de latencia inútiles y spam, incluso con un único secuenciador confiable. Finalmente, un impuesto a los MEV podría eliminar ciertos MEV “por orden de llegada”, como las ganancias de arbitraje derivadas de “saltos” discretos en los precios de los activos. Las ventajas potenciales de la priorización sobre la clasificación por orden de llegada están relacionadas en parte con las ventajas del intercambio en tiempo discreto sobre el intercambio en tiempo continuo analizadas en Budish, Cramton, Shim (2015).
Además, si bien la priorización parece perder valor a MEV de forma predeterminada, esta publicación muestra cómo diseñar aplicaciones para recuperarlo.
Compratir costos. Blast es Ethereum L2 y comparte algunas 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 las tarifas de prioridad), pero se puede implementar en la capa de aplicación en cualquier cadena utilizando una priorización competitiva sin requerir un soporte especial para compartir las tarifas. También permiten que las aplicaciones definan sus propios impuestos como funciones personalizadas de tarifas prioritarias, lo que proporciona una mayor flexibilidad y potencialmente mejora la componibilidad de las aplicaciones compatibles con MEV.
Soluciones sin confianza. Este artículo se centra en las motivaciones de las plataformas para utilizar la priorización competitiva y los métodos para aprovechar las plataformas de priorización competitiva, en lugar de discutir cómo aplicarla sin confianza.
Cada uno de los demás atributos necesarios para la priorización competitiva se ha discutido ampliamente anteriormente. Por ejemplo, en Fox, Pai, Resnick (2023), los autores analizan las vulnerabilidades en las subastas en cadena sin resistencia a la censura y describen el diseño de subastas resistentes a la censura utilizando múltiples proponentes simultáneos. Sin embargo, no recomiendan 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 el paquete de transacciones públicas forzadas de Péter Szilági.
en conclusión
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 motive a las aplicaciones a probar los impuestos MEV si son compatibles.
También esperamos que inspire más investigaciones sobre protocolos de priorización competitiva que minimicen la confianza en L1 y L2.
nota
En este artículo, utilizamos "proponente" para referirnos al actor o proceso que determina qué transacciones se incluyen en un bloque específico. En Ethereum L2, esta función suele ser desempeñada por el "secuenciador". En Ethereum L1, está poblado por un validador de Ethereum específico, llamado proponente, aunque los proponentes generalmente subcontratan la tarea de construir bloques en subastas competitivas en las que participan "retransmisores" y "constructores". Los detalles de cómo se dividen estas responsabilidades están fuera del alcance de este artículo.
En realidad, la tarifa de prioridad por Gas no se especifica explícitamente en la transacción, pero se puede calcular en la transacción. La transacción especifica un precio del gas, pero Ethereum también cobra una tarifa base, que se toma del precio del gas y se destruye. En lo que respecta al impuesto MEV, el cargo base debe ignorarse ya que está fuera del control del concesionario. La tarifa de prioridad por Gas (es decir, el precio de la parte de las tarifas de transacción que va al proponente del bloque) se puede calcular en Solidity como prioridadGasPrice = tx.gasprice - block.basefee.
Simplemente podemos definir "MEV" para excluir las ganancias del buscador y solo hacer referencia al valor que fluirá hacia el validador.
Tenga en cuenta que el proponentePriorityFee en realidad no se puede calcular como un múltiplo del monto total de prioridad de gas de PriorityFeePerGas utilizado en la transacción (igual al gas total utilizado en la transacción) durante el contrato, porque no hay forma de saber cuánto gas utilizará finalmente la transacción. . Sin embargo, esto normalmente no importa ya que todo lo que necesitamos es un límite superior. Para estar seguro, puede multiplicar el feePerGas prioritario por 30 millones: este es el gas máximo actual en un bloque de Ethereum. Sobreestimar este valor sólo significará que los impuestos a los MEV representan una proporción mayor de los MEV.
Suponiendo que una transacción no pueda exceder los 30 millones de gas, una tarifa de prioridad por gas de 50 000 resultaría en un pago de gas de 1500 gwei, aproximadamente $0,006 a un precio ETH de $4000.
Si la prioridad FeePerGas se establece de modo que la ganancia del arbitrajista sea cero, entonces la operación de arbitraje que maximiza las ganancias debe corresponder a la misma operación en el AMM que maximiza la función.
Arbitrum ha discutido reemplazarlo con una forma de priorización llamada Timeboost, pero al momento de escribir este artículo, aún no está en producción.
