Red Hive actualizada a Equilibrium
El logro más significativo fue la actualización exitosa de Hive a través de hardfork 25 (la versión Equilibrium), y se dedicó mucho tiempo a monitorear la actualización y brindar soporte a las aplicaciones de Hive según fuera necesario durante la transición.
La actualización de Equilibrium tuvo un efecto secundario inesperado: el cambio en las reglas de curación dio como resultado que los votos emitidos después de la horquilla dura fueran mucho más fuertes que los votos emitidos antes de la horquilla dura con respecto al peso de curación, lo que significaba que los votos emitidos en los días anteriores a la horquilla dura en general no recibió muchas recompensas de curación. Este fue un efecto temporal que ahora se ha resuelto ya que todas las publicaciones que se votaron activamente ahora se crearon después de la bifurcación, pero con suerte tendremos suficiente tráfico en nuestra próxima iteración de la red de prueba para poder detectar tales problemas en el futuro. de tiempo.
Trabajo contratado (software de nodo blockchain)
Mejoras en las herramientas de prueba y las pruebas utilizadas para verificar la funcionalidad de hived: https://gitlab.syncad.com/hive/hive/-/merge_requests/272
Se agregó un nuevo indicador –exit-before-sync a la interfaz de línea de comandos de hived (útil para descargar una instantánea sin luego sincronizar, consulte https://gitlab.syncad.com/hive/hive/-/issues/66 para obtener más detalles sobre por qué esta opción fue agregada):
https://gitlab.syncad.com/hive/hive/-/merge_requests/232
https://gitlab.syncad.com/hive/hive/-/merge_requests/273
Solucionamos el error reportado anteriormente que requiere que un hived se reinicie después de cargar una instantánea:
https://gitlab.syncad.com/hive/hive/-/merge_requests/274
Hemos estado analizando el rendimiento de nuestra nueva herramienta de "conversión de cadena de bloques" para crear redes de prueba rápidamente que reflejen la red principal y hemos identificado algunos códigos asociados con nonces como el posible cuello de botella.
Hivemind (middleware de redes sociales)
Hemos agregado un nuevo programador a nuestro equipo de hivemind e inicialmente estará trabajando en pruebas y correcciones de errores menores como un medio para aprender la base del código. Su primera solicitud de fusión está aquí:
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/518
Agregamos código para verificar la consistencia de la tabla hive_blocks (esto es parte del plan mencionado anteriormente para garantizar un funcionamiento sólido en el caso de que el proceso de postgres de hivemind se apague repentinamente o falle una reversión):
https://gitlab.syncad.com/hive/ hivemind / - / merge_requests / 516
Seguimos trabajando para mejorar el rendimiento de la función update_rshares inmediatamente después de una sincronización masiva de una instancia de hivemind. Estamos probando dos alternativas diferentes para mejorar el rendimiento general: 1) cambiar la sincronización masiva para que actualice rshares para publicaciones pagas sobre la marcha, reduciendo el trabajo de update_rshares a solo actualizar rshares para publicaciones no pagas (este enfoque requiere la introducción de un nuevo hived virtual_operation) y 2) agregar un índice (al menos temporalmente justo después de una sincronización masiva) para acelerar update_rshares. Ambos enfoques se encuentran actualmente en fase de prueba.
También reanudamos la investigación sobre la razón por la que algunos nodos de hivemind consumen más memoria que otros. Se ha sugerido que puede estar relacionado con diferencias en las instalaciones de Python o bibliotecas de Python en los diferentes sistemas, lo que me inclino a creer en este punto, ya que ya no vemos un consumo de memoria inesperado en ninguno de nuestros nodos de producción ejecutando la última versión oficial de hivemind. Entonces, si no podemos replicar este problema en nuestras próximas pruebas, es probable que lo eliminemos pronto, después de fusionar nuestros cambios de diagnóstico que identifican mejor las fuentes de uso de la memoria.
Marco de aplicación de Hive (HAF)
Nuestro desarrollador principal para este trabajo se encuentra actualmente de vacaciones.
Tenía la esperanza de que aún pudiéramos trabajar en el complemento psql_serializer (que alimenta datos de hived a hivemind bajo el sistema HAF) mientras tanto, pero el desarrollador encargado de eso estaba relacionado con otros problemas (por ejemplo, solución del problema de la instantánea) . Se ha asignado un nuevo desarrollador para trabajar en psql_serializer esta semana (el que tenía la tarea anterior se va de vacaciones durante dos semanas).
Condensador y billetera (base de código de fuente abierta para https://hive.blog y otras interfaces similares)
Revisamos y fusionamos una serie de actualizaciones aportadas por la comunidad al condensador y su billetera.
De @quochuy : https://gitlab.syncad.com/hive/wallet/-/merge_requests/102
De @guiltyparties :
https://gitlab.syncad.com/hive/wallet/-/merge_requests/101
https://gitlab.syncad.com/hive/condenser/-/merge_requests/268
De @eonwarped : https://gitlab.syncad.com/hive/condenser/-/merge_requests/269
¿Que sigue?
Varios de nuestros desarrolladores de Hive están de vacaciones ahora o se van de vacaciones la semana que viene (habían estado retrasando sus vacaciones para estar disponibles para el hardfork y cualquier problema potencial que pudiera surgir después). Así que solo tendremos 8 desarrolladores de BlockTrades trabajando en Hive durante las próximas dos semanas, y nuestro progreso inevitablemente se ralentizará durante este tiempo.
Después de que todos nuestros desarrolladores de Hive regresen de las vacaciones, nos tomaremos un par de semanas para comenzar a planificar qué trabajo programar para el próximo hardfork (HF26). Tengo algunas ideas preliminares para las mejoras en las que trabajará nuestro equipo, pero haremos una lista completa de los cambios propuestos y luego comenzaremos a priorizar lo que queremos incluir en la hoja de ruta para HF26. Mi plan en este momento es ceñirme a nuestro programa actual de "actualización del protocolo Hive cada seis meses" si es posible.
Además, como durante los hardforks anteriores, nuestras hojas de ruta no están fijas en piedra, por lo que podemos considerar realizar otros cambios propuestos incluso después de que se publique la hoja de ruta inicial, asumiendo que los cambios no son demasiado grandes.
Tenga en cuenta que el proceso anterior no significa que no tengamos objetivos de desarrollo claros antes de completar la hoja de ruta HF26. Por un lado, realizaremos actualizaciones de rendimiento en hived que no requieren un hardfork real, y estos cambios generalmente se publicarán a medida que se completen.
Aún más importante, en este punto, nuestras tareas de mayor prioridad giran en torno a la creación del marco HAF y las aplicaciones basadas en HAF, y todo esto es trabajo de capa 2 que no requiere ningún cambio de protocolo de Hive que requeriría una bifurcación. En otras palabras, también podemos lanzar HAF y las aplicaciones asociadas a la comunidad de desarrolladores tan pronto como estén listas, sin la mano de obra y los problemas de programación involucrados en lograr que los nodos se actualicen como parte de una bifurcación.