Cómo Validar el Código de Blockchain con Stellar Supercluster

Stellar es tan útil porque es confiable. Las organizaciones de ayuda mundial, las grandes empresas internacionales y los migrantes que envían remesas realmente no se llevan bien con 'moverse rápido, romper cosas' — necesitan poder enviar y recibir remesas, ayuda y otros tipos de pagos de manera fiable y con facilidad.

Eso significa que los desarrolladores que trabajan en Stellar Core no pueden simplemente escribir código y empujarlo a pubnet. En cambio, el código debe ser probado antes de que se ejecute en la red pública para asegurarse de que realmente funciona. Las actualizaciones deben ser sin interrupciones, para que los usuarios no enfrenten interrupciones al transaccionar en la red.

Stellar ya tiene dos redes separadas de la red pública (pubnet) que pueden ser usadas para cierta experimentación: testnet y futurenet. Pero testnet es para los miembros de la comunidad que quieren probar transacciones en Stellar, y por lo tanto no puede ser interferida para probar actualizaciones de Core. Futurenet, mientras tanto, está limitado a probar Soroban en la actualidad.

Por eso existe Stellar Supercluster, un conjunto de “misiones” que realizan pruebas automatizadas de las redes de Stellar Core, existe: Stellar Supercluster puede ser usado para validar código antes de que se active en pubnet. Puedes ver la lista completa de entornos simulados creados en el repositorio de Github. Las simulaciones involucran la ejecución de nodos centrales contenerizados en redes autónomas, luego alimentándolos con tráfico para probar la capacidad. Stellar Supercluster reemplazó una herramienta antigua llamada Stellar Core Commander, usando Kubernetes para una orquestación más fácil.

Para demostrar cómo funciona Stellar Supercluster, echemos un vistazo a dos misiones relacionadas: MissionSimulatePubnet y MissionSimulatePubnetTier1Perf. Como sugieren sus títulos, estas dos misiones simulan la pubnet y se usaron para probar una nueva mejora de transmisión de transacciones llamada Pull Mode por el desarrollador de SDF Hidenori Shinohara (más sobre eso a continuación).

Cuando Hidenori estaba diseñando el modo pull, su objetivo era optimizar la propagación de transacciones de una manera que mejore el TPS. Pero no podía simplemente mejorar este proceso de una manera que teóricamente tuviera sentido — tenía que mostrar al resto de la comunidad que realmente mejoraba el TPS de una manera tangible.

Para probar esto, primero necesitaba entender la topología de la red, o cómo varios nodos están conectados entre sí. El Stellar Consensus Protocol (SCP) requiere que los nodos lleguen a un acuerdo con otros nodos en los que confían — y dependiendo de qué nodos decidan confiar, hay infinitamente muchas configuraciones diferentes que pueden formar.

‍

El comando surveytopology permite a los desarrolladores tomar una instantánea de la topología de la red en un momento dado, y emitir este comando en diferentes momentos puede dar a alguien una idea de solo algunas de las formas en que los nodos pueden estar conectados. Pero esto probablemente no sea una encuesta exhaustiva, porque los nodos pueden optar por no ser detectados por este comando, y porque la topografía de la red podría verse completamente diferente dentro de minutos de emitir el comando. Además, mientras que a veces los nodos están directamente conectados entre sí en una configuración bastante eficiente, otras veces están mal configurados, creando ruido excesivo en los resultados. Para simular adecuadamente el impacto de una nueva característica, un desarrollador necesita probar numerosas configuraciones hipotéticas, sin importar lo que vea después de emitir el comando surveytopology.

En segundo lugar, Hidenori necesitaba entender el ritmo de los retrasos de la red. Los nodos que están geográficamente más distantes entre sí tardan un poco más en transmitir información. Pero una vez que se conoce la ubicación de dos nodos, se puede calcular el retraso de la red entre ellos dividiendo la distancia por la velocidad de la luz.

Por último, Hidenori necesitaba determinar las tasas de transacción y los tamaños para simular el sistema. Pero esta pieza es fácil, dada la inmutabilidad y transparencia de Stellar. Cualquiera puede mirar el historial del libro mayor de la red y ver cuán grandes y rápidas son las transacciones en promedio, y aplicar esos cálculos a una simulación de la red.

Cada uno de estos cálculos se usó para construir la arquitectura básica de una pubnet simulada — AKA misiones Stellar Supercluster MissionSimulatePubnet y MissionSimulatePubnetTier1Perf.

Una vez que la red está modelada, entonces puede ser probada para diferentes escenarios. En este caso, para probar el TPS, se realizaron tres simulaciones:

• Una que prueba algo cercano a la red real actual,
• Una que prueba configuraciones variantes potenciales de la red,
• Y una que prueba el límite superior de la cantidad de transacciones que se pueden realizar.

Las primeras dos simulaciones son bastante autoexplicativas. Para replicar la red real, los ingenieros de SDF ejecutaron un contenedor docker para cada nodo en un clúster de AWS, y Kubernetes para unirlos. Luego, sabiendo cómo han sido históricamente las transacciones, los ingenieros podrían emitir transacciones simuladas en la red simulada que imitaban el comportamiento del mundo real. Los nodos podrían estar conectados de diferentes maneras para ver cómo varias configuraciones impactaban el TPS cuando se implementaba el modo pull versus cuando no lo estaba. Se construyeron modelos para redes altamente conectadas así como aquellas donde los nodos validadores no están directamente conectados, por ejemplo. De esta manera, solo un puñado de computadoras podrían usarse para imitar la red real lo suficientemente confiable como para ver cómo el modo pull podría impactar el TPS.

La prueba de límites para el TPS sigue un proceso similar. En lugar de imitar transacciones vistas en pubnet, los ingenieros inundaron la red con tantas transacciones como fuera posible hasta que el sistema se rompió. Esto demuestra el número máximo absoluto de transacciones que la red podría emitir, con y sin implementar la característica del modo pull.

Simular una red de esta manera tiene algunos beneficios obvios. Con una fracción del número de máquinas, los desarrolladores pueden ver una aproximación de cuán bien una nueva característica puede funcionar en pubnet, predecir factores que podrían hacerla romperse, y suavizar cualquier problema que pueda obstaculizar la experiencia del usuario. Es la única manera responsable de introducir nuevas innovaciones que harán cambios tangibles y significativos en la red.

Hay algunas desventajas, sin embargo. Debido a que las simulaciones de Stellar Supercluster usan una fracción tan pequeña del CPU por nodo en comparación con la red real, los números son solo relativos, no exactos. Por ejemplo, cuando Hidenori estaba probando para el TPS, solo podía comparar si el TPS aumentaba o disminuía, en lugar de depender de los números finales de TPS producidos por MissionSimulatePubnet y MissionSimulatePubnetTier1Perf. Aunque puede observar el aumento o disminución porcentual de las transacciones, esos cambios porcentuales también tenían que tomarse como una aproximación. Y debido a que todos los nodos en un entorno simulado tienen el mismo poder computacional y se ejecutan en el mismo hardware, hay un nivel de uniformidad en las simulaciones de Stellar Supercluster que no existe en la red real.

A pesar de los desafíos, es difícil imaginar una mejor solución para probar características completas antes de empujarlas a pubnet. Las misiones de Stellar Supercluster simulan aspectos de la red rápidamente y con una fracción del poder computacional de pubnet, o incluso testnet o futurenet. Para los desarrolladores de la comunidad que quieren realizar planificación de capacidad en código nuevo o probar nuevas características, Stellar Supercluster es la mejor herramienta actualmente disponible. La información técnica detallando cómo hacer un clúster se puede encontrar en el repositorio de Github.

‍