MEV y PBS: quién arma el bloque importa

Un usuario envía al mempool público una compra de ETH por 10.000 USDC en un pool de intercambio. Antes de que entre en un bloque, un bot la ve, calcula cuánto moverá el precio y coloca una compra justo antes y una venta justo después. La transacción del usuario se ejecuta sin errores, pero recibe menos ETH del que habría recibido sola, y el bot se queda con la diferencia. Ninguna regla de la EVM se violó: lo único que cambió fue el orden.

Ese margen tiene nombre: MEV, valor máximo extraíble. ethereum.org lo define como el valor que se puede extraer de la producción de bloques, por encima de la recompensa y las comisiones normales, incluyendo, excluyendo o reordenando transacciones dentro de un bloque. [1] Este capítulo sigue ese valor desde el usuario hasta el validador, y luego mira cómo el protocolo intenta controlarlo.

Preguntas guía

• ¿Quién decide el orden de las transacciones en un bloque y quién cobra por ese orden?
• ¿Qué tiene que confiar un validador cuando firma un bloque que no puede ver?
• ¿Qué parte del MEV es útil para el sistema y qué parte daña al usuario?
• ¿Qué cambia cuando la separación entre builder y proposer pasa a ser parte del protocolo?

Historia del término: de mineros a validadores

El concepto se popularizó con el trabajo "Flash Boys 2.0" de 2019. Sus autores documentaron bots de arbitraje en exchanges descentralizados que pujaban comisiones cada vez más altas para quedar primeros en el bloque, un fenómeno que llamaron subastas de prioridad de gas (priority gas auctions). Mostraron además que esas comisiones elevadas eran un riesgo sistémico para la seguridad del consenso, y bautizaron el fenómeno general como "miner extractable value". [2]

Con la transición a prueba de participación, los mineros desaparecieron y los validadores pasaron a decidir inclusión y orden. Las técnicas de extracción siguieron existiendo, así que el término cambió a "maximal extractable value" sin cambiar la sigla. [1]

En la práctica, el validador casi nunca busca MEV por sí mismo. Lo hacen los searchers, operadores que analizan la cadena y el mempool para encontrar oportunidades y envían transacciones o paquetes (bundles) que las capturan. El validador recibe una parte porque los searchers compiten pagando comisiones; en oportunidades muy disputadas, como el arbitraje entre exchanges, pueden ceder la mayor parte de su ganancia.

Tres patrones de MEV y su efecto

ethereum.org describe tres patrones conocidos, y no todos son dañinos. [1]

• Arbitraje entre exchanges. Si dos pools cotizan distinto, alguien compra barato en uno y vende caro en otro dentro de una transacción atómica. Alinea precios entre mercados.
• Liquidaciones. Cuando un préstamo pierde colateral suficiente, el protocolo de préstamo permite que cualquiera lo liquide y cobre una comisión. Los searchers compiten por ser primeros, y eso mantiene solvente al protocolo.
• Sandwich. El caso del ejemplo inicial: compra antes y venta después de una operación grande. El usuario sufre más deslizamiento de precio y peor ejecución.

El código siguiente es ilustrativo y reproduce el sandwich con la fórmula de precio de un pool de producto constante con comisión de 0,3 %, que se explica en detalle en el capítulo de AMMs. Usa números reales en lugar de enteros para que se lea fácil.

// Ilustrativo: fórmula getAmountOut de Uniswap v2 (comisión 0,3 %) con números reales.
const getAmountOut = (amountIn, reserveIn, reserveOut) => {
  const inWithFee = amountIn * 997;
  return (inWithFee * reserveOut) / (reserveIn * 1000 + inWithFee);
};
 
let usdc = 200_000, eth = 100; // reservas del pool
const victimIn = 10_000;       // la víctima compra ETH con 10.000 USDC
const alone = getAmountOut(victimIn, usdc, eth);
 
const frontOut = getAmountOut(5_000, usdc, eth); // 1. el atacante compra antes
usdc += 5_000; eth -= frontOut;
const victimOut = getAmountOut(victimIn, usdc, eth); // 2. la víctima compra después
usdc += victimIn; eth -= victimOut;
const backOut = getAmountOut(frontOut, eth, usdc); // 3. el atacante vende
 
console.log({ alone: alone.toFixed(4), victimOut: victimOut.toFixed(4), attackerProfitUsdc: (backOut - 5_000).toFixed(2) });
// { alone: '4.7483', victimOut: '4.5251', attackerProfitUsdc: '460.35' }

La víctima recibe unos 4,53 ETH en vez de 4,75, y el atacante gana unos 460 USDC antes de pagar gas. La defensa del usuario es fijar un mínimo a recibir: si la víctima hubiera exigido al menos 4,70 ETH, su transacción habría revertido y el sandwich no habría sido rentable.

El efecto más serio está fuera del bloque. Si el MEV disponible en un bloque supera con mucho la recompensa normal, un validador puede tener incentivo a reorganizar la cadena para capturarlo, lo que amenaza la estabilidad del consenso.

Traza de ejecución: un slot con MEV-Boost

Hoy la mayoría de esta separación ocurre fuera del protocolo. MEV-Boost es un software de código abierto de Flashbots que el validador ejecuta junto a su cliente de consenso para comprar bloques a un mercado de builders (constructores de bloques). [3] El flujo de un slot (la ranura de tiempo en la que un validador asignado puede proponer un bloque) es este:

1. El validador registra su preferencia (dirección de cobro y límite de gas) en los relays con registerValidator.
2. Los builders arman bloques completos, con un pago al proposer, y los envían a uno o varios relays.
3. Cada relay simula los bloques: comprueba que se paga lo prometido a la dirección de cobro, que las transacciones existen y que el gas no supera el límite pedido. Solo ofrece la puja válida más alta.
4. En su slot, MEV-Boost pide a los relays configurados un encabezado con getHeader y elige el de mayor puja.
5. El proposer firma un bloque ciego (blinded block): un bloque que compromete el encabezado de ejecución sin conocer las transacciones.
6. Con submitBlindedBlock, el relay recibe la firma, revela el bloque completo y lo propaga.

Figura 1

Un slot con MEV-Boost: el proposer firma antes de ver el contenido

Fuentes:

[4]

Cómo leer esta figura

Diagrama de cuatro carriles verticales: builders, relay, proposer con MEV-Boost y red. Primero, los builders envían bloques completos con una puja al relay, que los simula y verifica el pago. Segundo, el proposer pide con getHeader el mejor encabezado y recibe encabezado y puja. Tercero, el proposer firma el bloque ciego y lo envía con submitBlindedBlock. Cuarto, el relay revela el bloque completo y lo publica en la red. Una caja al costado indica que si los relays fallan, el circuit breaker del cliente de consenso vuelve a construir el bloque localmente.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

La documentación de Flashbots describe al relay como una capa de disponibilidad de datos doblemente confiable: los builders confían en que enrute sus bloques de forma justa y los proposers confían en la validez, exactitud y disponibilidad del bloque. Ejecutar un relay no requiere permiso, pero quien lo usa le delega esa confianza. Para limitar el daño, los clientes de consenso implementan un circuit breaker: condiciones observables en la cadena que, si se cumplen, hacen que el validador deje de pedir bloques externos y construya localmente. [4]

Riesgo operativo: confianza en relays y concentración

Para un operador de validadores, MEV-Boost introduce dependencias concretas. Si el relay no revela el bloque después de la firma, el slot queda vacío y se pierde la recompensa de propuesta. Si el relay o el builder excluyen ciertas transacciones, el validador propone un bloque censurado sin haberlo visto. La lista de relays configurados es, por tanto, una decisión de riesgo que debe revisarse como cualquier otro proveedor.

A escala de red, ethereum.org señala dos presiones. La primera es la centralización de validadores: los operadores grandes pueden invertir más en capturar MEV, ganar más y atraer más stake. La segunda son los mempools con permiso: para evitar sandwiches, los usuarios envían transacciones por canales privados, y si esos acuerdos se vuelven exclusivos, el acceso al espacio de bloque deja de ser abierto. [1]

La idea detrás de PBS es aceptar que construir bloques se especialice y proteger lo que importa: que muchos validadores independientes puedan verificar y proponer. ethereum.org lo llama asimetría probador-verificador: la producción centralizada es tolerable si una red de validadores muy descentralizada puede comprobar que los bloques son honestos. [5]

Estado del roadmap: ePBS en Glamsterdam

EIP-7732, "Enshrined Proposer-Builder Separation", lleva la separación al protocolo. El bloque de la beacon chain deja de contener el payload de ejecución y pasa a contener una puja firmada de un builder, que se compromete a revelar después un payload con un hash concreto y a pagar un valor al proposer. Ese pago queda registrado como pendiente contra el saldo del builder en la beacon chain. [6]

Los builders se convierten en entidades con stake dentro del protocolo, registradas aparte de los validadores, y pueden participar con desde 1 ETH. Un subconjunto de cada comité, el Payload Timeliness Committee (PTC), atestigua si el builder reveló a tiempo el payload comprometido y si los datos de blobs estaban disponibles. El relay deja de ser necesario para garantizar el pago: la promesa del builder queda en el estado de consenso.

En cuanto al calendario, EIP-7773, la meta-EIP de Glamsterdam, lista EIP-7732 entre las propuestas programadas para inclusión y registra su activación en las redes de prueba Sepolia (6 de octubre de 2026) y Hoodi (26 de octubre de 2026), con la fila de mainnet todavía sin fecha al consultarla. EIP-7732 figuraba en estado "Last Call". [7] La página del roadmap de ethereum.org sitúa Glamsterdam en desarrollo para el cuarto trimestre de 2026 y menciona, para la actualización siguiente (Hegotá, 2027), listas de inclusión impuestas por la regla de elección de bifurcación (FOCIL), con un alcance que todavía no es definitivo. [8]

La lectura correcta para un equipo de ingeniería es separar tres estados: lo que corre hoy en mainnet (MEV-Boost fuera del protocolo), lo que está programado y activo en redes de prueba (ePBS) y lo que está propuesto (listas de inclusión). Cada uno merece un nivel de confianza distinto en un documento de diseño.

Lab propuesto: medir un sandwich en un pool local

Con el pool de producto constante del capítulo de AMMs desplegado en Anvil, el lab envía tres transacciones en el orden atacante, víctima, atacante, y compara el ETH recibido por la víctima con el que recibe sola. La validación observable es la diferencia, que debe coincidir con el cálculo del script anterior salvo por el redondeo de enteros. Después se repite con un amountOutMin ajustado y se verifica que la transacción de la víctima revierte. Como teardown basta detener Anvil.

Conexiones dentro de la serie

• Antes: bridges y riesgo cross-chain cierra el bloque de escalado y confianza entre dominios.
• Base necesaria: transacciones, gas y receipts, Gasper: Casper FFG y LMD-GHOST y validadores y attestations.
• Después: AMMs desde cero desarrolla la fórmula que usa el sandwich.
• Relacionado: liquidaciones en préstamos, otro origen de MEV.