¿Qué es MEV en cripto? Valor Máximo Extraíble explicado

Definición y alcance de MEV

El valor máximo extraíble (MEV) es la ganancia máxima que se puede capturar de la producción de bloques al incluir, excluir o reordenar transacciones, por encima de la recompensa de bloque estándar y las comisiones de gas. El término originalmente significaba valor extraíble por mineros porque los mineros de prueba de trabajo controlaban el contenido de los bloques. Tras el paso de Ethereum a prueba de participación, los validadores asumieron ese rol, por lo que el término más amplio valor máximo extraíble es ahora el estándar.

MEV no es un error en un contrato inteligente específico. Es una propiedad económica de cualquier blockchain donde una parte tiene discreción sobre el orden de las transacciones y donde las transacciones pendientes son visibles antes de su inclusión. Eso lo hace relevante para Ethereum, Solana, rollups L2 con secuenciadores centralizados y la mayoría de los demás entornos de ejecución, aunque la mecánica difiera.

Este artículo se centra en el mecanismo, las estrategias comunes y una forma reproducible de medir los efectos del ordenamiento usando llamadas JSON-RPC estándar. No recomienda una estrategia MEV específica ni respalda la extracción como modelo de negocio.

Supuestos y requisitos previos

La explicación asume que entiendes cómo las transacciones entran en un mempool, cómo el precio del gas y las tarifas de prioridad influyen en la inclusión, y cómo se ensamblan los bloques. Si necesitas un repaso sobre la secuenciación de transacciones, la guía sobre nonces y orden de transacciones es un buen punto de partida.

También deberías tener acceso a un endpoint RPC con capacidad de archivo o completo para la red que deseas inspeccionar. Los endpoints públicos a menudo limitan la tasa de las llamadas necesarias para reconstruir el contenido de los bloques y las transacciones pendientes, por lo que un endpoint dedicado o de pago es más confiable para el trabajo de medición.

• Un endpoint JSON-RPC para la red objetivo, almacenado como RPC_URL
• Familiaridad básica con curl o un lenguaje de scripting como Python
• Un nodo de archivo o completo si necesitas datos históricos de bloques
• Conciencia de que la visibilidad del mempool difiere según la red y el cliente

Cómo el orden de las transacciones crea valor extraíble

Cada bloque es una lista ordenada de transiciones de estado. Si dos transacciones tocan el mismo pool de liquidez, la primera se ejecuta contra las reservas actuales del pool y la segunda contra las reservas actualizadas. La diferencia en el precio de ejecución entre esos dos ordenamientos es el valor en juego. Un productor de bloques que puede elegir el orden puede, en principio, capturar esa diferencia.

En la práctica, el valor suele ser capturado por buscadores: participantes independientes que ejecutan algoritmos sobre datos de transacciones pendientes para encontrar ordenamientos rentables. Los buscadores envían paquetes de transacciones a los constructores, quienes ensamblan bloques y pujan por el derecho a proponerlos. Luego los validadores proponen el bloque ganador. Esta separación de roles a menudo se denomina separación proponente-constructor, y cambia quién captura MEV y cuánto de ello fluye de vuelta a los validadores.

El modelo mental clave es que MEV es una función de (1) el conjunto de transacciones pendientes, (2) la discreción de la parte que elige el orden, y (3) la sensibilidad económica de los contratos afectados. Elimina cualquiera de esos tres y la oportunidad se reduce.

Estrategias MEV comunes y su mecánica

La mayor parte de la actividad MEV cae en un pequeño número de patrones reconocibles. Entenderlos te ayuda a reconocer cuándo tus propias transacciones están expuestas.

Arbitraje en DEX: cuando dos pools cotizan el mismo activo a precios diferentes, un buscador compra en el pool más barato y vende en el más caro en el mismo bloque. Esto generalmente se considera benigno o incluso beneficioso porque empuja los precios hacia la paridad.

Liquidaciones: los protocolos de préstamo permiten a cualquiera pagar la deuda de un prestatario no saludable a cambio de una bonificación por liquidación. Los buscadores compiten por ser los primeros cuando una posición cruza su umbral, lo que es una carrera por el ordenamiento.

Ataques sándwich: un buscador coloca una compra antes de un gran swap pendiente y una venta después, beneficiándose del impacto en el precio que crea la operación de la víctima. La víctima recibe un precio de ejecución peor del que habría obtenido sin las transacciones circundantes.

Frontrunning y backrunning: versiones generalizadas de la misma idea, donde una transacción se inserta inmediatamente antes o después de una transacción objetivo para obtener ventaja. El sniping de acuñación de NFT y los reclamos por orden de llegada son ejemplos comunes.

Medición de los efectos del ordenamiento con JSON-RPC

Puedes construir una medición reproducible de los efectos del ordenamiento sin depender de ningún panel de terceros. El procedimiento a continuación reconstruye un bloque, identifica swaps contra un pool conocido y compara el precio ejecutado de cada swap con el precio medio del pool antes del bloque. La diferencia, agregada por bloque, es un límite inferior del valor de ordenamiento presente en ese bloque.

Primero, obtén el bloque y sus recibos. La siguiente llamada curl recupera un bloque por número con los cuerpos completos de las transacciones:

• Reemplaza 0x1312D00 con el número de bloque hexadecimal que deseas inspeccionar
• Configura RPC_URL con un endpoint que admita cuerpos completos de transacciones
• Para bloques históricos, usa un endpoint de archivo

curl -s -X POST "$RPC_URL" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["0x1312D00", true]}'

Un diagnóstico Python ejecutable para el ordenamiento de swaps

El script a continuación extiende la llamada manual a un diagnóstico repetible. Obtiene un bloque, filtra eventos Swap en una dirección de pool especificada e imprime la posición de cada swap en el bloque junto con su remitente. Ejecútalo en un rango de bloques para ver con qué frecuencia el mismo remitente aparece inmediatamente antes y después de un swap grande, lo cual es una firma de actividad sándwich.

El script usa solo la biblioteca estándar y una única variable de entorno RPC_URL. No requiere una clave API de ningún proveedor específico.

• Configura POOL_ADDRESS con el pool que deseas inspeccionar
• Los hashes de los temas de Swap difieren según el DEX; confirma el tema para tu protocolo objetivo
• Ejecuta en bloques consecutivos para distinguir el ruido de los patrones repetidos

import json, os, urllib.request

RPC_URL = os.environ["RPC_URL"]
POOL = os.environ.get("POOL_ADDRESS", "0x0000000000000000000000000000000000000000")
SWAP_TOPIC = "0xd78ad95fa46c994b6551d0da85fc275fe613ce37657fb8d5e3d130840159d822"

def rpc(method, params):
    body = json.dumps({"jsonrpc":"2.0","id":1,"method":method,"params":params}).encode()
    req = urllib.request.Request(RPC_URL, body, {"Content-Type":"application/json"})
    return json.loads(urllib.request.urlopen(req).read())["result"]

def scan_block(block_hex):
    block = rpc("eth_getBlockByNumber", [block_hex, True])
    print(f"block {int(block_hex,16)} txs={len(block['transactions'])}")
    for i, tx in enumerate(block["transactions"]):
        if tx.get("to", "").lower() == POOL.lower():
            print(f"  pos={i} from={tx['from']} input={tx['input'][:10]}")

if __name__ == "__main__":
    scan_block("0x1312D00")

Resultados de verificación esperados y cómo leerlos

Una ejecución exitosa imprime el número de bloque, el conteo de transacciones y cada transacción que se dirige al pool, con su posición y remitente. Si ves el mismo remitente en las posiciones i-1 e i+1 alrededor de un swap grande en la posición i, eso es consistente con un patrón sándwich. Si el mismo remitente aparece solo una vez, puede ser una operación de liquidez legítima.

Registra tus observaciones en una tabla de resultados para que la medición sea reproducible. A continuación se muestra una estructura sugerida; completa los valores de tus propias ejecuciones en lugar de copiar cifras.

La tabla es una plantilla de medición, no un punto de referencia. Cualquier número que publiques debe provenir de tus propias ejecuciones contra un endpoint y un rango de bloques documentados.

Solución de problemas comunes de medición

Si el script devuelve null para un bloque, es probable que el endpoint esté podado y no sirva estado histórico. Cambia a un endpoint de archivo o a un proveedor que admita explícitamente consultas de archivo. Si la lista de transacciones está vacía, confirma que pasaste true como segundo parámetro a eth_getBlockByNumber.

Si ves errores de límite de tasa, agrupa tus solicitudes o cambia a un endpoint dedicado. Los endpoints públicos a menudo limitan las solicitudes por segundo, lo que hace que el escaneo bloque por bloque no sea confiable. Para mediciones de alto volumen, un nodo dedicado o un plan RPC de pago es la opción práctica.

Si faltan eventos de swap, verifica el hash del tema para el DEX específico. Uniswap V2, V3 y otros protocolos usan firmas de eventos diferentes, y un tema que no coincida devolverá silenciosamente ninguna coincidencia.

• bloque null: usa un endpoint con capacidad de archivo
• transacciones vacías: pasa true para cuerpos completos
• límites de tasa: agrupa solicitudes o usa un endpoint dedicado
• no se encontraron swaps: confirma el tema del evento para el DEX objetivo

Enfoques de mitigación y sus ventajas y desventajas

No hay una solución única para MEV, y cada mitigación desplaza costos en lugar de eliminarlos. Los límites de deslizamiento reducen las pérdidas por sándwich pero pueden causar transacciones fallidas. Los relays de transacciones privadas ocultan las transacciones pendientes de los buscadores, lo que reduce el frontrunning pero depende de los supuestos de confianza y la cobertura del relay. Las subastas por lotes y la secuenciación justa buscan eliminar la discreción sobre el orden, pero requieren cambios a nivel de protocolo y pueden introducir latencia.

Para los usuarios, las palancas prácticas son la tolerancia al deslizamiento, el momento de la transacción y la elección de lugares que enrutan a través de mempools privados o liquidación por lotes. Para los desarrolladores, las palancas son el diseño de contratos (por ejemplo, esquemas de compromiso-revelación) y elecciones de infraestructura que brinden una visión consistente del estado pendiente.

Para los operadores de nodos y proveedores RPC, la pregunta relevante es si el endpoint expone un mempool público y con qué rapidez se propagan las transacciones pendientes. Una visión lenta o inconsistente del mempool hace que la medición no sea confiable y puede hacer que tus propias transacciones sean superadas por la competencia.

Consideraciones de infraestructura para cargas de trabajo conscientes de MEV

Si estás construyendo buscadores, análisis o sistemas de trading conscientes de MEV, el comportamiento del endpoint importa tanto como la estrategia. Necesitas acceso de baja latencia a transacciones pendientes, datos de bloques consistentes y soporte de archivo para backtesting. Los endpoints públicos rara vez proporcionan las tres cosas a escala.

El servicio API de OnFinality proporciona acceso RPC gestionado en múltiples redes, y los nodos dedicados te dan rendimiento aislado para cargas de trabajo sensibles a la latencia. Para una recomendación concreta de endpoint para tu red objetivo, el RPC Assistant puede emparejarte con un proveedor; este artículo se mantiene deliberadamente en el lado de la metodología.

Al comparar endpoints, mide el mismo rango de bloques en cada uno y registra la latencia de propagación, las tasas de error y la cobertura de archivo. Trata cualquier afirmación de rendimiento publicada como una hipótesis a verificar con tu propia carga de trabajo.

• Confirma el soporte de archivo antes de hacer backtesting con bloques históricos
• Mide la latencia de propagación de transacciones pendientes en cada endpoint candidato
• Verifica los límites de tasa contra tu volumen de solicitudes esperado
• Prefiere rendimiento aislado para estrategias sensibles a la latencia

Próximos pasos para seguir estudiando

Comienza ejecutando el diagnóstico en un rango pequeño de bloques en una red que ya uses. Compara los resultados con un segundo endpoint para ver cuánto del patrón observado depende del endpoint. Luego extiende el script para calcular el deslizamiento realizado por swap y agregarlo por bloque.

Para un contexto más amplio sobre operaciones de nodos y selección de endpoints, consulta la guía de alojamiento de nodos blockchain y la descripción general de endpoints RPC multicadena. Si estás evaluando proveedores para una red específica, el RPC Assistant puede reducir la elección, mientras que la página de precios te ayuda a comparar planes contra tu volumen de solicitudes esperado.