Serie explicativa sobre Discv5: #3

En este último artículo, se explica el concepto de tópicos, que permiten a los nodos agrupar información relacionada y facilitar que otros nodos la encuentren y se suscriban a ella.

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

En nuestros artículos anteriores, te presentamos el protocolo Discv5, abordando temas como la identidad del nodo, la gestión de registros y la comunicación. Sin embargo, para comprender plenamente el protocolo, es importante adentrarse más en el papel de los tópicos (‘topics’, léase temas o asuntos) en la mejora del proceso de descubrimiento. Los tópicos proporcionan una forma para que los nodos agrupen información relacionada y faciliten a otros nodos encontrar y suscribirse a esa información. En este artículo, explicaremos los tópicos en detalle, discutiendo su origen, cómo los nodos los gestionan utilizando el registro y la cola, y cómo se anuncian a través de la red. Al final del blog, tendrás una comprensión completa del protocolo Discv5 y cómo funciona en la práctica.

Contexto

En una red peer-to-peer como Ethereum, es común que los nodos necesiten encontrar y conectarse con otros nodos que ofrezcan servicios específicos o compartan intereses similares. Esto es crucial para mantener la red funcionando correctamente y permitir tareas como la validación de transacciones, el intercambio de datos de la blockchain y la ejecución de contratos inteligentes. Con el fin de facilitar este proceso, Discv5 emplea tópicos, que son strings (cadenas de texto) simples que actúan como identificadores de los servicios o intereses que un nodo ofrece. Estos tópicos proporcionan una forma clara y estandarizada de describir las capacidades de un nodo, lo cual simplifica la búsqueda y la interacción con otros nodos.

Cuando un nodo se hace visible bajo un tópico específico, se dice que coloca un anuncio para sí mismo. Dependiendo de las necesidades de la aplicación, un nodo puede anunciar varios tópicos, un solo tópico o incluso no anunciar ningún tópico. Todos los nodos que participan en el protocolo de descubrimiento Discv5 actúan como intermediarios publicitarios. Esto significa que aceptan anuncios de tópicos de otros nodos y los devuelven después a los nodos que buscan el mismo tópico. Al organizar diversos servicios e intereses, los tópicos mejoran la eficacia de la búsqueda y la conexión con otros nodos de la red, lo que en última instancia favorece el rendimiento y la solidez generales del sistema.

Ahora veremos cómo se almacenan y gestionan estos tópicos dentro del protocolo Discv5.

Tópicos y gestión

Tabla y cola de tópicos

En el núcleo de los tópicos en Discv5 se encuentra la tabla de tópicos, una estructura de datos que almacena anuncios para una amplia gama de tópicos. Cada entrada en la tabla está asociada con su propia lista de anuncios, conocida como cola de tópicos. Como su nombre indica, las colas de tópicos operan bajo el principio FIFO (primero en entrar, primero en salir) con una longitud limitada. Esto garantiza que los anuncios más antiguos se eliminen para dar cabida a los nuevos cuando la cola alcanza su capacidad máxima.

Para comprender mejor este concepto, imaginemos una tabla que contiene tres colas de tópicos diferentes: T1, T2 y T3. La cola de tópicos T1 se encuentra actualmente llena y no puede aceptar más anuncios hasta que se eliminen los antiguos para liberar espacio. Por otro lado, las colas de tópicos T2 y T3 tienen diferentes niveles de capacidad disponibles para acomodar nuevos anuncios.

Cuando se añade un nuevo anuncio a una cola de tópicos, se coloca al final de la cola. A medida que se van retirando los anuncios según su antigüedad, el más antiguo se elimina del principio de la cola, permitiendo que los anuncios siguientes asciendan en orden. Este mecanismo FIFO garantiza que cada anuncio tenga una oportunidad justa de ser descubierto y utilizado por los nodos que buscan servicios o intereses relacionados con un tópico específico.

Al organizar los anuncios de esta manera, la tabla de tópicos no sólo mantiene un sistema eficiente de almacenamiento y gestión de anuncios de tópicos, sino que también proporciona un método estandarizado para que los nodos busquen y descubran servicios ofrecidos por sus pares (nodos conectados) en la red.

Sistema de tickets

En Discv5, se ha implantado un sistema de tickets para gestionar eficazmente las inscripciones de anuncios. Los anuncios se colocan en una cola y permanecen en ella durante un periodo fijo de 15 minutos. Este sistema garantiza que los anuncios tengan la misma exposición y ayuda a mantener un proceso de publicación justo.

Cuando un nodo quiere poner un anuncio, tiene que esperar un tiempo determinado antes de que el anuncio sea aceptado. Este tiempo de espera depende de la disponibilidad de slots en la tabla de anuncios y en la cola de tópicos. Para más contexto, un slot es una posición en la tabla de anuncios en la que puede mostrarse un anuncio. Para controlar este tiempo de espera, el nodo recibe un ticket que indica cuánto tiempo debe esperar antes de que su anuncio sea aprobado. El nodo debe conservar este ticket y presentarlo una vez transcurrido el tiempo de espera.

El tiempo de espera para el registro de anuncios se determina según las siguientes reglas:

Si la tabla de anuncios está completa, el nodo deberá esperar hasta que haya un slot disponible en función del tiempo restante de vida del anuncio más antiguo. De esta manera, se garantiza que los anuncios sean reemplazados a tiempo y se brindan oportunidades equitativas para los nuevos anuncios.

Si la cola de tópicos está llena, el tiempo de espera del nodo se calcula restando el tiempo de vida del anuncio deseado al tiempo de vida del anuncio más antiguo en la cola. Esto contribuye a mantener un equilibrio entre los distintos tópicos y evita que un único tópico domine la cola.

Si hay slots disponibles tanto en la tabla como en la cola de tópicos, el anuncio puede colocarse de inmediato sin necesidad de esperar.

Los tickets son emitidos por los nodos y contienen información esencial para garantizar el correcto registro de los anuncios. Estos tickets cumplen varios propósitos: en primer lugar, confirman que el nodo que solicita el ticket es el mismo que intenta utilizarlo, lo que asegura un proceso justo para todos los participantes. Además, validan que el ticket se aplica únicamente a un tópico, evitando su uso indebido para múltiples anuncios o tópicos. Asimismo, los tickets solo pueden utilizarse dentro de un periodo de registro, lo que garantiza que los anuncios se coloquen en el momento oportuno. Por último, los tickets son de un solo uso, lo que evita cualquier ventaja injusta o exposición repetida a anuncios.

Con el fin de aumentar la seguridad y proteger la información contenida en los tickets, detalles como el tiempo de espera y el ID del nodo pueden cifrarse mediante una clave secreta. Al emplear este método, se garantiza que solo el nodo previsto pueda acceder al ticket y utilizarlo para el registro de anuncios.

Protocolo de anuncios

Veamos algunos mensajes de un artículo anterior para explicar cómo funciona el proceso de anuncio de tópicos en Discv5. El protocolo de anuncios en Discv5 es un mecanismo que permite a los nodos descubrir y conectarse con otros interesados en los mismos tópicos. Utilizaremos un ejemplo de la sección teórica de la especificación oficial de Discv5 para ilustrar este proceso.

Imaginemos tres nodos: A, B y C, que interactúan entre sí. El nodo A proporciona un servicio relacionado con un tópico llamado “Transaction relayer”. Para anunciar su servicio, el Nodo A decide utilizar el Nodo C como anunciante. Mientras tanto, el Nodo B busca servicios relacionados con la retransmisión de transacciones. Ahora examinemos la interacción paso a paso entre los nodos A y C mientras trabajan juntos para anunciar el tópico:

El Nodo A inicia el registro: El Nodo A inicia el proceso de anuncio enviando un mensaje REGTOPIC al Nodo C, solicitando registrar el tópico “Transaction relayer”. En esta fase, el Nodo A no incluye tickets en el mensaje, ya que aún no ha recibido ninguno.

Nodo A -> Nodo C: REGTOPIC ["Transaction relayer", ""]

El Nodo C responde con un ticket: El Nodo C procesa la solicitud y envía un mensaje TICKET al Nodo A, proporcionando un ticket y un tiempo de espera. El ticket es un identificador que el Nodo A utilizará en posteriores interacciones con el Nodo C, mientras que el tiempo de espera indica cuánto tiempo debe esperar el Nodo A antes de pasar al siguiente paso.

Nodo C -> Nodo A: TICKET [ticket, tiempo-de-espera]

El Nodo A espera y vuelve a enviar el registro: El Nodo A espera el tiempo de espera especificado y envía un nuevo mensaje REGTOPIC al Nodo C. Esta vez, el Nodo A incluye el ticket recibido en el mensaje para verificar su identidad y demostrar que ha seguido el tiempo de espera requerido.

Nodo A -> Nodo C: REGTOPIC ["Transaction relayer", ticket]

El Nodo C envía un nuevo ticket: El Nodo C verifica el ticket y responde con otro mensaje TICKET, proporcionando un nuevo ticket y un nuevo tiempo de espera. El Nodo A almacena este nuevo ticket para que esté listo para una llamada de confirmación. Este paso es necesario para garantizar la equidad del proceso de anuncio y evitar el spam.

Nodo C -> Nodo A: TICKET [ticket, tiempo-de-espera]

El Nodo C confirma el registro: Una vez finalizado el periodo de registro, el Nodo C selecciona el Nodo A como nodo registrado para el tópico “Transaction relayer”, basándose en factores como la prioridad del ticket y las plazas disponibles. El Nodo C añade el Nodo A a su cola de tópicos y envía un mensaje REGCONFIRMATION al Nodo A para confirmar el éxito del registro del anuncio.

Nodo C -> Nodo A: REGCONFIRMATION ["Transaction relayer"]

Durante este proceso, los nodos A y C intercambian mensajes REGTOPIC, TICKET y REGCONFIRMATION, junto con tiempos de espera para gestionar el registro del anuncio. Cuando el Nodo B busque el tópico “Transaction relayer”, enviará un mensaje FINDNODE al Nodo C, que proporcionará información sobre el registro del Nodo A. Como resultado, el Nodo B puede conectarse al Nodo A y acceder al servicio deseado.

Conclusión

En esta última parte de la serie explicativa sobre Discv5, hemos detallado cómo se utilizan los tópicos para mejorar el proceso de descubrimiento en la red Ethereum y cómo los nodos gestionan sus suscripciones. Los tópicos desempeñan un papel crucial en el mantenimiento de una red dinámica y saludable, ya que permiten a los nodos encontrar y conectarse eficientemente con otros que comparten sus intereses.

Al combinar todos los componentes discutidos en los blogs anteriores, como las identidades de los nodos, las tablas de enrutamiento y los mecanismos de comunicación segura, Discv5 emerge como un protocolo potente y robusto que posibilita una comunicación peer-to-peer eficiente, segura y escalable en la red Ethereum.

Esperamos que hayas disfrutado de esta serie y que ahora conozcas mejor el protocolo Discv5. Si tienes alguna pregunta o comentario, compártelos a continuación o ponte en contacto a través de las redes sociales. Para aquellos interesados en contribuir a la implementación C# de Discv5, pueden visitar el repositorio GitHub para más información. Esperamos que hayas disfrutado de esta serie y que ahora conozcas mejor el protocolo Discv5. Si tienes alguna pregunta o comentario, compártelos a continuación o ponte en contacto a través de las redes sociales. Para aquellos interesados en contribuir a nuestra implementación C# de Discv5, pueden visitar el repositorio GitHub para más información.

Gracias por tu interés y ¡feliz aprendizaje!