Esta es una traduccion para @blocktrades y la comunidad hispana de Hive. Puedes leer el articulo original en ingles aqui: https://peakd.com/hive/@blocktrades/quick-update-on-hive-related-activities-at-blocktrades

No he tenido mucho tiempo para postear últimamente, pero quería dar un rápido resumen de lo que BlockTrades ha estado trabajando con respecto a Hive, en el lado de la codificación y el hardware, que no se ha discutido mucho en postes anteriores.

Configuración de múltiples servidores API

Los servidores de la API proporcionan los datos de la cadena de bloques en varias formas utilizadas por todos los sitios web de frontend. Varios miembros de la comunidad están operando ahora servidores API, con algunas variaciones en las capacidades de los servidores.

BlockTrades está trabajando actualmente en la construcción de un "grupo" de tales servidores para una mayor disponibilidad. Tenemos un servidor funcional ahora (ha estado funcionando desde el hardfork de HIVE), pero todavía estamos trabajando en la solución del clúster. Hemos estado luchando con varios problemas de hardware, pero creo que estamos cerca de una solución a esos problemas, por lo que espero que nuestra capacidad de clúster sea operativa pronto.

Optimizando la imagen que sirve a los frontales

La mayoría de las personas incluyen imágenes en sus mensajes, pero no todos son conscientes de que esas imágenes no están almacenadas en los datos de la cadena de bloqueo (sólo el texto del mensaje lo está). En cambio, las imágenes en sí se mantienen en "servidores de imágenes" y los mensajes de las cadenas de bloqueo contienen enlaces a las imágenes de esos servidores de imágenes.

El servidor de imágenes principal de Steem fue proporcionado por Steemit Inc., así que hemos tenido que trasladarnos a nuestro propio servidor de imágenes para apoyar a Hive. Pudimos configurar el nuevo servidor de imágenes antes del HardFork, pero todavía estamos trabajando para optimizarlo para proporcionar un mejor servicio. Esto es importante, porque puede resultar en tiempos de carga más rápidos de los sitios web frontales desde los que se publica y se cura.

Un área en la que estamos optimizando es el uso de un "servidor de almacenamiento en caché de imágenes" que permite una rápida búsqueda de las imágenes recientemente mostradas. Desplegamos este servidor de cacheo en el momento del trabajo, pero estamos mejorando su rendimiento a medida que aprendemos sus peculiaridades. Un problema que encontramos hoy es que cuando tuvimos el servidor de cacheo configurado con un caché de disco más grande que su caché de memoria, su rendimiento comenzó a degradarse con el tiempo, así que lo hemos corregido.

También estamos experimentando con el ajuste de lo que reconoce como un "golpe de caché" (es decir, cuando puede darse cuenta de que una imagen es la que tenemos localmente en el servidor de caché, por lo que no necesitamos volver a buscarla en el servidor de imágenes). Esto reducirá la cantidad de carga tanto en el servidor de caché como en el de imágenes.

Optimizando el rendimiento de https://hive.blog

Durante la primera semana, nosotros y varios otros desarrolladores nos centramos en hacer ajustes básicos al software para hive.blog (incluyendo hacer que la cartera funcione con el sitio). Ahora que ese trabajo está hecho, pasamos a trabajar en hacer el sitio más rápido y más robusto.

Actualmente estamos agregando la capacidad de utilizar múltiples puntos finales de la API. Los puntos finales de la API son la forma en que los frontends consiguen que se muestren los datos de la cadena de bloqueo. Hive.blog fue diseñado para usar siempre un solo punto final, de modo que si este punto final tenía problemas, también los tenía Hive.blog. Una vez que se admiten varios puntos finales, el sitio web puede cambiar a un punto final diferente si el que está utilizando actualmente experimenta problemas.

Trabajo en cadena de bloques para el próximo Hive hardfork

Nuestro equipo de la cadena de bloqueo está trabajando actualmente en varias tareas para el próximo trabajo duro: 1) añadir código para hacer una segunda ronda de airdrops en algunas de las cuentas que fueron excluidas del lanzamiento aéreo anterior, 2) pruebas finales y correcciones para el código de poder de voto retrasado que tiene por objeto detener futuros ataques de votación por parte de los intercambios o alguien que hackea un intercambio, y 3) la realización de una auditoría de seguridad según lo solicitado por algunos de los intercambios que están interesados en la lista de Hive.

El código de airdrop de la segunda ronda

Este código transferirá a Hive, HP y HBD de la cuenta del tesoro a algunos grupos de cuentas que fueron excluidos en el lanzamiento inicial. Los grupos excluidos exactos que serán elegibles se decidirán por votación de los interesados, seguido por el acuerdo de los testigos para ejecutar el nuevo código de trabajo duro. Obsérvese que los interesados siempre pueden cambiar sus votos para modificar la composición de los 20 testigos principales si no están de acuerdo con las decisiones de los testigos sobre el hardfork.

Cambio del poder de voto retrasado

El código de poder de voto retrasado funciona descontando el poder de voto de la apuesta recién potenciada durante 30 días cuando se trata de presenciar la votación y la votación de propuestas.

Tenga en cuenta que este retraso no afectará a otros usos de los nuevos poderes. Por ejemplo, el juego recién activado aumentará inmediatamente el poder de voto en los puestos y aumentará los créditos de recursos disponibles.
Auditoría de seguridad

Esta auditoría implicará una revisión general del código de la cadena de bloqueo, centrándose en la verificación del código de criptografía que asegura que los fondos sólo pueden ser utilizados por alguien con las claves privadas correctas, y verificando que el código no permite que las monedas sean transferidas de forma inesperada.

Tiempo del proximo Hardfork

El momento para el próximo trabajo duro no ha sido determinado todavía. Dependerá tanto de cuándo esté listo el código como de cuándo los testigos y las partes interesadas lo consideren más apropiado. Tengan en cuenta que querremos dar a los intercambios de la lista de la Colmena al menos 30 días de aviso antes del trabajo duro, para que puedan prepararse para la transición de sus carteras al nuevo código.