Autor: Markus Hinrichs
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 hablar sobre la red y su desarrollo. El objetivo principal de cada Mesa Redonda de Operadores de Nodo es:
"...mejorar el protocolo Antelope (específicamente) para los operadores de nodos".
Mesas redondas ocurren todos los miércoles. Visita el canal de Telegram para obtener información sobre cómo unirse. La Fundación EOS Network proporciona tutoriales y documentación para aquellos que quieran aprender los conceptos básicos del funcionamiento de un nodo EOS.
A continuación se muestra una lista de las mesas redondas contenidas en este resumen bimensual:
18 de octubre: configuración de CPU mejorada, debate sobre la función de bloques iniciales, configuración simplificada en toda la red y más
25 de octubre: Deseos y aspiraciones para el formato de llamada del operador de nodo, últimos hitos para llegar a RC3
Asegúrese de buscar las notas de reuniones adicionales y comentarios en GitHub. Los vídeos residen en el Youtube de la ENF.
18 de octubre: Leap 5.0 en camino: Bloques iniciales, Mejoras de Rendimiento y Aportes de la Comunidad
Lanzamiento de Leap 5.0 y pruebas:
La reunión comenzó con una discusión exhaustiva sobre el lanzamiento de Leap 5.0.
Se recomendó encarecidamente a los miembros de la comunidad que participaran activamente en las pruebas de la versión candidata, RC2, con el objetivo principal de identificar y abordar cualquier problema antes de la versión estable oficial.
Cambios en la Opción de Porcentaje de Esfuerzo de CPU:
Se introdujo un cambio significativo con respecto a la opción de porcentaje de esfuerzo de la CPU.
La propuesta implicó pasar del uso de valores porcentuales a configurar el esfuerzo de la CPU en milisegundos.
Las opciones existentes, como el porcentaje de esfuerzo de la CPU, el esfuerzo de la CPU del último bloque, el desplazamiento del último bloque y las versiones del último bloque, debían ser reemplazadas por una nueva opción denominada "desplazamiento en ms al producir bloques".
Detalles de la nueva opción "desplazamiento en ms al producir bloques":
La opción "desplazamiento en ms al producir bloques" recientemente introducida otorga a los operadores de nodos la capacidad de especificar la cantidad de milisegundos que desean asignar para toda la ronda, que consta de 12 bloques.
Esta compensación juega un papel crucial en la determinación del tiempo asignado para manejar la latencia de producción de bloques.
Es importante destacar que se aclaró que este cambio no afectaría el mecanismo de consenso y fue diseñado específicamente para mejorar la eficiencia de la producción de bloques.
Producción y pruebas tempranas de bloques:
Las discusiones posteriores giraron en torno a la introducción de la producción temprana de bloques en Leap 5.0.
Michael, EOSUSA, presentó el concepto de alterar la configuración del reloj del sistema, lo que generó preocupaciones sobre posibles problemas y consecuencias no deseadas.
Se expresaron preocupaciones sobre cómo la producción temprana de bloques podría afectar a la red y si podría provocar bifurcaciones u otras complicaciones.
Rendimiento en pruebas de laboratorio:
Kevin Heifner expresó su entusiasmo por las posibles mejoras de rendimiento que se lograrían con la producción temprana de bloques.
La discusión destacó cómo la producción temprana de bloques permite más tiempo para que las transacciones se incluyan en los bloques, lo que en última instancia beneficia la eficiencia de la red.
El OC (compilador optimizado) de EOS VM fue reconocido como un importante mejorador del rendimiento, especialmente para las DApps y contratos de EOSIO.
Se llamó la atención sobre la probabilidad de que una mayor carga se transfiera a soluciones históricas para manejar el aumento del rendimiento.
"Hay un montón de mejoras de rendimiento desde los 1.8 días hasta donde estamos hoy, como si fuera un motor mucho más afinado y, por lo tanto, realmente debería poder manejar la carga" Kevin Heifner, OCI
Configuración de "desplazamiento en ms al producir bloques" y valores predeterminados:
La conversación giró hacia la configuración de "desplazamiento en ms al producir bloques" y sugirió valores predeterminados.
Se propuso un valor predeterminado de 450 milisegundos para el "desplazamiento en ms al producir bloques", y las discusiones enfatizaron la importancia de la configuración predeterminada para influir en el comportamiento del nodo.
Se destacó la flexibilidad como un factor clave que permite a los operadores adaptar la configuración para alinearse con las condiciones específicas de su red.
Bloques tardíos y sincronización de reloj:
Se abordó la cuestión de los bloques tardíos y su gestión en el contexto de la producción de bloques tempranos.
Se consideraron el impacto potencial de la sincronización del reloj y la latencia de la red en los bloques tardíos.
Kevin aclaró que los bloqueos tardíos podrían dar lugar a micro forks y se exploró el papel de la sincronización del reloj en este contexto.
Configuración del “Tiempo máximo de transacción” y el “Tiempo de ventana de lectura de solo lectura”:
La discusión abarcó la configuración del “Tiempo máximo de transacción” y los posibles cambios.
Kevin Heifner recomendó una configuración predeterminada "cercana a los 500 milisegundos”
Se destacó la importancia de configurar los ajustes para “Tiempo de ventana de lectura de solo lectura”, enfatizando la optimización de la red para mejorar el rendimiento.
Se sugirió que los operadores de nodos individuales deberían establecer estos valores en función de sus casos de uso específicos.
Aplicación a través del consenso en cadena:
El concepto de controlar la configuración mediante consenso en cadena se introdujo como un medio para simplificar los cambios de configuración en toda la red.
"... ahora los BP pueden controlar toda la red mediante un consenso" Kevin Heifner
Discusión sobre PR para etiquetar pares Peer-to-Peer:
Se mencionó brevemente una pull request pendiente relacionada con el etiquetado de pares peer-to-peer.
Debido a limitaciones de tiempo y a la ausencia del miembro crucial del equipo, Matthew Darwin, se pospuso una discusión detallada sobre este tema para una reunión futura.
La reunión concluyó con un llamado a la comunidad para que pruebe activamente Leap 5.0 rc2 y brinde comentarios para garantizar una transición fluida a la versión estable.
25 de octubre: Deseos y Aspiraciones para el Formato de Llamadas de Operadores de Nodos, Últimos Hitos para Llegar a RC3
Tema principal: Cómo Continuar la Mesa Redonda de Operadores de Nodos
Perspectivas y compromiso:
Ross de EOS Sphere agradeció los comentarios del equipo técnico.
Shaq enfatizó la necesidad de información y conocimientos técnicos de Leap.
Michael de EOSUSA reconoció el impacto de la colaboración en la maduración del software.
Kevin Heifner, OCI, enfatizó la importancia de la retroalimentación de los operadores de nodos.
Deseos de reuniones futuras:
Discusión sobre la inclusión de documentación en futuras convocatorias.
Tipos de documentación destacados, incluidos protocolos, operadores de nodos y documentos de desarrollador.
Consideración de características en evolución y cambios potenciales.
Requiere una exploración más profunda de las próximas funciones.
Formatos de reunión:
Se debatió la idea de realizar diferentes convocatorias para temas específicos y los participantes consideraron si serían valiosas las convocatorias ad hoc o de corta duración.
Surgieron preocupaciones de que un cambio a formatos más amplios podría convertir inadvertidamente estas llamadas en reuniones centradas en los desarrolladores, lo que provocaría que los operadores de nodos se desconectaran.
Selección de asistentes:
Los participantes expresaron su deseo de que los desarrolladores de peso (por ejemplo, Nathan James) se unan ocasionalmente a estas llamadas. Se propuso la idea de un intercambio bidireccional, llevando a Kevin Heifner a las reuniones de desarrolladores y aprovechando la experiencia de Nathan para la documentación y la orientación.
Se propuso el “equipo de ensueño” de participantes que incluiría a Kevin Heifner, Nathan James y contribuyentes habituales (Michael EOSUSA, Ross (EOS Sphere), Matthew Darwin). También podrían incluirse los operadores de nodos con gran infraestructura, Aaron Cox (Greymass) y especialistas en L2 como Stan de EOS Amsterdam.
Frecuencia de reuniones:
Se inclinan por mantener un horario semanal.
Duración de la reunión:
Sugerencia para mantener las reuniones constantes en una hora.
Consideración de ampliar el debate para debates en profundidad.
Horarios alternativos de reunión:
El desafío de alterar rutinas y fragmentar la participación.
Propuestas de convocatorias adicionales en diferentes horarios.
Mejoras en la agenda:
Agenda flexible sugerida con actualizaciones de estado y temas principales.
Evaluación de notas de la reunión:
Discusión sobre la adecuación de las notas de las reuniones.
Se recomienda buscar comentarios de personas ausentes.
Grabaciones de reuniones:
No hay preocupaciones sobre la grabación de reuniones.
Notas y transcripciones generadas por IA:
Se agradecen las notas generadas por IA, sujetas a la grabación activa.
Aumentar la asistencia:
El tema final se refería al aumento de la asistencia, con la sugerencia de involucrar activamente a los no asistentes para ampliar la participación en estas valiosas discusiones.
Elementos que Giran en Torno a los Hitos Relacionados con la Actualización de Leap RC2 → RC3
Se centró la atención en la disponibilidad de la CPU para la firma de transacciones, con una referencia específica a un parámetro de configuración, el "desplazamiento en ms al producir bloques", y estrategias para optimizarlo para obtener el máximo rendimiento.
Se describieron los hitos, centrándose en solucionar problemas para la próxima versión candidata.
Se discutieron algunos problemas críticos, incluidas las pruebas BLS que fallan en compilaciones ARM, y se está trabajando para abordarlos.
Parámetros de Configuración:
La configuración saludable para el parámetro "desplazamiento en ms al producir bloques" fue un tema importante; Ross planteó la pregunta y Kevin intervino con una explicación detallada de cómo se mejora esto en la próxima versión.
RC2 tenía un valor predeterminado del 90% o 600 milisegundos, lo que se consideró demasiado conservador.
En la nueva versión, la nueva configuración expresaba el desplazamiento en milisegundos, lo que permitía un ajuste más preciso. Los participantes discutieron varias configuraciones y los beneficios potenciales, como un mejor procesamiento de transacciones y una latencia reducida.
"Existe un aumento potencial en la latencia para las transacciones que llegan al bloque 12, pero solo las que llegarían al último bloque, por lo que ya sabes, un poco negativo es un positivo bastante grande para todo lo demás". Kevin Heifner
La ventaja más significativa se obtiene durante los períodos de congestión de la cadena. También ayuda a manejar las transacciones fallidas de manera más efectiva al brindar tiempo adicional para su evaluación sin afectar negativamente el rendimiento general. En esencia, optimiza la utilización de la CPU.
Fuentes y referencias