Serie explicativa sobre Discv5: #2

En este artículo exploramos cómo los nodos se encuentran y comunican de forma segura, abarcando mensajes, paquetes, inicio de conexiones y sesiones utilizando Discv5, proporcionando una comprensión clara de la comunicación peer-to-peer entre los nodos.

Este artículo es una traducción de “Discv5 Explainer Series: #2” escrito por Pier Two, traducido por Ari Kiry.

En el artículo anterior presentamos el protocolo Discv5 y explicamos cómo los nodos gestionan su identidad y vecinos. Mediante el uso de un sistema de identidad, los nodos pueden establecer conexiones seguras y verificables con otros nodos de la red. En este artículo continuaremos explorando cómo los nodos se encuentran y se comunican entre sí de forma segura. Explicaremos los diferentes tipos de mensajes y paquetes transmitidos en la red, así como el proceso de inicio de conexiones y el establecimiento de sesiones de comunicación utilizando Discv5. Al concluir la lectura de este artículo, obtendrás una comprensión clara de cómo los nodos se descubren y comunican entre sí de manera peer-to-peer.

Descripción general de mensajes y paquetes

Mensajes

El protocolo Discv5 admite varios tipos de mensajes que los nodos pueden enviar o recibir. Cada tipo de mensaje tiene un par correspondiente: uno para solicitar algo y otro para responder a ello. Por ejemplo, un nodo puede solicitar los metadatos (información sobre sí mismo) a otro nodo y obtener una respuesta con los metadatos correspondientes. Cuando un nodo recibe un mensaje, utiliza un número llamado ID del mensaje para identificar el tipo de mensaje al que pertenece y devuelve el tipo de mensaje apropiado. Estos mensajes desempeñan un papel crucial en el mantenimiento de la conectividad de la red, ya que permiten a los nodos encontrar los pares adecuados, compartir información y sincronizar datos. La tabla siguiente enumera todos los tipos de mensajes admitidos por Discv5 y sus correspondientes ID.

Paquetes

Uno de los aspectos fundamentales para lograr una comunicación segura entre los nodos de la red Ethereum es el cifrado y la estructuración de los mensajes. En lugar de enviar los mensajes en texto plano, el protocolo Discv5 emplea una clave de sesión compartida para encriptarlos. La generación de esta clave de sesión se lleva a cabo mediante un mecanismo de handshake, el cual detallaremos más adelante.

La comunicación segura en la red Ethereum se fundamenta en el uso adecuado de paquetes para gestionar los mensajes. Estas unidades de datos pequeñas contienen la información necesaria para mantener una comunicación cifrada y autenticada. Específicamente, el protocolo Discv5 utiliza estructuras de paquetes con el propósito de asegurar que la comunicación entre nodos sea segura y fiable.

Cada paquete del protocolo Discv5 consta de dos partes principales: una cabecera y un mensaje cifrado y autenticado opcionalmente. El componente de cabecera contiene una sección llamada Authdata, cuyo tamaño puede variar según el tipo de paquete. Básicamente, la cabecera proporciona la información necesaria para que el nodo receptor procese y maneje adecuadamente el paquete. En el protocolo Discv5, hay tres tipos principales de paquetes:

Paquete de mensaje ordinario: Este tipo de paquete permite enviar de forma segura mensajes cifrados y autenticados entre nodos. En los paquetes de mensajes ordinarios, la sección Authdata incluye el ID del nodo de origen, que identifica al remitente y garantiza la integridad de la comunicación.

Paquete WHOAREYOU: Si el destinatario de un paquete de mensaje ordinario tiene dificultades para descifrar o autenticar, puede enviar un paquete WHOAREYOU. Estos paquetes solicitan información adicional al remitente para confirmar su identidad y poder descifrar o autenticar correctamente el contenido del paquete. En los paquetes WHOAREYOU, la sección Authdata contiene un ID nonce (un valor aleatorio) y el número **Seq** del nodo solicitante, ambos son esenciales para verificar la identidad.

Paquete de mensaje handshake: Después de enviar un paquete WHOAREYOU, los paquetes de mensajes handshake se utilizan para establecer una nueva sesión entre nodos y transmitir de manera segura tanto los datos relacionados con el handshake como el mensaje original, que está cifrado y autenticado. Estos paquetes de mensajes handshake contienen la sección Authdata, que consta de un componente authdata-head de tamaño fijo, una firma ID, una clave pública temporal y, si es necesario, un registro de nodo opcional. En conjunto, estos componentes garantizan una conexión segura y autenticada entre los nodos.

Ahora que hemos abordado los diferentes tipos de mensajes y paquetes, es importante comprender cómo los nodos se retransmiten los paquetes entre sí.

Comunicación UDP

En el artículo anterior mencionamos que un protocolo es un conjunto de reglas utilizado para enviar y recibir datos a través de una red. En el caso específico del protocolo Discv5, se utiliza el Protocolo de Datagramas de Usuario (UDP) para transmitir paquetes entre nodos. UDP es una opción simple y eficiente para enviar datos sin requerir una conexión dedicada, lo que lo convierte en una elección ideal para aplicaciones que requieren tiempos de respuesta rápidos, como juegos online o transmisión de contenidos.

Para situarnos mejor, vamos a explicar brevemente cómo funciona el protocolo de Internet. El Protocolo de Internet (IP) es la base del conjunto de protocolos de Internet y desempeña un papel importante en el movimiento de datos a través de las redes de todo el mundo. Funciona dando una dirección IP única a cada dispositivo para que puedan intercambiar paquetes de datos. UDP y otro protocolo llamado Protocolo de Control de Transmisión (TCP) se construyen sobre IP, proporcionando diferentes características para la transmisión de datos. IP se utiliza ampliamente en muchas aplicaciones, desde la navegación web y los servicios de correo electrónico hasta la transferencia de archivos y el streaming, por lo que es una parte clave de la estructura moderna de Internet.

UDP se basa en la velocidad y la simplicidad, mientras que TCP se centra en transferencias de datos fiables y orientadas a la conexión. Con TCP, los dispositivos crean primero una conexión dedicada antes de intercambiar datos, lo que garantiza que los paquetes de datos se entreguen de forma fiable. Sin embargo, esta fiabilidad adicional puede provocar tiempos de respuesta más lentos y una mayor sobrecarga de procesamiento.

En el proceso de descubrimiento de nodos de Ethereum, cuyo objetivo es encontrar y comunicarse rápidamente con otros nodos de la red, UDP es una mejor opción. Aunque no garantiza siempre la entrega de los paquetes de datos ni una transmisión de datos fiable, la velocidad y simplicidad de UDP lo hacen más idóneo para este propósito.

A continuación, se presentan los puntos clave sobre la comunicación UDP en Discv5, en la cual los nodos confían para lograr una comunicación eficiente y fiable:

Límites de tamaño de paquetes: Discv5 establece límites máximos y mínimos para el tamaño de los paquetes, con el objetivo de asegurar una comunicación eficiente y fiable. El protocolo ha sido diseñado para manejar la mayoría de los mensajes dentro de estos límites, evitando así transferencias de datos excesivas que podrían ralentizar la red o resultar en la pérdida de paquetes.

Tiempos de espera reducidos: La baja latencia en la comunicación es fundamental para mantener una red eficiente. Por esta razón, las interacciones de solicitud y respuesta están diseñadas con tiempos de espera cortos, garantizando una comunicación rápida y fluida entre los nodos. Estos tiempos de espera evitan que los nodos queden esperando indefinidamente una respuesta y les permiten adaptarse a las condiciones cambiantes de la red de manera oportuna.

Destino de la respuesta: Cuando un nodo envía una respuesta a una solicitud, ésta se devuelve a la dirección del solicitante original, asegurando así el cierre adecuado del bucle de comunicación. Esta práctica contribuye a mantener la integridad del proceso de comunicación y permite que los nodos lleven un registro de sus interacciones con otros nodos de la red.

Proceso de arranque

Cuando un nodo se inicia por primera vez, se carga previamente con una lista de registros conocidos (ENR). Estos registros proporcionan al nodo un conjunto inicial de nodos a los que puede conectarse dentro de la red Ethereum, lo que sirve como punto de partida para descubrir pares adicionales. Para iniciar el proceso de descubrimiento de nodos, el nodo envía un mensaje PING a estos nodos conocidos para comprobar su estado y disponibilidad.

El mensaje PING es un método liviano que ayuda a determinar si un nodo está activo y accesible, contribuyendo a establecer una topología de red eficiente. Es importante tener en cuenta que los nodos de la lista precargada pueden no estar siempre en línea o disponibles, por lo tanto, el proceso de descubrimiento es esencial para mantener una red fiable y actualizada.

Antes de que los nodos puedan comunicarse de forma segura a través del protocolo Discv5, es necesario que establezcan un conjunto compartido de claves de sesión. Esto se logra mediante un proceso llamado “handshake” que involucra un protocolo de acuerdo de claves autenticadas basado en criptografía de curva elíptica. El handshake consiste en una serie de pasos que los nodos siguen para confirmar la identidad del otro y crear las claves criptográficas necesarias para una comunicación segura. Este proceso es fundamental en Discv5, ya que previene el acceso no autorizado a los mensajes intercambiados entre los nodos, protege la información sensible y garantiza la fiabilidad de la comunicación.

En la siguiente sección, se detallarán los aspectos del mecanismo del ‘handshake’ (apretón de manos) explicando cada paso y su importancia para mantener una comunicación segura.

Mechanismo handshake

Antes de que dos nodos puedan comunicarse, es necesario establecer una sesión segura para el intercambio de información. Este proceso asegura la confianza mutua entre los nodos, garantizando una comunicación segura y la verificación de sus identidades. Este procedimiento adquiere una importancia especial en las redes descentralizadas, donde los nodos deben establecer la confianza sin depender de una autoridad central.

Iniciación del handshake

Supongamos que el Nodo A desea comunicarse con el Nodo B, por ejemplo, para enviar un mensaje FINDNODE. En primer lugar, el Nodo A verifica si ya posee las claves de sesión de interacciones previas. Si las tiene, el Nodo A encripta su solicitud con esas claves. En caso contrario, el Nodo A inicia un handshake enviando un paquete de mensajes con contenido aleatorio. Este mensaje sirve como señal para que el Nodo B comprenda la necesidad de establecer una nueva sesión de comunicación segura.

En respuesta, el Nodo B envía un desafío (challenge) en forma de paquete WHOAREYOU, el cual incluye un valor único denominado ID nonce y, si está disponible, el número de secuencia del registro del Nodo A. El valor nonce ayuda al Nodo A a rastrear el desafío hasta el paquete de solicitud inicial, mientras que el número de secuencia permite al Nodo A determinar si debe enviar un registro actualizado al Nodo B.

Responder al desafío

Al recibir el desafío, el Nodo A confirma la disponibilidad y actividad del Nodo B para participar en el handshake. Seguidamente, el Nodo A reenvía la solicitud inicial como un paquete de el handshake que consta de tres partes: una firma de ID, una clave pública temporal y, si es necesario, su registro de nodo.

La firma ID se genera con el propósito de demostrar que el Nodo A tiene el control de la clave privada asociada a su registro de nodo. Esta firma evita la repetición del handshake, asegurando que cada handshake sea único y seguro.

El Nodo A genera la clave pública temporal como parte del protocolo de claves Diffie-Hellman, un método criptográfico que permite a dos partes establecer un secreto compartido a través de un canal inseguro. Esta clave temporal será utilizada por ambos nodos para derivar las claves de sesión compartidas y asegurar una comunicación segura.

Derivación de claves de sesión

El Nodo A y el Nodo B derivan nuevas claves de sesión utilizando un acuerdo de claves Diffie-Hellman y la función de derivación de claves HKDF. Este método, conocido como HKDF, permite extraer y ampliar claves criptográficas. Durante este proceso, el Nodo A genera una clave privada temporal y su correspondiente clave pública, mientras que el Nodo B utiliza su clave privada estática. La combinación de estas claves permite a ambos nodos crear un secreto compartido que servirá como base para las claves de sesión.

Las claves de sesión se dividen en claves del iniciador y del receptor, asegurando que cada nodo disponga de una clave única para cifrar y descifrar los mensajes. Esto aumenta la seguridad de la comunicación al prevenir el acceso no autorizado a la información intercambiada.

Finalizar el handshake

El Nodo B recibe el paquete de mensajes de enlace y verifica la firma ID utilizando la clave pública del Nodo A. Después de la verificación, el Nodo B intenta descifrar y autenticar el mensaje utilizando las claves de sesión recién obtenidas. Si el descifrado y la autenticación son exitosos, el Nodo B considera válidas las nuevas claves de sesión y responde al mensaje, por ejemplo, con un mensaje NODES.

A continuación, el Nodo A recibe el mensaje de respuesta y lo autentica/desencripta utilizando las nuevas claves de sesión. Si este proceso tiene éxito, ambos nodos habrán verificado la identidad del otro y podrán comunicarse de forma segura utilizando las claves de sesión establecidas.

Este proceso es crucial para mantener sesiones de comunicación seguras entre nodos en redes descentralizadas. Permite a los nodos verificar la identidad de los demás, establecer confianza y garantizar un intercambio de información más seguro y confiable, incluso en ausencia de una autoridad central.

Seguir leyendo

En este artículo hemos abordado ciertos aspectos clave de la comunicación entre nodos de Discv5, como los mensajes, los paquetes y el protocolo UDP para un intercambio de datos eficaz y fiable. También hemos hablado de cómo se inicia el proceso para que los nuevos nodos se unan a la red y del mecanismo de handshake seguro que garantiza la integridad y seguridad de la red.

En el último artículo hablaremos de cómo se estructuran los “topics”, del papel que desempeñan en la mejora del proceso de descubrimiento y de cómo los nodos gestionan sus suscripciones.

A Pier Two le encantaría conocer tu opinión sobre esta serie o responder cualquier pregunta que tengas. No dudes en compartir tus comentarios o contactar a través de redes sociales. Si estás interesado en contribuir a la implementación en C# de Discv5, visita el repositorio de GitHub para obtener más información. Aquí tienes el enlace al ultimo articulo de la serie.

Si buscas más recursos sobre Ethereum o la tecnología blockchain, puedes consultar la lista proporcionada en el primer artículo de la serie.