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 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 una lista de las mesas redondas incluidas en este resumen bimensual:
19 de julio: Cambios de Configuración Recomendados por la ENF para la Versión 5.0
26 de julio: Cancelado
Busque notas y comentarios adicionales sobre la reunión en GitHub. Los vídeos están en el YT de la ENF.
19 de julio: Cambios de Configuración Recomendados por la ENF para la Versión 5.0
La mesa redonda del 19 de julio puede ser el momento en que la comunidad de operadores de nodos cambie su enfoque de Antelope v4.0 a v5.0. Las medidas adoptadas para preparar el despliegue de la 5.0 probablemente comiencen con los cambios de configuración de la ENF discutidos en la reunión de hoy.
VISIÓN GENERAL
Eric Passmore publicó notas en Telegram que resumen las recomendaciones de la ENF para los cambios de configuración de nodeos. Los puntos principales de las notas se enumeran en la siguiente sección.
Eric comenzó llamando la atención sobre lo mucho que ha cambiado desde que B1 lanzó la versión 2.0. Cambiar la configuración tiene sentido a muchos niveles. Aun así, la ENF basa sus recomendaciones tanto en pruebas de rendimiento como en datos empíricos.
TEMA: Recomendaciones Publicadas del Canal de Telegram de los Operadores de Nodos del 18 de Julio
El primer elemento identificado son las transacciones en el entorno de producción que superan los 30ms. Es aquí donde destaca la actualización de transacciones read_only (solo lectura) añadida en Leap 4.0. Aumentar los límites beneficia inmediatamente tanto a las transacciones de read_only como a las del entorno de producción general.
Los cambios de configuración sugeridos por la ENF para julio de 2023 (publicados por Eric Passmore) son los siguientes.
1. Para los cambios de configuración de read-only (solo lectura), solo se ven afectadas las versiones Leap 4.0 y posteriores:
“(165ms) read-only-read-window-time-us a 165,000”
“(151ms) max-transaction-time a 151”
2. Para los cambios multisig, sólo se ve afectada (de momento) la red de prueba Jungle. Aún no es necesario realizar cambios en la mainnet (red principal):
“(150ms) max_transaction_cpu_usage a 150,000”
“(200ms) max_block_cpu_usage a 200,000”
Se espera que los cambios sugeridos sigan centrándose en la Jungle TestNet hasta que se coordine un plan de despliegue con la reunión semanal de los Operadores de Nodos.
Los cambios sugeridos preceden a la configuración por defecto que tiene previsto acompañar al lanzamiento de la versión 5.0. La publicación de Eric concluye con la notificación de que los ajustes de configuración estarán entre los elementos que se rastrearán para garantizar que tanto los productores como las cadenas tengan los mismos ajustes para asegurar un despliegue coordinado de la versión 5.0.
Discusión de la Reunión
Eric se unió a la mesa redonda para discutir los cambios recomendados. La comunidad no tuvo que discutir mucho para comprender la intención de la ENF. Tampoco hubo objeciones.
Temas discutidos brevemente incluyen:
aclaraciones de tiempo
el aumento de 30 a 151 milisegundos proporciona un amplio respiro
se esperan un par de semanas de pruebas en Jungle para los nuevos cambios
el énfasis en una coordinación fluida comienza con los cambios de configuración
suficiencia de la subjective billing (facturación subjetiva) por fallos en las transacciones
La facturación subjetiva ayuda a disuadir las transacciones fallidas basándose en el coste de la CPU y los cambios de configuración.
Tenga en cuenta que es imposible simular perfectamente la actividad en la Red EOS. Es posible que haya que modificar los cambios previstos. Hay que tener más en cuenta lo que puede salir mal (especialmente sobre los productores de bloques).
Es en este punto donde se sugirió una nueva entrada en el blog. Los Operadores de Nodo se mencionan varias veces a lo largo de la entrada del blog del 24 de mayo, An Introduction to Subjective Billing and Lost Transactions.
Otras menciones notables relacionadas con los cambios de configuración incluyen las pruebas de rendimiento/benchmark. Hay confianza en que las configuraciones se mantendrán.
Versión 5.0, facturación subjetiva y aceleración de la salida de bloques
¿Cómo conseguirá la versión 5.0 de Antelope Leap que los bloques salgan más rápido? El post del 24 de mayo (mencionado anteriormente) introduce actualizaciones de la facturación subjetiva:
"Las nuevas características de Mandel 3.1 permitirán a los operadores de nodos establecer el parámetro de tiempo de decaimiento de la facturación subjetiva de su nodo en la inicialización. Esta opción ajustará el tiempo que se tarda en poner a cero la factura subjetiva de una cuenta."
El anuncio del 8 de agosto, Leap v3.1 Release Features & Additional Tools, describe las nuevas herramientas de estilo de vida de las transacciones:
"Los artículos anteriores exploraban cómo el sistema de facturación subjetiva puede causar la pérdida de transacciones y esbozaban las soluciones existentes para los problemas comunes del ciclo de vida de las transacciones, como la pérdida de transacciones. La versión Leap v3.1 introduce nuevas herramientas para solucionar estos problemas y otros obstáculos relacionados con la experiencia del usuario."
Se prevén mejoras profundas a medida que el sistema de facturación subjetiva madure con la versión 5.0. En lugar de transacciones sin aplicar y en cola, el siguiente bloque puede comenzar inmediatamente. Incluso se ha sugerido que pueden completarse 12 bloques en una sola ronda. Se ha advertido de la necesidad de controlar el último bloque.
La reunión finalizó temprano, ya que la comunidad espera coordinarse para la versión 5.0.
Fuentes y Referencias