Author: 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 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 (13 UTC a 14 UTC durante el horario de verano). Para aquellos que deseen aprender los conceptos básicos de las operaciones del nodo EOS, la EOS Network Foundation proporciona tutoriales y documentación.
La discusión sobre nodos especiales se pospuso nuevamente. En cambio, los desarrolladores principales de Antelope dieron una idea de las generaciones de Leap 4.0 y 5.0 durante las mesas redondas de abril 05 y 12 respectivamente. Los desarrolladores principales buscaron informar a la comunidad y obtener comentarios.
5 de abril: Actualización y comentarios de Antelope v4.0.0
Esta semana, el grupo dio la bienvenida a los principales desarrolladores de la ENF para brindar información y demostraciones de v4.0.0. Brian Hazzard proporcionó notas que también están disponibles en el GitHub de EOS Nation para abril 05. Ver la mesa redonda grabada en el YouTube de la ENF.
DESCRIPCIÓN GENERAL
Antelope v4.0.0 impulsará aún más el dominio de EOS en rendimiento, escalabilidad y confiabilidad en comparación con otras cadenas de bloques. Las características identificadas (de las notas de Brian) incluyen:
proporcionar un rendimiento aún mayor con subprocesos múltiples
reducir la latencia y permitir una propagación de bloques más rápida
proporcionar más control de datos y visibilidad
mejoras en la calidad de vida de los operadores de nodos
Conclusiones específicas (de las notas de Brian):
get_block es 4 veces más rápido y ya no está en el hilo principal
El análisis de JSON en los nodos es aproximadamente el doble de rápido
Las ventanas de solo lectura y subprocesos múltiples permiten a los proveedores de API utilizar tantos subprocesos como estén disponibles.
Lin Huang: transacciones de solo lectura
Después de la descripción general de Brian, hubo una presentación de Lin Huang. Antes de las transacciones (y tareas) de solo lectura, Lin discutió:
nuevos puntos finales de RPC
acciones de estado no modificadas para evitar cambios accidentales
anular autorizaciones/firmas
siempre devolvier un rastro de transacción
transacciones separadas para seguimiento y registro de rastreo
registro de mente profunda
Lin realizó una demostración de < /cleos push transaction > y transacciones de solo lectura. Las características clave de las transacciones (y tareas) de solo lectura paralelizadas son:
solo lectura: puede funcionar en paralelo
lectura escritura: no se puede ejecutar en paralelo
ventana de lectura: solo se puede ejecutar en modo de solo lectura
ventana de escritura: puede ejecutarse tanto en lectura como en lectura y escritura; y secuencialmente en el hilo principal
configuraciones
Vlad: Programación de instantáneas y mejoras
Los elementos clave presentados por Vlad para la programación de instantáneas incluyen:
Instantáneas para la programación (futuras únicas y recurrentes)
3 llamadas API (snapshot_requests) para lograr lo anterior
almacenado como un archivo JSON
Describió las instantáneas recurrentes como la característica "más interesante". Las instantáneas se completan cada 20 bloques y continuarán hasta que finalicen. Las instantáneas no programadas se pueden hacer con una identificación.
Vlad también mencionó que una nueva herramienta (leap-util) está agregando nuevas características y tendrá soporte actualizado para /cleos.
Peter Oschwald: Evaluaciones de Rendimiento
Peter Oschwald detalló un tutorial de evaluaciones de rendimiento con un ejemplo de línea de comando y un informe. Originalmente se pensó para establecer una mejor manera de ejecutar métricas de rendimiento en diferentes nodos operativos. Luego, los desarrolladores podrían ver cómo sus mejoras pueden estar afectando el rendimiento en todo el ecosistema.
Peter recorrió tres capas diferentes herramientas de evaluación de rendimiento: simple, básico y avanzado. Cuanto más avanzada es la capa, más parámetros se permiten. Se puede encontrar más información sobre el banco de pruebas y las configuraciones típicas en el README de Pefromance_tests [ver 31:12 del video].
Peter continúa describiendo el generador de transacciones, un reemplazo para el complemento asociado y el manejo de TPS grandes. Después de repasar más funciones, indica planes para continuar desarrollando métricas de rendimiento. Por ejemplo, medir si el rendimiento de los nodeos está mejorando o empeorando.
Kevin Heifner: rendimiento, latencia, datos y calidad de vida
Kevin Heifner repasó rápidamente varios temas antes de cerrar la reunión. Usando las notas de Brian, Kevin repasó cuatro áreas amplias de mejora y sus subtemas:
Mayor rendimiento
Ejecución de tareas y transacciones de solo lectura en paralelo
Subprocesos múltiples y seguridad de subprocesos
Optimizaciones para http_plugin
Mejoras subjetivas de la CPU
Latencia reducida
Emparejamiento automático con nodos BP proximales programados
Validación más ligera para relays
Control de datos y visibilidad
exportador de Prometeo
División de logs de bloques y SHiP
Calidad de vida
Configuración del valor absoluto del monitor de recursos
Mejor registro a través de complementos de nodeos
Kevin pasó a probar cómo funciona actualmente el emparejamiento automático. El ejemplo entró en el tema de la conectividad relacionada con la programación de BP.
A continuación, proporcionó algunas notas sobre el complemento exportador de Prometheus:
IPv4 para 4.0 permite escuchar en un puerto separado cuando el complemento está habilitado
IPv6 para 5.0
División de registros (especifique un directorio de estado diferente)
Al concluir la reunión, se mencionó que los nodeos tienen acceso al directorio (retener) pero no a los archivos. La historia del estado sigue el mismo comportamiento.
Kevin terminó con micro optimizaciones donde los bloques se propagan después de una validación de encabezado y no es necesario que ocurran en el subproceso principal. Junto con una mejora 4x en get_block, se espera que la propagación de bloques sea mucho más rápida en un entorno 4.0. Él describe cómo "es un período más rápido" y más de la mitad del proceso (tiempo) se ha movido del hilo principal.
PANORAMA
EOS es una cadena de bloques muy rápida tal como está. El desarrollo de Antelope de v4.0.0 hará que EOS sea sustancialmente más rápida, más eficiente y amigable para los desarrolladores.
12 de abril: Mirando hacia el futuro a un entorno 5.0 y categorías de puntos finales
Los desarrolladores principales de Antelope brindaron su visión de un entorno 5.0 y solicitaron comentarios. Se realizaron comparaciones con las operaciones existentes, un entorno 4.0 y la previsión de 5.0. Busque las notas de la mesa redonda del 12 de abril y un enlace de video en EOS Nation GitHub.
Actualizaciones
v4.0.0-r3 liberado
CDT-rc1 saldrá pronto (posiblemente la próxima semana)
horario de oficina del desarrollador
Las nuevas características que vienen con v4.0.0-rc3 se detallan en el enlace provisto.
El horario de atención de los desarrolladores cada dos semanas brindará más apoyo a quienes asistan a las mesas redondas. Stephen Diesel estará liderando las reuniones. El primero será el 20 de abril y cada dos jueves después. No dude en comunicarse con Stephen en Telegram para obtener más información sobre CDT y otras cosas relacionadas con los desarrolladores (por ejemplo, DUNE, puntos débiles y las nuevas cápsulas Antler).
DESCRIPCIÓN GENERAL
Dado que faltan meses para una actualización de consenso 5.0 (posiblemente a principios de otoño), la reunión estuvo menos estructurada de lo habitual. Los temas clave de interés incluyen:
un deseo de retroalimentación temprana (y sueños para 5.0)
revisiones de propuestas
Complemento de Prometheus
categorías de punto final
TEMAS CLAVE
4.0 presentará el complemento Prometheus. En su breve tiempo de prueba, los miembros de la comunidad han solicitado que el complemento esté disponible para ejecutarse en un puerto configurable separado. Eso ahora parece ser un objetivo principal para 5.0.
Prometheus en un punto final separado inspiró otras configuraciones de endpoints. Algunas categorías de endpoints propuestas incluyen:
get_info
chain_ro
chain_rw
net_ro
net_rw
producer_ro
producer_rw
snapshot
trace_api
Prometheus
node
Las categorías no serán configurables con cada endpoint. Más bien, los endpoints se agruparán de manera que tengan sentido. También habrá uniformidad entre las categorías. El valor predeterminado será que todos los puntos finales estén en una categoría para que el sistema pueda funcionar como siempre lo ha hecho.
Se compartió una propuesta titulada “Configuraciones personalizadas de puerto/IO”.
Otra prioridad para 5.0 es la introducción de IPv6.
Comentarios de la reunión
La idea de categorías de endpoints eficientes pareció funcionar bien. Algunos comentarios y respuestas iniciales incluyeron:
comentarios sobre una nueva configuración (categoría) para get_supported_apis
el proceso de filtrado a través de conexiones
discusión sobre get_server_info y get_info que es independiente para el público y los operadores de nodos
Tal como está hoy, get_info generalmente se hace público. Sin embargo, existe la necesidad en entornos de pares (p. ej., nodos de productores) de que get_info no sea público.
Tenga en cuenta que existen opiniones sólidas sobre el mantenimiento de get_info en todos los puntos finales.
Cierre
La mesa redonda comenzó a concluir discutiendo una especie de modo de recuperación y umbral configurable.
Brian cerró la reunión preguntando a la comunidad sobre un entorno de ensueño para 5.0. Proporcionó sugerencias de áreas para enfocar las propuestas, pero sostuvo que la retroalimentación debería ser prácticamente ilimitada:
puntos de dolor
artículos especiales
mejorando el desempeño
nuevas capacidades significativas
impulsando la adopción
labrando un nicho
PANORAMA
La red EOS ahora está conectada a Ethereum a través de EOS EVM. 4.0 (actualización de consenso no esperada) y 5.0 (actualización de consenso planificada) están progresando con confianza. Ambas versiones mejoran la velocidad y la funcionalidad. EOS ya tiene un rendimiento superior en el espacio de las cadenas de bloques. Ahora es el momento de hacer realidad los sueños.