Autor: Marco González

Editor: Randall Roland

Traductor: Erick Birbe

Los operadores de nodos se reúnen cada semana con los desarrolladores principales de Antelope y los miembros de la comunidad. El objetivo primordial de la Mesa Redonda de Operadores de Nodos es:

Las reuniones tienen lugar los miércoles a las 14 UTC y duran una hora.

La Mesa Redonda del 1 de Febrero exploró los parámetros de configuración actuales (Leap v3.2) y futuros. A mitad de la discusión, quedó claro que la configuración de nodos es un tema que necesita más atención.

Con el reciente lanzamiento de DUNE v1.1, Leap da otro paso adelante en su misión de hacer que el desarrollo y la operación de los nodos sean más acogedores. Tenga en cuenta que la compatibilidad con Ubuntu 18.04 se eliminará antes de las pruebas de marzo de Leap v4.0. Los desarrolladores que deseen usar Ubuntu deberán actualizar. Las versiones de Ubuntu 20.04 y 22.04 serán compatibles oficialmente.

Además, tenga en cuenta que las pruebas de marzo no implicarán una actualización de consenso. En cambio, se mencionó septiembre (durante la mesa redonda del 8 de febrero) como una posible fecha objetivo de consenso.

La configuración de nodos para propósitos especiales resulta ser un tema complejo. Se necesita nueva documentación. La documentación de Leap 3.2 espera ver mejoras para abordar las configuraciones antes de la actualización.

Los tiempos de respuesta de HTTP ocuparon una gran parte de la reunión. Hay acuerdo en que un tiempo de respuesta debe ser al menos igual al tiempo máximo de serialización. Los tiempos de respuesta se pueden establecer más altos para asegurar un saldo entrante y saliente. Por ejemplo, una solicitud HTTP falla ese tiempo de espera en bloques grandes. Atomic Hub se utilizó como ilustración.

Además, se debe considerar el exceso de datos de llamadas y la eficiencia general en el futuro. Se mencionó al principio de la discusión que se esperaba ayuda con "bibliotecas de impulso" y cambios estratégicos.

Aquí la grabación en el YT de la EOS Network Foundation.

Las notas para la configuración de nodos potenciales y las aplicaciones ocuparon gran parte de esta reunión. El tema de discusión de la próxima semana se tituló: "Nodos de Propósito Especial".

La mejor manera de configurar los nodos para necesidades específicas espera extenderse más allá incluso de la discusión de la próxima semana. Las áreas principales identificadas para mejorar incluyen:

Tenga en cuenta que los elementos (por ejemplo, aliviar la presión y la eficiencia) a menudo están interrelacionados. Los nodos de propósito especial y su clasificación tratan con conceptos abstractos. La discusión también buscará agregar claridad.

La mesa redonda sobre el 8 de febrero comenzó el proceso de clasificación de las diferentes formas en que se configuran y utilizan los nodos. Un documento de taxonomía del nodo Antelope en desarrollo llega antes de Leap v4.0 (la fecha prevista es finales de marzo en la red de prueba de Jungle). Esté atento a una actualización de Leap consensuada a partir de septiembre.

Además de las fechas objetivo de marzo y septiembre, espere un anuncio sobre la congelación del código para Leap 4.0.

Los nodos de propósito especial son un modelo conceptual de todos los posibles casos de uso. Organizar el uso y la configuración de los nodos es un tema que ha resonado entre los desarrolladores de EOS durante algún tiempo. Con la versión 4.0, los operadores de nodos están a punto de experimentar un gran salto en la optimización de la gestión diaria.

Brian Hazzard comparó el proceso de lluvia de ideas de nodos con "bloques de Lego". Como se podría discernir, los rasgos y las funciones posteriores de los nodos Antelope suelen ser abstractos. Los comentarios de la comunidad son bienvenidos. Para ver la lista actual de rasgos de nodos o clasificaciones sueltas, visite el documento guía: proyecto de taxonomía de las funciones que desempeñan los diferentes nodos Antelope.

Las clasificaciones de trabajo se enumeran en el borrador del documento. En esta mesa redonda se revisaron:

Lo que sigue es una descripción general de los tipos de nodos discutidos durante esta reunión. Se pueden encontrar más detalles en GitHub (consulte los números de la semana) y el borrador del documento de taxonomía.

Los rasgos identificados de los nodos que requieren consenso que agregan bloques a una cadena incluyen:

Las mejores prácticas de configuración incluyen:

Consulte el borrador del documento de taxonomía para futuras consideraciones.

La clasificación más básica es el nodo de retransmisión de bloque. La definición lo dice todo. La retransmisión implica mantener conexiones con pares y validar encabezados de bloque. Crédito a Stephen Diesel por comentar:

La ventaja de un nodo de retransmisión es que puede operar con más pares (10-15) que un nodo BP. Además, tenga en cuenta que si bien un nodo de retransmisión de bloques puede ser público, no debe anunciarse (por ejemplo, en bp.json).

El comentario de Stephen ilustra la necesidad de mantener un grupo de pares capaz de proporcionar constantemente bloques listos para ser retransmitidos. Mantener una canalización abierta implica no solo transacciones sincronizadas, sino también la disposición a aceptar nuevos bloques. El no poder mantener una preparación fue identificado como un contribuyente a los bloques vacíos.

Al igual que los nodos de retransmisión de bloques, un nodo de retransmisión de transacciones puede actuar únicamente para retransmitir bloques tras la validación de un encabezado. Lo que distingue al nodo de retransmisión de transacciones es la capacidad de aceptar también:

Kevin Heifner compartió un enlace a una solución en proceso para mejorar la propagación de bloques después de la validación del encabezado. Michael de EOSUSA compartió un diagrama de la configuración de su nodo (ver Mesa Redonda 8 de febrero).

Las mejores prácticas serán exploradas y detalladas en el futuro. Los tipos de nodos parecen tener tres configuraciones básicas:

Mira la grabación en el YT de EOS Network Foundation.

Las siguientes cinco clasificaciones de nodos en el borrador del documento son: