Transcripción al español de “Cardano Technical Briefing: Dynamic Peer-to-Peer by Duncan Coutts”
Publicado en el canal de Youtube de IOHK el 19 de Marzo 2023
Enlace a la versión doblada al español
Acompaña a Duncan Coutts, arquitecto técnico de Input Output Global (IOG), en su charla sobre la última mejora de la red Cardano: Dynamic P2P. Se trata de una actualización que aporta mejoras continuas al rendimiento, la seguridad y la resistencia de la red.
Obtenga más información sobre la última evolución de la red de Cardano, incluidos los detalles de la puesta en marcha, que ha sido precedida por una extensa investigación, pruebas y simulaciones. Duncan también responde a una serie de preguntas enviadas previamente por la comunidad técnica de Cardano.
Echa un vistazo a nuestra entrada de blog sobre Dynamic Peer-to-Peer aquí: IOHK Blog - Page 1…
Para nuestros SPOs, seguimos compartiendo más actualizaciones con la comunidad SPO e invitamos a todos a unirse al grupo SPO Telegram y al canal Discord para discusiones técnicas.
Anuncios de SPO TG:
Discord:
Hola, soy Duncan Coutts, mí trabajo en IOG es ser el arquitecto del nodo Cardano. He estado trabajando en el nodo Cardano por mucho tiempo. Estuve involucrado, pero no a cargo, cuando realizamos el despliegue Génesis original, al principio, con Byron. Mí mayor llamado a la fama fue cuando dirigí el equipo que realizó la reescritura de Cardano para la liberación Shelley. Desde entonces me moví hacia cosas más mirando al futuro, ese es como el día a día, es por qué escuchaste menos de mí en los últimos años que cuando estábamos trabajando furiosamente en Shelley de Cardano.
Hoy quiero hablar de la capa de red y la liberación de par a par dinámica. La capa de red de Cardano es una capa en el software, en el nodo, que se sienta debajo de la capa de consenso, y soporta todas las necesidades de diseminación de información del algoritmo de consenso. Lo llamamos el protocolo de nodo a nodo, osea el protocolo de red, y el protocolo de nodo a nodo en sí mismo consiste de tres, que los llamamos, mini protocolos, que lidian con diferentes aspectos, diferentes tipos de información con que el nodo necesita intercambiar enre los nodos para soportar el protocolo en general. Cuando los SPOs y usuarios están estableciendos sus nodos, bueno, los SPOs en particular, tienen dos roles diferentes en que pueden configurar sus nodos para desempeñarse. Obviamente necesitan producir bloques, así que uno de los roles en que configuran sus nodos es como productor de bloques. Luego también establecen lo que llamamos relays, que de nuevo son nodos que sólo están configurados en el rol de relay de información, en vez de ser un productor de bloques. Y estas diferentes configuraciones son importantes acerca de cómo pensamos en la topología general de la red. Y la topología de la red estará cambiando un poquito, cuando nos movemos de la configuración actual al despliegue par a par dinámico.
En términos de lo que eso significa para la topología de la red, significa que hay conexiones directas entre todos los SPOs y en última instancia, conexiones directa entre los relays de los SPOs, y nodos de usuarios, que corren en sus computadoras, en sus servidores, lo que sea. La liberación de par a par dinámico traerá un número de beneficios. Lo que realmente hará, es automatizar la manera en que la topología está construída entre SPOs, productores de bloques, relays, pero realmente entre los relays de los diferentes SPOs. Así que esta liberación no es acerca de conectar directamente los relays de los SPOs con nodos de usuarios finales, es acerca de automatizar la manera en que los relays de los SPOs se conectan entre sí. En última instancia, en el futuro, una vez que tengamos Ouroboros Génesis, entonces seremos capaces de conectar relays de SPOs directamente con usuarios finales. Y eso también dependerá de todas estas funciones de par a par, pero en esta liberación, la cosa crucial que estará cambiando es acerca de cómo los relays de los SPOs se conectan entre sí. Una cosa que está cambiando, es que esto se está volviendo mucho más automatizado. En este momento los SPOs tienen que utilizar un sistema de configuración de alguna manera manual para especificar estáticamente la configuración de pares con que cada uno de sus relays se conectará. Eso se volverá automatizado, de un par de maneras diferentes. En este momento los SPOs tienen que listar un número bastante grande de relays de otros SPOs, por su dirección IP, nombre DNS, y tienen que utilizar un gran número de ellos porque necesitan tener, en todo momento, un cierto número de relays conectados. Pero si tenés una lista estática, no sabés cuál estará en o fuera de línea en un momento particular. Osea que tenés como que sobre aprovisionar, teniendo listado muchos de ellos, para que siempre puedas garantizar que al menos un número mínimo será listado. Mientras que con un sistema mucho más automatizado, que realiza esta liberación de par a par dinámica, en su lugar lo que ocurre es que todo el conjunto de todos los relays de los SPOs, están todos disponibles para ser elegidos, osea que no necesitás una lista estática como de 50, están todos ahí. Y luego hay un objetivo de, digamos 20, que podría ser configurado, pero 20 es un número razonable, y el sistema continuamente asegurará que ese número objetivo de conexiones a relays de otros SPOs es mantenida, incluso aunque otros pares entren y salgan. Así que eso puede darnos mejor utilización de recursos, porque todas estas conexiones corriente arriba tienen un costo, así que no necesitamos sobre puentear.
Así que la liberación de par a par dinámica entonces nos da un número de beneficios. En general obtenemos mejor seguridad porque esto es acerca de resistencia de toda la red a ataques de negación de servicio distribuido. La razón de esto es que ahora es fácil para los SPOs configurar sus productores de bloques y relays, para que los productores de bloques estén totalmente protegidos con cortafuegos al resto de internet, porque hace posible configurar sus cortafuegos de tal manera en que todas sus conexiones entrantes son bloqueadas, porque el productor de bloques puede realizar conexiones salientes a los propios relays de los SPOs sin tener que permitir conexiones TCP entrantes. Esto es como una simplificación de seguridad, o mejora, dependiendo de cómo lo mires. Además, también es posible que los productores de bloques establezcan arreglos de pares privados con otros SPOs, que no se hacen públicos. Es posible que los SPOs listen sus relays públicamente, pero también es posible tener pares ocultos, con los que pueden conectarse a través arreglos de vinculación privados con relays de otros SPOs. Eso proveerá resiliencia adicional si alguien estuviera intentando realizar un ataque de negación de servicio en toda la red. Debería tener algunas mejoras en el rendimiento y escalabilidad de la red. Y esto es debido a que la manera en que el par a par está construido dinamicamente en este momento, con la liberación del par a par dinámico, sigue, yo pienso, un procedimiento de optimización bastante inteligente. Nuestras simulaciones indican que produce un resultado general que es cercano a un resultado óptimo. Que es una afirmación bastante osada, pero tenemos simulación para respaldar eso. Significa que si sos capaz de construir una red global perfecta donde sólo elegís la conexión correcta entre cada nodo, ese es como el óptimo teórico. Bueno, resulta que este proceso de optimización que tenemos, basados puramente en información local, nos lleva bastante cerca, razonablemente cerca a ese óptimo global, que es un buen resultado. Esto nos está diciendo que el procedimiento completamente automatizado, en comparación con lo que la gente podría realizar manualmente, nos da un muy buen resultado en términos del tiempo total que toma para que los bloques sean transmitidos por la red, la gente podría pensar que manualmente podría elegir muy buenas opciones, y probablemente puedan obtener muy buenas opciones manualmente, pero, primero que todo, ya no tenemos que hacerlo manualmente, segundo, esto debería darnos un muy buen resultado global, en términos de tiempo de difusión de bloques, el tiempo que toma a los bloques atravesar la red.
Resumamos la historia de la capa de red, dónde está ahora, a dónde va, y cómo esta liberación de par a par dinámica encaja en el contexto general. Al principio, cuando tuvimos la liberación Byron, las cosas eran federadas, teníamos una topología de red federada. Significa que IOG estaba corriendo todos los nodos productores de bloques, en el comienzo, y todos los relays. Cuando tuvimos la gran liberación Shelley, descentralizamos la producción de bloques, haciendo que los SPOs se involucren, los nodos productores de bloques de los SPOs, y los relays de los SPOs. Pero todavía teníamos a IOG proveyendo un número de relays para apoyar los usuarios finales, merchants, exchanges, usuarios Daedalus, etc. Y esto que tenemos ahora es como un nodo híbrido. Es un híbrido entre una topología par a par y federada, porque la manera en que los SPOs se conectan entre sí, de hecho es una red de par par, aunque es una red de par a par configurada manualmente. Así que la liberación de par a par dinámica cambia eso automatizando esa parte, la cambia de ser configurada manualmente a ser completamente automatizada.
El próximo paso involucra el despliegue de Ouroboros Génesis. Ouroboros Génesis es una variación posteríor del algoritmo Ourboros, que fue publicado como documento académico hace unos años atrás . Y trae, de alguna manera, como la pieza importante final de Ouroboros, que es cómo arrancar desde génesis apropiadamente y de manera segura. Es cómo unirse de manera segura a la red, más adelante, en oposición a unirse desde cuando comenzó en el comienzo. Proveé revisión por pares apropiada, algoritmo probado matemáticamente para seguridad, para ser capaz de establecer confianza en la cadena más adelante, sin necesitar de otros intermediarios de confianza. La liberación de par a par dinámico nos da el mecanismo para la red de par a par. Pero que permite usuarios finales dentro de ese sistema, dentro de esa red de par, es Ouroboros Génesis.
Y la fase final del par a par, del despliegue de la capa de red, es una función que llamamos compartir pares, Eso significa que no son sólo los SPOs los que pueden tener relays en la red. Una vez que tengamos compartir pares, significa que cualquiera, no sólo SPOs, pueden proveer sus máquinas para actuar como relays. Esas son las fases del despliegue de capa de red.
Hablemos de cómo se desarrolló esto, cómo se desplegó. Su realización ha tomado mucho tiempo, atravesó una fase bastante larga de investigación y desarrollo, antes mencioné simulaciones, realizamos una bastante extensa colaboración de investigación donde miramos un montón de teoría, como dije, un montón de simulaciones, para intentar resolver un mecanismo local, local en el sentido de sólo depender en información que está disponible localmente para todo nodos, para que los nodos no tengan que confiar entre sí. Un mecanismo local para establecer un resultado global, que es minimizar para que los bloques sean transmitidos a través de la red. Luego esa fase de desarrollo incluye varios entornos con extensos testeos y simulaciones utilizando una técnica que usamos extensivamente llamada testeo basado en propiedades, en este caso testeo basado en propiedades en una simulación de red de IO. Y lo hemos estado corriendo con algunos pocos SPOs, que han sido muy útiles con versiones de pre producción, probando cosas, corriendo versiones de relays de par a par, en la red principal, durante algún tiempo, pero como nodos privados, que nosotros estuvimos y ciertos SPOs estuvimos corriendo, nos ayudaron con eso. Y ahora finalmente estamos llegando a la etapa de inclusión a liberación principal, le estamos pidiendo a todos los SPOs que comiencen a probar. La manera en que esto ha sido desplegado es, con cuidado, con cuidado, paso a paso. En particular, no es algo que se enciende automáticamente cuando actualizás, es algo que se permite en configuración. El nodo puede correr ya sea en modo par a par, o en el modo antiguo. Es algo en lo que todo el mundo puede escoger entrar en el momento correcto para ellos. Lo que inicialmente le estamos pidiendo que hagan a los SPOs es una configuración de un relay, donde al menos unos de sus relays está corriendo en modo par a par, y luego a medida que atravesamos el despliegue le estaremos recomendando a los SPOs que intenten configurar su productor de bloques en modo par a par, significa que tienen que dejar de pensar en cómo se comunican sus relays y productor de bloques entre sí, y eventualmente llegamos a la etapa en que los SPOs pueden tener todos sus productores de bloques y relays corriendo en modo par a par. Espero que eso haya sido interesante y haya informado un poco acerca qué está ocurriendo con la capa de red, con la liberación de par a par.
Hemos recolectado un par de preguntas de la comunidad, en particular creo que de SPOs, así que rápidamente voy a leer algunas de ellas.
¿Qué son los pares fríos, pares calientes y pares cálidos?, ¿Cómo funcionan?
Los pares fríos, calientes y cálidos son parte de cómo funcionan partes internas del nuevo par a par, lo que llamamos gobernante par a par, o gobernante saliente, mantiene rastreo de todos los pares en una de estas etapas. Los pares fríos son pares del que nodo sabe al respecto, pero no hay conexión con ellos. Los pares cálidos es donde hay una conexión establecida pero realmente está siendo utilizada para propósitos de monitoreo, para propósitos de evaluaciones de rendimiento, pero no siendo utilizada para los protocolos de consenso en sí mismos. Y los pares calientes son cuando el par está siendo utilizado, la conexión a ese par está siendo utilizado para el protocolo de consenso. Los pares son promovidos y degradados entre estas diferentes temperaturas, si te parece. Resulta que las investigaciones y simulaciones que realizamos indican que podemos tener políticas extremadamente simples para la promoción y degradacón. Resulta que sólo necesitamos una política inteligente. La promoción de fría a cálida podemos hacera aleatoria, y eso es lo que hacemos. La promoción de cálida a caliente, también la hacemos aleatoria. El único momento en que tenemos una política muy inteligente, es la degradación de caliente a cálida, y eso se hace realizando continuas mediciones de, técnicamente es qué pares nos dieron encabezados menos útiles durante el último período de tiempo, cuáles fueron los que menos a menudo dieron el encabezado primero, esos son los peores pares, degradamos algunos de los peores pares, y luego aleatoriamente promovemos un par par, y eso es suficiente para que funcione el procedimiento de optimización en general.
¿Será posible correr nodos ocultos?
¿Qué es un nodo oculto?, creo que lo querés decir por nodo oculto es uno que no está registrado como relay de SPO. Y por supuesto ya es posible correr relays y no registrarlos en la red como relay de SPO. Así que de alguna manera, es posible ahora y será posible en el futuro. La diferencia es que lo que ganás y perdés por un nodo oculto. Un nodo oculto que no está listado o registrado como relay de SPO, no recibirá conexiones entrantes de otros SPOs que están utilizando el modo de par a par. Porque está ocultos, no se los conoce, igualmente pueden realizar conexiones salientes pero no recibirán entrantes. A menos, por supuesto, que hagas acuerdos de pares privados con otros SPOs, porque podés decirle a otro SPO “aquí está la dirección IP, o el nombre DNS de mí nodo oculto”, y ellos pueden configurar sus relays, no sólo para realizar la cosa general de conectarse automáticamente a selección, digamos, otros 20 relays de SPOs. Pero es posible, en la configuración de par a par, seleccionar grupos particulares con objetivos particulares, podés decir “me gustaría siempre mantener al menos una conexión a estos dos relays, o dos conexiones a estos tres relays”, o algo así. Y podría incluir los relays ocultos de otro SPO, con el que tenés un acuerdo de par privado. Así que en ese sentido, si, será posible correr nodos ocultos.
¿Qué son los pares de libro contable?
Los pares de libro contable son pares que son seleccionados desde el libro contable. Recordá que los SPOs pueden registrar sus relays en la cadena. Estos son relays de los que todo el mundo sabe al respecto. En la capa de par a par dinámica, cuando los nodos están pensando qué nodos van a seleccionar, el bote general de donde pueden seleccionar pares, son los que están registrados en el libro contable. Este es el conjunto de pares con que un SPO configuraría sus relays para conectarse, porque un SPO quiere configurar sus relays para conectarse con otros SPOs.
¿Es Ouroboros Génesis un requisito para el despliegue de par a par en red principal?
La relación entre Ourobors y par a par es que, técnicamente, mayormente, son independientes entre sí. Pero, necesitás ambos antes de poder permitir a los usuarios finales formar parte de la red de par a par. Par a par provee un mecanismo, o la capa de red, realiza la organización real de la topología, que es mecanismo por el cual los nodos, incluidos en los nodos de usuarios finales, exchanges, etc, forman parte de la red, estableciendo conexiones, etc, etc. Pero Ouroboros Génesis es el facilitador que lo hace seguro, para que los usuarios finales hagan eso.
¿Será posible configurarlo para sólo aceptar conexiones entrantes de IPs especificadas?
La respuesta corta a esto es no, pero probablemente no necesites hacer eso. No provee esa función directamente, esa es una función que necesitarías realizar con tu propio cortafuegos. Pero la cosa interesante es que no necesitarías hacer esto en absoluto, probablemente, con la liberación de par a par dinámico, porque, es posible establecer una conexión en la otra dirección. Probablemente la premisa de la cuestión es alguien imaginando su nodo productor de bloques, aceptando conexiones entrantes de un relay. Pero esa no es la manera en que recomendaremos configurar estas cosas, eso todavía sería posible, pero en su lugar, la manera en que lo recomendamos, para el productor de bloques, para establecer una conexión saliente al relay. Y el relay de todos ya tiene que aceptar conexiones de todos lados, es un relay público. Y eso funcionaría, porque una de las mejoras principales en la liberación de par a par es que toda conexión es potencialmente bidireccional, significa que en términos de protocolos , puede ser corrido en ambas direcciones en esa conexión TCP, significa que no importa quién se conecta con quién, en qué dirección inicialmente, para la dirección en que corra el protocolo de consenso. Así que, podés tener A conectado a B, o B conectado a A, y cualquiera puede ser corriente arriba o abajo, entre sí, dependiendo de cómo se configuran y el estado de esos dos nodos. Así que la recomendación para la configuración típica será, el productor de bloque establece una conexión saliente, a través de su cortafuegos, hacia los relays del propio SPO, y luego bloquea todas las conexiones entrantes, porque no necesitará haber ninguna conexión entrante, porque son las salientes las que todavía pueden ser utilizadas en ambas direcciones. Así que con suerte eso reasegurará esa configuración. Ok, eso es todo, para más información podés seguirnos en twitter, para discusión más técnica podés unirte al Discord.