Front-running

¿Qué es el front-running?

El front-running consiste en detectar la transacción pendiente de otra persona y enviar una transacción competidora antes para obtener una ventaja económica.

En el ámbito de las criptomonedas, el front-running suele producirse cuando un bot automatizado observa una transacción antes de que se confirme y envía la suya con más posibilidades de ejecutarse primero.

El atacante puede ofrecer una comisión de prioridad más alta, enviar un bundle privado a un constructor de bloques, utilizar una infraestructura más rápida o negociar otra forma de ordenación de transacciones.

El front-running es más habitual en las blockchains programables, donde las transacciones pendientes pueden revelar operaciones rentables, liquidaciones, reclamaciones de tokens, acuñaciones de NFT, subastas u otras acciones sensibles al tiempo.

La transacción de la víctima todavía puede ejecutarse, pero puede obtener un precio peor, pagar más, perder una oportunidad o fallar tras cambiar el estado de la blockchain.

El front-running es una forma de valor máximo extraíble, conocido habitualmente como MEV.

La documentación de Ethereum sobre el valor máximo extraíble describe a los front-runners generalizados como bots que supervisan transacciones pendientes y copian oportunidades rentables ofreciendo comisiones más altas.

No todas las transacciones que se colocan antes que otra son maliciosas, ya que las blockchains necesitan algún método para decidir qué transacciones pendientes se incluyen en un bloque y en qué orden.

La cuestión clave es si alguien aprovecha el conocimiento anticipado de la transacción de otro usuario para extraer valor de él o capturar una oportunidad que el usuario ha revelado.

¿Cómo funciona el front-running?

Un usuario de blockchain crea y firma una transacción que interactúa con una wallet, un token, una aplicación descentralizada o un contrato inteligente.

Normalmente, el usuario envía la transacción firmada a un nodo mediante un punto de acceso de llamada a procedimiento remoto.

El nodo comprueba condiciones básicas como la firma, el nonce de la cuenta, el saldo disponible y el formato de la transacción.

Tras validarla, el nodo puede colocar la transacción en su mempool local y compartirla con otros nodos.

Un mempool es un conjunto de transacciones pendientes que aún no se han incluido en un bloque confirmado.

El ciclo de vida de las transacciones de Ethereum con Proof of Stake explica que, por lo general, las transacciones válidas se añaden a los mempools locales y se difunden a través de la red de la capa de ejecución.

Los bots de front-running supervisan este flujo y simulan las transacciones pendientes para determinar si ejecutar otra transacción primero podría generar beneficios.

Cuando aparece una oportunidad rentable, el bot crea una transacción competidora e intenta obtener una posición anterior en el mismo bloque o en uno previo.

El atacante puede aumentar la comisión de prioridad, utilizar conexiones de baja latencia, enviar transacciones directamente a una infraestructura especializada o agrupar varias transacciones en un bundle ordenado.

Si la transacción del atacante se ejecuta primero, cambia el estado de la blockchain antes de procesar la transacción de la víctima.

Entonces, la víctima interactúa con el estado modificado y puede obtener un resultado peor de lo esperado.

Un ejemplo sencillo de front-running

Imagina que un usuario envía una orden grande de compra de tokens a través de un pool de liquidez automatizado.

La transacción pendiente revela el par de tokens, el tamaño de la operación, el deslizamiento máximo y otros detalles de ejecución.

Un bot calcula que la compra aumentará considerablemente el precio del token en el pool.

El bot compra el token antes de que se ejecute la transacción del usuario.

La compra del usuario hace subir el precio y se completa con un precio medio menos favorable.

Después, el bot puede vender sus tokens al precio más alto y quedarse con la diferencia tras descontar las comisiones.

Cuando el atacante opera antes y después del usuario, la estrategia completa suele denominarse ataque sandwich.

La primera transacción del atacante es la operación de front-running y la segunda es la operación de back-running.

Front-running en los mercados tradicionales frente al mercado cripto

El front-running en las finanzas tradicionales suele implicar que una persona opere utilizando información confidencial sobre una orden inminente de un cliente.

El glosario de futuros de la CFTC define el front-running en futuros y opciones sobre materias primas como la toma de una posición basada en información no pública sobre una transacción inminente de otra persona.

El front-running en blockchain puede ser diferente, porque la información de un mempool público puede estar visible para muchos participantes de la red, en lugar de ser conocida únicamente a través de una relación confidencial.

Por tanto, un bot cripto puede actuar basándose en datos de transacciones observables públicamente, en lugar de información de clientes robada.

Esta diferencia técnica no convierte automáticamente todas las estrategias de front-running en blockchain en legales, justas o aceptables.

El tratamiento jurídico puede depender de la jurisdicción, el activo, la relación entre los participantes, el origen de la información, las normas del mercado y de si la conducta implica fraude o manipulación.

El significado de front-running en blockchain se centra principalmente en la visibilidad y el orden de las transacciones, mientras que la definición tradicional pone mucho énfasis en el uso indebido de información anticipada sobre órdenes.

¿Qué es un mempool?

Un mempool es el espacio de almacenamiento temporal de un nodo para las transacciones válidas que esperan a ser incluidas en un bloque.

No siempre existe un único mempool global perfectamente sincronizado, ya que cada nodo puede recibir transacciones diferentes en momentos distintos.

La latencia de la red, la configuración de los nodos, el enrutamiento privado, la sustitución de transacciones y las conexiones entre pares pueden generar distintas vistas locales.

Las transacciones pendientes suelen revelar el emisor, el destinatario, el valor transferido, los ajustes de gas y la llamada codificada al contrato inteligente.

La documentación de Ethereum sobre transacciones explica cómo los datos de una transacción identifican la función del contrato y los argumentos que el usuario pretende ejecutar.

Esta transparencia permite a los nodos validar y simular transacciones, pero también permite a los bots estudiar las intenciones de los usuarios antes de la confirmación.

Una transacción enviada mediante una ruta privada puede evitar el mempool público, aunque será visible cuando se incluya en un bloque.

Cómo permite el orden de las transacciones el front-running

Un bloque contiene las transacciones en una secuencia concreta, porque los resultados de los contratos inteligentes pueden depender del estado creado por transacciones anteriores.

Una compra de tokens ejecutada primero puede obtener un precio mejor que una compra idéntica ejecutada unos puestos más tarde.

Una liquidación completada primero puede recibir una recompensa que ya no estará disponible para la transacción siguiente.

Una acuñación limitada de NFT puede completarse antes de que se procesen todas las solicitudes pendientes.

Por tanto, los constructores de bloques tienen poder de ordenación con valor económico.

Pueden incluir, excluir, retrasar y ordenar transacciones dentro de los límites del protocolo y del tamaño de bloque.

Los searchers identifican oportunidades de ordenación rentables y pueden ofrecer al constructor una parte de los beneficios esperados.

El front-running existe porque el orden de las transacciones tiene valor siempre que dos o más acciones compiten por modificar el estado de la blockchain.

Comisiones de prioridad y pujas de gas

Los usuarios pueden adjuntar comisiones de prioridad para incentivar la inclusión más rápida de las transacciones en redes que utilizan ordenación basada en comisiones.

El modelo de comisiones de Ethereum separa la comisión base, determinada por el protocolo, de la comisión de prioridad opcional que se paga al proponente del bloque.

La especificación EIP-1559 señala que los productores de bloques tienen un incentivo económico para preferir las transacciones que ofrecen primas de gas más elevadas.

Un front-runner puede enviar una transacción competidora con una comisión de prioridad superior a la de la transacción observada.

Históricamente, este comportamiento dio lugar a subastas de prioridad de gas en las que varios bots subían repetidamente las comisiones para competir por la misma oportunidad.

Unas comisiones más altas no garantizan una ejecución anterior, porque la construcción moderna de bloques también puede implicar flujo de órdenes privado, bundles, pujas de constructores y reglas específicas de las aplicaciones.

El usuario no debería dar por hecho que aumentar solo la comisión de gas le protege del front-running.

¿Qué es el MEV?

El valor máximo extraíble es el valor que puede obtenerse al incluir, excluir u ordenar estratégicamente transacciones dentro de los bloques.

El front-running es una forma de MEV, porque el atacante obtiene beneficios colocando una transacción antes de la acción de otro usuario.

El MEV también incluye back-running, ataques sandwich, liquidaciones, arbitraje y algunas formas de censura o retraso de transacciones.

Algunas formas de MEV pueden mejorar la eficiencia del mercado al corregir diferencias de precio o completar liquidaciones necesarias.

Otras empeoran directamente la ejecución de los usuarios o generan riesgos de seguridad y centralización.

El efecto ético y económico depende del origen de los beneficios y de si perjudican a otro participante.

Un arbitraje que iguala los precios de dos mercados después de una operación puede ser distinto de un ataque sandwich que provoca deliberadamente que el usuario obtenga el peor precio permitido por su transacción.

¿Quién realiza front-running en cripto?

Un searcher es una persona o un sistema automatizado que identifica oportunidades rentables de ordenación de transacciones.

Los searchers suelen ejecutar software que supervisa transacciones pendientes, simula cambios del estado de la blockchain, calcula gastos y envía bundles rentables.

Un constructor de bloques reúne transacciones en un bloque candidato y puede seleccionar las combinaciones que generen el mayor pago total.

Un validador o proponente de bloques se encarga de proponer un bloque válido conforme a las reglas de consenso de la red.

Algunas redes combinan estos papeles de forma más directa, mientras que otras separan la secuenciación de transacciones, la construcción de bloques y su propuesta.

Los usuarios comunes también pueden hacer front-running manualmente si observan una acción pública y envían una transacción competidora, aunque los sistemas automatizados suelen tener una gran ventaja de velocidad.

Front-running generalizado

Un front-runner generalizado no necesita comprender la finalidad comercial exacta de todas las aplicaciones descentralizadas que supervisa.

El bot puede simular una transacción pendiente y determinar si copiar su llamada modificando los datos del emisor podría generar beneficios.

Si la simulación resulta rentable, el bot intenta ejecutar primero la acción copiada.

Esta estrategia puede dirigirse a nuevas oportunidades de arbitraje, reclamaciones de tokens, funciones vulnerables de contratos y otras oportunidades reveladas por transacciones pendientes.

Los bots generalizados pueden hacer que la divulgación pública de llamadas rentables a contratos sea peligrosa, porque una transacción copiada podría llegar primero a la blockchain.

Los desarrolladores nunca deberían incluir secretos valiosos directamente en los datos de una transacción suponiendo que permanecerán ocultos hasta su ejecución.

Front-running por desplazamiento

El front-running por desplazamiento se produce cuando un atacante copia o sustituye la acción de un usuario y la completa primero.

La transacción posterior de la víctima puede fallar porque la oportunidad ya no existe.

Algunos ejemplos son reclamar una recompensa, registrar un nombre, acuñar un activo limitado, aceptar una oferta o completar una liquidación.

El atacante obtiene beneficios al desplazar al usuario original, en lugar de cambiar el precio que este recibe.

Los diseños de contratos inteligentes que priorizan a quien llega primero están especialmente expuestos cuando la información necesaria aparece en el mempool público.

Front-running por inserción

El front-running por inserción coloca una transacción del atacante antes de la de la víctima y permite que esta se ejecute después.

El atacante cambia deliberadamente el estado de una forma que hace que la ejecución de la víctima resulte más rentable para él.

El ataque sandwich es la forma más conocida de front-running por inserción.

El atacante compra primero, permite que la víctima mueva el mercado y vende inmediatamente después.

La víctima suele obtener un precio cercano al peor nivel permitido por los ajustes de deslizamiento de la transacción.

Supresión y retraso de transacciones

La supresión consiste en impedir, retrasar o superar mediante una puja a otra transacción para que el atacante pueda completar primero una acción.

El atacante puede enviar muchas transacciones con comisiones elevadas, aprovechar una regla de secuenciación o colaborar con una infraestructura capaz de excluir temporalmente a la víctima.

La supresión se diferencia de la simple copia porque su objetivo es impedir que la transacción original alcance a tiempo la posición necesaria.

Esta estrategia puede afectar a subastas, reclamaciones con plazo, acciones de gobernanza y competiciones de liquidación.

Las redes y aplicaciones pueden reducir el riesgo de supresión mediante reglas de ordenación justa, garantías de inclusión y diseños que no concedan todo el valor a la primera transacción.

Ataques sandwich

Un ataque sandwich rodea la operación de una víctima con una transacción anterior y otra posterior.

La transacción de front-running mueve el precio del pool en contra de la víctima.

A continuación, se ejecuta la operación de la víctima y el precio vuelve a moverse en la misma dirección.

La transacción de back-running del atacante revierte su posición inicial y obtiene beneficios.

La víctima sufre un deslizamiento adicional que no se habría producido sin las operaciones del atacante.

El ataque solo es posible si la transacción de la víctima permite suficiente variación del precio para que toda la secuencia siga siendo válida y rentable.

Unos límites de deslizamiento más bajos pueden reducir la extracción potencial, aunque un límite demasiado estricto puede hacer que la transacción de un usuario falle durante una volatilidad normal.

Front-running frente a back-running

El front-running coloca una transacción antes de la transacción objetivo.

El back-running coloca una transacción inmediatamente después de una transacción objetivo o en una posición posterior estratégica.

Un participante de back-running puede aprovechar una oportunidad de arbitraje creada por una operación completada por un usuario sin cambiar el precio que este ya ha recibido.

Un front-runner cambia el estado antes de que se ejecute la operación del usuario y puede empeorar directamente el resultado.

Un ataque sandwich combina ambos métodos en torno a la misma víctima.

El back-running aún puede generar congestión o concentrar beneficios, pero suele considerarse menos perjudicial para el usuario objetivo que el front-running deliberado.

Front-running frente a arbitraje

El arbitraje intenta obtener beneficios de las diferencias de precio entre mercados o pools de liquidez.

Un searcher puede realizar arbitraje después de que una operación de usuario genere una nueva diferencia de precio.

Este arbitraje de back-running puede ayudar a restablecer la coherencia de los precios de mercado.

El arbitraje mediante front-running actúa antes de la transacción observada y cambia el resultado que recibe el usuario original.

La diferencia depende del orden de las transacciones y del origen de los beneficios, no de que el atacante describa la estrategia como arbitraje.

Una estrategia puede combinar una corrección de precios que mejora la eficiencia con una extracción perjudicial para un usuario.

Front-running en swaps de tokens

Los swaps de tokens son un objetivo habitual porque las transacciones pendientes revelan la dirección de la operación, el tamaño y la tolerancia al deslizamiento.

Los swaps grandes en pools con poca liquidez producen un mayor impacto en el precio y más beneficios potenciales para los atacantes.

Un bot puede simular la operación y calcular el mayor tamaño de la orden de front-running que todavía permitiría que la transacción de la víctima se ejecutara.

Entonces, el bot puede elegir un tamaño que lleve a la víctima cerca del importe mínimo de salida aceptable.

Antes de aprobar un swap, los usuarios deberían revisar el impacto en el precio y los ajustes de deslizamiento.

Una cotización favorable en pantalla no garantiza una ejecución idéntica si la transacción sigue pendiente en un mempool público.

Front-running en liquidaciones

Los protocolos de préstamo cripto pueden permitir que usuarios externos liquiden deuda en situación de riesgo y reciban una recompensa por liquidación.

Varios bots pueden detectar la misma posición liquidable y competir por completar primero la acción.

Un bot que observa la transacción pendiente de otro liquidador puede enviar la misma liquidación con mayores incentivos de ordenación.

La transacción del liquidador original puede fallar si la posición ya se ha procesado.

Si la transacción fallida se incluye y revierte, aun así puede consumir gas.

La competencia por las liquidaciones puede contribuir a la solvencia de un protocolo y, a la vez, generar un front-running agresivo entre searchers.

Front-running en acuñaciones de NFT y reclamaciones de tokens

Las acuñaciones limitadas de NFT y las reclamaciones de tokens pueden generar oportunidades valiosas para quienes llegan primero.

Una transacción de acuñación pendiente puede revelar la función del contrato y los parámetros necesarios antes de confirmarse.

Un bot puede copiar la transacción, aumentar su incentivo de ordenación y adquirir primero el artículo limitado.

Un código secreto público incluido en los datos de una transacción deja de ser secreto en cuanto la transacción entra en un mempool visible.

Los sistemas de compromiso y revelación, las listas de permitidos firmadas, la asignación aleatoria y los límites por dirección pueden ofrecer más protección que una contraseña revelada públicamente.

Front-running en subastas

Una subasta abierta en blockchain puede revelar todas las pujas antes de que termine el periodo de pujas.

Un participante puede observar la puja ganadora actual y enviar inmediatamente una puja ligeramente superior antes de la fecha límite.

Las reglas de la subasta pueden permitir este comportamiento, pero puede generar ventajas injustas para los bots de baja latencia.

Los diseños de puja sellada y compromiso y revelación ocultan los importes de las pujas hasta que termina la fase de compromiso.

Los desarrolladores deben incluir penalizaciones o plazos claros para reducir el riesgo de que los ganadores se nieguen a revelar pujas desfavorables.

Front-running en actualizaciones de oráculos

Los contratos inteligentes suelen utilizar oráculos para obtener precios cripto y otros datos externos.

Una actualización pendiente del oráculo puede revelar que el precio de referencia de un contrato está a punto de cambiar.

Un atacante puede operar antes de la actualización, mientras la aplicación sigue utilizando datos desactualizados.

También puede posicionarse para una liquidación o un pago que pase a estar disponible justo después de la actualización.

Las aplicaciones deberían validar la actualidad de los precios, utilizar reglas de actualización adecuadas y evitar diseños que proporcionen beneficios garantizados en torno a cambios previsibles de los oráculos.

Una seguridad sólida de los oráculos requiere algo más que ocultar las transacciones, ya que también importan la calidad de los datos y la lógica de los contratos.

Front-running en transacciones de gobernanza

Las transacciones de gobernanza on-chain pueden revelar votos, cambios de delegación, ejecución de propuestas y acciones de tesorería antes de confirmarse.

Un participante puede reaccionar a un voto pendiente tomando prestados, comprando o delegando tokens de gobernanza, o transfiriéndolos.

Un atacante también puede intentar ejecutar una propuesta antes de que una transacción defensiva cambie las condiciones necesarias.

Las reglas de snapshot, los retrasos de votación, los periodos de quórum y la ejecución con bloqueo temporal pueden reducir las ventajas de ordenación en el último momento.

Los sistemas de gobernanza deberían definir cuándo se mide el poder de voto, en lugar de depender únicamente de qué transacción se ejecuta primero.

Cómo afecta el front-running a los usuarios

El front-running puede hacer que los usuarios reciban menos tokens, paguen más por un activo, pierdan una recompensa o desaprovechen una oportunidad sensible al tiempo.

Una transacción desplazada puede fallar y, aun así, consumir una comisión de red.

La extracción repetida puede encarecer las aplicaciones descentralizadas y hacer que resulten menos previsibles para los participantes comunes.

Los usuarios pueden responder trasladando transacciones a canales privados, lo que reduce la transparencia del mercado público de transacciones.

Los searchers profesionales más grandes pueden obtener ventajas gracias a datos más rápidos, mejores simulaciones, relaciones directas con constructores y mayor capital.

Estas ventajas pueden concentrar el poder económico aunque la blockchain subyacente siga estando abierta a cualquiera.

Front-running y centralización de la blockchain

El MEV rentable puede recompensar a las organizaciones que cuentan con la mejor infraestructura, algoritmos, flujo de órdenes privado y conexiones con constructores.

Los validadores más pequeños pueden tener dificultades para obtener ingresos comparables mediante la construcción independiente de bloques.

Esta presión puede fomentar la especialización de los constructores de bloques y la concentración de las relaciones de enrutamiento de transacciones.

La documentación de Ethereum sobre MEV señala que el acceso desigual al MEV puede generar economías de escala y aumentar la presión hacia la centralización.

El flujo de órdenes privado puede proteger transacciones individuales, pero hacer que actividades de mercado importantes sean menos visibles y menos abiertas.

Por ello, los diseñadores de redes deben equilibrar la protección de los usuarios, el acceso transparente, la resistencia a la censura y la construcción eficiente de bloques.

Separación entre proponente y constructor

La separación entre proponente y constructor divide la construcción del bloque de la responsabilidad del validador de proponerlo.

Los constructores especializados ensamblan bloques candidatos y compiten ofreciendo pagos al proponente seleccionado.

El proponente puede elegir una puja sin tener que descubrir por su cuenta todas las oportunidades de MEV.

La hoja de ruta de Ethereum para la separación entre proponente y constructor explica que separar estas funciones puede distribuir más ampliamente los ingresos de MEV entre los validadores y reducir parte de la presión hacia la centralización.

La separación entre proponente y constructor no elimina el front-running, porque los constructores aún pueden ordenar transacciones y recibir bundles de los searchers.

Su objetivo principal es cambiar la estructura del mercado en torno a la construcción de bloques y reducir la necesidad de que cada validador opere sistemas MEV avanzados.

MEV-Boost y bundles privados

MEV-Boost es un middleware de código abierto que permite a los validadores de Ethereum recibir bloques de un mercado competitivo de constructores.

Los searchers pueden enviar bundles cuyo orden interno de transacciones debe conservarse para que la estrategia funcione.

Los constructores combinan bundles de transacciones y otros flujos de órdenes para formar bloques completos.

Los bundles privados pueden impedir que se copie una estrategia rentable en el mempool público.

También pueden permitir que los searchers definan condiciones de ejecución, por ejemplo, incluir un grupo de transacciones solo si todos los pasos tienen éxito.

Los sistemas de bundles privados reducen algunas formas de competencia en el mempool público, pero introducen cuestiones de confianza, relays, constructores y centralización.

Cómo pueden los usuarios reducir el riesgo de front-running

Los usuarios pueden reducir el riesgo de front-running limitando cuánto movimiento desfavorable del precio puede aceptar una transacción.

Un swap debería incluir un importe mínimo de salida o un importe máximo de entrada razonable que el contrato inteligente haga cumplir.

Antes de enviar una operación grande, los usuarios deberían examinar el impacto en el precio y la liquidez disponible.

Dividir una operación grande en transacciones más pequeñas puede reducir el impacto individual en el precio, aunque aumenta las comisiones y no garantiza protección.

Una ruta de transacción privada puede mantener el contenido de la transacción fuera del mempool público hasta que se incluya en un bloque.

Los usuarios también pueden elegir aplicaciones que utilicen subastas por lotes, flujo de órdenes protegido, precios límite o ejecución basada en intenciones.

Las transacciones muy sensibles al tiempo no deberían incluir secretos visibles públicamente que otra cuenta pueda reutilizar.

Todos los métodos de protección implican contrapartidas relacionadas con la velocidad de ejecución, la confianza, la privacidad, las comisiones y la posibilidad de que la transacción se retrase.

Protección frente al deslizamiento

La tolerancia al deslizamiento define cuánto puede alejarse el precio de ejecución del precio cotizado antes de que falle una transacción.

Una tolerancia amplia al deslizamiento ofrece al atacante más margen para mover el precio y mantener válida la operación de la víctima.

Una tolerancia reducida limita los posibles beneficios del ataque sandwich, pero puede provocar fallos durante una volatilidad normal o con poca liquidez.

Los usuarios deberían ajustar el deslizamiento según el activo, la profundidad del pool, el tamaño de la operación y las condiciones actuales del mercado.

La aplicación debería hacer cumplir el límite de deslizamiento on-chain, en lugar de depender únicamente de una advertencia visual en la interfaz.

Los campos como el importe mínimo de salida, el importe máximo de entrada y la fecha límite de la transacción deberían ser visibles y comprensibles antes de que el usuario firme con su wallet.

Envío de transacciones privadas

El envío privado remite una transacción a determinados constructores o relays sin difundirla a través del mempool público habitual.

Como los bots públicos no pueden ver de antemano toda la transacción, se dificultan las estrategias habituales de front-running y ataques sandwich.

La documentación de Flashbots Protect describe un mempool privado diseñado para ocultar las transacciones enviadas a los bots de front-running y sandwich.

El enrutamiento privado no hace que una transacción sea invisible para todos, porque la infraestructura seleccionada puede recibir su contenido.

Los usuarios deben tener en cuenta qué constructores o searchers reciben los datos, qué ajustes de privacidad se aplican y si la ruta puede censurar o retrasar las transacciones.

Una transacción privada también puede requerir un proceso de cancelación o gestión de nonce diferente al de una transacción pública habitual.

Órdenes limitadas y trading basado en intenciones

Una orden limitada define el peor precio de ejecución aceptable, en lugar de aceptar cualquier precio dentro de un amplio margen de deslizamiento.

Una intención describe el resultado que desea el usuario y permite que varios solvers compitan para determinar cómo lograrlo.

La competencia entre solvers puede mejorar la ejecución si el sistema les impide aprovecharse de la intención revelada por el usuario.

La liquidación por lotes puede procesar varias órdenes a la vez a un precio de compensación común, lo que reduce la ventaja de insertar una transacción justo antes de otra.

Estos sistemas siguen necesitando reglas que regulen el acceso de los solvers, la visibilidad de los datos, los fallos, la censura y las garantías de liquidación.

La palabra «protegido» no debería interpretarse como una promesa de que no sea posible ninguna forma de MEV o ejecución desfavorable.

Sistemas de compromiso y revelación

Un sistema de compromiso y revelación divide una acción en un compromiso oculto y una revelación posterior.

Durante la fase de compromiso, el usuario publica un hash criptográfico de la acción secreta y un valor aleatorio.

El hash demuestra que el usuario eligió la acción sin revelar su contenido.

Durante la fase de revelación, el usuario publica la información original para que el contrato pueda comprobar que coincide con el compromiso.

Esta estructura puede proteger subastas, votaciones, reclamaciones y otras aplicaciones frente a la copia directa.

Los sistemas de compromiso y revelación requieren transacciones adicionales, introducen retrasos, plantean problemas si no se revela la información y complican la experiencia de usuario.

El contrato debe impedir que los atacantes copien un valor revelado y lo asocien a otra cuenta.

Mempools cifrados

Un mempool cifrado oculta el contenido de las transacciones mientras estas esperan a ser ordenadas.

Los constructores pueden comprometerse con un orden sin conocer las acciones exactas incluidas en las transacciones cifradas.

Las transacciones se descifran después de que la decisión de ordenación llegue a la fase requerida.

Este enfoque puede reducir el front-running y los ataques sandwich, al tiempo que mantiene una vía pública para incluir transacciones.

Los mempools cifrados requieren una liberación segura de claves, resistencia a la colusión, una recuperación fiable y retrasos de procesamiento aceptables.

No ofrecen privacidad permanente para las transacciones, porque su contenido normalmente se hace público durante la ejecución.

Investigación actual sobre el front-running en Ethereum

A julio de 2026, varias propuestas de mejora de Ethereum exploran protecciones a nivel de protocolo frente al front-running, pero no deben describirse como funciones activas de la mainnet.

El borrador EIP-8105 propone un mempool cifrado que mantendría oculto el contenido de las transacciones hasta su inclusión y posterior descifrado.

El borrador EIP-8184 propone un proceso público de compromiso antes de la revelación para transacciones cifradas sensibles al MEV.

El borrador EIP-8209 propone marcos de transacción de compromiso y revelación que retrasan la divulgación de los datos de ejecución.

Estas propuestas exploran distintas contrapartidas relacionadas con la criptografía, los proveedores de claves, el retraso de inclusión, la filtración de información y la complejidad del protocolo.

Al estar aún en fase de borrador, los desarrolladores y usuarios no deberían suponer que las transacciones habituales cuentan automáticamente con estas protecciones.

Cómo pueden los desarrolladores reducir el front-running

Los desarrolladores deberían identificar todas las funciones de contrato cuyo resultado dependa del orden de las transacciones.

Los swaps y las compras de tokens deberían aplicar on-chain condiciones de salida mínima, entrada máxima y caducidad.

Las subastas pueden utilizar pujas selladas, compensación por lotes o mecanismos de compromiso y revelación, en lugar de simples pujas públicas que prioricen a quien llega primero.

Las acuñaciones y reclamaciones limitadas pueden utilizar pruebas de elegibilidad firmadas, asignación aleatoria o periodos de reclamación que reduzcan las ventajas de velocidad.

Las aplicaciones que utilizan oráculos deberían rechazar datos desactualizados y evitar transiciones de estado previsibles que generen beneficios garantizados.

Los sistemas de liquidación pueden utilizar subastas o incentivos distribuidos en vez de conceder toda la oportunidad al primer bot.

Los desarrolladores deberían probar los contratos con muchos órdenes de transacción posibles, en lugar de dar por hecho que las llamadas se ejecutarán en el orden en que las envían los usuarios.

Cualquier secreto necesario para ejecutar un contrato debería permanecer off-chain hasta una fase segura de revelación.

Por qué son arriesgados los diseños que priorizan a quien llega primero

Un contrato que prioriza a quien llega primero concede valor a la primera transacción válida que se ordena.

Las blockchains públicas no garantizan que el primer usuario que pulsa un botón sea quien primero incluya una transacción.

La latencia de la red, las comisiones de prioridad, la selección del constructor, los bundles privados y la capacidad del bloque influyen en el orden.

Los bots pueden observar a los usuarios comunes y reaccionar más rápido de lo que la mayoría puede hacerlo manualmente.

Por tanto, los sistemas de alto valor que priorizan a quien llega primero acaban convirtiéndose en competiciones de infraestructura y ordenación de transacciones, en lugar de ofrecer una verdadera justicia cronológica.

La selección aleatoria, el procesamiento por lotes o los periodos de elegibilidad pueden ofrecer resultados más justos cuando el orden exacto de llegada no es necesario desde el punto de vista económico.

Cómo detectar el front-running

El front-running puede investigarse examinando el orden de las transacciones confirmadas dentro de un bloque.

Un explorador de bloques muestra el número de bloque, la posición, el emisor, el destinatario, los ajustes de comisiones y los registros de eventos de cada transacción.

Un analista puede comparar la acción esperada de la víctima con las transacciones inmediatamente anteriores y posteriores.

Un patrón de ataque sandwich suele incluir una compra del atacante, una compra de la víctima en la misma dirección y una venta posterior del atacante en la dirección contraria.

El analista debería calcular el beneficio total del atacante después de las comisiones de gas, los pagos al constructor y los cambios en el precio del token.

La coincidencia temporal por sí sola no demuestra una intención maliciosa, ya que traders independientes pueden reaccionar a la misma información de mercado.

Las observaciones del mempool, las trazas de ejecución, las relaciones entre direcciones, los patrones repetidos y los bundles de transacciones pueden aportar pruebas más sólidas.

Indicadores de un posible ataque sandwich

El usuario obtiene un precio de ejecución mucho peor que la cotización previa a la transacción, aunque no se supere el límite de deslizamiento seleccionado.

Otra dirección compra el mismo token inmediatamente antes que el usuario dentro del mismo bloque.

La misma dirección u otra relacionada vende el token inmediatamente después de la transacción del usuario.

Las dos operaciones del atacante parecen tener un tamaño calculado para maximizar la extracción sin provocar la reversión de la transacción de la víctima.

La secuencia genera un resultado neto positivo para el atacante después de todos los gastos de transacción.

Una secuencia puede ser accidental, pero los patrones repetidos en muchos usuarios ofrecen pruebas más sólidas de una estrategia automatizada.

¿Se puede evitar por completo el front-running?

Ningún método por sí solo evita todas las formas de front-running en todas las arquitecturas de blockchain.

El enrutamiento privado protege el contenido de las transacciones frente al mempool público, pero puede revelarlo a intermediarios seleccionados.

Los diseños de compromiso y revelación impiden la copia directa, pero añaden retrasos y exigen que los usuarios completen una segunda fase.

Los mempools cifrados reducen la exposición de la información, pero plantean dificultades criptográficas y de gestión de claves.

Las subastas por lotes reducen las ventajas de ordenación dentro de cada lote, pero siguen necesitando reglas justas para incluir los lotes.

Un límite estricto de deslizamiento protege el precio de ejecución, pero puede aumentar el número de transacciones fallidas.

Por lo general, una protección eficaz combina controles de usuario, diseño de aplicaciones, enrutamiento privado, ordenación justa e investigación de protocolos.

¿Es ilegal el front-running?

La legalidad del front-running depende de la jurisdicción, el mercado, el activo, la relación entre las partes y la conducta concreta aplicables.

El front-running tradicional basado en información confidencial sobre órdenes de clientes está prohibido en muchos entornos financieros regulados.

El front-running en blockchain puede utilizar información visible en un mempool público, lo que plantea cuestiones jurídicas y fácticas distintas.

La conducta aún puede plantear problemas relacionados con el fraude, la manipulación, las prácticas engañosas, los deberes fiduciarios, la información confidencial o las normas del mercado.

Que un contrato inteligente permita una transacción no demuestra que todos sus usos sean legales.

Los usuarios y desarrolladores que utilicen estrategias de alto valor deberían solicitar asesoramiento jurídico cualificado en las jurisdicciones donde operen.

Estafas de front-running

Los estafadores suelen promocionar supuestos bots de front-running que prometen beneficios cripto garantizados.

El contrato inteligente proporcionado puede enviar directamente al estafador los activos depositados por el usuario.

Un tutorial falso puede pedir a la víctima que pegue una dirección secreta de wallet en el código del contrato o que financie una cuenta controlada por el atacante.

Algunos esquemas afirman que un depósito mayor permitirá al bot superar más transacciones y obtener mayores rentabilidades.

Las estrategias MEV reales requieren infraestructura avanzada, simulaciones fiables, capital, controles de riesgo y competencia frente a searchers profesionales.

Ningún script público puede garantizar beneficios de front-running después de las comisiones, las transacciones fallidas, los cambios de mercado y la competencia.

Los usuarios nunca deberían revelar una frase de recuperación o una clave privada para instalar, activar o financiar un bot de trading.

Riesgos para quienes hacen front-running

Una transacción de front-running puede fallar si la transacción objetivo se cancela, se sustituye, se retrasa o se envía por una ruta privada.

Otro bot puede superar la puja del atacante o conseguir una posición mejor en el bloque.

La víctima puede utilizar un límite de deslizamiento que haga que el ataque deje de ser rentable.

Un movimiento rápido del mercado puede convertir el inventario temporal del atacante en una pérdida.

Las comisiones de gas y los pagos al constructor pueden consumir los beneficios previstos.

Los contratos maliciosos pueden atraer deliberadamente a los bots y hacer que las transacciones copiadas pierdan dinero.

Los riesgos jurídicos, operativos, reputacionales y de contraparte también pueden afectar a las organizaciones que participan en estrategias de ordenación de transacciones.

Preguntas frecuentes

¿Qué es el front-running explicado de forma sencilla?

El front-running consiste en ver la transacción cripto pendiente de otro usuario y enviar una transacción competidora antes para obtener una ventaja.

¿Por qué es posible el front-running en las blockchains?

Es posible porque las transacciones pendientes pueden revelar las intenciones de los usuarios antes de que un constructor de bloques determine el orden final de ejecución.

¿Qué es un mempool?

Un mempool es el conjunto de transacciones pendientes válidas de un nodo que aún no se han incluido en un bloque confirmado.

¿Existe un único mempool global?

No. Cada nodo puede tener una vista distinta de las transacciones pendientes debido a la latencia, las conexiones entre pares, la configuración y el enrutamiento privado.

¿Qué es un bot de front-running?

Un bot de front-running es un software automatizado que supervisa transacciones pendientes e intenta ejecutar acciones rentables antes que ellas.

¿Qué es un front-runner generalizado?

Un front-runner generalizado simula transacciones pendientes y copia llamadas rentables a contratos sin necesitar una estrategia programada para cada aplicación.

¿El front-running es lo mismo que el MEV?

El front-running es una categoría de MEV, que también incluye back-running, arbitraje, liquidaciones, ataques sandwich y otras estrategias de ordenación.

¿Qué es un ataque sandwich?

Un ataque sandwich coloca una operación antes de la de la víctima y otra después para obtener beneficios del movimiento de precio resultante.

¿Cuál es la diferencia entre front-running y back-running?

El front-running se ejecuta antes de una transacción objetivo, mientras que el back-running se ejecuta después.

¿El arbitraje es lo mismo que el front-running?

No. Puede haber arbitraje sin perjudicar a una transacción pendiente concreta, mientras que el front-running aprovecha el conocimiento anticipado de una transacción para obtener una posición anterior.

¿Puede el front-running afectar a los swaps de tokens?

Sí. Los bots pueden mover el precio de un pool de liquidez antes de un swap y hacer que el usuario reciba menos tokens.

¿Puede el front-running afectar a las acuñaciones de NFT?

Sí. Los bots pueden copiar transacciones de acuñación pendientes y obtener NFT limitados antes que los usuarios originales.

¿Puede el front-running afectar a las liquidaciones?

Sí. Los bots suelen competir por completar primero las liquidaciones rentables de protocolos de préstamo.

¿Puede el front-running afectar a la gobernanza?

Sí. Los votos y las transacciones de ejecución pendientes pueden revelar acciones que otros participantes intentan anticipar o bloquear.

¿Pagar más gas evita el front-running?

No. Una comisión de prioridad más alta puede mejorar la velocidad de inclusión, pero no garantiza protección frente a bundles privados o constructores especializados.

¿Un deslizamiento bajo evita los ataques sandwich?

Un deslizamiento bajo reduce los beneficios disponibles, pero no elimina todos los ataques y puede hacer que la transacción falle ante movimientos normales del precio.

¿Qué es el envío de transacciones privadas?

El envío privado remite una transacción a una infraestructura seleccionada sin difundir primero todo su contenido a través del mempool público.

¿Las transacciones privadas son totalmente privadas?

No. Los constructores o relays seleccionados pueden ver la transacción y su contenido normalmente se hace público después de incluirla en un bloque.

¿Qué es un sistema de compromiso y revelación?

Un sistema de compromiso y revelación permite al usuario demostrar su compromiso con información oculta y revelarla solo en una fase posterior.

¿Qué es un mempool cifrado?

Un mempool cifrado oculta el contenido de las transacciones hasta que se confirma la decisión de ordenación o se cumple otra condición de descifrado.

¿Ethereum tiene actualmente un mempool cifrado en la mainnet?

No. A julio de 2026, los sistemas de mempool cifrado a nivel de protocolo seguían siendo propuestas de investigación, no funciones estándar de las transacciones de la mainnet de Ethereum.

¿Qué es la separación entre proponente y constructor?

La separación entre proponente y constructor permite que constructores especializados creen bloques y que los validadores elijan y propongan bloques candidatos.

¿La separación entre proponente y constructor elimina el front-running?

No. Cambia la estructura de producción de bloques, pero no impide que los constructores y searchers ordenen transacciones para obtener MEV.

¿Cómo puedo identificar un ataque sandwich?

Busca una operación del atacante antes de tu swap y otra operación del mismo atacante en sentido contrario después, dentro del mismo bloque.

¿Puede un explorador de blockchain demostrar que hubo front-running?

Un explorador de blockchain puede revelar el orden y los resultados de las transacciones, pero demostrar la intención puede requerir datos del mempool, trazas de ejecución y patrones repetidos.

¿El front-running siempre es rentable?

No. Los atacantes pueden perder dinero por transacciones fallidas, competencia, comisiones, cambios de precio y contratos engañosos.

¿Los bots de front-running tienen beneficios garantizados?

No. Las afirmaciones sobre beneficios garantizados de los bots son engañosas y suelen estar relacionadas con estafas.

¿Es ilegal el front-running?

Su legalidad depende de la jurisdicción, el origen de la información, las normas del mercado, las relaciones entre las partes, el activo y la conducta concreta.

¿Pueden los desarrolladores diseñar contratos resistentes al front-running?

Sí. Pueden utilizar controles de deslizamiento, liquidación por lotes, sistemas de compromiso y revelación, asignación aleatoria, oráculos sólidos y métodos de ejecución privada.

¿Cuál es la mejor protección contra el front-running?

La protección práctica más sólida combina límites de deslizamiento cuidadosos, un diseño de aplicación adecuado, enrutamiento privado y reglas de transacción que no recompensen las simples ventajas de ordenación.

Conclusión

El front-running consiste en utilizar el conocimiento anticipado de una transacción de criptomonedas pendiente para enviar otra transacción antes y obtener un beneficio económico.

Lo hacen posible las transacciones pendientes visibles, el valor económico del orden de las transacciones, la competencia por las comisiones y el estado programable de la blockchain.

Entre sus formas habituales se encuentran el desplazamiento, los ataques sandwich, las competiciones de liquidación, la copia de acuñaciones de NFT, las pujas en subastas y las estrategias relacionadas con oráculos.

El front-running forma parte del MEV, pero no todas las formas de MEV perjudican a los usuarios de la misma manera.

Los searchers, constructores, validadores, relays, wallets y desarrolladores de aplicaciones influyen en cómo se observan y ordenan las transacciones.

Los usuarios pueden reducir su exposición mediante ajustes razonables de deslizamiento, el envío privado de transacciones, la ejecución con órdenes limitadas y una revisión cuidadosa del impacto en el precio.

Los desarrolladores pueden reducir las oportunidades subyacentes mediante sistemas de compromiso y revelación, subastas por lotes, asignación aleatoria, un diseño seguro de oráculos y límites de ejecución on-chain.

A julio de 2026, los mempools cifrados y los formatos de transacción de compromiso antes de la revelación siguen siendo áreas importantes de investigación en Ethereum.

Ninguna protección es perfecta, porque cada enfoque implica contrapartidas relacionadas con la confianza, los retrasos, la privacidad, la resistencia a la censura, las comisiones y la complejidad.

Comprender el front-running ayuda a los usuarios cripto a evaluar mejor la ejecución de las transacciones y a evitar estafas que prometen beneficios fáciles mediante supuestos bots MEV.