Actualización de Estado – Hans Moog (hilo de Twitter)

296

¡Buen viernes Ioteros! Esta actualización de estado que les traemos hoy, está extraída de un hilo de Twitter publicado por Hans Moog. Si bien no es la clase de posts a los que estamos acostumbrados, nos pareció interesante que no se pierdan este breve informe sobre el Estado de GoShimmer.


Se dice en Twitter

Actualización sobre GoShimmer de Hans Moog 

Así que … después de unos días de ponerme al día con el trabajo, hoy por fin voy a tener algo de tiempo para Twitter😅.

Quería aprovechar la oportunidad para dar a todo el mundo una pequeña actualización de estado sobre el progreso en goshimmer y lo que hemos estado trabajando en los últimos 2-3 meses.

A finales del año pasado (después de depurar la primera versión del Consenso Multiverso) empezamos a implementar una de las últimas piezas que faltaban en coordicide – la funcionalidad “merge to master” que se encarga de limpiar las ramas o branchs decididas para mantener los algoritmos rápidos y con buenas performances.

Lo que estimamos que llevaría unas 3-4 semanas resultó ser mucho más complejo y nos mantuvo ocupados durante casi 3 meses.

¿Qué había pasado?

Al principio, parecía que el problema era mucho menos complejo de lo que suponíamos y la implementación de los cambios previstos avanzaba muy rápido.

Sin embargo, cuando terminamos y quisimos probar los cambios… nada funcionaba y los nodos tenían errores de consenso instantáneos.

Primero pensamos que había un error en nuestros últimos cambios, pero después de casi 2 semanas de depuración y construcción de herramientas para “inspeccionar” mejor nuestras estructuras de datos, nos dimos cuenta de que no era nuestro código el que estaba mal, sino que el problema era consecuencia de un problema muy fundamental en nuestros conceptos, que sólo se manifestaba en combinación con este último bloque de construcción que faltaba para eliminar la información de la base de datos.

Después de unas dos semanas de brainstorming y discusiones diarias, habíamos entendido el problema lo suficientemente bien como para resolverlo.

Nuestra solución no sólo eliminaría el problema, sino que también aumentaría enormemente el rendimiento de nuestros nodos y simplificaría nuestro código.

Lamentablemente, estos cambios eran tan fundamentales que afectaban a casi todas las partes de nuestro código, lo que también significaba una cantidad masiva de trabajo inesperado para nosotros.

Hace 2 ó 3 semanas, y alrededor de 50000 líneas de código modificadas después, pudimos finalmente enviar el primer prototipo que soportaba esta característica tan crucial.

Con este último bloque de construcción en su lugar, considero que los algoritmos y las estructuras de datos en torno a nuestro “Mecanismo de Votación OTV vainilla” están finalmente hechos conceptualmente y vamos a empezar a escribir los primeros TIPs y especificaciones en las próximas semanas.

Todavía queda un poco de trabajo, limpiando la base de código y cambiando todo para que esté en su forma final prevista (resultado de nuestro último avance) antes de que podamos abordar los últimos temas en torno a:

– configurar el control de la congestión + eliminar el PoW
– los snapshots locales
– pruning
– pruebas de inclusión
– sincronización
– refactorización de multihilo / solidificación

Para la mayoría de estos temas pendientes y en cierto modo interdependientes hemos discutido varias soluciones y parece que ahora estamos convergiendo a una idea que, de nuevo, es sorprendentemente sencilla.

Por primera vez desde que me uní a IOTA, tenemos una imagen muy concreta de cómo codificar todo esto y va a ser extremadamente simple y hermoso.

Nunca he estado tan entusiasmado con nuestra tecnología como en las últimas 2-3 semanas después de “ver” la solución final por primera vez 🥳

Comentarios

comentarios

pasarela de pagos con criptomonedas