El protocolo Ethereum y el ecosistema más amplio tienen como objetivo mejorar continuamente el valor que Ethereum puede proporcionar. Una restricción clave en todo el ecosistema para mejorar Ethereum ha sido el Valor Extraíble Máximo (MEV).MEV). MEV se refiere al valor máximo que el agente del protocolo responsable de incluir, ordenar y excluir transacciones en un bloque puede extraer del sistema. Esta publicación resume los métodos propuestos para mitigar los efectos negativos de MEV en las aplicaciones y el protocolo, e investiga las direcciones futuras de investigación.

Este post está organizado de la siguiente manera:

La primera sección propone una categorización bidimensional de técnicas de mitigación de MEV fuera del protocolo. Se explora un ejemplo de cada categoría.

La sección posterior explora por qué el protocolo Ethereum no puede funcionar como la infraestructura que previene o rebaja MEV.

En tercer lugar, exploramos lo que el protocolo de Ethereum hace para prevenir las externalidades negativas de MEV.

Finalmente, sostenemos que ninguno de las técnicas de mitigación de MEV discutidas dentro o fuera del protocolo puede resolver todos los problemas causados por MEV simultáneamente.

El comienzo de esta publicación funciona como una sistematización parcial del conocimiento sobre la mitigación de MEV. Sin embargo, la cuarta sección presenta un argumento relativamente novedoso de que la mitigación de MEV fuera del protocolo no resuelve los problemas de MEV dentro del protocolo. Este argumento se basa en un papelporDavide Crapisy yo.

Esta publicación se refiere a técnicas de mitigación dentro y fuera del protocolo. Con técnicas de mitigación MEV dentro del protocolo, nos referimos a mecanismos que son parte de las reglas del protocolo Ethereum o que requerirían cambiar las reglas del protocolo Ethereum. Las técnicas de mitigación fuera del protocolo son todos los mecanismos que no están en el protocolo.

Mitigación de MEV fuera del protocolo

MEV impone rentas a los usuarios que interactúan con una cadena de bloques. Para aumentar el valor que facilita Ethereum, es intuitivo disminuir la renta que representa MEV. El mandato de las técnicas de mitigación de MEV fuera del protocolo es disminuir el efecto inhibidor de valor que plantea MEV sin cambiar las reglas del protocolo de Ethereum.

Utilizaremos cómo se extrae MEV en los Automated Market Makers (AMMs) y, por consiguiente, cómo se puede mitigar como ejemplo. Muchos AMMs funcionan de la siguiente manera:

Los proveedores de liquidez (LPs) proporcionan varios tokens diferentes a un AMM y permiten que el AMM establezca los precios contra los cuales los usuarios pueden comerciar con los tokens del LP.

Un AMM ajusta sus precios solo en respuesta a las transacciones incluidas en los nuevos bloques. Este ajuste discreto contrasta con las continuas fluctuaciones de precios de los tokens subyacentes en los mercados externos.

Cuando se necesita proponer un bloque, el productor de bloques puede incluir transacciones que utilizan el precio de mercado externo públicamente observable para arbitrar las cotizaciones obsoletas en un AMM, extrayendo así MEV.

Esta forma de MEV, conocida como Reequilibrio de Pérdidas-Versus-Reequilibrio (LVR)es un costo para los proveedores de liquidez. Manteniendo constantes las comisiones que se acumulan para los proveedores de liquidez, la cantidad de liquidez proporcionada disminuye con la cantidad de LVR extraído del AMM. Menos liquidez significa que las operaciones de los usuarios tienen un mayor impacto en el precio, lo que significa que es más caro para los usuarios operar en el AMM. Un objetivo del diseño de AMM es disminuir el costo que LVR impone en el AMM. De manera similar, un objetivo del diseño de la aplicación, en general, es disminuir el costo de MEV en los usuarios.

Hay muchas maneras en las que se puede reducir el costo de MEV. A grandes rasgos, las técnicas de mitigación de MEV fuera de protocolo se dividen en dos ejes:

• Técnicas de mitigación de MEV de infraestructura específica de la aplicación o compartida.
• Previniendo MEV o reembolsando MEV.

El primer eje es si una aplicación mitiga MEV por sí misma o se basa en alguna infraestructura compartida. El segundo eje es más complicado. Una aplicación podría diseñarse para evitar la exposición del MEV en primer lugar, o podría vender el derecho a extraer el MEV y reembolsar los ingresos por ventas a los extraídos. El reembolso de MEV hace un uso incorrecto de la definición de MEV, que es el valor que el actor responsable de incluir, ordenar y excluir transacciones puede extraer del sistema. El MEV que se rebaja no se extrae del sistema y, por lo tanto, no se ajusta estrictamente a la definición de MEV. Aun así, el uso del término MEV puede ser útil, ya que todos los conceptos relacionados con MEV se aplican al valor que se reembolsa, independientemente de a dónde van los ingresos. Veremos ejemplos de las cuatro posibilidades y discutiremos sus ventajas relativas.

Figura 1: Categorización bidimensional de las técnicas de mitigación de MEV fuera del protocolo con ejemplos para cada categoría.

Aplicación específica y prevención de MEV: La función que maximiza AMM.

La técnica de mitigación de MEV que suele ser conceptualmente más intuitiva para aquellos que escuchan sobre MEV por primera vez es una aplicación que evita la exposición a MEV. Un ejemplo emocionante es el función de maximización AMM propuesto por Andrea Canidio y Robin Fritsch. Realiza lotes de operaciones recopiladas durante un período de tiempo y las ejecuta todas a un precio de liquidación uniforme. Los autores muestran que elimina LVR y el sandwiching, otra forma de MEV. La intuición es que todos los participantes negocian al precio marginal del grupo después del lote y que los arbitrajistas tienen incentivos para negociar hasta el punto en que este precio sea igual al precio del mercado externo. Este sistema es similar a una subasta de lotes frecuente propuesta por Budish, Cramton, and Shim (2015)en la literatura de finanzas tradicionales. Por cierto, es un excelente ejemplo de sinergias entre las finanzas descentralizadas y tradicionales. Las ideas de finanzas tradicionales se pueden implementar en las finanzas descentralizadas; el aprendizajes de la implementaciónpuede luego ser utilizado para informar las finanzas tradicionales.

MEV específico de la aplicación y de reembolso: el MEV que captura AMM.

La MEV capturando AMM (McAMM) es un ejemplo de una mitigación de MEV específica de la aplicación que se basa en la retirada. El McAMM subasta el derecho a ser el primer trader en interactuar con el AMM en un bloque, lo que permite a este trader extraer un posible arbitraje. Los ingresos de la subasta se distribuyen entre los proveedores de liquidez arbitrados. Si la subasta es eficiente, los ingresos deben ser iguales al valor de arbitraje extraído de los proveedores de liquidez. Este diseño podría conducir a la misma eliminación de LVR que la función de maximización de AMM discutida anteriormente, aunque el enfoque es radicalmente diferente. Que esto ocurra en la práctica depende en gran medida de las implementaciones específicas de la subasta.

Infraestructura y devolución de MEV: MEV-Share.

El reembolso no tiene que ser específico para una aplicación. Flashbots, una empresa que opera en el espacio de construcción de bloques, ha desarrolladoParticipación en MEV. Permite a los usuarios elegir qué datos de transacción compartir en una subasta de forma privada. Los postores ofrecen por el derecho de colocar esta transacción en un paquete y así extraer MEV de ella. El usuario puede recibir los ingresos de la subasta. Esta infraestructura no es específica de la aplicación, ya que las transacciones podrían interactuar con cualquier aplicación.

Infraestructura y prevención de MEV: flujo de órdenes protegido en un mundo con fines de lucro.

Finalmente, existen mecanismos infraestructurales que buscan prevenir la extracción de MEV. Un ejemplo es Flujo de orden protegido en un mundo en busca de beneficios (PROF). PROF se basa en un productor de bloques dentro de un entorno de ejecución de confianza (TEE) que se compromete de manera creíble con una regla de pedido, por ejemplo, por orden de llegada. Los TEE tienen dos propiedades críticas que hacen que el compromiso sea creíble, a saber:

• [ ] Integridad: el código y los datos dentro del TEE no pueden ser modificados o manipulados, ya sea durante la ejecución o mientras están almacenados, por entidades externas como el sistema operativo, el hipervisor o actores malintencionados.
• [ ] Confidencialidad: los datos y cálculos dentro del TEE permanecen privados e inaccesibles para entidades no autorizadas, incluido el sistema host, otras aplicaciones o atacantes.

Cualquier usuario que envíe su transacción a un productor de bloques que se comprometa a ejecutar una regla de pedido sabe que el productor de bloques en el TEE lo hará. Por lo tanto, PROF puede evitar ciertos tipos de extracción MEV, como la ejecución frontal para cualquier aplicación, sin cambiar las reglas del protocolo Ethereum.

Diferentes técnicas de mitigación de MEV tienen diferentes pros y contras. Las técnicas de prevención de MEV específicas de la aplicación son difíciles de encontrar, ya que requieren mucha investigación y trabajo de implementación por aplicación. Por otro lado, la prevención de MEV infraestructural requiere mucho sobrecarga. Por ejemplo, algunas técnicas de prevención de MEV infraestructural requieren ejecutar hardware costoso y hacer mucho desarrollo comercial. Si el reembolso es efectivo depende en gran medida de si la subasta es competitiva, lo que depende de detalles de la subasta como su formato y cuándo tiene lugar.

Es posible que estas cuatro técnicas de reducción del MEV no sean colectivamente exhaustivas ni totalmente excluyentes entre sí. Tenga en cuenta también que las dimensiones se asemejan a espectros y no a binarios, como se muestra en la Figura 1. Por ejemplo, algunas técnicas de mitigación de MEV pueden ser más infraestructurales que otras. El campo se mueve muy rápidamente, lo que hace que cualquier categorización sea un desafío. Finalmente, el espacio se siente optimista, y muchos pueden compartir la opinión de que el MEV como porcentaje del valor total facilitó se reducirá rápidamente.

La falta de mitigación MEV en el protocolo

Estas técnicas de mitigación de MEV pueden parecer insatisfactorias para algunos. ¿Por qué Ethereum no puede ser la infraestructura de protocolo que resuelve holísticamente el MEV? Tal vez algunos lectores sugieran usar una regla de ordenación específica. Las propuestas para hacer cumplir una regla de ordenación particular en Ethereum, como gatekeeping, son controvertidas y tienen sus propias desventajas.primero en llegar, primero en ser servidoNo ha ganado un amplio apoyo. Creo que hay dos razones fundamentales por las cuales el protocolo no ha podido resolver de manera integral la carga que MEV impone a los usuarios finales y las aplicaciones, ambas están relacionadas con la restricción de neutralidad creíble de Ethereum.

Primero, Ethereum no puede obtener un orden global transitivo que satisfaga la "equidad". Ethereum alberga una variedad de aplicaciones que cada una puede beneficiarse de diferentes tipos de reglas de ordenación. Si bien el orden de llegada puede ayudar a algunas aplicaciones, puede inhibir el crecimiento de los demás. Por lo tanto, es difícil para el ecosistema ponerse de acuerdo en lo que es justo. Además, incluso si el ecosistema llegara a un acuerdo sobre una regla de ordenación justa, es difícil obtener una regla de ordenación globalmente transitiva porque una transacción puede llegar a diferentes nodos en momentos diferentes.

Estas inconsistencias causan problemas en los protocolos de ordenación de primera llegada, primera servida. Específicamente, incluso si el orden en el que los nodos individuales reciben transacciones es transitivo, no significa que el orden agregado también sea transitivo. Las reglas de ordenación de primera llegada, primera servida pueden quedar atrapadas en ciclos para restaurar la transitividad, y a veces, estos ciclos tienen que resolverse mediante una regla arbitraria, como elegir un orden total alfabéticamente. Esto puede significar que las transacciones para las que el orden de primera llegada, primera servida es más importante, como las transacciones de arbitraje sensibles al tiempo, no se ordenen de esta manera, sino arbitrariamente.

Figura 2: Diapositiva que muestra los ciclos de Condorcet en los que las reglas de ordenación de primero en llegar, primero en ser servido pueden quedarse atascadas. Diapositiva tomada de una presentación sobre Themis por Mahimna Kelkar.

Además del hecho de que las reglas de ordenación de primero en llegar, primero en ser servido tienen problemas teóricos, no está clarosi son deseablesen primer lugar. Esta regla de ordenación beneficia a aquellos con conexiones más rápidas. Si las conexiones rápidas son lo suficientemente valiosas, esto podría llevar a una carrera de latencia, como se ve en finanzas tradicionalescon grandes inversiones en tecnología de velocidad. La tecnología de velocidad podría dañar la neutralidad creíble en las blockchains ya que incentiva la centralización geográfica.

Las visiones inconsistentes sobre cuándo llegan las transacciones causan problemas para la regla de ordenación de primero en llegar, primero en servir y para cualquier regla de ordenación. Las reglas de ordenación suelen buscar alcanzar algunas propiedades económicas. Por ejemplo, la ordenación prioritaria del gas busca incluir esas transacciones en orden de cuánto valoran ser incluidas primero. Por lo general, estos deseos económicos se cumplen solo si hay una visión global de qué transacciones deben ser ordenadas. Dado que es difícil obtener una visión global transitiva a partir de visiones locales transitivas, es difícil obtener dicha visión global. En otras palabras, algunos validadores pensarán que una transacción debería ser ordenada dentro de una ranura, mientras que otros pensarán que debería estar en otra ranura, degradando las propiedades económicas que el ecosistema podría esperar recibir de una regla de ordenación fija.

En segundo lugar, el protocolo de consenso no tiene conocimiento de los juegos de MEV que se juegan en la capa de ejecución. Esto haría que fuera difícil diseñar un esquema de reembolso en el protocolo, ya que actualmente el protocolo no entendería qué valor tiene MEV y a quién se debería reembolsar. Finalmente, el protocolo debe permanecer neutral de manera creíble. No debería estar en una posición en la que tenga que tomar una decisión con opinión sobre a quién debería reembolsar el MEV, incluso si pudiera, ni debería elegir técnicas de prevención de MEV que favorezcan aplicaciones específicas sobre otras.

Un ejemplo interesante que se acerca a una técnica de reembolso de MEV en el protocolo es Impuestos MEV, propuesto por Dan Robinson y Dave White. Permite a cualquier aplicación sobrecargar la tarifa de prioridad en el protocolo estableciendo un parámetro, digamos $k$. Cualquier usuario que interactúe con la aplicación tendrá que pagar $k$ veces la tarifa de prioridad que pagó al validador de consenso a la aplicación. Puede ver cómo este sistema podría reembolsar los ingresos de MEV a las aplicaciones de manera generalizada. Por ejemplo, si hubiera 10 ETH de MEV para ser extraídos de una aplicación, con $k = 9$, al ser el primero en interactuar con ella, un usuario puede pagar una tarifa de prioridad de 1 ETH al validador y 9 ETH a la aplicación, asumiendo que las transacciones se ordenan por tarifa de prioridad.

Los impuestos MEV son una dirección prometedora, pero como lo indican sus autores, deben ser explorados aún más para entender cómo funcionarían en Ethereum. Uno de los aspectos desafiantes puede ser que los impuestos MEV asumen que la tarifa de prioridad es una señal universal para la cantidad de MEV. Si bien esto puede ser cierto si se impone un orden de prioridad, el propio ordenamiento puede disminuir la cantidad total de MEV, similar a cómo una subasta de primer precio de varias unidades puede tener una menor ganancia que una subasta combinatoria. Flashbots’SUAVEparece estar dirigiéndose en la dirección opuesta, lo cual permite preferencias más expresivas. SUAVE actualmente no está activo, pero tiene como objetivo construir un generador de bloques descentralizado que fusiona de manera óptima paquetes sin una regla de orden específica.

Las tarifas de prioridad pueden no parecer MEV bien cuando los buscadores quieren expresar sus preferencias para ser incluidos de una manera más compleja que la tarifa de prioridad unidimensional. Quizás un buscador quiera ser incluido dentro del bloque antes que los paquetes de búsqueda competidores, pero no le importa la posición absoluta dentro del bloque. Usar tarifas de prioridad significaría que el buscador compite por la posición con todos los usuarios, independientemente de su relevancia para este buscador.

Hay otras formas de disminuir la MEV extraída de los usuarios además de las reglas de ordenación. Una dirección de investigación es mempools cifradas. Esto significa que los usuarios transmiten transacciones en forma encriptada. Solo después de la inclusión, la transacción se descifra. El productor de bloques, por lo tanto, no conoce el contenido de la transacción, lo que hace imposible llevar a cabo transacciones de front-running basadas en los datos ahora protegidos.

Los mempools encriptados están activos en Gnosis Chain, una blockchain que tiene una arquitectura similar a Ethereum. Los participantes del ecosistema, notablemente Red de obturación , tiene como objetivo llevar los mempools cifrados a la mainnet de Ethereum. Algunos factores limitantes actuales son las suposiciones de confianza que son necesarias con técnicas de criptografía basadas en cifrado de umbral, el estado de las Funciones de Retardo Verificables, y el problemas de disponibilidad de datos gratuitosrelacionado con mempools encriptados.

En resumen, Ethereum no puede ser la infraestructura que evita el MEV porque el ecosistema no ha podido ponerse de acuerdo sobre una regla de ordenación justa y porque es difícil lograr una ordenación global transitiva dada cualquier regla de ordenación. Algunas propuestas para reglas de ordenación, como el ejemplo de impuestos MEV dado anteriormente y actualizaciones de protocolo, se han discutido que podrían facilitar una ordenación global transitiva que satisfaga la "equidad". Sin embargo, actualmente no hay un consenso general sobre si esto es deseable. Ethereum no puede ser la infraestructura que reembolsa el MEV porque la capa de consenso no es consciente de lo que sucede en la capa de ejecución y Ethereum no puede elegir entre aplicaciones, ya que debe mantenerse neutral.

¿Qué hace el protocolo?

El párrafo anterior muestra lo difícil que es para el protocolo eliminar la carga que MEV impone a los usuarios. Sin embargo, muchos mecanismos del protocolo manejan MEV y una completa sección del roadmap de Vitalik está dedicado a ello. ¿Qué hacen estos mecanismos?

Estos mecanismos en el protocolo tienen como objetivo resolver un problema diferente de las técnicas de mitigación discutidas anteriormente. En lugar de maximizar el valor que Ethereum facilita al minimizar el MEV extraído de los usuarios, los mecanismos en el protocolo tienen como objetivo maximizar la neutralidad creíble de Ethereum al minimizar las externalidades negativas del MEV. El MEV no solo disminuye la utilidad de aquellos que lo extraen, sino que también distorsiona en gran medida el comportamiento del extractor, por ejemplo, incentiva la centralización a través de economías de escala y causa inestabilidad del consenso.

Las fuerzas económicas son un gran riesgo de centralización para el consenso de Ethereum y, transitivamente, para su neutralidad creíble. Si hay economías de escala, se espera que los pequeños agentes de consenso se fusionen con los grandes agentes para beneficiarse. Si hay retornos a la sofisticación, los validadores racionales pueden comportarse de manera diferente a las especificaciones honestas. Las economías de escala o los retornos a la sofisticación para los agentes del consenso son externalidades negativas de MEV.

El protocolo tiene como objetivo evitar las externalidades negativas desagregando los roles que los agentes de consenso tienen en Ethereum y aislando estos roles entre sí. Actualmente, Ethereum asigna todos los siguientes roles a un solo agente, pero en principio, estos son roles separados. Los tres roles identificados hasta ahora son los siguientes:

• Atestiguar la información necesaria para el consenso y crear bloques de consenso es el papel más crítico en el sistema de consenso de Prueba de Participación de Ethereum. Ejemplos son atestiguar la cabeza de la cadena, atestiguar la oportunidadde mensajes, y creando bloques de consenso cuando sea necesario. Las recompensas por estos roles son bastante homogéneas entre los participantes.
• [ ] Proporcionar el bloque de ejecución. Este rol garantiza la vitalidad de la capa de ejecución. Puede consistir en la presentación oportuna de la carga de ejecución y en la asignación eficiente de los derechos de construcción de la carga de ejecución. Las recompensas de este rol dependen de la tolerancia al riesgo y la velocidad del participante.
• [ ] Construyendo el bloque de ejecución. Este rol decide el orden de las transacciones en una carga de ejecución. Tiene el mayor potencial para extraer MEV del sistema, y claras economías de escala, altas barreras de entrada y sofisticación están asociadas con este rol. Por lo tanto, las recompensas son muy heterogéneas entre los participantes.

El ecosistema de Ethereum tiene como objetivo aislar estos tres roles para que los incentivos que provienen de un rol no afecten los incentivos de aquellos que cumplen otro rol. Algunos roles, como el ordenamiento de transacciones, pueden ser más centralizados siempre que la validación de bloques sea confiable y altamente descentralizada, y un conjunto descentralizado de participantes pueda garantizar la resistencia a la censura, como Vitalik afirmó en su influyente...Publicación de Endgame.

Separación de Proponente-Constructor (PBS) tiene como objetivo separar las funciones de proponer y construir la carga útil de ejecución. Es una filosofía de diseño que reconoce las diferentes funciones y facilita la externalización de la responsabilidad de construcción de bloques del proponente a una parte especializada. MEV-Boost es la instantánea actual fuera del protocolo de PBS. Permite a todos los proponentes, independientemente de su sofisticación, acceder a los mismos mercados de MEV. Concretamente, garantiza que el constructor reciba el derecho de construir el bloque y que el proponente reciba su pago por vender este derecho. Con MEV-Boost, un proponente no se beneficia invirtiendo en técnicas sofisticadas de extracción de MEV, pero puede seguir siendo relativamente poco sofisticado en esta área y disfrutar de las mismas recompensas que los proponentes más sofisticados.

Separación Attester-Proposer (APS)es conceptualmente similar a PBS. También reconoce la diferencia entre dos roles: atestiguar y proponer bloques de consenso y proponer bloques de ejecución. APS se encuentra actualmente en la fase de investigación y no hay ninguna versión fuera del protocolo en vivo. Los proponentespuede que quiera ser rápidoporque les permite enviar su bloque más tarde, lo que significa que pueden incluir más transacciones. Es vital para el protocolo de consenso no incentivar la latencia porque conduce a la centralización geográfica. APS a veces se ve como la última línea de defensa para el protocolo Ethereum.

PBS y APS muestran cómo estos tres roles pueden estar aislados. Sin embargo, implementar estas dos actualizaciones del protocolo también significa que los participantes que crean bloques estarían muy centralizados, lo cual es terrible para la resistencia a la censura. Ethereum tiene como objetivo superar estos problemas construyendo válvulas unidireccionales entre estos roles. El protocolo puede sobrecargar el papel de atestiguar bloques con el de atestiguar qué transacciones están pendientes en el mempool. Un comité de atestiguadores sería entonces responsable de crear una lista de transacciones que el productor de bloques debe incluir, o de lo contrario su bloque sería ignorado por los atestiguadores. Estos tipos de mecanismos se llaman listas de inclusión.

Estas válvulas desafían la separación de roles. Esmuy difícil de diseñarválvulas que utilizan de manera significativa las propiedades de un conjunto de participantes, por ejemplo, restringiendo otro conjunto de participantes, al mismo tiempo que garantizan que aquellos participantes en el otro extremo de la válvula no afecten a los participantes que los afectan. Como ejemplo, el conjunto descentralizado de atestadores sería responsable de crear una lista de inclusión. No queremos que el productor de bloques ni los incentivos de centralización relacionados con la producción de bloques afecten a los atestadores.

Figura 3: División del trabajo por Separación Attester-Proposer (APS) y Separación Proposer-Builder (PBS) con listas de inclusión y venta de derechos de construcción como válvulas unidireccionales entre roles.

No hay una sola solución para dos problemas separados

El objetivo principal de los mecanismos MEV en protocolo difiere fundamentalmente de las técnicas de mitigación de MEV en aplicaciones e infraestructuras. Las técnicas de mitigación fuera de protocolo generalmente tienen como objetivo disminuir el MEV por unidad de valor facilitado. En contraste, las técnicas de mitigación en protocolo tienen como objetivo prevenir las externalidades negativas de MEV que centralizan los agentes de consenso de Ethereum. Técnicas específicas de mitigación de MEV pueden contribuir a ambos objetivos. MEV-Boost, por ejemplo, es técnicamente fuera de protocolo, pero su único objetivo es prevenir las externalidades negativas de MEV.

Además, las restricciones en los dos problemas son diferentes. Los mecanismos dentro del protocolo deben diseñarse teniendo en cuenta los requisitos de hardware y un protocolo neutral. En contraste, las restricciones de las técnicas de mitigación de MEV fuera del protocolo dependen de los deseos de los diseñadores de la aplicación o infraestructura, que pueden adaptarse a un caso de uso particular.

Dado que estos problemas tienen objetivos y restricciones diferentes, es intuitivo que no existe una sola solución que pueda abordar ambos. Además, puede haber una dicotomía más fundamental entre los dos problemas. Esta sección esboza un argumento para esta dicotomía, también presentada en un artículo de Davide Crapis y yo.

Los diseñadores de aplicaciones desean reducir el MEV por unidad de valor porque esto atraería a más usuarios y, por lo tanto, aumentaría el valor total que estas aplicaciones facilitan. Si el MEV por unidad de valor disminuye pero el valor total facilitado aumenta, la cantidad total de MEV podría disminuir pero también podría aumentar. Los mecanismos de MEV en el protocolo se preocupan por la cantidad total de MEV que los agentes de consenso pueden extraer. Incluso si la cantidad total de MEV es una fracción despreciable del valor que Ethereum facilita, no está claro que el protocolo no necesite aún aislar los diferentes roles de consenso necesarios para evitar la centralización en los participantes del consenso de Ethereum.

Como ejemplo de este argumento, considera el caso de Pérdida versus Reequilibrio(LVR), introducido anteriormente como las pérdidas por arbitraje de latencia que enfrentan los proveedores de liquidez en los AMM debido a que sus cotizaciones en cadena quedan obsoletas entre bloques en comparación con el mercado externo en constante actualización. En su trabajo, Milionis et al. encuentran que el LVR acumulativo durante un intervalo es proporcional al tiempo del intervalo elevado a la potencia de 3/2.

A primera vista, esto sugeriría que disminuir el tiempo de ranura también disminuye MEV. Sin embargo, LVR son las pérdidas de arbitraje por unidad de liquidez. Además, Joel Hasbrouck, Thomas Rivera y Fahad SalehmostróLas posiciones individuales de LP pueden considerarse activos en los que se puede invertir. Los rendimientos esperados de los activos suelen basarse en su riesgo. No está claro cómo cambiaría el riesgo de una posición de LP a medida que disminuyen los tiempos de ranura, pero para el bien del argumento, supongamos que permanece constante. Entonces, los rendimientos de una posición de LP deberían permanecer constantes independientemente de los tiempos de ranura; por lo tanto, si los costos por unidad de liquidez disminuyen, los ingresos por unidad de liquidez también deben disminuir. En los AMM, los ingresos disminuirían porque más liquidez fluye hacia el AMM. Más liquidez significa que más unidades de liquidez enfrentan LVR. Por lo tanto, el efecto agregado es ambiguo. Entonces, no está claro cómo cambiaría la cantidad total de MEV derivada de LVR si cambian los tiempos de ranura, incluso si el MEV por unidad de valor puede disminuir.

Además, disminuir el LVR haría que las AMM sean lugares más atractivos para operar debido a que hay más liquidez, lo que significa que más operadores que pagan comisiones utilizan la AMM, lo que lleva a una mayor liquidez. Además, la experiencia del usuario se beneficia de tiempos de bloque más cortos y la cantidad total de MEV derivada del LVR puede aumentar con los tiempos de bloque. Esto es problemático para el protocolo, aunque los usuarios disfrutan de operaciones más eficientes.

Tabla 1: Impacto de los tiempos de ranura en LVR, la cantidad de liquidez y la cantidad total de MEV. Esta tabla muestra cómo el tiempo de ranura afecta el LVR por ranura y el factor por el cual se multiplica la liquidez. Supone que los ingresos por comisiones se mantienen constantes y que el costo de oportunidad por ranura es cero. Los resultados están normalizados con los valores correspondientes al tiempo de ranura de 12 segundos utilizado como referencia.

La Tabla 1 muestra que la cantidad total de MEV originado desde LVR puede mantenerse igual incluso si el tiempo de ranura disminuye. Los valores de esta tabla se generan asumiendo que las tarifas son la única fuente de ingresos, el arbitraje de latencia es el único costo para los proveedores de liquidez, y el costo de oportunidad por ranura permanece constante en cero. Estas suposiciones son demasiado simplistas. Por lo tanto, estos números pueden presentar límites superiores en la liquidez aumentada por ranura y, por lo tanto, en la cantidad total de MEV.

Es difícil decir cómo se mantendrán estas predicciones. El ecosistema sabe poco sobre las motivaciones de los proveedores de liquidez y los intercambios de riesgo y recompensa.incluso menos sobre el comportamiento de los operadores de liquidez. Tal vez los LP consideren el riesgo de las posiciones de LP de manera diferente dependiendo de los tiempos de ranura, lo cual podría ayudar a predecir qué sucede con la cantidad total de MEV a medida que los tiempos de ranura disminuyen.

Potencialmente, este ejemplo se puede generalizar. Las técnicas de mitigación de MEV fuera del protocolo que buscan minimizar el MEV por unidad de valor inducen simultáneamente más valor que fluye a través del sistema; por lo tanto, el impacto de la mitigación de MEV en la cantidad total de MEV es ambiguo. Por lo tanto, creo que Ethereum no puede confiar en la mitigación de MEV fuera del protocolo para evitar las externalidades negativas de MEV en los agentes de consenso.

Renuncia:

1. Este artículo se reimprime de [ Julian Ma], Todos los derechos de autor pertenecen al autor original [Julián Ma]. 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 aprendizaje de gate. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.