Schwartz propone una solución para XRPL ante el regreso de los temores de front-running

David "JoelKatz" Schwartz ha propuesto un plan de reserva de transacciones para el XRP Ledger tras nuevas afirmaciones de que los usuarios aún pueden enfrentar ataques de front-running y sandwich en pagos, cruce de ofertas, operaciones en DEX y swaps de market maker automatizado (AMM). 

El debate comenzó después de que XRPresso afirmara que algunos actores pueden ser capaces de ver las transacciones pendientes antes de que un ledger se cierre y usar esa información para atacar operaciones.

"Un grave problema de front-running persiste en el XRPL que perjudica a los usuarios regulares." XRPresso afirmó que los validadores y nodos bien conectados pueden ver las transacciones en la cola de pre-validación y luego enviar sus propias transacciones para buscar una mejor posición en el orden final del ledger.

XRPresso señaló que el problema afecta principalmente a los usuarios que operan a través de billeteras y dApps. Según la publicación, el orden final dentro de cada ledger sigue un proceso determinista conocido, y los envíos repetidos pueden aumentar la probabilidad de ubicarse cerca de una operación objetivo. Eso podría empeorar el deslizamiento para el trader original cuando una estrategia sandwich tiene éxito.

Schwartz presenta un esquema de reserva

"Por las razones que he explicado, no estoy tan preocupado por este problema." Schwartz escribió que la preocupación aún merecía una respuesta práctica. Luego propuso un esquema de reserva de transacciones que podría hacer que una transacción divulgada se ejecute antes que cualquier transacción formada después de que se volviera visible.

El plan añadiría un nuevo objeto de ledger llamado ReservedTxns. Ese objeto contendría un número de secuencia de ledger y un array de IDs de transacción (TxID). Una nueva transacción TxnReserve permitiría a un usuario reservar un espacio para una transacción en un ledger futuro, siempre que la solicitud cumpla con las reglas de comisión, tiempo y ejecución.

Schwartz dijo que una reserva debería costar al menos el doble de la comisión de transacción normal. El ledger objetivo tendría que ser mayor que el ledger actual y no más de 16 ledgers por adelante. Cada objeto reservado contendría menos de 32 IDs de transacción (TxID), a menos que el diseño amplíe posteriormente el límite.

Las transacciones reservadas se ejecutarían primero

Según la propuesta, una transacción reservada se difundiría cerca del momento en que se conocen las propuestas del ledger anterior. Schwartz dijo que el software de XRPL podría añadir una función para retener dichas transacciones y liberarlas solo cuando se cumpla esa condición. La transacción también debería establecer su último ledger válido como el ledger donde se espera que se ejecute.

Cuando ese ledger se ejecute, la red primero verificaría si existe un objeto ReservedTxns para el número de secuencia del ledger. Si existe, la red ejecutaría las transacciones listadas que están en el conjunto de consenso antes que las demás transacciones. Luego las eliminaría del conjunto para evitar ejecuciones repetidas y borraría el objeto de reserva.

La documentación de XRPL indica que el ordenamiento canónico está diseñado para ser determinista, eficiente y difícil de manipular. Su documentación de DEX también señala que el orden de transacciones está diseñado para desincentivar el front-running porque las operaciones se ejecutan cuando se cierra un nuevo ledger. Sin embargo, la documentación de trading algorítmico de XRPL indica que el front-running es difícil, pero no imposible.

Las actualizaciones de DeFi elevan las apuestas

El momento coincide con que los desarrolladores de XRPL continúan expandiendo el stack DeFi de la red. La Fundación XRPL propuso recientemente AMM Swappable Curves, una actualización en borrador que añadiría opciones de StableSwap y liquidez concentrada al market maker automatizado (AMM) nativo. XRPL también está preparando herramientas nativas de préstamo y escrow programable.

Esas actualizaciones podrían traer más actividad de trading on-chain, crédito y liquidación a XRPL. La cobertura reciente también mostró casos de uso institucionales, incluyendo una liquidación de Tesorería tokenizada con la participación de Ripple y JPMorgan. A medida que la actividad crece, el ordenamiento de transacciones y la visibilidad de operaciones pendientes pueden atraer más atención de desarrolladores, traders y validadores.

Schwartz también abordó posibles riesgos de denegación de servicio. Dijo que un atacante podría intentar llenar ranuras de reserva en muchos ledgers, pero el aumento de comisiones podría hacer eso costoso. En un ejemplo, las comisiones subirían una vez que se llenen 16 ranuras y podrían alcanzar varias veces la tasa de reserva base cerca de las 30 ranuras. La propuesta aún no es una enmienda formal, pero ofrece a la comunidad de XRPL un camino técnico claro para revisar.