Autor: Marco González

Editor: Randall Roland

Traductor: Erick Birbe

Desde el primer lanzamiento de AntelopeIO (Leap 3.1) en septiembre, el enfoque pasó de registrar el lanzamiento de la tecnología de última generación a identificar características importantes para el avance. Entre las discusiones más notables de 2022 estuvieron:

Esta edición del resumen bimensual de la Mesa Redonda de EOS Node Operator cubre enero 04, así como también 11 y 18 (conjunto). Las dos primeras reuniones de 2023 tomaron un formato diferente; por razones de seguridad, no se publicaron videos.

Una preocupación primordial de la mesa redonda del 4 de enero fue recopilar comentarios sobre posibles cambios en el modelo de recursos de AntelopeIO. En semanas anteriores, los problemas de congestión en WAX se identificaron como áreas que podrían mejorarse para el rendimiento operativo general. La reunión comenzó identificando los puntos débiles experimentados por los operadores de nodos.

Después de la discusión sobre el uso de RAM, se consideró el hardware de bajo y alto grado. Los posibles puntos conflictivos incluyen un tope de limitaciones (grado bajo) y viabilidad económica (grado alto). Con respecto a un nuevo modelo de recursos, existe una oportunidad para:

La idea es que un nuevo modelo de recursos debería centrarse en un aumento rentable del almacenamiento de red disponible.

Se sopesó un modelo de recursos de "gas" (o combustible) frente a las opciones actuales, como recursos en bruto, REX y servicios de PowerUp. Sin embargo, históricamente se ha demostrado que pagar cada transacción tiene sus propios problemas. Las microtransacciones, un área en la que EOS sobresale, suelen ser una carga pesada para los modelos de gas. Además, existe un factor psicológico al alejarse de las operaciones integradas de EOS.

Las operaciones sin gas caracterizan a EOS como una cadena fácil de usar. Uno de los primeros conceptos que guiaron el avance de EOS fue que las propias dApps modelan sus servicios para ser proveedores de recursos para sus usuarios. Sin duda, un usuario-plus. Sin embargo, la viabilidad económica y el potencial de abuso necesitan más deliberación.

Un resultado potencial que surgió de la discusión del combustible fue codificar soluciones nativas. La evaluación de los sorteos de recursos (por ejemplo, usuarios, desarrolladores, billeteras y operadores de nodos) puede identificar limitaciones. El modelo de recursos estaría entonces listo para mejorar el entorno operativo.

El objetivo para desarrollar un nuevo modelo de recursos es:

Un área que parece ofrecer grandes recompensas con relativamente poco esfuerzo es el servicio PowerUp, a menudo ambiguo. No valía la pena investigar la mejora de los recursos de NET.

Los temas de la agenda incluyen continuar la discusión sobre el modelo de recursos de AntelopeIO, particularmente para los servicios de nodo. Las áreas de preocupación ya identificadas incluyen historia y API.

Las notas de reuniones publicadas se registraron de manera diferente para enero 11 y 18. Este último comenzaba con un resumen de las dos últimas convocatorias. A partir de ahí, la atención se centró en continuar la discusión del modelo de recursos.

Las pocas actualizaciones de progreso de software mencionadas incluyeron:

La reunión se abrió con comentarios de los desarrolladores. El desarrollo de Mac comenzó a ser abordado con más por venir en una mesa redonda posterior. Si bien Mac no es oficialmente compatible, los desarrolladores pueden compilar por sí mismos. Algunos temas de interés incluyeron la compilación de CDT (kit de herramientas para desarrolladores de contratos) como una opción para DUNE (Utilidades de Docker para la ejecución de nodos). Las acciones de GitHub (y Ubuntu) también se mencionaron como una opción para compilar y, por lo tanto, eludir CDT.

En este punto de la discusión, una nueva mesa redonda específica para desarrolladores encontró apoyo.

La discusión continuó sobre cómo el modelo de recursos de AntelopeIO impacta a los operadores de nodos. Las actualizaciones de estado fueron:

Una discusión abierta sobre cómo los comentarios de los operadores de nodos pueden ayudar a ENF a brindar soluciones. Lo que sigue son temas identificados pensados ​​para facilitar (o suavizar) las operaciones.

Las herramientas de EOS Nation se mencionaron como un punto de partida útil para poner en marcha un nodo. Animus también se compartió para el seguimiento de puntos finales. Se cree que reemplazar la dependencia de terceros con soluciones más nativas (por ejemplo, Wharf kit, mejores billeteras, mejorar el encendido) mejoraría la usabilidad de la cadena. Esta solución se identificó como de bajo esfuerzo/alta recompensa. Otras soluciones eficientes incluyeron:

Las soluciones más complejas parecen ser el emparejamiento y la garantía de la conectividad. WAX se mencionó como una gran necesidad en esta área. Si un nodo público se llena, podrían existir opciones para nodos privados y/o pares preferidos. Los nodos públicos aún se mantendrían.

Lo último en la lista para la reunión del 18 de enero fueron las instancias de nodeos de solo lectura y la propagación de bloques. Combinar bloques después de los encabezados debería resultar una mejora considerable. La propagación del bloque de ayuda viene en forma de lo mencionado anteriormente parche 3.1 y potencialmente a través de nodos de solo retransmisión.

Se puede aliviar la presión de los nodos que escriben y sincronizan mediante indicadores de solo lectura (desde archivos de estado). El escalado mejora cuando se reduce la presión del nodo. Al identificar nodos para un propósito específico, se pueden incluir más pares y al mismo tiempo reducir la RAM.

Los nodos de propósito específico trajeron a colación la discusión de funciones más elaboradas e interactivas. Por ejemplo, ¿los nodeos deberían ser una solución inclusiva o los microservicios ofrecen ventajas? DFUSE y GRAPH se mencionaron aquí.

Además, tenga en cuenta que un documento de diseño con capacidad de solo lectura espera salir pronto.

Los problemas de planificación pueden impedir la próxima reunión.