Traducción al español de “Cardano decentralization continues: insights into our P2P deployment”, escrito por Marcin Szamotulski, Jefe de Ingeniería de Software en IOG.
Los stake pools pronto podrán probar las conexiones peer-to-peer automatizadas
Para asegurar su sostenibilidad a largo plazo, su resistencia y su independencia de las entidades de gobierno centralizadas, es fundamental la descentralización de la red Cardano. Con la producción de bloques ya totalmente descentralizada, el siguiente objetivo es desarrollar nuestro ecosistema de operadores de stake pool (SPO) descentralizado para crear conexiones fiables y eficaces entre los nodos distribuidos.
Otorgar el poder de validar bloques y transacciones a los operadores de stake pool precisa de reformas en el software de la red. A finales de abril, la activación del regulador peer-to-peer (P2P), unida al despliegue del gestor de conexiones, permitió la puesta en marcha de una red de pruebas P2P privada. Actualmente evaluamos esta red de pruebas de ingeniería y desplegamos una red de pruebas P2P semipública en la que un grupo de OSP invitados nos ayudan a probar y poner a punto.
En el artículo sobre el gobernador P2P, abordamos la arquitectura de la red y la interacción entre los miniprotocolos y los componentes sobre los que se basa la comunicación directa y automatizada entre nodos. En esta ocasión, analizamos cómo ha evolucionado el modelo de conectividad hasta hacer posible la conectividad automatizada entre pares y reflexionamos sobre los resultados de la puesta en marcha de la red privada de pruebas.
Evolución de la conectividad de la red
El modelo de conectividad de la red Byron funcionaba en un estado federado, al lanzar Cardano. Es decir, IOHK mantenía nodos centrales y de retransmisión que se conectaban a otros 200 nodos de retransmisión [relay] aproximadamente (Figura 1).
Figura 1. La estructura de la red federada de Byron
Tras el lanzamiento de Shelley el pasado año, Cardano empezó a funcionar en un entorno híbrido. Esto permitió a los stake pools construir su red P2P manualmente conectándose a los nodos centrales, de retransmisión [relay] y a los siete nodos de retransmisión federados [de IOG] que ayudaron a mantener la red durante esta fase de transición (Figura 2).
Figura 2. La estructura inicial de la red híbrida de Shelley
A partir de marzo, los bloques se producen de forma totalmente descentralizada, con los stake pools siguiendo topologías manuales para las conexiones P2P. Ello significa que los SPO han estado empleando una lista de nodos de retransmisión registrados en todo el mundo a fin de generar su configuración para las conexiones con otros pares. Con el fin de ofrecer mayor eficiencia, es fundamental que la comunicación de los nodos sea automatizada, evitando depender de los nodos de retransmisión que se ejecutan en IOG. Por ello, actualmente el equipo de redes está desplegando el código P2P automatizado, que permite a los operadores del pool crear y ejecutar una red más descentralizada.
Por consiguiente, cuando se implante la red principal P2P, el mantenimiento de Cardano estará a cargo únicamente de los nodos gestionados por la comunidad (Figura 3).
Figura 3. La estructura final de la red con la comunicación automatizada de los nodos
Red de prueba [testnet] P2P y comunicación de nodos
El pasado mes, la primera etapa del despliegue de la red P2P fue la puesta en marcha de la red privada de pruebas P2P. Se ha empleado para probar las capacidades básicas de los componentes:
-
Gobernador P2P: se encarga de gestionar los conjuntos de pares activos, pasivos y fríos [hot, warm, and cold] y se asegura de que el nodo cumpla con el número objetivo de cada tipo de par.
-
Gestor de conexiones: se encarga de crear conexiones salientes o de registrar las entrantes, de hacer un seguimiento de su estado y de permitir la reutilización de las conexiones TCP full-duplex.
-
Servidor: se encarga de aceptar las conexiones y de realizar una limitación dinámica de la velocidad.
-
Gobernador del protocolo de entrada: se encarga de ejecutar y seguir el estado del lado de la conexión de entrada. Esto implica el seguimiento del estado de cada peer remoto (cold, warm o hot) y el estado de cada miniprotocolo de entrada.
La implantación del sistema P2P se llevó a cabo en un entorno privado y se probó entre ocho nodos que se conectaron a la red principal y se comunicaron con los nodos de retransmisión de SPO activos; estos, a su vez, se conectaron con otros retransmisores y nodos productores de bloques. El sistema ha permitido a los nodos descubrir los stake pool retransmisores mediante el registro de stake pool en la cadena [on-chain], en el que se incluye el nombre DNS o la dirección IP de cada retransmisor.
Según los resultados de las pruebas, los nodos podían seleccionar arbitrariamente a los pares para comunicarse, incluidos los de la red principal. El empleo de una métrica “ascendente” [“upstream”] posibilitó excluir a los pares de peor rendimiento y seleccionar aleatoriamente nuevos pares para la conexión. Se ha demostrado esta política en simulaciones a gran escala (10.000 nodos), ofreciendo resultados casi óptimos. Durante las pruebas en vivo, los integrantes del equipo observaron muchas iteraciones del procedimiento de optimización. También se percataron de que las conexiones de los pares se producían con pares cercanos y lejanos de distintos lugares, aspecto que era propio de los ocho nodos que funcionaban en diferentes partes del mundo.
En estos momentos, los equipos de redes y DevOps se esfuerzan en mejorar el entorno de la red de pruebas, de modo que todos los SPO invitados a la red de pruebas semipública tengan la posibilidad de establecer conexiones directas entre ellos. Además se trabaja en mejoras de las funciones y en los procesos de prueba para obtener los resultados más eficientes. En función de introducir nuevos objetivos para los pares locales raíz [local root peers], el equipo está ultimando las pruebas de características relacionadas como objetivos para pares conocidos, establecidos y activos.
En breve lanzaremos la red de pruebas P2P semipública, que contará con el apoyo de un pequeño grupo de SPO asociados para ayudar en las pruebas iniciales y posteriormente ampliarla a toda la comunidad de SPO. Como siempre, las primeras opiniones e ideas de nuestra comunidad son fundamentales para probar, iterar y mejorar los procesos a medida que avanzamos hacia una arquitectura P2P totalmente automatizada y descentralizada para la red principal de Cardano.
Contribuciones adicionales de Karl Knutsson, Duncan Coutts, Neil Davies, Prashanti Naik y Olga Hryniuk.
Nota del Traductor:
La terminología técnica en inglés le es común a los SPO, pero no al usurio promedio. En aras de hacer que la traducción sea lo más asequible posible a todos, he puesto al lado de la traducción de cada término (para el usuario promedio); su equivalente en inglés (para los SPO).