FAQ sobre Mitigación de Transacciones Fallidas

Así es como el commit a Stellar Core v18.2.0 describe la nueva característica:

"Esto agrega un nuevo paso de amortiguación estadística a la maquinaria de encolamiento/inundación de transacciones del pastor, para intentar dar forma al tráfico del flujo de pagos de ruta cíclicos (intento de arbitraje) en una base por par de activos. La red ha estado experimentando volúmenes muy altos de estas txs (casi todas fallan); esto les da a los validadores una nueva herramienta para manejar ese volumen. Tiene un umbral controlable e intensidad (gestionado por un par de variables de configuración) y está configurado por defecto a un factor de amortiguación razonable."

Esencialmente, los operadores de validadores pueden configurar sus nodos para identificar un tipo específico de transacción — pagos de ruta circulares — y filtrar muchos de los destinados a fallar mientras aún permiten suficientes para preservar un arbitraje saludable. Actualmente, todas estas transacciones se consideran para inclusión en el libro mayor, y la mayoría de ellas fallan. Debido a que fallan durante la aplicación en lugar de durante la presentación, compiten por espacio en el libro mayor, aumentan las tarifas de la red y persisten para siempre en el registro histórico. Al filtrar algunas de ellas, los validadores pueden ser capaces de reducir su impacto en la red.

Durante los últimos años, la red de Stellar ha procesado un alto número de transacciones fallidas causadas por una multitud de bots de comercio intentando aprovechar un número limitado de oportunidades de arbitraje. La red ha funcionado bien bajo la carga: el rendimiento sigue siendo alto; los libros mayores continúan cerrándose en alrededor de 5 segundos, pero estas transacciones vienen en oleadas, y periódicamente, representan una porción desproporcionada de la actividad de la red. Para tener una idea de la escala, echa un vistazo a la oleada de barras naranjas en el gráfico de tasa de éxito de transacciones en la parte inferior de la página de Actividad de la Red de Stellar Expert:

Esas oleadas de transacciones fallidas naranjas no le hacen bien a nadie: no enriquecen a los desarrolladores; no hacen los mercados más eficientes, pero, al reclamar espacio limitado en el libro mayor, sí causan problemas:

• Fuerzan a la red a entrar en modo de tarifas de urgencia, lo que aumenta las tarifas de la red para todos
• Inflan permanentemente el libro mayor, lo que hace más costoso operar un validador o nodo Horizon
• Hacen que la reproducción de datos históricos sea mucho más lenta, lo que dificulta la incorporación de nuevos nodos a la red
• Ralentizan los tiempos de cierre del libro mayor
  

Para permitir que Stellar continúe funcionando como un sistema rápido, eficiente y descentralizado para pagos, queremos asegurarnos de que sea fácil operar validadores y nodos Horizon. También queremos asegurarnos de que sea económico para los exchanges, proveedores de billeteras, proveedores de servicios de pago transfronterizo y otros desarrolladores y empresas enviar transacciones a la red. Al permitir que los validadores filtren algunas de las transacciones destinadas a fallar antes de que se apliquen al libro mayor y se comprometan al registro permanente, esperamos preservar la eficiencia y usabilidad de la red.

Las transacciones fallidas son causadas por bots de comercio que toman un enfoque de fuerza bruta para el arbitraje.

Stellar tiene un conjunto único de operaciones llamadas pagos de ruta, que permiten el envío y conversión simultáneos de moneda — envío USD; recibes ARS — y hacen increíblemente fácil usar la red para transacciones transfronterizas y entre monedas.

Los pagos de ruta convierten moneda consumiendo órdenes en los libros de órdenes integrados de Stellar o comerciando contra fondos de liquidez, y a veces una ineficiencia da lugar a una ligera discrepancia de precios. No entraremos en detalles aquí, pero los desarrolladores se dieron cuenta de que, de vez en cuando, puedes enviar un pago de ruta circular y terminar con un poco más de dinero del que empezaste, y construyeron bots para buscar esas oportunidades, y tratar de capitalizarlas.

Muchas personas construyeron bots de arbitraje, y todos buscan las mismas oportunidades. Cuando surge una, es una carrera: el bot ganador envía una transacción que reclama la oportunidad y tiene éxito; los bots restantes envían transacciones condicionadas a la existencia de esa oportunidad, y dado que ya no está disponible, esas transacciones fallan.

Debido a que esas transacciones cumplían con el requisito de tarifa mínima, fallan después de que se incluyen en el libro mayor en lugar de antes, por lo que terminan estorbando a todos los demás. Es como un grupo de palomas revoloteando alrededor de un banco del parque: dejas caer una miga en la acera, todas se lanzan tras ella. Una paloma consigue la miga, las demás se quedan hambrientas, y mientras los perdedores se sientan allí arrullando y pavoneándose y deseando lo que podría haber sido, bloquean la acera para que los peatones no puedan usarla.

Creemos que esta característica proporciona una solución quirúrgica temporal al problema. Permite a los validadores identificar y filtrar un tipo muy específico de transacción, lo que significa que podrían ser capaces de prevenir que las transacciones fallidas congestionen el libro mayor sin afectar otro tráfico de la red. Es un enfoque hiper enfocado, y llegamos a él basados en comentarios del ecosistema de Stellar. A largo plazo, un cambio de protocolo sugerido podría permitir la agrupación general de transacciones y facilitar la creación de políticas por grupo, y actualmente hay una discusión en curso sobre cómo podría funcionar, ¡a la que cualquiera es libre de unirse!

Antes de decidirnos por este enfoque, consideramos otras posibilidades y tuvimos discusiones públicas sobre ellas. Específicamente...

Hablamos sobre aumentar la tarifa mínima

En 2020, iniciamos una discusión en la lista de correo sobre aumentar la tarifa mínima con una publicación en el blog explicando cómo podría reducir las transacciones fallidas de bots de arbitraje. Después de una discusión animada, quedó claro que no había un consenso general para un aumento de tarifas, y parecía poco probable que los validadores votaran para aprobarlo.

Aumentar la tarifa mínima podría haber excluido a los bots de arbitraje, pero muchos en el ecosistema señalaron que también habría hecho la red más costosa para todos. Argumentaron que los creadores de mercado, quienes proporcionan liquidez vital para la conversión de moneda y pagos transfronterizos, habrían sido particularmente afectados porque actualizan sus posiciones en el DEX todo el día, todos los días, para mantener los precios consistentes a través de los mercados. Así que en lugar de intentar excluir a los bots de arbitraje aumentando la tarifa mínima de la red...

Dejamos que el precio de urgencia se encargara del problema

Las tarifas en Stellar son dinámicas: cuando la presentación de transacciones supera el límite configurable de 1,000 operaciones/libro mayor, la red entra en modo de precio de urgencia. Las tarifas sirven como ofertas en una subasta VCG, y las transacciones que especifican tarifas más altas tienen prioridad para su inclusión en el libro mayor. \

El precio de urgencia permite a los usuarios de la red superar a los bots en busca de arbitraje, y muchos productos y servicios construidos sobre Stellar recibieron el mensaje después de que publicamos un FAQ en febrero de 2021, y se les ocurrieron estrategias para aumentar sus ofertas de tarifas. Sin embargo, porque los bots en busca de arbitraje envían transacciones en oleadas — recuerda, todos persiguen las mismas oportunidades, y cobran vida siempre que surge una — a menudo causan picos erráticos de tarifas, que son imposibles de predecir y difíciles de razonar. Muchos en el ecosistema continuaron expresando preocupación sobre la frecuencia del precio de urgencia, y solicitaron una solución técnica para reducir las transacciones fallidas sin aumentar las tarifas.

El límite de operaciones/libro mayor es configurable, y los validadores votan dónde establecerlo justo como votan para ratificar conjuntos de transacciones y agregarlas al libro mayor. Ahora mismo, han optado por un límite de 1,000 operaciones/libro mayor.

Aunque podrían aumentar ese límite, el consenso general entre los validadores es que hacerlo no resolvería el problema creado por los bots de arbitraje de fuerza bruta. De hecho, solo les daría más espacio para enviar transacciones destinadas a fallar. El tamaño del libro mayor crecería, habría más datos para que los operadores de nodos gestionaran, y el costo y complejidad de operar la infraestructura de Stellar aumentarían.

Cuando los validadores establecen el límite del libro mayor, intentan encontrar un equilibrio: quieren permitir un rendimiento suficiente para apoyar la actividad significativa de la red mientras también aseguran que la infraestructura de Stellar no requiera hardware especializado. Stellar es de participación abierta, y personas de todo el mundo deberían poder iniciar un nodo para contribuir a la red. Aumentar el límite del libro mayor para acomodar aún más transacciones fallidas va en contra de ese objetivo.

Si este cambio funciona, facilitará enviar transacciones exitosas. Al reducir el número de pagos circulares en busca de arbitraje enviados por bots considerados para inclusión en el libro mayor, esta característica puede reducir la competencia por espacio en el libro mayor, disminuir la frecuencia de precios por sobredemanda y facilitar que los productos, servicios y usuarios de Stellar en general envíen transacciones exitosamente a la red.

Dicho esto, aún recomendamos seguir las mejores prácticas al enviar una transacción a la red. Específicamente:

• Establece un límite de tiempo. De esa manera, si la transacción no tiene éxito dentro del tiempo especificado, sabrás que no está esperando ser procesada. Puedes intentarlo de nuevo sabiendo que no duplicarás accidentalmente, digamos, un pago.
• Establece la máxima tarifa que estás dispuesto a pagar. Realmente pagarás la cantidad mínima necesaria para hacer el libro mayor. En circunstancias normales, incluso con una tarifa máxima más alta establecida, pagarás el mínimo de la red — actualmente 100 stroops.
• Implementa un bucle de reintento con un retraso creciente (por ejemplo, 30s, 60s, 90s). Solo debería ejecutarse una vez que hayas superado el límite de tiempo que estableciste.
  

Si todavía estás obteniendo errores al intentar enviar transacciones, consulta el documento Manejando Errores con Gracia.

Si este cambio funciona, mantendrá las tarifas bajas reduciendo los casos de precios por sobredemanda.

Vale la pena mencionar que, incluso con el alto volumen de transacciones fallidas enviadas por bots, las tarifas de Stellar han permanecido increíblemente bajas. Al momento de escribir esto, la tarifa promedio por libro mayor de los últimos 30 días fue de 0.0004140 XLM. Aunque esperamos que ese número disminuya debido a esta característica, reitero: tu tarifa representa la cantidad máxima que pagarás por una transacción; en realidad se te cobrará el mínimo necesario para hacer el libro mayor. ¡Establece esa tarifa tan alta como estés dispuesto a pagar!

No. Un número suficiente de transacciones de pago de camino circular todavía harán el libro mayor para permitir un arbitraje saludable.

Cuando esta característica esté activada, un validador formará el tráfico que sugiere para inclusión en el libro mayor agrupando pagos circulares de arbitraje en competencia y eligiendo aleatoriamente cuáles mantener y cuáles pasar. Es configurable, y los operadores de validadores pueden ajustar el número de transacciones que permiten pasar. Funcionalmente, la cantidad de arbitraje exitoso permanecerá igual al status quo.

Sin embargo, en lugar de permitir que cada intento de arbitraje por fuerza bruta llegue hasta la etapa de aplicación antes de fallar, aumentando así la competencia por la inclusión en el libro mayor y abultando el registro permanente, esta característica permite a los validadores filtrar transacciones destinadas a fallar más temprano en el ciclo de vida de la transacción.