MEV en Cripto: Cómo Funciona el Valor Máximo Extraíble y Cómo Medirlo

Qué Significa MEV en Cripto y de Dónde Viene

El valor máximo extraíble (MEV) es el valor máximo que se puede extraer de la producción de bloques por encima de la recompensa de bloque estándar y las tarifas de gas, mediante la inclusión, exclusión o reordenación de transacciones dentro de un bloque. El término comenzó como "valor extraíble por mineros" bajo prueba de trabajo, cuando los mineros controlaban la inclusión y el orden de las transacciones. Después de que las redes pasaron a prueba de participación, los validadores asumieron esos roles, por lo que el término más amplio es ahora el estándar. El mecanismo subyacente no cambió: quien controla el orden controla un grado de libertad pequeño pero económicamente significativo sobre la ejecución.

Ese grado de libertad existe porque el espacio de bloques es escaso y las transacciones no son conmutativas. Un swap que mueve el precio de un pool, una liquidación que cambia un factor de salud o un mint que agota un límite de suministro producen resultados diferentes según lo que se ejecute antes y después. MEV es la monetización de esa no conmutatividad. No es intrínsecamente malicioso; el arbitraje que cierra brechas de precios entre venues también es MEV, y mejora la eficiencia del mercado aunque compita por los mismos derechos de orden.

• Orden: colocar una transacción antes o después de otra para cambiar su resultado económico.
• Inclusión: decidir si una transacción rentable o no rentable entra en el bloque.
• Exclusión: censurar o retrasar transacciones, lo que puede ser rentable en sí mismo.
• Escasez de espacio de bloque: la restricción que hace valioso el orden en primer lugar.

Supuestos y Requisitos Previos para Esta Guía

Este artículo asume que entiendes cómo las transacciones entran en un mempool, cómo las tarifas de gas o prioridad influyen en la inclusión y cómo se producen los bloques en al menos una cadena EVM. Deberías sentirte cómodo llamando métodos JSON-RPC y leyendo objetos de transacción y recibo en bruto. El procedimiento de medición utiliza una interfaz JSON-RPC estándar compatible con Ethereum, por lo que funciona contra cualquier endpoint que exponga eth_getBlockByNumber con cuerpos de transacción completos.

Dos límites importan. Primero, el comportamiento documentado del protocolo (lo que garantiza un cliente o una especificación) es distinto del comportamiento observado en una red específica en un momento específico; este último debe medirse. Segundo, esta página no recomienda un endpoint o proveedor específico. Para la elección concreta de un endpoint RPC, utiliza el Asistente RPC, que cubre directamente la selección de endpoints y proveedores.

La Cadena de Suministro MEV: Buscadores, Constructores y Validadores

En teoría, todo el MEV corresponde al productor del bloque, porque solo el productor puede garantizar que una transacción rentable se incluya. En la práctica, la mayor parte de la detección y ejecución la realizan participantes independientes llamados buscadores, que ejecutan algoritmos sobre datos pendientes e históricos de la cadena para encontrar oportunidades y envían transacciones o bundles que las capturan. Los buscadores compiten por velocidad y por cuánto de la ganancia están dispuestos a pagar por la inclusión, por lo que una gran parte del MEV bruto se transfiere hacia arriba como tarifas de prioridad o pagos a constructores.

En redes con un diseño de separación proponente-constructor (PBS), los constructores ensamblan bloques candidatos a partir de bundles y pujan por el derecho a que su bloque sea propuesto. Los validadores (o secuenciadores en rollups) seleccionan entre las pujas. Esta separación es lo que hace que MEV sea medible como mercado: las pujas, los bundles y los pagos son artefactos observables en lugar de decisiones privadas del minero. En redes sin PBS, el productor realiza ambos roles y el mercado es menos transparente.

• Buscadores: detectan oportunidades y envían transacciones o bundles.
• Constructores: fusionan bundles en un bloque candidato y pujan por la inclusión.
• Proponentes/validadores/secuenciadores: seleccionan y finalizan el bloque.
• Usuarios: proporcionan el flujo de órdenes que crea las oportunidades y soportan gran parte del costo.

Estrategias MEV Comunes y Qué Hacen a los Usuarios

El arbitraje DEX es la categoría más benigna y competitiva: un buscador opera contra un pool cuyo precio se ha desviado de otro venue y captura el diferencial. Las liquidaciones son similares en estructura, recompensando al primer keeper que reembolsa un préstamo no saludable. El frontrunning generalizado copia cualquier transacción pendiente rentable y la reenvía con una tarifa más alta. El sandwiching es la estrategia que los usuarios sienten más directamente: un buscador compra antes de un swap grande, deja que la operación de la víctima mueva el precio y luego vende inmediatamente después, capturando el slippage que la víctima estaba dispuesta a tolerar.

El costo para el usuario del sandwiching está limitado por la tolerancia de slippage establecida en el swap. Una tolerancia más ajustada reduce la cantidad extraíble pero aumenta la probabilidad de fallo. Esta es una compensación real, no una configuración que pueda optimizarse hasta desaparecer, y es por eso que slippage y MEV se discuten juntos habitualmente.

Un Modelo Mental: MEV como una Subasta de Orden

La forma más clara de razonar sobre MEV es tratar cada bloque como una pequeña subasta sobre el orden de las transacciones. Cada participante que puede influir en el orden envía una puja en forma de tarifa o pago de bundle. El orden ganador maximiza los ingresos del productor, que no es necesariamente el orden que maximiza el bienestar del usuario. MEV es, por tanto, la brecha entre el orden que maximiza los ingresos y el orden que los usuarios habrían elegido.

Este modelo explica varios patrones observados. La competencia lleva los márgenes de los buscadores hacia cero mientras los pagos totales a los productores se mantienen altos. Las oportunidades fáciles de detectar atraen a muchos buscadores y, por tanto, una alta competencia de tarifas. Las oportunidades que requieren datos o capital propietarios atraen a menos participantes y retienen más margen. Cuando mides MEV, realmente estás midiendo el tamaño de esta subasta en el tráfico que observas.

Medición de los Efectos del Orden en Tu Propio Tráfico RPC

No puedes inferir MEV en tu tráfico a partir de una sola transacción. Necesitas el contexto del bloque: qué transacciones se ejecutaron antes y después de la tuya, y cuál era el estado del pool en cada paso. El procedimiento a continuación extrae bloques recientes con cuerpos de transacción completos, extrae swaps contra un pool objetivo y registra el orden de cada transacción dentro de su bloque. Ejecútalo contra un endpoint que controles o en el que confíes, y registra el rango de bloques y la marca de tiempo para que los resultados sean reproducibles.

El script utiliza solo métodos JSON-RPC estándar. Reemplaza RPC_URL con tu endpoint y POOL con el contrato del pool que te interese. No pretende detectar todos los patrones MEV; produce los datos de orden que necesitas para analizarlos.

import os, json, urllib.request

RPC_URL = os.environ.get("RPC_URL", "RPC_URL")
POOL = os.environ.get("POOL", "0x0000000000000000000000000000000000000000")
SWAP_TOPIC = "0xd78ad95fa46c994b6551d0da85fc275fe613ce37657fb8d5e3d130840159d822"  # Uniswap V2 Swap

def rpc(method, params):
    req = urllib.request.Request(
        RPC_URL,
        data=json.dumps({"jsonrpc": "2.0", "id": 1, "method": method, "params": params}).encode(),
        headers={"Content-Type": "application/json"},
    )
    with urllib.request.urlopen(req, timeout=30) as resp:
        body = json.loads(resp.read())
    if "error" in body:
        raise RuntimeError(body["error"])
    return body["result"]

latest = int(rpc("eth_blockNumber", []), 16)
start = latest - 20
rows = []
for n in range(start, latest + 1):
    block = rpc("eth_getBlockByNumber", [hex(n), True])
    if not block or not block.get("transactions"):
        continue
    for idx, tx in enumerate(block["transactions"]):
        to = (tx.get("to") or "").lower()
        if to != POOL.lower():
            continue
        rows.append({
            "block": n,
            "tx_index": idx,
            "tx_hash": tx["hash"],
            "from": tx["from"],
            "gas_price": int(tx.get("gasPrice", "0x0"), 16),
        })

print(json.dumps(rows[:50], indent=2))
print(f"blocks_scanned={latest - start + 1} pool_txs={len(rows)}")

Verificación de la Medición y Registro de Resultados

Una ejecución exitosa imprime un arreglo JSON de transacciones del pool con su número de bloque e índice intra-bloque, seguido de una línea de resumen. Verifica la salida contra un explorador de bloques para uno o dos bloques: los hashes de transacción e índices deben coincidir exactamente. Si no coinciden, tu endpoint está devolviendo una vista diferente de la cadena, lo cual es en sí mismo un hallazgo que vale la pena registrar.

Registra los resultados en una tabla para que las ejecuciones sean comparables entre endpoints y ventanas de tiempo. No rellenes números que no hayas medido; deja las celdas vacías hasta que una ejecución los produzca. A continuación se muestra una plantilla útil.

• | Ejecución | Etiqueta del endpoint | Rango de bloques | Txs del pool | Índice intra-bloque mediano | Notas |
• |-----|----------------|-------------|----------|--------------------------|-------|
• | 1 | RPC_URL (A) | latest-20..latest | (medido) | (medido) | línea base |
• | 2 | RPC_URL (B) | mismo rango | (medido) | (medido) | comparar consistencia |

Procedimiento de Diagnóstico: Comparación de Dos Endpoints

Si sospechas que tu endpoint te está dando una vista obsoleta o reordenada de transacciones pendientes o confirmadas, ejecuta el mismo rango de bloques contra dos endpoints y compara los resultados. El script a continuación compara hashes de transacción e índices por bloque. La divergencia en bloques confirmados indica un problema de consistencia; la divergencia en datos pendientes es esperada y no debe tratarse como una falla.

Esto es un diagnóstico, no un benchmark. Te dice si dos endpoints coinciden en el estado confirmado, no cuál es más rápido o confiable bajo carga. Para preguntas de rendimiento, mide la latencia y las tasas de error por separado durante una ventana controlada.

const RPC_A = process.env.RPC_A || "RPC_URL";
const RPC_B = process.env.RPC_B || "RPC_URL";

async function call(url, method, params) {
  const res = await fetch(url, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ jsonrpc: "2.0", id: 1, method, params }),
  });
  const body = await res.json();
  if (body.error) throw new Error(JSON.stringify(body.error));
  return body.result;
}

async function compareBlock(n) {
  const [a, b] = await Promise.all([
    call(RPC_A, "eth_getBlockByNumber", ["0x" + n.toString(16), false]),
    call(RPC_B, "eth_getBlockByNumber", ["0x" + n.toString(16), false]),
  ]);
  const ha = a.transactions.join(",");
  const hb = b.transactions.join(",");
  return { block: n, match: ha === hb, countA: a.transactions.length, countB: b.transactions.length };
}

(async () => {
  const latest = parseInt(await call(RPC_A, "eth_blockNumber", []), 16);
  const results = [];
  for (let n = latest - 10; n <= latest; n++) results.push(await compareBlock(n));
  console.table(results);
})();

Solución de Problemas Comunes de Medición

La mayoría de las mediciones MEV fallidas provienen de cuatro causas: el endpoint no devuelve cuerpos de transacción completos, el rango de bloques es demasiado pequeño para contener actividad relevante, la dirección del pool o el tema del evento es incorrecto, o el endpoint está balanceado entre nodos con vistas ligeramente diferentes. Cada una tiene un síntoma y una solución distintos.

Si eth_getBlockByNumber devuelve transacciones solo como hashes, pasa true como segundo parámetro. Si el escaneo devuelve cero transacciones del pool, amplía el rango y confirma la dirección del pool y el tema del evento contra una transacción conocida. Si dos endpoints discrepan en bloques confirmados, trátalo como un incidente de consistencia y vuelve a ejecutar después de que los endpoints se resincronicen. Si los resultados varían entre ejecuciones en el mismo rango, es probable que tu endpoint esté enrutando a diferentes backends.

• Arreglos de transacciones vacíos: verifica el parámetro booleano y la codificación del número de bloque.
• Cero coincidencias: verifica la suma de comprobación de la dirección del pool y el tema del evento.
• Resultados inconsistentes: fija un solo endpoint o usa un nodo dedicado.
• Tiempos de espera agotados: reduce el rango de bloques y añade reintentos con retroceso exponencial.

Limitaciones, Compensaciones y Enfoques de Mitigación

Los datos de orden por sí solos no prueban intención. Una transacción que parece sándwich puede ser un arbitraje legítimo que casualmente rodeó otra operación. La atribución requiere datos a nivel de bundle, APIs de constructores o heurísticas que están fuera del JSON-RPC estándar. Trata cualquier estimación de MEV a partir de datos de bloque en bruto como un límite inferior con falsos positivos.

Las mitigaciones tienen diferentes compensaciones. Un slippage más ajustado reduce la rentabilidad del sándwich pero aumenta los swaps fallidos. Los relays de transacciones privadas reducen la exposición al frontrunning pero concentran la confianza en el operador del relay. Los mempools cifrados y la secuenciación justa buscan eliminar las ventajas de orden a nivel de protocolo pero cambian la latencia y las garantías de inclusión. Las subastas por lotes y el enrutamiento basado en intenciones trasladan el problema del orden a la competencia de solvers. Ninguno de estos elimina MEV; cada uno mueve dónde se captura y quién soporta el costo.

Próximos Pasos: Instrumentación y Elecciones de Infraestructura

Para ir más lejos, extiende la medición a datos a nivel de bundle donde la red los exponga, rastrea las distribuciones de tarifas de prioridad por bloque y correlaciónalas con la actividad del pool. Mantén un rango de bloques fijo y una etiqueta de endpoint para cada ejecución para que los resultados sigan siendo comparables. Si necesitas acceso consistente y de baja varianza a datos confirmados y pendientes, un nodo dedicado elimina la varianza del balanceador de carga que confunde las comparaciones de endpoints; consulta las opciones de nodo dedicado y la descripción general de precios RPC antes de comprometerte con un plan.

Para la selección de endpoints y proveedores específicamente, utiliza el Asistente RPC en lugar de adivinar. Para obtener información sobre cómo encajan los nodos y las capas RPC, la guía de alojamiento de nodos blockchain y la guía de endpoints RPC son compañeros útiles. Si trabajas con múltiples cadenas, la guía de endpoints RPC multicadena cubre las diferencias operativas que afectan la medición de MEV.

• Fija un endpoint por ejecución de medición y registra su etiqueta.
• Guarda la salida JSON en bruto junto a la tabla de resumen para reproducibilidad.
• Vuelve a ejecutar el mismo rango de bloques después de cualquier cambio de endpoint.
• Separa las comprobaciones de consistencia de las pruebas de latencia y rendimiento.