Ripple propone solución contra el front-running en XRP Ledger
David Schwartz, cofundador de XRP Ledger y CTO emérito de Ripple, ha propuesto un mecanismo de reserva de transacciones de dos componentes para mitigar los riesgos de front-running y ataques de sandwich en el DEX nativo y el AMM de XRPL.
La propuesta, surgida como respuesta a las inquietudes planteadas por la cuenta de análisis XRPresso.io, introduce garantías de ejecución prioritaria para los usuarios dispuestos a pagar una tarifa de reserva. Esta medida de integridad de mercado cobra especial relevancia a medida que las entradas institucionales en productos de XRP continúan escalando.
Actualmente, el planteamiento se encuentra bajo debate en la comunidad y no se ha formalizado como una enmienda de red. Esta distinción es crucial: en el XRP Ledger, los cambios de protocolo requieren una mayoría cualificada de validadores a favor antes de su activación. Esto significa que, aunque el diseño de Schwartz tiene peso, debe enfrentar un proceso de gobernanza definido antes de implementarse en la red principal.
Cómo funciona el mecanismo ReservedTxns de XRP
El esquema introduce dos nuevos componentes al protocolo. El primero es un objeto de registro llamado ReservedTxns, que almacena un número de secuencia de registro objetivo y una lista de hasta 32 identificadores de transacciones.
Cuando se ejecuta ese registro específico, cualquier transacción listada que esté presente en el conjunto de consenso se procesa primero, por delante de todas las demás, tras lo cual el objeto se elimina. El segundo componente es un tipo de transacción denominado TxnReserve, que permite a un usuario reclamar un espacio prioritario para una o más transacciones futuras mediante el envío de una reserva antes de que se cierre el registro objetivo.
Existen tres restricciones que rigen el TxnReserve: la tarifa de reserva debe ser al menos el doble de la tarifa de transacción estándar; el registro objetivo debe estar dentro de los 16 registros siguientes al actual; y la transacción real debe configurar su campo LastLedgerSequence para que coincida con el registro reservado.
Estas reglas no son accidentales; definen tanto el costo económico del sistema como la estrecha ventana de tiempo en la que opera. El límite de 16 registros mantiene las reservas estrechamente vinculadas a la ejecución a corto plazo, evitando que el mecanismo se utilice maliciosamente como una herramienta para manipular las colas de transacciones de forma generalizada.
La protección contra ataques de denegación de servicio (DoS) está integrada mediante el escalado dinámico de tarifas: a medida que los espacios de reserva superan los 16, las tarifas aumentan, alcanzando varios múltiplos de la reserva base al acercarse a los 30 espacios. Schwartz también especificó que el software del servidor XRPL retendría las transacciones reservadas y las liberaría solo cuando se conozcan las propuestas del registro anterior, comprimiendo así la ventana de visibilidad previa a la ejecución.
«Esto garantiza que puedas ejecutar tu transacción antes que cualquier otra que se haya formado después de que la tuya fuera revelada», afirmó Schwartz. «Se usaría este enfoque en cualquier momento que se desee realizar una transacción asegurando que no pueda ser objeto de un ataque sandwich o front-running».
El problema de front-running en XRPL que Schwartz busca resolver
La preocupación de XRPresso se centra en una característica estructural del XRP Ledger: las transacciones pendientes permanecen en una cola públicamente visible antes de que se cierre un registro, lo que otorga a los validadores y nodos bien conectados una visión anticipada de las operaciones entrantes.
Debido a que el orden canónico de las transacciones en XRPL se determina mediante una fórmula determinista conocida que involucra los hashes de las transacciones, un actor sofisticado podría enviar transacciones similares repetidamente para aumentar la probabilidad de aterrizar en una posición favorable respecto a una operación objetivo. Esta es la base mecánica para un ataque sandwich en el DEX o AMM.
Schwartz reconoció la exposición pero cuestionó el enfoque. Argumentó que todos los participantes tienen el mismo acceso a la cola pública y que los validadores no obtienen ninguna ventaja estructural en el ordenamiento a menos que varios conspiren entre sí.
«Si varios validadores conspiraran, o si un solo validador lo intentara, sería muy obvio para todos exactamente quién lo está haciendo», señaló, añadiendo que no se ha confirmado ningún intento de este tipo fuera de una prueba de concepto.
También destacó una restricción de rentabilidad práctica: extraer valor significativo requiere simultáneamente una alta liquidez (para generar un volumen que valga la pena atacar) y una baja liquidez (para mover el precio a un costo manejable), una combinación que rara vez se presenta en XRPL.
Aunque este argumento no ha satisfecho plenamente a los críticos, distingue el perfil de riesgo actual de XRPL del entorno de MEV (Valor Máximo Extraíble) históricamente activo en Ethereum.
El debate sobre el front-running en DeFi no es exclusivo del ecosistema XRP. El cofundador de Binance, Changpeng Zhao, propuso el año pasado un DEX de perpetuos tipo «dark pool» utilizando criptografía de conocimiento cero para ocultar los datos de las órdenes hasta su ejecución. Dicho enfoque también recibió críticas de defensores de la descentralización, quienes argumentaron que recrea las asimetrías de información que las criptomonedas fueron diseñadas para eliminar.
XRPresso planteó un argumento similar en respuesta a Schwartz, sosteniendo que una confidencialidad selectiva para los detalles de las transacciones pendientes sería una solución a largo plazo más limpia que una capa de tarifas de reserva, señalando implementaciones que ya están activas en cadenas competidoras.
Últimas noticias del mercado:
- Meme coins en $22.000M mientras Dogecoin defiende soportes clave
- Ethereum: Tom Lee mantiene su apuesta pese a la caída de ETH
- Securitize debuta en NYSE y acelera la tokenización de RWA
Más
in numbers
