| icon |
|---|
robot |
{% embed url="https://mirror.xyz/seedlatam.eth/nU0v23aHxFI7Aml-7JJr0i0VQyhzzLYqkqDnypxVN2Y" %} November 27th, 2021 {% endembed %}
{% embed url="https://mirror.xyz/seedlatam.eth/pp9tJ0Ovq3f-i0ZwgDloxB4vls91QaGEJQbA2Ow2t1s" %} December 7th, 2021 {% endembed %}
{% embed url="https://mirror.xyz/seedlatam.eth/C4gjpjtCGqN6tV1d9tpT_yxEPt69blwwA5eK64oL4Zw" %} March 8th, 2022 {% endembed %}
Si analizamos las recompensas que recibe un validador de Ethereum podemos clasificarlo básicamente en tres:
- Emisión del protocolo (inflación)
- Tarifas que pagan los usuarios (fees)
- 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:
- Decidir qué transacciones incluir o excluir de un bloque.
- 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.
{% 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:
- tx1: paga muy poco, no es incluida.
- tx2: paga muy poco, no es incluida.
- tx3: paga lo necesario, entra en el próximo bloque.
- tx4: paga un poco más de lo necesario, entra en el próximo bloque.
- tx5: paga más que la anterior, entra en el próximo bloque.
- tx6: paga más que la anterior, entra en el próximo bloque.
- tx7: paga más que la anterior, entra en el próximo bloque.
- 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.
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.
- 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:
-
Auction MEV (MEV de subasta):
Aunque este tipo de MEV no puede eliminarse por completo, su impacto se redujo de manera considerable.
-
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.
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.
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="https://www.ethernow.xyz/mempool/all" %}
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.
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="https://dune.com/hildobby/eth2-staking" %}
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:
- Cliente de ejecución.
- Cliente de consenso.
- 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).
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="https://www.flashbots.net" %}
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:
- Iluminar (Illuminate): Exponer la actividad del MEV, proporcionando visibilidad sobre cómo y dónde ocurre, para que pueda ser comprendida por la comunidad.
- 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.
- 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.
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.
- 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.
- Builder: Son las entidades responsables de construir bloques optimizando las ganancias provenientes del MEV.
- Relay: Son los intermediarios que facilitan la comunicación entre los Builders y los Proposers.
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:
- Comprar el mismo token antes de que el usuario realice su compra (front-running).
- Incluir la transacción del usuario (su compra).
- 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
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:
- Ingresos por tarifas estándar: Las comisiones habituales que los usuarios pagan para incluir sus transacciones en un bloque.
- 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.
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:
- 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.
- 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.
Con todas las partes explicadas, podemos detallar el flujo general desde la perspectiva del relay en unos pocos pasos:
- Análisis del mempool: Los Searchers identifican oportunidades en el mempool y envían paquetes de transacciones (bundles) a los Builders.
- Recepción de ofertas: Los Builders crean bloques optimizados y envían sus propuestas al relay, que actúa como un subastador confiable.
- 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).
- 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.
- 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.
Los relays son esenciales para garantizar la integridad y seguridad del flujo de bloques:
- 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.
- 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.
- 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.
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.
{% embed url="https://medium.com/etherscan-blog/rapid-rise-of-mev-in-ethereum-9bcb62e53517" %}
{% embed url="https://blog.bcas.io/mev-examination-and-putting-a-stop-to-micas-article-92-nonsense" %}
{% embed url="https://paragraph.xyz/@chaskin/private-transactions-where-mev-and-the-public-mempool-go-to-die" %}
{% embed url="https://ethereum.org/en/developers/docs/mev/" %}