Autor: Marco González
Editor: Randall Roland
Traductor: Cristhian Rincon
Los operadores de nodos, desarrolladores del núcleo de Antelope y miembros de la comunidad se reúnen cada semana para debatir las preguntas más cautivadoras 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 (de 13 UTC a 14 UTC durante el horario de verano). La EOS Network Foundation ofrece tutoriales y documentación para quienes deseen aprender los fundamentos del funcionamiento de un nodo EOS (y mucho más).
A continuación figura la lista de las dos mesas redondas incluidas en este resumen bimensual:
21 de junio: Documento de mejoras P2P en el que se enumeran el problema y las soluciones
28 de junio: Recorte de bloques, planificación para Leap 5.0, IF, OC
Puede encontrar más notas y comentarios sobre las reuniones en GitHub. Las grabaciones de vídeo se encuentran en el YT de la ENF.
21 de junio: Documento de Mejoras P2P en el que se Enumeran el Problema y las Soluciones
La reunión del 21 de junio continuó el debate sobre el P2P. Un documento de GitHub que respondía a algunos de los comentarios de las últimas semanas guio el debate.
Visión general
El documento orientativo define claramente el problema. La definición de una solución aceptable coincide con los comentarios anteriores.
Actualizaciones
durante la reunión se publicó el parche Leap 4.0.3
Desglose del Documento Orientativo Sobre Mejoras P2P
La página del documento guía se divide en varias secciones: el Problema, la Solución, las Cuestiones, los Recursos y los Comentarios.
Problema: Oportunidades, Público y Estrategia
Los grupos de usuarios tienen necesidades diferentes. Ahora se entienden mejor las prioridades.
El público identificado se basa en Antelope y:
"personas técnicamente competentes" (operadores de nodos) preocupadas por "soluciones fiables, rentables y simplificadas".
Para alinear el problema con el desarrollo básico, hay que centrarse en "mejorar la experiencia del usuario y la eficiencia de la infraestructura". El éxito de la implementación espera producir "una adopción más amplia y el éxito del protocolo Antelope".
Volviendo a las oportunidades de los usuarios objetivo, las principales prioridades son las siguientes:
Lo más destacado de la lista es "mejorar la selección de pares en modo catch up para los bloques disponibles".
El ancho de banda ha sido un debate habitual en las últimas semanas. La siguiente prioridad es mejorar el control del "consumo de ancho de banda de los pares". Evitar abusos y rotar automáticamente a los pares son puntos centrales.
La tercera gran prioridad es la "capacidad de etiquetar las conexiones entre pares como internas o externas". Si se tiene éxito aquí se espera resolver "los (niveles) de confianza dentro de la infraestructura interna".
Consulta el documento y/o el vídeo para ver descripciones de otros aspectos, como la interfaz de usuario basada en terminales, las listas negras de pares y la sincronización.
Definir una Solución e Identificar los Riesgos
El nombre dado a la oportunidad de producto descrita anteriormente es "P2P Improvements" (Mejoras P2P). Las cuatro métricas principales para el éxito, como se enumeran en el documento de GitHub:
Mejorar el tiempo de sincronización de un nodo nuevo o reiniciado
Reducir el número de pasos necesarios para configurar un nuevo nodo.
Mejorar la fiabilidad de las transacciones que transitan por la red P2P
Mejorar la velocidad de las transacciones que transitan por la red P2P
El proceso de identificación de riesgos se guía por un artículo (The Four Big Risks) escrito por el Silicon Valley Project Group. La pregunta formulada se centra en la RFP P2P Peer Discovery en relación con los plazos paralelos:
"¿Hay riesgo de conflicto o solapamiento?".
Vea la página de documentación para más recursos y temas.
Comentarios y Sugerencias a la Reunión
Las respuestas de los participantes incluyen:
nodos internos y cuellos de botella
la velocidad de almacenamiento es fundamental
se mencionó el bloks-log como una preocupación en relación con la lectura y los pares locales (por ejemplo, número de operaciones y sincronización)
opciones de sincronización limitadas
ancho de banda frente a alcance del estado (puede no ser un problema si hay suficiente ancho de banda y rotación de pares)
Diálogo de conclusión
La reunión concluye con preguntas aclaratorias. Se preguntó sobre el estrangulamiento (ralentización) como estrategia de gestión del ancho de banda. Según los comentarios recibidos, el estrangulamiento se considera una opción frente a la desconexión de pares.
El equipo de desarrollo invita a los operadores de nodos a ayudar a dirigir el curso de los próximos pasos. Se llamó la atención sobre la sección de desglose de tareas ("Características/Epics") de la página del documento. Aquí se mencionan el ancho de banda y los mecanismos de control.
28 de junio: Recorte de bloques, planificación para Leap 5.0, IF, OC
En la reunión del 28 de junio se identificó el recorte de bloques como un área a mejorar. La planificación de Leap 5.0 incluye tiempo de preparación, nuevas normas, IF, OC y más.
Vista general
Los operadores de nodos compartieron su experiencia con el actual proceso de recorte de bloques. Se habló de diagnóstico, automatización y más tipos de soluciones. En el último tercio de la reunión se habló de la planificación y los preparativos de Leap 5.0.
Actualizaciones
no hay novedades sobre Leap 4.0
el equipo de desarrollo sigue trabajando en un calendario provisional para la versión candidata 5.0
Más información sobre Leap 5.0 en una sección posterior.
Inquietudes de la Comunidad
Se abrió el turno de palabra para escuchar las preocupaciones que rondan por la mente de la comunidad. El debate se inició en torno al recorte de bloques y las diferencias entre las expectativas de la versión 4.0.3 y la 5.0. El interés por el recorte de bloques fue inmediato. El recorte de bloques suscitó un interés inmediato. El uso de la utilidad leap para recortar una solución para una excepción bloks-log suscitó varios comentarios. La necesidad de ampliar el recorte a varios cientos de bloques parece mejorable. Los recortes más pequeños que pueden identificar los errores (excepciones) son una característica atractiva a añadir.
Temas Discutidos en Mayor Profundidad
Dos temas parecieron resonar en el discurso de apertura:
formato y contenido de leap-util (por ejemplo, prueba de humo)
necesidad de hacer retroceder bloks-log
A continuación figura una lista de los puntos concretos mencionados. Los puntos de la lista siguen un orden cronológico y lógico general, tal como se registraron en la reunión:
visualización frente a funcionalidad
posibles mejoras para un recorte mínimo
garantizar una solución segura
sugerencia de añadir recortes sucesivos (uno a uno)
una herramienta de diagnóstico del recorte podría determinar los bloques corruptos
solución de auto-reparación que tenga cuidado de no auto-eliminar bloques
soluciones para nodos públicos frente a privados
la solución completa a través de una instantánea remite a las precauciones relativas a los nodos públicos frente a los privados
La comunidad parece querer herramientas de diagnóstico y recuperación más sencillas. Para más detalles, visite leap-util is unable to successfully run a detailed smoke test and trim the blocklog. #1348.
PLANIFICACIÓN PARA LEAP 5.0
Como ya se ha mencionado, ha comenzado la planificación de una versión candidata de Leap 5.0. El equipo de desarrollo trabaja para mitigar el largo y complicado proceso que supone una actualización consensuada. Leap 5.0 establecerá un procedimiento estándar. Se necesitan un par de meses para preparar a la comunidad. Los planes se centran en una versión previa a las vacaciones, con lo que el despliegue comenzaría en septiembre.
Se espera que Leap tenga dos versiones importantes al año. Una de ellas requerirá probablemente una actualización de consenso. La reducción de los costes de explotación de los nodos es una de las principales preocupaciones. Esto incluye la reducción de costes para los operadores de nodos al añadir nuevas cadenas. Se hicieron comentarios sobre los beneficios de la experiencia y la optimización (RAM, CPU y espacio en disco). Se hizo hincapié en la importancia de que más personas se actualicen a la versión 4.0.
Dos de las principales funciones de actualización del protocolo para 5.0 son:
Finalidad instantánea (IF)
Funciones de optimización del compilador (OC)
La IF parece ser el punto decisivo de los dos. La IF sigue siendo una iniciativa clave del plan inicial de la ENF para el nuevo EOS. Las características de la OC son ventajas de rendimiento destinadas principalmente a mejorar la EVM. Sin embargo, hay beneficios generales de OC que incluyen a los productores. Vea Add eos-vm-oc-enable auto mode #1322 para más información.
En paralelo se están desarrollando otros elementos, previstos en futuras versiones para no retrasar la 5.0.
Diálogo de conclusión
La reunión concluye con un examen de las características de la OC para la 5.0. El desarrollo actual se centra en las mejoras fundamentales. La OC debería funcionar primero con contratos del sistema eosio (por ejemplo, para tokens y EOS EVM) antes que las demás características mencionadas. Las nuevas características y la preparación de Leap 5.0 seguirán siendo probablemente el centro de atención de futuras reuniones.