Explora Cardano: 3. Red Cardano: a. Acerca de la red Cardano

La red Cardano es una infraestructura técnica que combina los nodos Cardano y sus interacciones relativas en un sistema unificado. Consiste en una colección de nodos que se comunican entre sí para mantener el libro mayor distribuido. Estos nodos son los actores de Cardano que validan los bloques, añaden bloques a la cadena y distribuyen las transacciones.

La capa de red es la fuerza motriz para cumplir con los requisitos de intercambio de información, que incluye la difusión de nuevos bloques y la información de las transacciones para establecer un mejor flujo de datos. Los nodos de Cardano mantienen conexiones con pares que han sido elegidos a través de un proceso de selección de pares personalizado.

Sigue estos enlaces para encontrar las especificaciones detalladas de:

Flujo de datos entre y dentro de los nodos

Para entender cómo se comunican los nodos entre sí, supongamos que el nodo A está conectado al nodo B. Entonces, el protocolo Ouroboros programa un nodo N para que genere un nuevo bloque en un slot de tiempo determinado. Dependiendo de la ubicación de los nodos A, B y N en la topología de la red, y de si un nuevo bloque llega primero a A o a B, el nodo A puede estar situado más arriba o más abajo del nodo B.

Se utiliza un conjunto de miniprotocolos para permitir la comunicación entre diferentes nodos. Cada miniprotocolo implementa un requisito básico de intercambio de información, como informar a los compañeros del último bloque, compartir bloques según sea necesario o compartir nuevas transacciones en la red Cardano. A efectos de conexión, los miniprotocolos están determinados por la versión del protocolo de la red. Por ejemplo, hay dos conjuntos de protocolos: nodo a nodo y nodo a cliente. El conjunto de protocolos de nodo a cliente lo utilizan los monederos y los consumidores de la cadena. Los conjuntos de protocolos utilizan diferentes conjuntos de miniprotocolos y la versión se negocia cuando se establece una nueva conexión utilizando un protocolo específico (los protocolos se describen en las siguientes secciones).

Los clientes también pueden elegir qué miniprotocolos de nodo a cliente utilizar, pero es importante tener en cuenta que el nodo debe ser capaz de responder a todos ellos para soportar diferentes casos de uso. Por ejemplo, para comunicarse, el nodo A ejecuta su instancia del lado del cliente del miniprotocolo chain-sync que habla con una instancia del servidor del miniprotocolo chain-sync en el nodo B. Esta situación es similar a la funcionalidad de otros miniprotocolos.

El esquema siguiente ilustra cómo fluyen los datos dentro de un nodo. Los círculos representan los threads del protocolo y los threads internos que se encargan de ejecutar los procesos del cliente y del servidor dentro de los respectivos miniprotocolos.

Existen dos tipos de flujo de datos:

Los miniprotocolos se comunican con los miniprotocolos de otros nodos enviando y recibiendo mensajes a través de una red pública (Internet); este flujo no está contemplado en el esquema anterior, pero se diseñará potencialmente para una mejor comprensión.
Dentro de un nodo, los miniprotocolos se comunican entre sí leyendo de, y escribiendo en, una variable mutable compartida, que está representada por recuadros en el esquema. Las flechas indican si un thread tiene acceso de lectura o escritura al estado compartido.

Cómo se abordan las complejidades y limitaciones de la red

Para diseñar una arquitectura de red eficiente y robusta, se han evaluado una serie de cuestiones potenciales relacionadas con la complejidad y las restricciones.

El control de la congestión es una de estas características y se utiliza para hacer frente a la sobrecarga del sistema. El control de la congestión es vital para asegurar que el sistema es lo suficientemente robusto mientras opera con altas cargas de trabajo. Dentro del diseño de la red, es común que el número de transacciones que se producen pueda ser mayor que el número que puede ser realmente procesado para su inclusión en el blockchain. Por lo tanto, es importante garantizar que el aumento de la tasa de presentación de transacciones en un bloque no disminuya el rendimiento del blockchain.

El nodo actual tiene un límite en la cantidad de datos que puede procesar. En particular, un nodo puede tener que compartir su capacidad de procesamiento con otros procesos que se ejecutan en la misma máquina o instancia del sistema operativo. Esto significa que un nodo puede ralentizarse y hacer que el sistema no pueda procesar todos los datos disponibles de la red.

Para solucionar estos problemas, la función de control de la congestión se ha diseñado para que funcione adecuadamente en una situación de este tipo y se recupere de las condiciones transitorias. En cualquier caso, un nodo no debe sobrepasar sus límites de memoria, por lo que deben existir límites de memoria definidos, cuyas infracciones se tratan como violaciones del protocolo. Estos factores hacen que el sistema pueda cumplir los objetivos de rendimiento.

Las restricciones de tiempo real y el tiempo universal coordinado son otros aspectos que se han tenido en cuenta al diseñar la arquitectura de red. En Cardano, los protocolos de consenso Ouroboros modelan el paso del tiempo físico como una secuencia infinita de slots de tiempo, asignando líderes de slot para crear un nuevo bloque en esos slots de tiempo. La elección de un tiempo de slot, sin embargo, puede causar ciertas complejidades en cuanto a la longitud del slot, ya que debe ser lo suficientemente largo para que un nuevo bloque tenga una buena oportunidad de llegar al siguiente líder de slot a tiempo. Por ello, el valor elegido para la longitud de slot se fijó inicialmente en 20 segundos en la era Byron. Con Ouroboros Praos ahora implementado en la era Shelley, se elige una longitud de slot de 1 segundo pero, en promedio, sólo 0,05 de los slots producirán un bloque (y por lo tanto, en promedio, habrá intervalos de 20 segundos entre bloques). Se supone que las desviaciones de reloj entre los relojes locales de los nodos son pequeñas con respecto a la longitud del slot. No obstante, hay que tener en cuenta las posibles imprecisiones del reloj, especialmente cuando se trata de bloques entrantes con marca de tiempo. Es importante diferenciar si hay una diferencia de tiempo o si el nodo considera un comportamiento adverso de otro nodo.

Utilización de mini-protocolos

Los miniprotocolos se utilizan para la comunicación entre múltiples nodos mientras se implementan los requisitos de intercambio de información. Un miniprotocolo es un bloque de construcción modular definido del protocolo de red. La estructuración del protocolo de red en torno a los miniprotocolos ayuda a gestionar la complejidad general del diseño, al tiempo que garantiza una flexibilidad útil.

Los miniprotocolos describen tanto al iniciador como al respondedor dentro del flujo de comunicación. El iniciador es el elemento dual del respondedor y viceversa. Un nodo suele ejecutar muchas instancias de miniprotocolos, que incluyen muchas instancias del mismo miniprotocolo. Cada instancia de miniprotocolo del nodo se comunica entonces con la instancia dual del par exacto. Todos los miniprotocolos que se comunican con el mismo par comparten un único canal de comunicación (pipe o socket). Se utiliza un multiplexor o desmultiplexor para multiplexar los respectivos protocolos por ese canal.

El conjunto de miniprotocolos que se utiliza para la conexión entre dos participantes del sistema depende del papel de estos participantes, por ejemplo, si el nodo actúa como un nodo completo o un consumidor de blockchain (por ejemplo, un monedero).

También cabe destacar que la implementación de los miniprotocolos utiliza un marco genérico para las máquinas de estado. Este marco utiliza técnicas de corrección por construcción para garantizar la implementación de varias propiedades del protocolo. En particular, esta técnica asegura que no se produzcan bloqueos y que la comunicación se cancele en los siguientes escenarios:

cuando se espera que una de las partes transmita el siguiente mensaje, y la otra parte está esperando el mensaje, y ambas partes están de acuerdo en que el protocolo ha terminado
cuando cualquiera de las partes recibe un mensaje que no se espera según el protocolo

Todos los miniprotocolos basados en este marco incluyen la siguiente información en su descripción:

una descripción informal del protocolo
estados de la máquina de estado
mensajes intercambiados
un gráfico de transición de la vista global de la máquina de estado
la implementación del protocolo por parte del cliente
la implementación del protocolo por parte del servidor

Ejemplos de miniprotocolos

Esta sección presenta algunos ejemplos de miniprotocolos.

Protocolo Ping Pong

Se trata de un sencillo protocolo de prueba que un cliente puede utilizar para comprobar que el servidor responde. El protocolo Ping-Pong es muy simple porque los mensajes no llevan ningún dato y el cliente Ping-Pong, así como el servidor Ping-Pong, no acceden al estado interno del nodo.

Protocolo de Solicitud de Respuesta

El protocolo de solicitud de respuesta es polimórfico en cuanto a los datos de solicitud y respuesta que se transmiten. Esto significa que hay diferentes aplicaciones posibles de este protocolo y la aplicación del protocolo determina los tipos de solicitudes enviadas y respuestas recibidas.

Protocolo de Sincronización de Cadena

El protocolo de sincronización de la cadena es utilizado por un consumidor de blockchain para replicar localmente la blockchain del productor. Un nodo se comunica con varios nodos ascendentes y descendentes y ejecuta una instancia de cliente independiente y una instancia de servidor independiente para cada nodo con el que se comunica.

El protocolo de sincronización de cadena es polimórfico. El protocolo de nodo a cliente utiliza una instancia del protocolo de sincronización de cadena que transfiere bloques completos, mientras que la instancia de nodo a nodo sólo transfiere cabeceras de bloque. En el escenario de nodo a nodo, el protocolo de obtención de bloques se utiliza para transferir bloques completos.

Protocolo de Obtención de Bloques

El protocolo de obtención de bloques permite a un nodo descargar un rango de bloques.

Miniprotocolo de Presentación de Transacciones Locales

El Miniprotocolo de Presentación de Transacciones Locales es utilizado por los clientes locales, por ejemplo, los monederos o las herramientas CLI, para enviar transacciones a un nodo local. El protocolo no se utiliza para enviar transacciones de un nodo central a otro. El protocolo sigue un patrón simple de solicitud-respuesta:

el cliente envía una solicitud con una sola transacción.
el servidor acepta la transacción (devolviendo una confirmación), o la rechaza (devolviendo el motivo).

Protocolo de Presentación de Transacciones de Nodo a Nodo

El protocolo de envío de transacciones de nodo a nodo se utiliza para transferir transacciones entre nodos completos. El protocolo sigue una estrategia basada en la extracción, en la que el iniciador solicita nuevas transacciones y el respondedor responde con transacciones. Es adecuado para un entorno sin confianza en el que ambas partes necesitan protegerse de los ataques de consumo de recursos de la otra parte. La implementación del miniprotocolo de transacciones de nodo a nodo se basa en un marco de miniprotocolo genérico (el mismo que para todos los demás miniprotocolos). Por razones técnicas, los papeles del iniciador y del respondedor se invierten en este caso en comparación con la forma en que se implementan otros miniprotocolos en el marco. En otras palabras, el servidor es el iniciador que solicita nuevas transacciones, y el cliente es el respondedor que responde con transacciones.

Mini protocolo Handshake

El miniprotocolo handshake se utiliza para negociar la versión del protocolo y los parámetros del mismo que utilizan el cliente y el servidor. Se utiliza en primer lugar cuando se inicia una nueva conexión y consiste en una única solicitud del cliente y una única respuesta del servidor. El miniprotocolo handshake es un protocolo genérico que puede negociar cualquier tipo de parámetros de protocolo. Asume que los parámetros del protocolo pueden ser codificados y decodificados a partir de términos de Representación Concisa de Objetos Binarios (CBOR). Un nodo que ejecute el protocolo handshake debe instanciarlo con el conjunto de versiones de protocolo soportadas y funciones callback para manejar los parámetros del protocolo. Estas funciones de llamada de retorno son específicas para las versiones de protocolo soportadas.

Encuentra una copia oficial de este documento aquí:

https://docs.cardano.org/explore-cardano/cardano-network/about-the-cardano-network

Más traducciones de Cardano en: Cardano For The World