Front-Running y Back-Running

Todo bloque es, en el fondo, una lista ordenada. Una vez que interiorizáis eso —que un bloque no es una bolsa de transacciones sino una cola estrictamente secuenciada, ejecutada de arriba abajo, con los efectos de la transacción anterior plenamente aplicados antes de que se ejecute la siguiente— el MEV deja de parecer misterioso. Se vuelve obvio. Si podéis elegir dónde aterriza vuestra transacción respecto a la de otro, y podéis ver su transacción antes de que se ejecute, entonces podéis actuar sobre información que ya han revelado pero aún no han materializado. Ese es todo el truco.

Esta lección cubre los dos movimientos de ordenación primitivos —front-running (saltar antes de la víctima) y back-running (colarse después)— más la taxonomía formal con la que se construye cada ataque posterior. Los sándwiches, la liquidez JIT, el sniping de oráculos: todos no son más que front-runs y back-runs con ropa más elegante.

Front-running: saltarse la cola, actuar sobre la filtración

Analogía. Imaginad un agente de bolsa que recibe una orden enorme de un cliente: “comprar 500.000 acciones de Acme”. El agente sabe que esa orden, en cuanto llegue al mercado, empujará el precio de Acme hacia arriba. Así que antes de ejecutar la del cliente, compra Acme discretamente para su propia cuenta, deja que la orden del cliente eleve el precio y se embolsa la diferencia. En las finanzas tradicionales este es el delito de manual del front-running, y es ilegal precisamente porque requiere acceso privilegiado: tienes que ser el infiltrado que ve el flujo de órdenes.

En una blockchain pública, ese privilegio queda abolido. El pool de transacciones pendientes —la mempool— se difunde a todo el mundo. Cualquiera que ejecute un nodo ve la transacción de la víctima en el instante en que se anuncia, mucho antes de que se mine. No hay infiltrado, porque todos lo son.

Definición. El front-running es el acto de colocar tu transacción de modo que se ejecute inmediatamente antes de una transacción objetivo (“víctima”), con el fin de lucrarte de la información que la transacción pendiente de la víctima revela. No le robas su transacción: corres para actuar sobre sus consecuencias antes de que lo haga ella, ocupando una posición anterior en el bloque.

Ejemplo resuelto. Observas la mempool y detectas un swap pendiente: un operador está a punto de comprar a mercado una gran cantidad de un token en un AMM de producto constante al estilo Uniswap. Sabes que una compra grande sube por la curva de bonding, así que el precio posterior a la operación será notablemente más alto que el actual. En concreto:

1. Envías tu propia compra del mismo token, con una comisión de prioridad más alta para que se ordene antes del swap de la víctima. Te ejecutas al precio actual, más bajo.
2. La compra grande de la víctima se ejecuta a continuación, empujando el precio hacia arriba, exactamente como predijiste.
3. Ahora estás sentado sobre tokens que compraste baratos, justo antes de una operación que movía el precio y que sabías que venía.

Capturaste valor que, en efecto, filtró la víctima al difundir su intención en un pool público. La víctima, mientras tanto, se ejecuta a un precio algo peor del que habría obtenido, porque tu compra empujó la curva antes de que aterrizara la suya.

Back-running: surfear la estela que deja la operación

Analogía. El front-running es colarse delante de alguien; el back-running es ponerse justo detrás para recoger lo que se le caiga. Cuando pasa un barco grande deja una estela, y un surfista listo no pelea contra el barco: surfea la estela que crea. El back-running se lucra de las secuelas de la transacción de la víctima, no de adelantarse a ella.

Definición. El back-running es colocar tu transacción de modo que se ejecute inmediatamente después de una transacción objetivo, con el fin de capturar un cambio de estado que el objetivo crea. No compites por el precio de la víctima: cosechas la nueva oportunidad que su transacción abre.

El back-run clásico es el arbitraje. Un swap grande en un AMM aleja el precio de ese pool del resto del mercado. En el instante en que aterriza el swap, hay una discrepancia de precio entre ese pool y los demás: dinero gratis para quien lo opere de vuelta a la línea primero. Un back-runner se cuela justo después del swap grande y captura ese arbitraje. Otros objetivos de back-run:

• Ser el primero en actuar sobre una actualización fresca de oráculo (p. ej. un nuevo feed de precios habilita una liquidación rentable).
• Ser el primero en entrar en un pool recién creado o en un contrato recién fondeado (sniping del estado inicial).
• Capturar la oportunidad de reequilibrio que crea un depósito o retirada grande.

Ejemplo resuelto. Una ballena vende a mercado un token en un pool de producto constante, desplomando el precio de ese pool un 4% por debajo de cualquier otro mercado. Le haces back-run:

1. Tu transacción se ordena inmediatamente después de la venta de la ballena.
2. Compras el token ahora infravalorado de ese pool agotado y simultáneamente lo vendes en otro mercado que aún está al precio antiguo.
3. Te embolsas aproximadamente el diferencial que acaba de abrir la operación de la ballena: un arbitraje casi sin riesgo que existió durante exactamente una posición de transacción.

Generalmente más suave con la víctima. El back-running normalmente no empeora la ejecución de la víctima: actúas después de que su operación ya esté liquidada, así que no mueves el precio en su contra como hace un front-run. El arbitraje que capturas es valor que creó la ineficiencia de precios del AMM, no valor extraído directamente del bolsillo de la víctima. Por eso el back-running se considera a menudo el primo más “benigno”: la ballena ya obtuvo su (mal) precio; tú solo limpias el estropicio después. El front-running, en cambio, degrada directamente la ejecución de la víctima.

La posición es el ataque: velo en el bloque

Un bloque no es más que una lista ordenada, y la única decisión real del atacante es en qué posición ponerse respecto a la víctima. Pon una transacción por encima de la víctima y le haces front-running; por debajo, back-running; ambas, y has construido un sándwich (próxima lección). Usa los controles de abajo para soltar la transacción del atacante en cada posición y mira qué le compra eso.

Una taxonomía de los ataques de ordenación

En 2019 un artículo fundacional (“Flash Boys 2.0”) dio al campo un vocabulario limpio. Todo ataque de ordenación cae en uno de tres cajones, definidos por lo que tu transacción le hace a la de la víctima:

Desplazamiento

Un ataque de desplazamiento hace que la transacción de la víctima falle, revierta o se vuelva irrelevante: tú agarras la oportunidad que ella buscaba, y la suya ya no hace nada útil. No necesitas que la transacción de la víctima tenga éxito; solo necesitas llegar primero.

• Ejemplo. Una reclamación rentable de bug bounty, una asignación de airdrop, un arbitraje de un solo disparo o una liquidación que solo una transacción puede ganar. Ves la reclamación pendiente de la víctima, la copias, pagas una comisión de prioridad más alta y aterrizas primero. Cobras la recompensa; la transacción de la víctima ahora revierte o no hace nada porque la oportunidad ya se esfumó.
• Rasgo clave. La transacción de la víctima queda desplazada: su éxito era mutuamente excluyente con el tuyo, y tú ganaste la carrera.

Inserción

Un ataque de inserción envuelve a la víctima: colocas una transacción antes y otra después de ella —front-run más back-run combinados—, de modo que la víctima se ejecuta apretada en el medio. El ataque de inserción canónico es el sándwich, donde compras por delante de la compra de la víctima para inflar el precio, dejas que se ejecute al precio inflado y luego vendes justo después. Ambas transacciones necesitan que la de la víctima tenga éxito (es el relleno de tu sándwich). A continuación le damos a la inserción su propia lección completa, con las matemáticas exactas.

Supresión (censura)

Un ataque de supresión retrasa o excluye la transacción de la víctima, manteniéndola fuera del bloque o empujándola a un bloque posterior. No reordenas alrededor de ella; te aseguras de que no se ejecute ahora.

• Ejemplo. Frenar la liquidación o actualización de oráculo de un competidor el tiempo suficiente para que gane la tuya, o censurar transacciones para que una oportunidad sensible al tiempo siga abierta para ti. Históricamente esto se hacía a veces saturando la cadena con spam para desplazar al objetivo; con la construcción de bloques moderna puede significar que un builder simplemente elija omitir una transacción.
• Rasgo clave. El ataque va de ausencia: la transacción de la víctima se suprime en lugar de rodearse.

Por qué esto es un problema exclusivamente de blockchain

Los ataques de ordenación no son ideas nuevas: las finanzas tradicionales llevan un siglo combatiendo el front-running. Lo nuevo es que las blockchains los hacen sin permiso y programables. Tres propiedades se combinan en una tormenta perfecta:

1. Mempool pública. Las transacciones pendientes se difunden a todos los nodos antes de minarse. La “visión privilegiada del flujo de órdenes” para la que un front-runner de finanzas tradicionales necesita un asiento de infiltrado es, on-chain, simplemente lo predeterminado: cualquiera puede leerla.
2. Construcción de bloques sin permiso. Cualquiera puede pagar para influir en la ordenación. Pujando una comisión de prioridad más alta (y, en el stack moderno, enviando bundles a los builders de bloques), un participante corriente puede comprar una posición elegida en el bloque. No hay mesa de cumplimiento de un exchange que te detenga.
3. Ejecución determinista. La EVM ejecuta transacciones en una secuencia fija con los efectos de cada una plenamente aplicados antes de la siguiente. Así que un atacante puede simular el resultado exacto de “mi tx, luego la de la víctima” fuera de la cadena y saber con precisión cuánto ganará antes de comprometerse. El beneficio no es una apuesta; está calculado.

Contraste con las finanzas tradicionales. Allí, el front-running es ilegal, perseguible y requiere acceso privilegiado (debes ser un agente o infiltrado que pueda ver el flujo). On-chain, el mismo acto es sin permiso (sin acceso especial), seudónimo (difícil de atribuir) y no obviamente ilegal (es “solo” pagar por posición en el bloque). El mecanismo que hace la cadena transparente y sin confianza es el mismísimo que entrega a los atacantes un asiento gratis en la mesa del flujo de órdenes.

Front-runners generalizados: bots que ni siquiera leen el código

Podríais suponer que un front-runner necesita entender qué hace la transacción de la víctima: reconocer un swap, decodificar una reclamación, parsear los calldata. La realidad inquietante es que no lo necesitan. Los front-runners generalizados (a veces “bots de frontrunning generalizado”) trabajan a ciegas: extraen transacciones pendientes de la mempool, simulan cada una contra el estado actual y comprueban si simplemente copiarla —sustituyendo su propia dirección— les daría un beneficio. Si la simulación muestra una ganancia, el bot reproduce la transacción para sí mismo con una comisión de prioridad más alta para aterrizar primero.

El bot no tiene ni idea de que está reclamando un airdrop, cosechando una recompensa o haciendo sniping de un arbitraje: solo sabe que el simulador devolvió “esto es rentable si lo ejecuto”. Por eso incluso un contrato totalmente nuevo y oscuro puede sufrir front-run en segundos tras aparecer una transacción explotable: el atacante no necesita entender tu protocolo, solo notar que tu transacción pendiente genera dinero y robarla yendo primero. Es una máquina pura de causa y efecto: ver beneficio → copiar → superar la puja → ganar.

Atándolo todo

Quita la jerga y los ataques de ordenación se reducen a una sola idea: un bloque es una lista ordenada, y elegir tu posición en esa lista es una forma de poder. Sitúate antes de la víctima para actuar sobre la intención que filtró en la mempool pública — eso es el front-running, y empeora su ejecución. Sitúate después de ella para cosechar el arbitraje o cambio de estado que su operación creó — eso es el back-running, generalmente más suave con la víctima. La taxonomía formal clasifica cada variante por lo que tu transacción le hace a la suya: desplazamiento (la suya muere), inserción (la envuelves — el sándwich) y supresión (la suya nunca se ejecuta). Nada de esto requiere acceso de infiltrado, porque la mempool pública, la ordenación sin permiso y la ejecución determinista entregan el asiento privilegiado a todo el mundo — y los bots generalizados lo explotan sin siquiera leer tu código.

A continuación —el ataque sándwich— tomamos el patrón de inserción que acabamos de definir y fijamos las matemáticas exactas: cómo la compra del front-run recorre la curva de producto constante, cuánto peor se vuelve exactamente la ejecución de la víctima, cómo la tolerancia de slippage fija el techo de beneficio del atacante y cómo calcular el tamaño óptimo del sándwich. Los dos primitivos que aprendisteis aquí —front-run más back-run— están a punto de combinarse en la extracción más infame de todo el MEV.