Se lanzó Leap 3.2, fue revelado en esta Mesa Redonda. Además, se discutió el problema fundamental de la Base de Datos de Estado: su uso de RAM astronómicamente alto. Se exploraron soluciones potenciales a largo y corto plazo, así como compensaciones.

Además, la ENF proporcionó un breve resumen de los detalles de las mejoras del complemento NET al final de la reunión, donde también se decidió el cronograma de la siguiente mesa redonda: Exportador Prometheus de Leap 4.0 presenta estadísticas para la caja negra nodEOS. 13 participantes se unieron a la mesa redonda esta vez.

El desarrollo de software es el principal tema de discusión durante las sesiones semanales de la mesa redonda de operadores de nodos EOS. Los desarrolladores, los productores de bloques, los ingenieros de blockchain y los miembros de la comunidad que desean obtener más información sobre el proceso de desarrollo de EOS se benefician del conocimiento que proporciona.

Un ecosistema puede crecer sana y naturalmente compartiendo e interactuando a menudo. La EOS Network Foundation ha recibido comentarios favorables sobre su progreso por parte de los BP y desarrolladores. La comunidad EOS es consciente del hecho de que su voz ahora es apreciada y escuchada. Por último, pero no menos importante, se están dando respuestas a las preocupaciones de la comunidad.

Resumen de las actualizaciones de Antelope Leap en camino

de Stephen Diesel (ENF, Product Manager de Leap)

ACTUALIZACIONES	PLAZO DE LANZAMIENTO
Versión final de Leap 3.2	lanzado en Github
Actualizaciones del contrato del sistema	en camino
Lanzamiento de DUNE	diciembre, 2022

Al comienzo de esta reunión, Stephen anunció que Leap 3.2 se lanzará en Github, pero no es una actualización de consenso y, por lo tanto, es opcional.

Brian Hazzard acepta estar disponible para cualquier pregunta relacionada con la actualización en varios canales. La próxima semana habrá una actualización del documento Net Plugin Enhancements, ya que la última reunión recopiló excelentes ideas y definió algunas nuevas características potenciales para el backlog.

Reformulado el Recorte de la Base de Datos de Estado: Demasiada RAM utilizada para almacenar el Historial de Estado

Michael de EOSUSA no pudo estar en la reunión, pero sugirió el tema para esta reunión: Recorte de la Base de Datos de Estado. Los participantes acordaron que el verdadero problema es que se está utilizando demasiada memoria RAM. Según Stephen, se está redactando una RFP con el objetivo de investigar el problema de la memoria RAM.

Compensación de Rendimiento vs a Tamaño de RAM

Kevin Heifner planteó la pregunta principal: "¿Cuánto rendimiento está dispuesto a sacrificarse por el tamaño de la RAM? ¿Se está dispuesto a sacrificar 1 ciclo de producción de bloque para cargar datos en la RAM (como un bloque de calentamiento)?" Sin embargo, existe un alto riesgo de spam con esta solución.

Simplemente hay una gran demanda de RAM que nunca parece satisfacerse. Por el momento se necesitan 128 GB de RAM para ejecutar la base de datos de estado WAX sin problemas. El problema es que los dispositivos normales no tienen suficiente espacio para más RAM. Es difícil encontrar dispositivos con CPU potentes y mucho espacio para RAM. Tal vez los dispositivos de diseñador gráfico/animador podrían cumplir con los requisitos futuros.

Oportunidades definidas a corto y largo plazo (cotizado)

Oportunidades a corto plazo

La coalición Antelope está redactando un RFP para investigar este tema.
Hacer que el modo Heap se inicie y se apague más rápido
¿Existe la oportunidad de hacer que el tmpfs sea más original?
Dejar las consultas de cuenta deshabilitadas puede ahorrar en RAM (oportunidad para la configuración del operador de nodo, ya es posible)
Almacenar las consultas de cuenta en el disco (tal vez 4GB de RAM en ahorros aquí para aproximadamente 14 millones de cuentas en WAX, probablemente no valga la pena)

Oportunidades a largo plazo

¿Se pueden incentivar los contratos inteligentes para especificar RAM frente a almacenamiento en disco?
Los proveedores de hardware deben comenzar a ofrecer núcleos de CPU muy rápidos con grandes cantidades de RAM.

Mejoras P2P (complemento de red) (por Brain Hazzard)

Brian Hazzard se refirió rápidamente a las siguientes inquietudes y se ofreció a presentarlas con más detalle en la siguiente reunión después de una breve consulta del anfitrión, Daniel Keyes, sobre si podía brindar un breve resumen de las propuestas específicas para mejorar el complemento de red discutidas recientemente de forma interna.

Existiría la posibilidad de hacer validaciones más ligeras que ocurren para bloques en retransmisión. Esto podría ahorrar tiempo y hacer que el relevo sea más rápido.
Sería posible codificar si un bloque está lleno (en términos de tiempo de CPU construido) transmitiendo y comenzando en el siguiente bloque.
Configuración automática de pares para optimizar la latencia (los BP lo hacen manualmente en este momento).
- optimizar para el cronograma (¿Qué BP viene antes, cuál después?)
- optimizar en términos de latencia

Agenda de la próxima semana

Un debate sobre qué datos deberían incluirse en el Exportador Prometheus en el próximo Leap 4.0 propuesto por Matthew de EOS Nation:

nodeEOS es como una caja negra, muchos operadores de nodos no tienen idea de lo que sucede dentro. Hay una solicitud para dar algunas estadísticas al respecto.

Se alienta a los asistentes a la reunión de node a traer su lista de deseos para Prometheus durante la próxima reunión.

Participantes (13) de esta mesa redonda:

Randall Roland | EOSsupport.io
Dario | EOSsupport.io
Kevin Heifner | OCI
Matt Witherspoon | ENF
Brian Hazzard
Jannis - Rakeden (Jannis)
Max Cho | KOREOS
Daniel Keyes | EOS Nation
Stephen Diesel | ENF
Matthew Darwin | EOS Nation
Corvin Meyer auf der Heide | liquiid.io
Patrick Burns | Aloha EOS
Ross Dold | EOSphere

Fuentes y referencias

Resumen de la mesa redonda EOS Node Operator por Daniel Keyes

Créditos de imagen
- Banner de EOS Support Graphics