Autor: Marco González
Editor: Randall Roland
Traductor: Erick Birbe
Los Operadores de Nodos, los desarrolladores principales de Antelope y los miembros de la comunidad se reúnen cada semana para discutir las preguntas resaltantes del día. El objetivo principal de cada Mesa Redonda de Operadores de Nodos es:
“...mejorar el protocolo Antelope (específicamente) para los operadores de nodos”.
Las Reuniones tienen lugar todos los miércoles de 14 UTC a 15 UTC.
Las dos primeras Mesas Redondas de marzo continuaron la discusión sobre los Nodos Especiales, particularmente con respecto a las mejores prácticas. En marzo 1 la Mesa Redonda exploró los objetivos de BP Nodes frente a las mejores prácticas. El 8 de marzo terminó con Nodos de Retransmisión Solo de Bloque. Si está aquí por el inminente "congelamiento de código", espere un anuncio dentro de los días posteriores a la Mesa Redonda del 8 de marzo. En cuanto al lanzamiento de la red de prueba Leap 4.0.0, el equipo de desarrollo se mantiene dentro del cronograma para el objetivo de fines de marzo o principios de abril.
El 'Proyecto de taxonomía de las funciones que desempeñan los diferentes Nodos Antelope' contiene notas completas. Para explorar el comienzo de la discusión de Nodos Especiales, visite la sección titulada 'Reuniones posteriores a la actualización' en GitHub.
1 de marzo: Nodos de Propósito Especial (continuación)
Soluciones de Historial y Mejores Prácticas
Vea la Mesa Redonda del 1 de marzo en el Youtube de la ENF. Lee las notas sobre EOS Nation (Leap) GitHub.
ACTUALIZACIONES
La Mesa Redonda del 1 de marzo es la cuarta en una discusión en curso sobre Nodos de Propósito Especial. Entre los problemas se encuentran modelos de recursos más eficientes en todo el ecosistema. Eso incluye una regla de tres avisos versus necesidades de facturación subjetivas.
TEMAS CLAVE
El grupo recogió anotaciones sobre los proveedores de Historia. Los tipos de Nodos Principales que mencionan específicamente el historial en el borrador del documento incluyen:
Nodo API de Cadena
Nodo de Historial de Estado
Soluciones de Capa 2 e Historial
Las soluciones de capa 2 que mencionan la historia incluyen:
Servicio de captura de eventos: procesa la salida del Nodo Alimentador (ver proyecto de taxonomía para más info)
Servicio de Proveedor de Historial: API para clientes que solicitan datos de eventos históricos
En cuanto a la “historia del estado”, entre los temas se encuentran:
Divisibilidad
Casos de uso y soluciones
Nodos vs. herramientas externas
Estado y eventos actuales vs. históricos
Además, consulte las sugerencias de seguimiento para el historial.
La lista de tipos de nodos concluye con el Nodo Proveedor de Recursos, la tercera solución de capa 2 de la lista. Su objetivo es potenciar la experiencia del usuario. Si bien el Nodo del Proveedor de Recursos actualmente ejecuta node.js, eventualmente puede descentralizarse como un complemento de API. El documento del Proyecto de Taxonomía define el Nodo Proveedor de Recursos como:
"Acepta e interpreta transacciones de los clientes, las valida y realiza la lógica comercial para determinar si el nodo firmará conjuntamente una transacción para cubrir los costos de CPU/NET/RAM".
Mejores Prácticas
La reunión continuó con las mejores prácticas, el esfuerzo y requisitos para una configuración óptima. Un objetivo clave para las mejores prácticas incluye la identificación de mínimos en las redes de Antelope (por ejemplo, WAX, Telos...).
Probablemente habrá debates sobre las mejores prácticas, especialmente teniendo en cuenta las diferentes necesidades entre las redes. Por ejemplo, todo lo siguiente varía según la utilización de la red blockchain:
Ancho de banda de la red
CPU del dispositivo
RAM
Requisitos de disco
Requisitos del Dispositivo
Los requisitos del dispositivo tomaron la discusión sobre las mejores prácticas. Los operadores deben verificar la configuración general de los nodos al cambiar un tipo de nodo. Por ejemplo, la ejecución con arranques y paradas frente a la ininterrumpida debería volver a ajustar una CPU a las recomendaciones de AtticLabs. Ver el documento del Proyecto de Taxonomía para el enlace de AtticLabs y otros requisitos de dispositivos como ECC RAM, procesadores x86 y más.
PERSPECTIVA Y NOTAS ADICIONALES
Cerrando la Mesa Redonda hubo notas sobre las mejores prácticas de seguridad y no reutilizar claves de hardware.
Chain API Node recibió algunas palabras finales sobre las mejores prácticas de configuración de nodeos para Block Producer Nodes. Las recomendaciones incluyen:
Habilite todas las API excepto Trace API y SHIP
No use una instantánea cuando ejecute un Nodo Productor de Bloques
Verificación doble habilitada y peso para características no deseadas
La discusión del Nodo API de Cadena concluyó sobre lo que debería estar disponible (por ejemplo, simplificar con solo Getinfo, aunque Prometheus puede proporcionar una solución).
Tenga en cuenta que ciertos tipos de nodos requerirán configuraciones variables. La reunión se cierra con elementos de seguimiento adicionales (en la sección Próximos Pasos del documento Proyecto de Taxonomía).
8 de marzo: Nodos de Propósito Especial (continuación)
Prácticas recomendadas de configuración de Nodos de Retransmisión solo de Bloques
Vea la Mesa Redonda del 8 de marzo en el Youtube de la ENF. Lea las notas sobre EOS Nation (Leap) GitHub.
ACTUALIZACIONES
El equipo de Antelope informa que va por buen camino para una versión candidata de fin de mes/principios de abril. El desarrollo centrado en el futuro de Antelope Leap 4.0.0 ha concluido por el momento. Un anuncio sobre un "congelamiento de código" es inminente. Se espera que llegue una versión candidata a la versión 4.0.0 dentro de un par de semanas.
TEMAS CLAVE
La discusión inicial revisó las mejores prácticas de configuración de nodeos para Nodos Productores de Bloques. El peering es casi siempre interno. La protección de una red de nodos internos con una clave WireGuard (por ejemplo) es eficaz. WireGuard es solo una opción. Tales claves evitan conexiones inesperadas y molestas.
Los escenarios de casos de uso especiales (p. ej., resincronización) se unieron a los elementos de seguimiento en la sección “Próximos Pasos". También se aconsejó considerar el aumento de la eficiencia.
Prácticas Recomendadas de Configuración de Nodos de Retransmisión solo de Bloques
El resto de la Mesa Redonda se centró en los Nodos de Retransmisión solo de bloques y sus mejores prácticas de configuración. El grupo entró en detalles sobre el número de conexiones. En una reunión anterior, se consideraron apropiadas de 10 a 15 conexiones para el archivo de configuración. Este pequeño rango de conexión es simplemente un punto de partida.
Con respecto a Leap 3.2, es seguro maximizar las conexiones de Nodos de Retransmisión solo de Bloque entre 25 y 50. Varias notas añadidas fueron:
Muchos operadores han manejado 75 o más en algún caso
Más conexiones equivalen a una mayor probabilidad de ser "arrancado"; por ejemplo, durante una actualización
Leap 4.0 puede demostrar que maneja conexiones prácticamente ilimitadas (con respecto al hardware)
Requisitos del Dispositivo
La primera consideración mencionada para los requisitos del dispositivo de Nodo de Retransmisión solo de Bloque fue que se necesita más de uno para evitar un único punto de falla.
Gran parte del resto de la discusión se centró en la conectividad y la velocidad. Se enfatiza una conexión a Internet confiable. También un disco rápido con un fuerte enfoque de escritura. Ver otras mejores prácticas en el documento del Proyecto de Taxonomía para comentarios sobre registros de bloques completos y parciales. Tenga en cuenta que Leap 4.0 espera tener una función de conexión de Nodo Automático.
Aquí se hace una distinción importante con respecto a un concepto erróneo popular. En las cadenas Antelope, una instantánea es solo el estado actual. Eso es diferente de la definición de Ethereum. Por lo tanto, para las cadenas de Antelope, una red de pares solo necesita "suficiente" de un registro de bloque completo. No es necesario un historial completo para los relés internos en las cadenas Antelope.
PERSPECTIVAS
Mencionado a lo largo del proyecto de taxonomía la discusión es el impacto de ajustar variables fuera de las mejores prácticas. Por ejemplo, un Nodo de Retransmisión solo de Bloques puro no acepta nada más que bloques. Además, tenga en cuenta que es posible que Leap 4.0 no requiera Nodos de Retransmisión solo de Bloque.
Se espera que la Mesa Redonda de la próxima semana continúe la discusión sobre las mejores prácticas para la configuración de nodos específicos de los Nodos API.