Agradecimientos a Jistro y Enti por sus valiosos comentarios, revisiones y discusiones en la realización de este artículo.
El Maximum Extractable Value (MEV, por sus siglas en inglés) es una técnica empleada por algunos validadores para aumentar significativamente sus recompensas por bloque, llegando incluso a generar hasta 73.48 ETH por la validación de un solo bloque. Si bien el MEV podría parecer interesante, esto representa un riesgo enorme para la descentralización en Ethereum y en especial, para mantener a Ethereum como una blockchain resistente a la censura.
Ciclo de vida de las transacciones en Ethereum Antes de profundizar más en qué es el MEV y porqué es uno de los aspectos que componen al “bosque oscuro ” es importante tener en cuenta que al día de hoy, los validadores delegan la construcción de bloques a entidades especializadas conocidas como "constructores" (Builders ). Este evento no ocurre dentro del protocolo sino que se hace uso de bots también llamados MEV searchers que se adentran en la mempool
Desde la introducción de EIP1559 los usuarios tienen la capacidad de añadir una Priority Fee que permita que su transacción tenga prioridad al ser seleccionada. Los searchers buscan las transacciones que están dispuestas a pagar una mayor comisión para aumentar las recompensas del bloque. Si tomamos como ejemplo visual el sitio txstreet podemos entender a los searchers como agentes externos que eligen a los ciudadanos (transacciones) que están dispuestos a pagar más (los que establecen un PriorityFee mayor) para poder subir a los autobuses (bloques).
Técnicas de MEV En el diseño de blockchains, la consideración del MEV emerge como un pilar fundamental para preservar la seguridad y la descentralización del protocolo. Esta medida se revela como un factor crítico en la prevención de ataques contra las transacciones de los usuarios, nivelando el campo de juego para todos los validadores y evitando la concentración de beneficios en manos de aquellos con recursos más avanzados. A continuación exploraremos algunas de las técnicas de MEV utilizadas en el ecosistema, las cuales son fundamentales para comprender los desafíos y oportunidades en este ámbito así como las soluciones que se están explorando actualmente.
Arbitraje
La estrategia más común para aprovechar el MEV en Ethereum es el arbitraje. Esto ocurre cuando existe una discrepancia en el precio de un activo en dos DEXes . Los validadores pueden obtener ganancias al comprar el activo de un exchange en donde el precio es menor e inmediatamente después venderlo en uno donde el precio es mayor. En muchas ocasiones se hace uso de flash loans para poder ejecutar estas operaciones con un gran volumen. En este ejemplo se puede observar como un searcher consiguió obtener una ganancia de 45 ETH al realizar una flash loan de 1,000 ETH y hacer las operaciones correspondientes entre Uniswap v2 y Sushiswap.
Liquidación
Otra estrategia ampliamente utilizada es a través de liquidaciones. En las plataformas de préstamos como Maker o Aave se requiere un mínimo de colateral para mantener abierta una posición, cuándo esta cae por debajo del mínimo necesario automáticamente la posición se cierra y el colateral es vendido con un descuento para prevenir que el sistema se vuelva insolvente y los deudores deben pagar una comisión al DEX por haber sido liquidados.
En esta estrategia, los searchers compiten para analizar los datos de la blockchain lo más rápido posible para determinar qué deudores pueden ser liquidados y ser los primeros en enviar una transacción de liquidación y cobrar la comisión de liquidación para sí mismos.
Ataque Sandwich
Además del arbitraje y las liquidaciones, uno de los ataques más dañinos a los usuarios ocurre cuando los searchers identifican grandes compras de un criptoactivo y se anticipan a la compra de este adquiriéndolo antes de que finalice la transacción en la cadena. La idea en este ataque es ejecutar una transacción antes (frontrunning )y una después de la transacción (backrunning ) del usuario con el propósito de hacer que los usuarios paguen un mayor precio por los activos que intentan comprar.
Para entender mejor este ataque, asumamos que Alice intenta comprar 1,000 ETH con DAI en Uniswap, al ser una transacción sumamente grande es de esperar que esta tenga un impacto en el precio. Aquí es donde un searcher colocará la misma transacción antes que ella y una orden de venta inmediatamente después de su compra obteniendo una ganancia significativa debido al aumento en el precio por las dos transacciones previas.
A diferencia del MEV por liquidación, este tipo de ataque es más riesgoso para los MEV Searchers debido a que es posible evitar este tipo de ataques haciendo que los searchers sufran pérdidas.
Otros tipos de MEV
Existen dos técnicas de MEV más en los que no entraremos en detalle ahora mismo pero serán abordados en un reporte posterior, estos son conocidos como “Sandwich envenenado” la cuál funciona como una estrategia de defensa ante los ataques sandwichs y otra llamada “Just-in-Time (JIT) liquidity attacks” en la cual se debe proveer liquidez a una piscina antes de que una gran orden sea ejecutada.
El problema del MEV Como te habrás dado cuenta, estas técnicas de MEV impactan a los participantes de la red de diversas maneras. Por ejemplo, los usuarios que realizan transacciones pueden verse afectados por la censura de sus operaciones, lo que puede resultar en la pérdida de oportunidades al momento de hacer transacciones o incluso en la incapacidad de ejecutarlas. Además, la manipulación de transacciones mediante técnicas de front y back running (e incluso ataques sandwich) pueden generar desconfianza entre los participantes al momento de realizar transacciones como swaps o al aportar liquidez. Por otro lado, quizá menos dañino pero de igual manera desigual, las operaciones de arbitraje no están al alcance de la mayoría de usuarios haciendo que solo unos pocos se beneficien de ello.
Como te habrás dado cuenta, los distintos ataques de MEV (a excepción del Sandwich envenenado) representan una seria amenaza para los diversos participantes de la red. Estas amenazas no solo radican en la capacidad de reorganizar las transacciones que residen en la mempool sino también en la posibilidad de censurarlas. Actualmente, aproximadamente 43% de todas las transacciones en Ethereum han sido censuradas debido a la utilización de Relayers que cumplen con las regulaciones de la OFAC . Puedes encontrar una lista completa de qué Relayers censuran transacciones aquí .
Soluciones para combatir el MEV En el pasado, los mineros eran capaces de ordenar los bloques para poder extraer MEV pero, con el cambio a Proof of Stake esta tarea se ha vuelto prácticamente imposible debido al nuevo algoritmo que se implementó para determinar cuál es la cadena canónica. Bajo este nuevo modelo, si bien los validadores son seleccionados al azar estos tienen la posibilidad de retrasar la proposición de los bloques para permitir que los builders obtengan más información y así crear un bloque con más MEV.
A continuación exploraremos cuatro soluciones a nivel protocolo que pretenden solucionar distintos apartados relacionados al MEV, es importante aclarar que estas soluciones no son todas las que existen y existen diversos acercamientos para combatir este problema tanto a nivel aplicación como a nivel protocolo:
MEV Boost Diferentes organizaciones como la Ethereum Foundation y Flashbots han buscado que cualquier usuario pueda acceder al MEV, a través de distintas herramientas están intentando asegurarse que ningún participante obtenga ventaja de este mercado. La idea principal surge por añadir un cambio en el protocolo llamado Proposer Builder Separation (PBS) el cual se refiere a dividir la responsabilidad de crear (builder ) y proponer bloques (proposer ), tema que abordaremos en breve. Como una implementación temprana Flashbots ha creado MEV-Boost, una herramienta que funciona a la par del software principal para operar un validador de Ethereum y con la cual los operadores de nodos pueden conectarse a varios “relays” y empezar a aceptar bloques preconstruidos que contengan MEV.
Los validadores solo reciben la cantidad de recompensa que el bloque tendrá y el header del bloque **(necesario para poder proponer exitosamente) pero no pueden ver el contenido del bloque antes de que este sea agregado a la cadena. De esta manera, se asegura que los validadores no puedan hacer frontrunning a los builders y se mantiene cierto grado de privacidad y descentralización al momento de proponer un bloque. Además, al reducir las responsabilidad de un validador se consigue minimizar el conocimiento técnico y hardware necesario para operar un validador de forma exitosa lo cual es un plus para futuras actualizaciones como Statelessness
Listas de Inclusión Las listas de inclusión (IL, por sus siglas en inglés) fueron propuestas reciéntemente en las EIP-7547 y son un mecanismo destinado a mejorar la resistencia a la censura de una cadena. Están diseñadas para no ser invasivas, de forma que su funcionamiento no pueda perjudicar a un productor de bloques honesto que esté sometido a ellas.
De manera superficial el funcionamiento de estas listas podría entenderse como si se tratase de la fila de un supermercado:
Propuesta del slot N:
El Proposer (quien coloca los productos en la cinta) emite un bloque firmado (la cinta transportadora con las compras) y una IL (un resumen de los productos) para el slot N+1 (la siguiente sección de la cinta). Las transacciones (los productos individuales) se incluirán en el slot N (la sección actual de la cinta) o en elslot N+1 (la siguiente sección). Los resúmenes de las transacciones incluyen la dirección de origen (quién hizo la compra) y sus respectivos límites de gas (cuánto están dispuestos a pagar por la transacción). Solo los resúmenes están firmados, pero las transacciones individuales no. Validación del slot N:
Los validadores (los cajeros) solo considerarán el bloque para su validación y elección de cadena (decidir cuál fila seguir) si han visto al menos una IL para ese slot (la cual tuvo que ser propuesta en slot N-1) Consideran el bloque como inválido si las transacciones de la IL no pueden ser ejecutadas en el slot N (si hay productos que no se pueden vender en ese momento) o si el maxFeePerGas (el precio máximo que están dispuestos a pagar) de las transacciones no es al menos un 12,5% más alto que el del slot actual (Con esto, se aseguran de que las transacciones que no sean ejecutadas serán válidas e incluidas en slot N-1). Validación del slot N+1 :
El Proposer del slot N+1Proposer del slot N (un resumen de las compras de la persona anterior). Dentro de la información que se va a ejecutar (”payload” o las compras del nuevo cliente) se incluye una lista de los índices de las transacciones del payload del **slot N que satisfaga alguna entrada del resumen de la IL firmada. El payload es considerado válido si: Se cumplen las condiciones de ejecución, lo que incluye cumplir con el resumen de la IL y ser ejecutable desde la perspectiva de la capa de ejecución (los cajeros pueden procesar las compras). Se cumplen las condiciones de consenso, que incluyen una firma del Proposer del bloque anterior (asegurando que el cliente anterior pagó y salió de la fila). Las ILs tienen como objetivo principal garantizar la inclusión de transacciones específicas en un bloque, limitando la libertad de los constructores al momento de decidir qué transacciones incluir. El uso de estas permitirá reducir la cantidad de MEV que puede extraerse ya que es posible que algunos builders dejen de participar en ciertos slots si es que las ILs los obligan a incluir transacciones que podrían ser controvertidas. Esta dinámica brinda a aquellos relayers que no censuran transacciones ventajas competitivas significativas.
Mempool Encriptada Otra de los acercamientos que se han planteado son las Mempools Encriptadas, propuesta por Justin Drake , quien es Ethereum Researcher. Estas pretenden ser herramientas que permitan afrontar los problemas asociados al MEV y a la censura de las transacciones. La idea básica consiste en permitir que los usuarios suban transacciones de forma encriptada y los Builders se comprometan a incluir esas transacciones antes de desencriptarlas:
Con esto en mente es muy sencillo visualizar cómo se resuelven los 2 problemas abordados:
MEV: Un searcher no puede hacer un ataque sandwich si no puede ver las transacciones.Censura: Un searcher no debería ser capaz de censurar una transacción al no poder verla. Si quisiera excluirla, debería excluir todas las transacciones encriptadas (lo que eventualmente no sería tan redituable)Proposer Builder Separation Por último, tenemos lo que quizá es el acercamiento más ambicioso ante el problema del MEV, como sabemos, en el mercado actual de transacciones el proposer elige directamente qué transacciones incluir en el siguiente bloque fijándose en qué transacciones del mempool pagan la priority fee más alta. Esto permite que se puedan utilizar estrategias para decidir qué transacciones incluir (o no incluir) y aprovechar las distintas oportunidades que podrían aparecer (ver Técnicas de MEV). Dicho de otro modo, los validadores en Ethereum son responsables de la creación, proposición y validación de los bloques. Todo esto ocurre en un lapso de aproximadamente 12 segundos lo que implica que la tarea de crear un bloque con la mayor cantidad de MEV sea una tarea complicada.
Proposer Builder Separation (PBS) es una característica de diseño de blockchains que busca dividir la responsabilidad de construir y proponer bloques en dos roles separados conocidos como builder y proposer con el objetivo de mejorar la escalabilidad y seguridad de la red al mismo tiempo que evita que la censura de las transacciones. Para entender mejor el porqué es necesaria esta implementación debemos dividir el funcionamiento del MEV Boost (implementación actual de PBS) en dos ámbitos: la interacción entre proposers y relayers , y la interacción entre relayers y builders .
Relación entre Proposers y relayers
Hoy en día, los proposers confían en los relayers para:
Asegurarse de que el proposer recibe un header válido. Asegurarse de que el proposer recibe el pago cuando se ha llevado a cabo una acción honesta. Asegurarse de que el bloque del proposer se propaga y se devuelve al proposer original. Dentro de esta relación se puede observar cómo en el primer punto se equilibra la seguridad del builder con la del consenso, donde diferentes tipos de relayers tienen diferentes niveles de riesgo. Por otro lado, en el tercer punto equilibra la seguridad del builder con la vitalidad del consenso ya que los relayers introducen retrasos en la propagación del bloque para reducir el riesgo de ataques de frontrunning contra el builder .
Relación entre Relayers y Builders
Hoy en día, los builder confían en los relayers para:
Proteger el payload del builder hasta que sea seguro liberarla. Asegurarse de que todos los builders reciben un trato equitativo. En el primer punto, se asegura que el payload no se filtre y otros builders o proposers puedan robarlo y utilizarlo dentro del mismo slot o el siguiente. Mientras tanto, en el segundo se busca preservar que nuevos relayers tengan las mismas oportunidades que aquellos con un mayo historial.
Con esto claro, es fácil observar porqué bajo este nuevo esquema, la seguridad que proveen los validadores al proponer bloques se aislará completamente mientras que la responsabilidad de construir el bloque se delegará a un tercero. PBS trae consigo una gran ventaja al implementar esta característica ya que con la división de estos roles se podrá crear un mercado de subastas de producción de bloques más justo y no permisionado. Además de reducir la centralización que existe actualmente en los relayers y redireccionar una proporción del MEV a los validadores.
Involúcrate Las soluciones presentadas no solo buscan abordar los desafíos técnicos del MEV, sino que también tienen como objetivo promover una red más equitativa, resistente a la censura y segura para todos los participantes. Y como ya es tradición, todos estos temas son un rabbit hole en sí mismo y si quieres mantenerte al día sobre las diferentes implementaciones y avances que se tienen sobre estos temas aquí te compartimos algunas de las fuentes de información que te permitirán mantenerte actualizado:
ETHResearch EthResearch es un foro en línea dedicado a la discusión de temas relacionados con Ethereum y blockchain en general. Es un lugar donde desarrolladores, investigadores, entusiastas y miembros de la comunidad pueden intercambiar ideas, compartir investigaciones, proponer mejoras y debatir sobre diversos aspectos técnicos y conceptuales relacionados con Ethereum y la tecnología blockchain. EthResearch es una plataforma importante para fomentar la colaboración y la innovación dentro de la comunidad Ethereum.
Flashbots Flashbots es una organización de investigación y desarrollo creada para mitigar las externalidades negativas que plantea el Maximum Extractable Value (MEV) a las cadenas de bloques empezando por Ethereum. Puedes adentrarte en su foro o en las MEV Community Calls Flashbots Protect
PBS Foundation Reciénteemente se anunció el lanzamiento de la PBS Foundation PBS Foundation es proteger la descentralización de la capa de consenso de Ethereum mediante el avance de la investigación presente y futura dentro de la filosofía de diseño del protocolo PBS. Este esfuerzo de colaboración se extiende por toda la primera línea; incluyendo participantes activos de la industria, investigadores dentro del mundo académico, así como desarrolladores e investigadores independientes. El objetivo es sacar a la luz los retos más importantes del diseño del PBS para garantizar un mercado sano y dinámico para todos los validadores.
Además, desde el primero de enero se ha habilitado un programa piloto de grants con duración de seis meses que se enfocará en cuatro áreas:
Infraestructura Investigación Transparencia de la información Educación y comunidad 
