Este articulo es interesante de @blocktrades version español, spanish

Voy a publicar este post un poco antes, ya que espero estar muy ocupado el lunes. Antes de entrar en mi reporte normal sobre los temas de codificación detallados en los que el equipo de BlockTrades trabajó la semana pasada y nuestros planes para la próxima semana, primero quería dar un breve resumen del proceso de trabajo duro como sucedió la semana pasada, ya que eso es lo que ha estado impulsando nuestro flujo de trabajo en la última semana.

Revisión del trabajo duro 24 (y un trabajo duro "no planeado" antes de eso)

En la fecha de hardfork 24 (14 de octubre), los desarrolladores de aplicaciones seguían haciendo cambios relacionados con hardfork 24 y reportando los problemas de API que encontraban con hivemind, mientras que el equipo de BlockTrades trabajaba en la corrección de esos bugs según se iban reportando (discutiré las correcciones de bugs más adelante en este post). Mientras tanto, los 20 testigos principales estaban a la espera, esperando una señal de "todo despejado" de que había suficientes aplicaciones estables para que pudiéramos ejecutar con seguridad el hardfork actualizando sus nodos al código del hardfork 24 (etiquetado en el repositorio de nodos hived como v1.24.2 o v1.24.3).

Varios de los 20 testigos principales ya habían actualizado su código al código de Hardfork 24, pero esto fue considerado correcto por mí y otros desarrolladores, ya que el código HF24 requiere una super-mayoría de los 20 testigos principales para cambiar a él para activar el nuevo protocolo HF24 que contiene. Esto permitió que algunos de los 20 principales testigos no tuvieran que esperar mientras esperábamos que la integración de aplicaciones y de la mente llegara a un nivel aceptable antes de activar el hardware.

Desafortunadamente, esto condujo a un efecto secundario inesperado: el código de HF24 contenía un cambio de protocolo que no estaba debidamente protegido contra la ejecución antes de hardfork 24. Esto significa que un nodo HF24 podría producir un bloqueo que no sería aceptado por los nodos HF23. Nunca antes habíamos visto este error disparado, porque sólo podía causar un problema cuando un nodo HF24 producía un bloque y sólo entonces bajo circunstancias especiales.

Ha habido algunas veces antes de la fecha de trabajo duro cuando hemos ejecutado un nodo HF24 como nodo productor, pero en el pasado, tal nodo estaba en minoría, así que lo peor que podría haber pasado si este fallo se disparaba era que el nodo HF24 se bifurcara temporalmente, y luego volviera a caer en el consenso con la cadena cuando el bloque que generaba no era aceptado por los nodos HF23.

Pero en la fecha de la bifurcación, aunque no teníamos una super-mayoría de los 20 nodos principales corriendo HF24, sí teníamos una mayoría corriendo HF24. Y una mayoría es suficiente para determinar cómo se resuelven las bifurcaciones en cadena. Así que cuando uno de los nodos de HF24 producía un bloque que era rechazado por los nodos de HF23, pero aceptado por los nodos de HF24, la lógica de resolución de las bifurcaciones mantenía a los nodos de HF24 en una bifurcación dura no planificada separada de los nodos de HF23 (dividiendo efectivamente la cadena en dos bifurcaciones).

Los 20 testigos principales se dieron cuenta rápidamente de lo que estaba sucediendo, así que decidieron ejecutar la horquilla dura actualizando los nodos HF23 restantes a HF24, de modo que todos los nodos se unieran a la horquilla mayoritaria. Esto también requirió que todos los operadores de nodos de la API actualizaran sus nodos de la API a HF24, y que todas las aplicaciones de Hive cambiaran a sus versiones de HF24 para utilizar esos nodos de la API.

Debido a que el hardfork 24 se ejecutó un poco antes de lo que nos hubiera gustado debido a la división de la cadena, todavía no habíamos resuelto todos los errores y problemas de rendimiento de las aplicaciones de hivemind y Hive en el momento del hardfork. Esto condujo a varios fallos y ralentizaciones experimentadas por los usuarios de las aplicaciones en los últimos días. Pero los desarrolladores de Hive han estado trabajando duro para resolver los problemas lo más rápido posible y las cosas ya se ven mucho mejor, y espero que los problemas restantes se resuelvan muy pronto.

Una cosa para el futuro: Quiero buscar formas de detectar problemas como la ruptura de la cadena antes de que ocurran. Una posibilidad podría ser establecer un nodo de testigo secundario especial que ejecute el nuevo código que señale los bloques como uno de los 20 principales testigos, pero donde los bloques que produzca sólo se transmitan a un nodo de código antiguo aislado que informaría si no pudiera aceptar ninguno de los bloques que recibiera del nuevo nodo. También podemos reducir la posibilidad de que este problema ocurra en la práctica haciendo que la mayoría de los 20 testigos principales se actualicen muy cerca del mismo tiempo, pero eso sólo puede llevarnos hasta cierto punto: la solución ideal sería tener un mejor método de prueba para detectar esos problemas y creo que alguna variación de mi propuesta anterior debería funcionar.

Trabajo de colmena (software de nodo de cadena de bloques)

Hicimos varios cambios en las respuestas de la API devueltas por hived, principalmente en respuesta a los informes de los desarrolladores de aplicaciones:
https://gitlab.syncad.com/hive/hive/-/merge_requests/125
https://gitlab.syncad.com/hive/hive/-/merge_requests/126
https://gitlab.syncad.com/hive/hive/-/merge_requests/133

También hicimos una limpieza general del docker, scripts y archivos de configuración de la colmena:
https://gitlab.syncad.com/hive/hive/-/merge_requests/130

También arreglamos un problema con la cartera de clientes: seguía usando la vieja cadena de identificación después del trabajo duro, por lo que no podía generar transacciones adecuadas. Parece que había muy pocas pruebas escritas previamente para probar el cli-wallet.
https://gitlab.syncad.com/hive/hive/-/merge_requests/128

El arreglo de la cartera de clientes era necesario para los intercambios, así que etiquetamos una nueva versión v1.24.4 que incluye este cambio (y los otros arreglos anteriores). Nótese que ninguno de los cambios anteriores son necesarios por los testigos de consenso, por lo que los testigos principalmente siguen funcionando 1.24.2. Estos cambios sólo son necesarios para los nodos e intercambios de la API.

Ayer comenzamos una repetición completa para comprobar todos los cambios anteriores (esto lleva unas 18 horas). No esperamos ningún problema, ya que los cambios se diseñaron como cambios no consensuados, sólo cambios en la API, pero más vale prevenir que curar.

Hivemind (Microservicio de medios sociales de segunda capa)

La mayor parte de nuestro tiempo todavía lo pasamos en la mente del VIH, pero hicimos muy buenos progresos.

Nuestras mejoras en la mente del VIH se pueden separar en dos categorías: correcciones de errores (datos erróneos o faltantes en las respuestas de la API) y consultas lentas que resultan en tiempos de respuesta inaceptables. Nuestras correcciones de errores se realizan normalmente en respuesta a informes de los desarrolladores de aplicaciones, pero las consultas lentas se detectan normalmente observando el rendimiento de los servidores postgres utilizados por nuestro nodo API con la herramienta pghero. Hemos encontrado que pghero es muy útil para encontrar qué consultas SQL están consumiendo más tiempo para completarse (funciona como un perfilador). También es útil para encontrar índices duplicados e innecesarios que pueden afectar al rendimiento.

Los cambios descentralizados de la lista también se fusionaron en la rama de desarrollo, después de las actualizaciones (el código había divergido mucho desde que se hicieron estos cambios, por lo que requirió una cantidad decente de fusión y pruebas manuales): https://gitlab.syncad.com/hive/hivemind/-/merge_requests/275

Hivemind status

Con las últimas optimizaciones (la última grande fue la solicitud de fusión 310 hecha el sábado), la mente de urna parece estar funcionando bastante bien, pero todavía tenemos que hacer algunas optimizaciones más, y también tenemos que volver a habilitar la actualización de la reputación (esto se deshabilitó temporalmente porque necesitaba una mayor optimización para evitar inaceptables ralentizaciones de sincronización que causaban un exceso de carga en los nodos de la mente de urna cuando recibían el tráfico del mundo real).

Tenemos una versión optimizada del alogoritmo de sincronización de reputación en un sistema de desarrollo local, pero lo probaremos más adelante en uno de nuestros servidores de API experimentales con tráfico de API del mundo real antes de hacerlo parte de la construcción oficial.

Actualmente estamos ejecutando una sincronización completa de hivemind (esto ha sido generalmente un proceso de 4 días) para ver si hay algún problema, ya que hemos estado omitiendo este proceso durante la última semana y haciendo mejoras incrementales a nuestra base de datos de hivemind existente con el fin de probar rápidamente los nuevos cambios.

Experimentando con la configuración óptima de los nodos de la API

Otra cosa que hemos estado haciendo esta semana es experimentar con la configuración de nuestro nodo API para un rendimiento óptimo. He estado compartiendo parte de esa información que hemos descubierto en el canal de operadores del nodo API, pero haré un informe completo aquí más tarde sobre nuestros hallazgos, una vez que hayamos completado ese trabajo.

Condensador (código abierto para hive.blog)

Hicimos algunos cambios más en hive.blog y su cartera relacionados con los cambios en hardfork 24 (sobre todo en la cartera, ya que ya hicimos varias actualizaciones en el propio condensador), especialmente eliminando los usos de la función get_state que está siendo obsoleta en favor de llamadas a la API más eficientes.
https://gitlab.syncad.com/hive/wallet/-/merge_requests/38
https://gitlab.syncad.com/hive/wallet/-/merge_requests/39
https://gitlab.syncad.com/hive/wallet/-/merge_requests/40
https://gitlab.syncad.com/hive/wallet/-/merge_requests/42
https://gitlab.syncad.com/hive/wallet/-/merge_requests/43
https://gitlab.syncad.com/hive/wallet/-/merge_requests/45

https://gitlab.syncad.com/hive/condenser/-/merge_requests/118
https://gitlab.syncad.com/hive/condenser/-/merge_requests/121
https://gitlab.syncad.com/hive/condenser/-/merge_requests/119

Una solución que necesitamos desplegar pronto es un cambio para que el condensador actualice correctamente el estado del botón de votación después de que un usuario vote:
https://gitlab.syncad.com/hive/condenser/-/merge_requests/129

¿Qué es lo próximo de la semana?

Tenemos algunas optimizaciones más que hacer a la Hivemind, y espero que recibamos algunos informes más de errores, además de que todavía tenemos que desplegar el código de cálculo de reputación final. Pero espero que ese trabajo se ralentice en los próximos días, aunque la prueba de sincronización completa de la colmena no se completará probablemente hasta cerca del final de la semana (ya hemos observado una ralentización hoy en la sincronización completa con los últimos cambios que necesita ser analizada).

Traducción realizada con la versión gratuita del traductor www.DeepL.com/Translator este contenido pertenece a Hive account@blocktrades

Actualización sobre el trabajo de Blocktrades y los resultados de HF24 por blocktrades