Saltar al contenido

Front-running en cadena

El front-running en cadena aprovecha la información de una transacción pendiente para ejecutar otra antes y obtener beneficio. Esta entrada explica cómo influyen el pool público, el orden, el MEV, el deslizamiento y el envío privado.

Actualizado

Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.

Respuesta directa

El front-running en cadena ocurre cuando alguien conoce una transacción pendiente y logra que otra se ejecute antes para extraer valor. Puede copiar una llamada rentable, comprar antes de una orden conocida o competir por una oportunidad escasa en cadena. Es una modalidad de valor máximo extraíble (MEV), no un sinónimo de todas las estrategias de MEV.

La oportunidad existe porque una transacción de Ethereum suele difundirse y permanecer en pools de transacciones antes de que un validador la incluya en un bloque. Los searchers pueden examinar operaciones pendientes, simular resultados y enviar sus propias transacciones o paquetes. El orden final se decide durante la construcción del bloque; pagar una mayor comisión de prioridad puede influir en la inclusión, pero no garantiza una posición concreta.

Para el usuario importa si la transacción revela una intención valiosa antes de ejecutarse, si sus límites dejan margen para extraer valor y quién puede influir en el orden. Los swaps en DEX con deslizamiento amplio, los reclamos públicos con secretos reutilizables, las liquidaciones, las subastas y las acuñaciones limitadas pueden atraer competencia.

Cómo funciona

En una operación sándwich, un searcher detecta una compra pendiente en un DEX, adquiere el mismo activo justo antes y lo vende justo después. La compra del usuario eleva el precio del pool entre las dos operaciones del searcher. La estrategia solo funciona si el mínimo que recibirá el usuario aún permite ejecutar tras el movimiento adicional y el beneficio cubre todas las comisiones.

Los front-runners generalizados buscan llamadas cuyo valor pueda copiarse. Si una transacción revela una respuesta o autorización que no está vinculada al destinatario previsto, otra cuenta puede reproducir la llamada e intentar ejecutarla primero. El contrato puede usar esquemas de commit-reveal y vincular el reclamo a un destinatario concreto; pedir al usuario que suba las comisiones no protege la información ya expuesta.

Los campos de comisiones de Ethereum, como maxPriorityFeePerGas y maxFeePerGas, determinan cuánto está dispuesto a pagar el remitente. No ocultan el contenido, y los builders pueden evaluar paquetes en vez de ordenar cada transacción por un solo campo. Por tanto, el front-running es un problema de información y orden, no solo una carrera por el precio del Gas.

Ejemplo

Supongamos que un pool AMM contiene 100 ETH y 200,000 USDC. Un usuario envía públicamente una transacción para comprar ETH con 10,000 USDC y una tolerancia de deslizamiento del 5%. La transacción pendiente revela la dirección, el tamaño y la salida mínima aceptable.

Un searcher simula el swap y envía una compra para ejecutarla antes, seguida de una venta para después. Si ambas quedan alrededor de la transacción del usuario, este recibe menos ETH que sin el sándwich, aunque permanece dentro del límite del 5%; el searcher conserva la diferencia tras las comisiones.

El resultado no está garantizado. Otros searchers, las comisiones del pool, los cambios de precio, la falta de inclusión o la comprobación de salida mínima pueden eliminar la rentabilidad o hacer fallar la secuencia. Una operación grande normal también afecta al precio, por lo que deben revisarse las trazas y el estado del pool antes de atribuir todo el deslizamiento a un ataque.

Riesgos y mitigación

Ningún ajuste elimina todo riesgo de ordenamiento. El objetivo práctico es reducir filtraciones innecesarias y limitar la pérdida que una transacción acepta.

  • Fijar una salida mínima o límite de precio defendible según la profundidad del pool y las condiciones actuales; no ampliar el deslizamiento solo para forzar la ejecución.
  • Revisar impacto en el precio, liquidez, reglas de transferencia del token y ruta antes de firmar, sobre todo en operaciones grandes en pools poco profundos.
  • Usar cuando proceda servicios reputados de envío privado o protección MEV, comprobando cobertura de builders, comportamiento ante fallos, política de privacidad y supuestos de confianza.
  • Al diseñar protocolos, no colocar secretos para el primero que llegue en los datos; usar vinculación al destinatario, commit-reveal, subastas por lotes u otros mecanismos adecuados.

El envío privado puede ocultar una transacción del pool público, pero no ofrece una garantía universal. El usuario confía en que el servicio y los builders no la filtren ni la exploten; cambiar la ruta RPC antes de la confirmación puede hacerla pública. También puede retrasarse o no incluirse.

Errores frecuentes

Mito 1: Pagar más Gas impide el front-running

Una comisión de prioridad mayor puede mejorar las probabilidades de inclusión, pero no oculta la operación. Searchers y builders pueden enviar un orden o paquete más valioso, así que pujar con comisiones no basta como protección.

Mito 2: Toda ejecución desfavorable es un ataque sándwich

Las órdenes grandes mueven por sí mismas los precios de un AMM y el mercado puede cambiar mientras la transacción está pendiente. Las comisiones de ruta, los impuestos de transferencia y la competencia normal también pueden empeorar la ejecución.

Mito 3: Un deslizamiento cero siempre es lo más seguro

Un límite demasiado estricto puede rechazar movimientos normales y aun consumir Gas si la transacción pública se revierte. El límite adecuado depende de la liquidez, el tamaño, la urgencia y la pérdida máxima aceptable.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...