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 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.
El abril 19 y 26 Las mesas redondas analizaron el desarrollo de Leap. El 19 de abril se pensó lo que podría suceder con la versión 5.0 de Leap. Para el 26 de abril, v4.0.0 se había lanzado. La última mesa redonda de abril recibió comentarios y exploró una nueva propuesta.
19 de abril: Esperanzas y Sueños para Leap 5.0 y más allá
El tono era una especie de paisaje onírico que exploraba el futuro potencial de la Red EOS. Busque las notas de la reunión de abril 16 en EOS Nation GitHub. Vea la mesa redonda grabada en el YouTube de la ENF.
DESCRIPCIÓN GENERAL
Faltan meses para la versión 5 de Antelope. Dar forma al desarrollo ocurre ahora. Se alienta la retroalimentación de la comunidad. Vea los comentarios de los participantes y comparta los suyos. Pero primero, algunas actualizaciones:
Leap v4.0.0 es inminente
Herramientas Antler
Se espera una demostración de CDT en una semana o dos
Dirigida por el equipo de Antelope, la mesa redonda del 19 de abril exploró las esperanzas, aspiraciones y sueños para la versión 5.0 y posteriores.
El siguiente resumen adapta las notas presentadas por Brian Hazzard. La versión 5.0 de Antelope Leap tiene un objetivo impreciso para su lanzamiento en otoño de 2023. Esté atento a las actualizaciones y posiblemente a un lanzamiento a partir de septiembre.
La versión 5.0 de la red principal de EOS representa el futuro y la visión de la comunidad. Se pidió a los participantes que expresaran su lista de deseos (pensamientos y sueños). Entre los subtemas de discusión estuvieron:
intereses para hoy
cambios pequeños, pero de impacto, que son relativamente fáciles de alcanzar
acciones analgésicas pragmáticas, útiles, divertidas y generales
factores notables, controvertidos y sorprendentes
Planos lunares y aspiraciones brillantes tanto de operadores como de usuarios
Los subtemas anteriores ayudaron a impulsar los deseos de desarrollo de 5.0 (y más allá). A continuación se presentan breves resúmenes de cada uno de los nueve participantes:
Ross: detección dinámica de pares, automatización de los mejores pares y visualización sencilla del último bloque
Daniel: bloques de construcción ETH útiles y compatibles con múltiples cadenas e integración con The Graph
Miguel: Endpoint de administración más detallado ("GetInfo2") y una consulta de estado que indica un nodo seguro/sincronizado ("Está listo")
Marco (MachnBird Sparo): hardware y procesamiento de pagos fácil/accesible
Aarón: permisos con autorizaciones temporales y reglas específicas que coinciden con los envíos
Kevin: paralelización de validación de bloques, 100K TPS y escalado horizontal
Denis: mejorar los recursos nativos a través de la consolidación y la rentabilidad
Tonio: Integración de Loki para registro y una solución de monitoreo nativa
J. P.: administración mejorada de pares a través de una API operativa y estar al tanto fácilmente de nuevas características/correcciones
Mateo: integrar WAX RNG, IPv6 en todas partes, nodeos de inicio automático y formato de instantáneas comprimidas
PANORAMA
La retroalimentación de la comunidad es fundamental para el desarrollo actual. Uno podría deducir que proporcionar comentarios temprano durante el desarrollo de 5.0 será más valioso.
26 de abril: Propuesta de nodeos 5.0 para API/Serialización
Con Leap v4.0.0 ahora en vivo, el enfoque está en arreglar un curso (s) para el desarrollo de 5.0 en los próximos meses. Notas de la reunión de abril 26 están en EOS Nation GitHub. La propuesta, (actualizado) Restricciones de tiempo de serialización/API para nodeos 5.0, se encuentra en un enlace de la ENF en hackmd.io. Busque una grabación en el YouTube de la ENF.
DESCRIPCIÓN GENERAL
Una vez más, la atención se centró en los comentarios de la comunidad. En realidad, la discusión tomó más un formato de preguntas y respuestas. Las actualizaciones incluyen:
V4.0.0 se lanzó esta semana y algunos operadores de nodos ya están adoptando
CDT v4rc1 probablemente para la próxima semana
A continuación se presenta una breve descripción de la propuesta. Los dos puntos principales para los cambios que llegarán pronto a la versión 5.0 son:
Límite de serialización ABI
restricciones de elementos API no atómicos
La mayoría de las solicitudes de ABI (interfaz binaria de aplicación) vieron la deserialización movida al grupo de subprocesos HTTP. El resultado es una mejor capacidad de respuesta de los nodos en el subproceso principal.
Como consecuencia, existen restricciones en la cantidad de elementos devueltos para las API no atómicas. Más específicamente, las solicitudes de http_max_response_time deben especificar un rango y un tiempo máximo. Temiendo en cuenta que las solicitudes válidas siempre devuelven al menos un objeto, con un máximo predeterminado de 1000 elementos.
Un resumen de los requisitos de orientación es el siguiente:
Los nodos API deberían atender con éxito cualquier solicitud atómica
las llamadas API no atómicas deben especificar un tiempo máximo de solicitud
debe protegerse contra las "abi-bombs" proporcionadas por el usuario
Discusión
La discusión fue más libre que de costumbre. Los temas enumerados se seleccionaron por lo que se destacó e inspiró la conversación de ida y vuelta.
Por qué get_block cambió
La velocidad, la eficiencia y evitar congelar el subproceso principal parecían inspirar el traslado de get_block al subproceso HTTP.
Supervisión del tiempo
Se recomienda Prometheus sobre una solución de historial. Prometheus también debería ayudar mucho con el monitoreo. Entre la lista de deseos se encuentra una solución ligera y ampliamente disponible.
Caso de uso para desarrolladores
Se discutió brevemente la posibilidad de que los desarrolladores usen un complemento. También lo fue el avance del complemento, la mención de trace_api_plugin y cómo algunos desarrolladores (finanzas en particular) desconfían de las soluciones de capa 2.
Otros temas
Entre los otros temas que recibieron mucho tiempo de discusión se encuentran:
razones para fallar (o congelar)
tiempo máximo de respuesta
más sobre una solución de historia
instantáneas
PANORAMA
Leap 5.0 seguramente traerá discursos acalorados y más propuestas. Hacer que esta propuesta orientada al rendimiento sea correcta debería ser de gran ayuda para establecer un rumbo sin problemas para 5.0. Los participantes parecen albergar sentimientos similares, con un enfoque en la calidad más que en impulsar rápidamente una solución.
Fuentes y referencias