> For the complete documentation index, see [llms.txt](https://seednodes.gitbook.io/club-de-nodos/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://seednodes.gitbook.io/club-de-nodos/avanzado/mev.md). # MEV ## Artículos previos: {% embed url="" %} November 27th, 2021 {% endembed %} {% embed url="" %} December 7th, 2021 {% endembed %} {% embed url="" %} March 8th, 2022 {% endembed %} ## Introducción ¿Qué es MEV? Si analizamos las recompensas que recibe un validador de Ethereum podemos clasificarlo básicamente en tres: 1. Emisión del protocolo (inflación) 2. Tarifas que pagan los usuarios (fees) 3. MEV

https://ultrasound.money/#monetary-premium

El **Valor Máximo Extraíble (MEV, por sus siglas en inglés)** se refiere al valor adicional que los validadores pueden obtener debido a su capacidad para: 1. Decidir qué transacciones incluir o excluir de un bloque. 2. Determinar el orden en que se ejecutan las transacciones dentro del bloque. Ambos aspectos tienen implicaciones importantes para el sistema y dan lugar a diferentes tipos de MEV. En este artículo, abordaremos brevemente el MEV relacionado con el primer punto y exploraremos en profundidad el segundo, donde el reordenamiento de transacciones puede generar valor adicional, habilitando prácticas como el *front-running* (adelantamiento) o el *sandwiching* (intercalación). En resumen, el MEV es el valor que los validadores pueden extraer más allá de las recompensas por bloque y las tarifas de transacción. ## **Inclusion/Exclusion** MEV y EIP-1559, un poco de historia {% hint style="success" %} En esta sección hablamos de mineros, porque esto sucedía en la era POW {% endhint %} Una de las motivaciones detrás de la EIP-1559, el sistema actual de tarifas de Ethereum, fue mitigar e incluso eliminar parte del MEV relacionado con la inclusión y exclusión de transacciones. En el sistema anterior, Ethereum utilizaba un mecanismo de subasta para vender el espacio en los bloques, o más específicamente, el gas. Este gas representa el esfuerzo computacional necesario para ejecutar operaciones dentro de Ethereum. Como compradores de este recurso, los usuarios observaban otras transacciones para estimar cuánto estaban pagando (la tarifa por unidad de gas, conocida como *gas price*), y luego ajustaban su propia oferta ligeramente por encima de las existentes. Este proceso generaba ciertas ineficiencias, como el *auction MEV* (MEV de subasta) y el *base* *MEV*. Para entender estos diferentes tipos de MEV pensemos en un momento de alta demanda en la antigua red de Ethereum. En esas circunstancias, no todas las transacciones enviadas podían ser incluidas en el bloque siguiente; solo aquellas que ofrecían tarifas más altas lograban entrar. Consideremos el siguiente ejemplo, donde 8 transacciones compiten por ser incluidas en el siguiente bloque: 1. **tx1**: paga muy poco, no es incluida. 2. **tx2**: paga muy poco, no es incluida. 3. **tx3**: paga lo necesario, entra en el próximo bloque. 4. **tx4**: paga un poco más de lo necesario, entra en el próximo bloque. 5. **tx5**: paga más que la anterior, entra en el próximo bloque. 6. **tx6**: paga más que la anterior, entra en el próximo bloque. 7. **tx7**: paga más que la anterior, entra en el próximo bloque. 8. **tx8**: paga más que la anterior, entra en el próximo bloque.

https://raw.githubusercontent.com/jordanmmck/crypto-diagrams/master/eip1559/EIP1559.png

**Eje X (horizontal):** Representa el tamaño total del bloque en términos de gas consumido. Observamos que **tx7** requiere más gas que las demás, lo cual puede suceder cuando una transacción implica mayor esfuerzo computacional, como por ejemplo mintear un dominio es mas costoso que simplemente enviar ETH. **Eje Y (vertical):** Indica el precio por unidad de gas pagado por cada transacción. Cada transacción en el bloque tiene tres componentes diferenciados por colores: **Amarillo:** Representa el costo base de la transacción, es decir, el esfuerzo computacional puro necesario para ejecutarla. No tiene en cuenta la demanda de los usuarios. **Magenta:** Indica el *Base MEV*, el sobreprecio que los usuarios pagan debido al congestionamiento de la red. Esto corresponde a la diferencia entre el costo base y el precio justo para incluir la transacción en el bloque. **Violetita:** Representa el *Auction MEV*, que es el sobreprecio adicional pagado por los usuarios debido al modelo de subasta. Este sobreprecio no es esencial para ser incluidos en el bloque y podría ser reducido con mecanismos más eficientes. Entonces: **tx1 y tx2:** No lograron ser incluidas debido a sus tarifas bajas. **tx3:** Pagó el precio justo para entrar al bloque, absorbiendo solo el *Base MEV*. **tx4 a tx8:** Pagaron tarifas por encima de lo necesario, generando ademas el *Auction MEV*, una ineficiencia del sistema de subasta que beneficiaba a los mineros. El proceso ciego de ofertar hacía que los usuarios tendieran a pagar de más. Por ejemplo, la tx8 pago mucho más que tx3 cuando podría haber pagado solo un poco más, o incluso lo mismo, para obtener el mismo resultado. Por otro lado los mineros no necesitaban este ingreso adicional para estar correctamente incentivados. #### Implementación de la EIP-1559 La **EIP-1559** introdujo un nuevo mecanismo para abordar las ineficiencias del sistema de tarifas anterior. En lugar de una subasta de primer precio, se implementó un sistema que combina una **tarifa base (*****base fee*****)**, que todos los usuarios deben pagar para incluir sus transacciones, y una **propina opcional (*****tip*****)**, destinada a los constructores de bloques para incentivar la prioridad en la inclusión. $$ fee = (baseFee + priorityFee) \* gasUsed $$ * La tarifa base (base\_fee) es un valor ajustado por el protocolo para mantener el uso de la red a un nivel constante * El tip (pririty\_fee) es una cantidad adicional pagada al validador (cometa) para incentivarlo a incluir tu transacción. La siguiente imagen muestra una vista en tiempo real del precio del gas. En condiciones normales, la tarifa base (*base fee*) suele ser significativamente mayor que la tarifa de prioridad (*priority fee*). Esto se debe a que, en general, incluir transacciones no presenta mayores dificultades, ya que los bloques suelen tener suficiente espacio disponible. La mayoría de los validadores simplemente toman todas las transacciones visibles en la red y las incluyen en el bloque. Sin embargo, las tarifas de prioridad pueden presentar una variabilidad extrema, especialmente en escenarios de congestión.

https://www.blocknative.com/gas-estimator

Por lo tanto la mejora del EIP-1559 eficientizo los dos principales tipos de MEV presentes en el sistema anterior: 1. **Auction MEV (MEV de subasta):** Aunque este tipo de MEV no puede eliminarse por completo, su impacto se redujo de manera considerable. 2. **Base MEV (MEV base):** En el nuevo sistema, la tarifa base se quema en lugar de destinarse a los constructores de bloques. Esto redistribuye el valor a favor de los holders de ETH, beneficiando al ecosistema al reducir la oferta total de la criptomoneda, en lugar de enriquecer exclusivamente a los mineros. Si bien este nuevo modelo eficientizo la situación descripta, el desafío relacionado con el orden específico de las transacciones persiste. Actualmente, Ethereum carece de un sistema dentro del protocolo para regular este aspecto. ## **Specific Ordering MEV -** La Importancia del Orden de las Transacciones En el estado actual de Ethereum los constructores de bloques tienen la libertad de ordenar las transacciones según lo deseen, ya que el protocolo no ofrece un mecanismo oficial para que los usuarios expresen sus preferencias sobre el orden relativo de sus transacciones. Sin embargo, en un entorno financiero como Ethereum, donde millones de dólares pueden depender de pequeñas diferencias en el orden de ejecución, esta falta de control puede tener consecuencias significativas. El orden de las transacciones puede ser la diferencia entre obtener ganancias o sufrir pérdidas, especialmente en escenarios de alta volatilidad. Para abordar esta necesidad, surgió una solución fuera del protocolo llamada **MEV-Boost**, un sistema que permite a ciertos usuarios expresar y pagar por sus preferencias sobre el orden de las transacciones. Esto ha permitido un mecanismo más estructurado para gestionar el **Specific Ordering MEV** (MEV por orden específico), un tipo de MEV que va más allá de las simples tarifas y está relacionado directamente con actividades financieras dentro de Ethereum, tales como: * *Front-running* (adelantamiento de operaciones). * *Back-running* (seguimiento de operaciones). * *Sandwiching* (intercalación). * *Generalized front-running* (adelantamiento generalizado). En la práctica, esta falta de control sobre el orden dentro del protocolo ha dado lugar a un mercado no oficial, donde algunos usuarios y constructores negocian directamente por el lugar de sus transacciones en el bloque. ## Construcción estándar de bloques - *Vanilla Block Building* #### Lo que ve el usuario que envía una transacción El proceso para enviar una transacción en Ethereum es relativamente simple: la billetera (*wallet*) genera la transacción, el usuario la firma y esta se transmite a un nodo de Ethereum, ya sea un nodo propio o a través de un servicio intermediario como Infura o Alchemy. Estos nodos comparten la transacción con otros nodos conectados, formando una red de transacciones pendientes conocida como el *mempool* público. Este *mempool* es accesible para cualquier participante de la red, lo que proporciona transparencia sobre el estado actual de las transacciones pendientes. Se puede ver el estado en tiempo real del *mempool* público en el siguiente enlace: {% embed url="" %} El usuario queda a la espera de que un *block builder* tome su transacción del *mempool* y la incluya en el próximo bloque. #### Lo que hace el validador En el sistema *Proof of Stake* (PoS) de Ethereum, se elige aleatoriamente a un validador para actuar como *block proposer*(proponente de bloque). A día de hoy (agosto de 2024), hay más de 1.000.000 de validadores activos. Esta métrica se puede consultar en el siguiente enlace: {% embed url="" %} Esto implica que, para un validador individual, ser seleccionado como *block proposer* es una tarea poco frecuente. En el caso que estamos analizando, conocido como *vanilla block building*, el validador, que será el *block builder*, debe tener instalados en su nodo los siguientes clientes estándar de Ethereum: 1. **Cliente de ejecución.** 2. **Cliente de consenso.** 3. **Cliente de validación.** Con estos clientes estándar, al momento de elegir transacciones del *mempool* público para insertarlas en un bloque, solo se consideran aspectos básicos como el *base fee* y el *priority fee*. Una vez creado el bloque, este se envía a la red. Bajo este modelo, el validador recibe recompensas únicamente por las tarifas (*fees*) pagadas por los usuarios y el subsidio del protocolo (emisión). A continuación, se explicará cómo es el proceso para seleccionar y ordenar transacciones en Ethereum para que los validadores puedan obtener ganancias a través del *MEV* (Valor Máximo Extraíble). ## La llegada de Flashbots En la situación descrita anteriormente, no es difícil imaginar que los validadores con herramientas avanzadas para monitorear el *mempool* público puedan utilizar la información de las transacciones de los usuarios para su propio beneficio. Este escenario plantea serios desafíos para la equidad y la descentralización dentro del ecosistema de Ethereum. Es aquí donde entra en escena Flashbots, una organización de investigación y desarrollo enfocada en mitigar los problemas asociados al *MEV*. {% embed url="" %} Flashbots no tiene como objetivo eliminar el *MEV* por completo. En cambio, busca transformar la forma en que se gestiona el MEV a través de los siguientes pilares fundamentales: 1. **Iluminar** (*Illuminate*): Exponer la actividad del *MEV*, proporcionando visibilidad sobre cómo y dónde ocurre, para que pueda ser comprendida por la comunidad. 2. **Democratizar** (*Democratize*): Permitir que todos los constructores de bloques (*block builders*) participen en la red, eliminando la necesidad de conexiones exclusivas o pertenecer a grupos privilegiados. 3. **Distribuir** (*Distribute*): Asegurar que los ingresos generados por el *MEV* se repartan de manera más equitativa entre los participantes. Este enfoque representa un avance significativo hacia un sistema más justo y transparente dentro de Ethereum, mitigando los efectos más nocivos del *MEV* y promoviendo la descentralización. MEV-Boost es una **herramienta específica** creada por Flashbots como parte de su solución al problema del *MEV* previamente descrito. A continuación, explicaremos cómo funciona. ## MEV - Boost Es un cliente que los nodos validadores deben instalar para poder obtener recompensas adicionales gracias al MEV. MEV-Boost conecta a los validadores con todo un sistema paralelo al protocolo de Ethereum. {% hint style="info" %} El flujo operativo sigue la filosofía de *Proposer-Builder Separation* (PBS), que establece que las entidades encargadas de construir y proponer bloques en Ethereum deben ser diferentes. {% endhint %} Este sistema tiene un objetivo muy concreto: dar garantías de seguridad al validador proponente del bloque para que pueda subastar la creación del bloque al mejor postor. Este sistema está compuesto por tres actores principales: **proposers**, **builders** y **relay**.

1. **Proposer**: Son los nodos validadores encargados de cumplir todos los requisitos de la *beacon chain* para proponer bloques en Ethereum. En cada *slot*, un validador específico será responsable de proponer un bloque, mientras que el resto de los validadores se encargan de atestiguar que dicho bloque es honesto. 2. **Builder**: Son las entidades responsables de construir bloques optimizando las ganancias provenientes del MEV. 3. **Relay**: Son los intermediarios que facilitan la comunicación entre los *Builders* y los *Proposers*. #### Builders y Searchers El flujo de funcionamiento de MEV comienza con los usuarios de Ethereum cuando envían sus transacciones. Eventualmente, estas transacciones llegan al *mempool* público. Aquí es donde entran en juego unas entidades llamadas *Searchers*. Los *Searchers* son bots, es decir, computadoras que ejecutan programas muy específicos. Estos programas están diseñados para correr algoritmos que identifican oportunidades de MEV en el *mempool*, con el objetivo de maximizar ganancias.

**Ejemplo:** Supongamos que un usuario decide comprar un token. Un *Searcher* podría detectar esta transacción en el *mempool* y buscar formas de extraer valor de ella. Por ejemplo, podría ejecutar un ataque de *sandwiching* (intercalación), que consiste en construir un paquete de transacciones (*bundle*) con el siguiente orden: 1. Comprar el mismo token antes de que el usuario realice su compra (*front-running*). 2. Incluir la transacción del usuario (su compra). 3. Vender el token inmediatamente después de la compra del usuario (*back-running*). Con este mecanismo, el *Searcher* puede generar ganancias al aprovechar el impacto que la transacción del usuario tiene sobre el precio en el mercado. Sin embargo, para que estas ganancias sean efectivas, el *bundle* debe ser incluido en el próximo bloque. {% hint style="info" %} Lo que sucede aca es que cuando se ejecuta la compra del searcher, el precio del activo sube y el usuario termina comprando menos tokens de lo esperado. Desde el punto de vista del usuario, una forma de protegernos de este tipo de MEV es ajustando el *slippage* en los dex. {% endhint %} El *Searcher* incluye un soborno (*bribe*) dentro de este *bundle* para convencer al *Builder* (constructor de bloques) de procesar el paquete de transacciones exactamente como está ordenado. A continuacién se ve una victima de este tipo de MEV:

https://www.reddit.com/r/UniSwap/comments/17ytq0j/what_happened_here_i_am_so_confused/?rdt=49214

**Hash de la Transacción**: 0x11ee1c1fd6cb5e7b0b7716082cacb461dc6f2bfa2f3ed119205822d1dc04ba55

https://etherscan.io/tx/0x11ee1c1fd6cb5e7b0b7716082cacb461dc6f2bfa2f3ed119205822d1dc04ba55

En el bloque se puede ver claramente porque le llamamos sandwiching, donde los MEV bot son los panes:

https://etherscan.io/txs?block=18604963&ps=100&p=3

#### **Builders: los que construyen los bloques** Los *Builders* reciben paquetes de transacciones (*bundles*) enviados por los *Searchers*, los organizan en un bloque y buscan maximizar los ingresos asociados a ese bloque. Estos ingresos provienen de dos fuentes principales: 1. **Ingresos por tarifas estándar:** Las comisiones habituales que los usuarios pagan para incluir sus transacciones en un bloque. 2. **Valor extraído de MEV:** Los incentivos (*bribes*) ofrecidos por los *Searchers* dentro de los *bundles*. Además, los *Builders* complementan el bloque añadiendo transacciones normales si es necesario. Por lo general, configuran su propia dirección como la dirección *coinbase* (destinataria de las recompensas), lo que les permite recibir tanto las tarifas estándar como los incentivos relacionados con el MEV. Sin embargo, los *Builders* no tienen la capacidad de proponer bloques directamente en la red Ethereum. El protocolo de Ethereum es el que determina qué validador actuará como *block proposer* (proponente de bloque) en cada *slot*. Por esta razón, los *Builders* deben ofrecer un incentivo atractivo al *proposer* para que acepte su bloque. Esto ocurre porque el *proposer* no actúa como la dirección *coinbase* cuando incluye el bloque construido por el *Builder*, lo que significa que no recibe directamente las tarifas ni los incentivos contenidos en ese bloque. #### **Relays: los intermediarios** Los *relays* actúan como intermediarios que facilitan la comunicación entre *builders* y *proposers*, desempeñando un rol clave en el flujo de bloques: 1. **Conexión con múltiples *****Builders*****:** Un *relay* se conecta a varios *Builders* para recopilar los encabezados de los bloques junto con el soborno (*bribe*) ofrecido al *proposer*. 2. **Selección del mejor bloque:** El *relay* analiza las ofertas recibidas y selecciona el encabezado del bloque que proporciona el soborno (*bribe*) más alto, enviándolo luego al *proposer*. En su esencia, los *relays* son bienes públicos. No generan ingresos y su función principal es centralizar y facilitar el acceso a la información de los *Builders*, evitando que los validadores tengan que conectarse directamente a múltiples *Builders*. Esto simplifica el proceso y refuerza la seguridad del sistema. #### **Flujo general del MEV** Con todas las partes explicadas, podemos detallar el flujo general desde la perspectiva del *relay* en unos pocos pasos: 1. **Análisis del mempool:** Los *Searchers* identifican oportunidades en el *mempool* y envían paquetes de transacciones (*bundles*) a los *Builders*. 2. **Recepción de ofertas:** Los *Builders* crean bloques optimizados y envían sus propuestas al *relay*, que actúa como un subastador confiable. 3. **Selección del mejor bloque:** El *relay* evalúa las ofertas de los *Builders*, selecciona el encabezado del bloque con el soborno (*bribe*) más alto y lo envía al *proposer* (validador designado). 4. **Firma del bloque:** El *proposer* firma digitalmente el encabezado seleccionado usando su clave privada. Esto asegura que no pueda firmar otro bloque y da confianza al *Builder* de que su bloque será propuesto. 5. **Liberación del bloque:** Con la firma del *proposer* en mano, el *Builder* libera el bloque completo. Este bloque regresa al *relay*, que lo entrega al *proposer* para su inclusión en la cadena de bloques. Este flujo asegura que todas las partes involucradas trabajen de manera eficiente y confiable, maximizando las ganancias de MEV mientras se mantiene la seguridad y el orden en la red Ethereum.

En la siguiente imagen podemos ver como se ve “realmente” este flujo:

En la parte inferior de la imagen donde están los *proposers*, solo vemos las entidades principales (que tienen una porción muy significativa del stake). Los *solo-stakers* no figuran en el grafico. #### **Protección contra comportamientos deshonestos** Los *relays* son esenciales para garantizar la integridad y seguridad del flujo de bloques: 1. **Prevención de robo de bloques:** Si un *Builder* enviara directamente su bloque al *proposer*, este último podría intentar robarlo copiando la transacción del soborno (*bribe*) o desempaquetando las transacciones de MEV para aprovecharse del valor capturado. 2. **Garantía contra modificaciones:** Los *relays* aseguran que el *proposer* no pueda alterar el bloque recibido, ya que cualquier intento de firmar encabezados alternativos será detectado por el sistema Ethereum, generando un conflicto. 3. **Penalización por conflicto:** En caso de que un *proposer* firme dos encabezados diferentes, será penalizado (*slashing*), lo que puede resultar en la pérdida parcial o total de sus 32 ETH en *staking*. Este mecanismo protege a los *Builders* y desincentiva cualquier intento de manipulación. De esta manera, los *relays* fortalecen la confianza y la transparencia en el proceso de construcción y propuesta de bloques dentro de la red Ethereum. ## Conclusiones El mecanismo de separación entre proposers y builders que trae *Mev Boost* ha sido todo un éxito en términos de adopción, con cerca del 90% de los bloques de Ethereum usando este sistema después de "The Merge" en septiembre de 2022.

Esto muestra que los validadores prefieren delegar la producción de bloques a constructores especializados para ganar más recompensas.

Pero, aunque funciona bien, no es perfecto; todavía hay desafíos y cosas por resolver. Más adelante, en otros artículos, hablaremos sobre nuevas ideas y soluciones para mejorar el manejo del MEV, cómo este sistema puede seguir evolucionando, y abordaremos temas como la conformidad con las regulaciones de OFAC (OFAC compliance) y su impacto en el ecosistema. Además, exploraremos cuestiones filosóficas relacionadas con el MEV: ¿es bueno o malo? ¿Es inevitable en un sistema descentralizado? También profundizaremos en los detalles de los diferentes tipos de MEV, analizando sus particularidades, beneficios y desafíos, para entender mejor cómo afectan a los usuarios y validadores en el ecosistema blockchain. ## Referencias {% embed url="" %} {% embed url="" %} {% embed url="" %} {% embed url="" %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://seednodes.gitbook.io/club-de-nodos/avanzado/mev.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.