Puntos clave de la noticia:
- Schwartz, CTO Emeritus de Ripple, analizó una propuesta de ordenamiento de transacciones basada en consenso para el XRP Ledger.
- El esquema implicaría que los validadores voten el orden de cada transacción, lo que ralentizaría significativamente el proceso de consenso.
- La opción de usar un flag opcional podría, paradójicamente, facilitar los ataques de front-running contra transacciones que no activen esa bandera.
David Schwartz, CTO Emeritus de Ripple, reabrió el debate sobre uno de los problemas estructurales del XRP Ledger: la posibilidad de que actores malintencionados ejecuten ataques de front-running o sandwich sobre los pagos y cruces de órdenes en la red. Su análisis dejó en claro que las soluciones disponibles tienen costos que podrían superar los beneficios.
A inicios de la semana, Schwartz presentó un esquema de reserva de transacciones que busca garantizar que cada transacción se ejecute antes que cualquier otra creada después de su divulgación. La propuesta generó múltiples reacciones en la comunidad de XRP, muchos usuarios cuestionan la viabilidad técnica del mecanismo en el ledger.
About the closest thing to this you could actually do is have transaction ordering determined by consensus with validators voting on transaction ordering as part of the consensus process. But there are a lot of disadvantages to this.
The big one is that it would slow the…
— David 'JoelKatz' Schwartz (@JoelKatz) July 1, 2026
Schwartz Aborda el Ordenamiento por Consenso
Uno de los interrogantes surgidos fue si incorporar marcas de tiempo precisas por segundo permitiría ordenar las transacciones cronológicamente. La ingeniera de software de Ripple Mayukha Vadari respondió que esto no es viable: distintos nodos reciben cada transacción en momentos levemente diferentes, dado que deben propagarse a través de la red de pares.
Schwartz señaló que la alternativa más cercana es el ordenamiento por consenso, donde los validadores votan el orden de las transacciones como parte del proceso de validación. Sin embargo, advirtió que esta solución presenta algunas desventajas. La principal es que aumentaría considerablemente la cantidad de bits sobre los cuales alcanzar consenso, ralentizando el proceso de forma considerable.
Schwartz también evaluó una opción intermedia: una flag opcional que los usuarios podrían activar en sus transacciones para solicitar un ordenamiento prioritario, a cambio de una comisión adicional. Las transacciones con esa flag activada tendrían preferencia en el relay y su orden sería determinado por consenso.
Soluciones Descartadas
Sin embargo, el propio Schwartz identificó el problema central de este enfoque. Activar la flag para algunas transacciones y no para otras crearía una asimetría que facilitaría exactamente los ataques que se busca prevenir. «No creo que valga la pena, especialmente porque hace que sea más fácil hacer front-running o sandwich a las transacciones que no activan la flag», declaró. Basándose en ese razonamiento, descartó la propuesta como solución neta al problema.
