Cambios Propuestos en la Presentación de Transacciones

Estamos proponiendo una actualización a stellar-core para permitir 1 transacción por cuenta fuente por libro mayor. Esto significa que si un nodo Stellar está procesando actualmente una transacción de la cuenta A, cualquier nueva transacción de A será rechazada, y necesitará ser reenviada más tarde. “Procesando” se refiere al periodo de tiempo entre que una transacción entra en la cola de transacciones y se aplica al libro mayor o se descarta. Core aceptará nuevas transacciones subsiguientes tan pronto como la transacción anterior sea confirmada o descartada debido a precios por sobrecarga.

Aumentos de tarifa

Los usuarios no deberían ver ningún impacto en la funcionalidad de aumento de tarifa. Es decir, si una transacción de aumento de tarifa llega con la misma o diferente fuente de tarifa y la transacción interna ya está presente en la cola de transacciones, la nueva transacción no será rechazada, y en su lugar reemplazará a la transacción anterior (asumiendo que el aumento de tarifa es válido, por supuesto). Además, la misma cuenta puede pagar por múltiples aumentos de tarifa por libro mayor (asumiendo que las transacciones aumentadas tienen diferentes cuentas fuente).

Cuentas de canal

Los usuarios que utilizan cuentas de canal no se ven afectados, asumiendo que la misma cuenta de canal no envía múltiples transacciones por libro mayor. Además, usar cuentas de canal es nuestra solución recomendada para la escalabilidad de transacciones (más sobre esto abajo).

Este cambio introduciría algunas restricciones a la red Stellar, pero creemos que es un cambio positivo que mejorará la experiencia de interactuar con la red porque:

• Reduce la ambigüedad y confusión sobre cuándo se aceptan las transacciones en la red
• Puede mejorar el contrato de envío de transacciones y hacer las implementaciones más fáciles. La funcionalidad actual es de “mejor esfuerzo”, lo que significa que dependiendo de las condiciones de la red/configuración de infraestructura, los usuarios pueden no ser capaces de alcanzar el rendimiento deseado y tienen que implementar mecanismos complicados de manejo de errores/reintentos.

Varios ejemplos abajo ilustran los desafíos alrededor de escalar el rendimiento de transacciones con el mecanismo de múltiples-transacciones-por-cuenta.

Transacciones fuera de orden

Stellar-core descarta transacciones que llegan fuera de orden (con error de “número de secuencia malo”). Horizon intenta proteger contra eso reordenando las transacciones en memoria, pero hay advertencias:

• El reordenamiento no tiene efecto si se usan múltiples instancias de Horizon.
• Por esta razón, el reordenamiento no funciona en SDF Horizon
• Para instancias de Horizon de un solo hilo con un solo servidor, enviar 1 o múltiples transacciones por cuenta fuente no tiene efecto porque el punto final de envío de transacciones de Horizon bloquea hasta que la transacción entra en el libro mayor o se descarta*

‍*Esto no siempre es cierto, ya que a veces Horizon informa de tiempos de espera en transacciones que no son _realmente_ descartadas por la red.

Precios por sobrecarga

El comportamiento actual hace que los resultados de envío de transacciones sean bastante impredecibles cuando la red está experimentando precios por sobrecarga* (lo que ocurre frecuentemente en la red). Específicamente, si la cuenta A envía T1..TN a la cola, mientras la red está en precios por sobrecarga, todas las nuevas transacciones estarán atascadas hasta que T1 sea incluida en el libro mayor (incluso si T2…TN tienen tarifas muy altas). Aún peor, si T1 es descartada, todas las transacciones subsiguientes tienen que ser descartadas y reenviadas. Si el usuario quiere aumentar la tarifa de algunas transacciones, necesitará aumentar la tarifa de todas las transacciones por adelantado para que los aumentos de tarifa tengan algún efecto.

*los precios por sobrecarga son un evento cuando hay más transacciones queriendo entrar en el bloque de lo que la red permite, causando que la red priorice transacciones con las tarifas más altas

Además de las razones anteriores, este cambio es necesario para apoyar de manera segura a Soroban. Las transacciones de Soroban son bastante diferentes de las transacciones actuales: son potencialmente mucho más grandes en tamaño, y usan un modelo de tarifa multidimensional. Stellar-core tiene varias características de seguridad integradas, y SDF trabaja con el ecosistema más amplio para sugerir mejoras que ayuden a asegurar que la red sea robusta y resiliente. Cambiar al límite de 1 transacción/cuenta permite propagar transacciones de Soroban de una manera que protege contra ataques de denegación de servicio.

Debido a que las mismas cuentas fuente pagan tarifas tanto para transacciones Stellar como para Soroban, y debido a limitaciones/complejidad de la implementación de stellar-core, esta solución se aplica a todas las transacciones enviadas a stellar-core.

Antes de sugerir este cambio, echamos un vistazo a datos históricos que sugieren que el número de cuentas con múltiples transacciones por libro mayor es muy bajo. Para los usuarios afectados, cuentas de canal son la solución recomendada para enviar transacciones a la red a una alta tasa porque:

• Las cuentas de canal eliminan la dependencia en números de secuencia que causan que las transacciones se “atasquen” detrás de otras si la red está bajo carga pesada. Permiten a los usuarios aumentar la tarifa o reenviar las transacciones deseadas individualmente.
• Las cuentas de canal eliminan la necesidad de manejar escenarios de fallo complicados donde “cadenas de transacciones” son descartadas o prohibidas en la red y necesitan ser reenviadas.

El nuevo límite es necesario para que el Protocolo 20, que introduce el soporte de Soroban, funcione correctamente. Es decir, el límite necesita ser aplicado en toda la red antes de que los nodos voten para actualizar al Protocolo 20. La línea de tiempo propuesta es la siguiente:

• Ahora: recoger comentarios de la comunidad sobre el cambio propuesto
• 12 de julio: SDF Horizon fuerza el límite de 1 transacción/cuenta.
  Opción para desactivar: Los usuarios afectados aún pueden ejecutar su propia instancia de Horizon y desactivar la bandera.
• 25 de julio: Se lanza la versión 19.13.0 de Core que establece el límite por defecto.
  Los usuarios pueden desactivar manualmente el límite. Sin embargo, a medida que otros nodos actualicen a 19.13.0, los usuarios que lo desactiven pueden ver problemas de envío de transacciones ya que el resto de la red no aceptará múltiples transacciones por cuenta.
• 22 de agosto: Se lanza la versión 20.0.0 de Core que fuerza el límite y no permite a los usuarios desactivarlo.
  A medida que los nodos/Horizons actualicen a 20.0.0, los usuarios que aún desactiven el límite pueden ver problemas de envío de transacciones ya que el resto de la red no aceptará múltiples transacciones por cuenta.
• Otoño 2023: Votación del Protocolo 20, el límite se aplica en toda la red.
  Cualquier nodo que no ejecute v20.0.0 no podrá sincronizarse con la red

¿Tu experiencia es diferente de lo descrito arriba? ¿Crees que este no es el cambio correcto? ¡Haznos saber! Queremos entender tu caso de uso, y ayudarte a encontrar la mejor solución.