Ir al contenido principal
Todas las coleccionesEOS Support Media
Resumen Bimensual de la Mesa Redonda de Operadores de Nodos [Agosto de 2023 n.º1]
Resumen Bimensual de la Mesa Redonda de Operadores de Nodos [Agosto de 2023 n.º1]

Publicado el 18 de agosto de 2023

Dario Cesaro avatar
Escrito por Dario Cesaro
Actualizado hace más de un año

Autor: Marco González
Editor: Randall Roland

Traductor: Cristhian Rincon

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 de Antelope (específicamente) para los operadores de nodos".

Las Mesas Redondas se celebran todos los miércoles. Visita el canal de Telegram para obtener información sobre cómo unirte. La EOS Network Foundation ofrece tutoriales y documentación para quienes deseen aprender los conceptos básicos del funcionamiento de un nodo EOS (y mucho más).

A continuación figura una lista de las mesas redondas incluidas en este resumen bimensual:

  • 2 de agosto: Conversación abierta sobre la actualización a 5.0

  • 9 de agosto: Presentación del plan del protocolo Leap 5.0

Busque notas y comentarios adicionales sobre la reunión en GitHub. Los vídeos están en el YT de la ENF.

2 de agosto: Conversación Abierta Sobre la Actualización a 5.0

La mesa redonda del 2 de agosto no se grabó. Lo que sigue es una conversación abierta sobre lo que puede esperarse en las semanas previas a la actualización consensuada de Antelope Leap 5.0. Dada la naturaleza crítica y el calendario deseado, es de esperar que la mesa redonda sea más formal (como en las versiones 3.0).

VISIÓN GENERAL

En las últimas semanas se ha hablado de la planificación de una actualización consensuada. En la próxima mesa redonda se espera presentar el calendario de lanzamiento.

TEMA: Conversación Abierta Sobre la Actualización a 5.0

El calendario de lanzamiento de Leap 5.0 destacará los elementos esenciales y los no esenciales. Algunas funciones parecen estar listas, mientras que otras siguen planteando dudas. Sólo un par de elementos podrían justificar el retraso del lanzamiento. La finalidad instantánea (IF) es un elemento crítico del lanzamiento. Sigue siendo el tema central de las mesas redondas de la primera fase.

Las discusiones comunitarias también deberían centrarse en:

  • alinear los líneas de tiempo (y temas relacionados)

  • reservar tiempo para la(s) primera(s) versión(es)

  • comentarios en la red de pruebas

  • esperar que la actividad aumente a medida que se acerque la versión final

Observaciones y Retroalimentación

Mientras se esperaba el anuncio de la programación, la comunidad identificó algunos puntos destacados. Michael, de EOSUSA, encabezó la lista:

  • debatir e informar sobre el estado de la actualización

  • garantizar que los entornos que utilizan la versión 3.0 se actualicen a la 5.0 con la misma facilidad (relativa) que los que ya utilizan la 4.0.

  • falta información sobre los ajustes recomendados en las cadenas Antelope

  • se ha sugerido una guía de actualización

Menciones Adicionales

Algunas otras preocupaciones incluyen:

  • Jungle Testnet

  • información sobre los cambios de configuración disponibles anteriores a las recomendaciones de la versión 4.0

  • ABIs

  • configuraciones por defecto que se remontan a entornos anteriores

  • redundancia incorporada que garantiza que 5.0 fluya hacia una solución eficaz

Clausura con un Enfoque Centrado en la Mejora de la Documentación

Aunque la ENF ha realizado un magnífico trabajo perfeccionando la documentación básica en docs.eosnetwork.com, Leap 5.0 ofrece una oportunidad única. Las actualizaciones por consenso suponen un reto debido al inmenso esfuerzo de coordinación con todas las partes (activas). Los BP deben actuar conjuntamente dentro de un plazo acordado para completar una multisig. Configurar los dispositivos es una preocupación tanto de los BP como de los operadores de nodos.

Mantener una red segura y que funcione sin problemas es el objetivo final. Otra iniciativa de la versión 5.0 es establecer un nuevo estándar para el proceso de actualización consensuado. La nueva documentación forma parte de este esfuerzo. Entre las sugerencias para la nueva documentación figuran los cambios de configuración entre versiones y la introducción de nuevas funciones (por ejemplo, un compilador optimizador). También se sugirieron notificaciones sobre configuraciones específicas de cambios preexistentes (para versiones 4.0) que faciliten la transición a la v5.0.

Una vez más, cabe esperar que la próxima mesa redonda adquiera un cariz más formal, similar al de los meses de desarrollo y lanzamiento de la versión 3.0, el producto estrella de la ENF. La combinación de velocidad y calidad de los últimos productos de la fundación (desde varias versiones 4.0 hasta ahora la 5.0) es sencillamente asombrosa.

9 DE AGOSTO: Presentación del Plan de Protocolo Leap 5.0

La mesa redonda del 9 de agosto se grabó y está disponible. La ENF compartió su plan para lanzar Leap v5.0.

VISIÓN GENERAL

Entre los principales temas tratados en la mesa redonda del 9 de agosto se incluyen:

  • finalidad instantánea (IF)

  • pruebas de repetición

  • descubrimiento peer

  • línea de tiempo

  • Redes de prueba Kylin y Jungle

  • hitos previstos

  • transacciones diferidas

TEMA: Presentación del Plan de Protocolo Leap 5.0

Aunque las fechas pueden cambiar, el calendario presentado en la mesa redonda del 9 de agosto representa el orden de operaciones para el lanzamiento de Leap v5.0.

El primer hito importante está previsto para mediados de septiembre con la versión candidata (5.0.0-rc1). Hay varias tareas que deben completarse antes de recibir el visto bueno de los BP. Entre ellas figuran:

  • pruebas en las redes de testnet Jungle y Kylin

  • una versión estable

  • acordar una fecha para multisig

La decisión de "sí" o "no" depende de la activación de los BP. Esta convocatoria está prevista (provisionalmente) para finales de noviembre o principios de diciembre. El contrato del sistema debe actualizarse antes de permitir la finalidad instantánea. Desde la activación hasta el despliegue, IF espera tardar aproximadamente una semana. Con suerte, IF estará funcionando en EOS a principios de diciembre.

Los Debates Comunitarios se centrarán en el Plan (Lanzamiento) del Protocolo Leap 5

La comunidad espera liderar los futuros debates sobre programación. Es poco probable que el descubrimiento de pares y las transacciones de sólo lectura retrasen Leap v5.0. Para septiembre, el equipo espera tener una fecha de lanzamiento firme y semifirme.

Más allá del SI, la prueba de repetición es la otra característica que podría alterar significativamente el plan de lanzamiento (véase la mesa redonda del 2 de agosto).

Cortar una versión candidata: Repetición de Pruebas y Programación de la Red Testnet

En torno al minuto 7 se produce un tema de interés. La discusión se centró en el corte de una versión candidata y las pruebas de repetición. Un factor determinante será la comparación de los hashes de integridad de sucesivas instantáneas más repeticiones de bloques. Tenga en cuenta que la actualización a Leap v5.0 no necesitará una resincronización del registro de bloques.

Sigue habiendo problemas para realizar una repetición completa de Génesis. Micheal, de EOSUSA, mencionó los problemas de regresión (ya solucionados) y el tiempo que queda hasta su finalización. El equipo de desarrollo sigue centrado en lanzar la versión 5.0 con una repetición del registro de bloques. Investigar las repeticiones de Génesis es algo que el equipo tiene en mente para una futura actualización.

Otra discusión enérgica comenzó cuando se mencionó la red testnet de Kylin. Mathew, de EOS Nation, recomendó que Kylin no se ejecutara en paralelo con la red testnet de Jungle. Lo que siguió fue un cambio de programación que mantuvo las fechas objetivo para incluir una ejecución de Kylin a mediados de octubre. Las pruebas deben completarse antes del lanzamiento estable previsto de Leap v5.0.0 antes de noviembre.

Cierre con Operaciones Diferidas

Las transacciones diferidas han quedado obsoletas. Lo ideal sería eliminarlas para la v5.0. Si las transacciones diferidas permanecen en la v5.0, es posible que persistan un año más. Se desconoce si algún contrato depende de ellas.

Se están estudiando dos decisiones para eliminar las transacciones diferidas. La primera solución permite dar marcha atrás. Sin embargo, su aplicación llevaría mucho tiempo. La otra opción, más razonable, consiste en que los BP realicen una prueba que desactive brevemente la función. A continuación, los comentarios de la comunidad podrían determinar el destino de las transacciones diferidas. No se conoce ningún proyecto que dependa de las transacciones diferidas.

La semana que viene, el debate volverá a centrarse en el lanzamiento de Antelope Leap v5.0.


Fuentes y Referencias

¿Ha quedado contestada tu pregunta?