- Zilliqa está trabajando para resolver el problema del tiempo de inactividad de la cadena de bloques al que se enfrentan los usuarios.
- Zilliqa tiene previsto introducir herramientas de verificación formal para comprobar la «corrección, fiabilidad y confiabilidad de los sistemas de software de misión crítica».
Zilliqa, la primera blockchain pública en implementar sharding, anunció una actualización urgente de su plataforma de blockchain. Jun Hao Tan, el vicepresidente senior de seguridad e ingeniería de Zilliqa señaló que la actualización es un intento de resolver el problema del gran consumo de memoria en los nodos de minería para la comisión de DS. Así, en un anuncio del miércoles 14 de julio, Zilliqa tuiteó:
Estimada comunidad
Estamos trabajando en una actualización urgente de la red. En este periodo de actualización, no se procesarán transacciones y la API de la blockchain puede no ser accesible. Les mantendremos informados sobre el estado de la actualización. Gracias por su continuo apoyo.
En su publicación en Reddit, Zilliqa señaló que su última actualización de la red v8.0 estaba repleta de características. Además, se redujo el tiempo de bloqueo, se ajustaron las prioridades para los mineros, junto con varias otras optimizaciones. Sin embargo, la cadena de bloques de Zilliqa mostró inestabilidad después de la actualización. Como resultado, el equipo central intervino en varias ocasiones para introducir parches. Pero esto provocó múltiples caídas.
Zilliqa señaló que su objetivo es aportar transparencia al tiempo que adopta medidas que reduzcan las posibilidades de que se produzcan tales acontecimientos en el futuro. Pretende aportar nuevas características sobre su tecnología subyacente, al tiempo que sigue los estándares de la industria y realiza pruebas de estrés. El anuncio de Reddit Zilliqa
Una vez que los cambios y las pruebas unitarias están completamente listos, ejecutamos estos nuevos cambios en una red privada a pequeña escala durante un período de tiempo, seguido de una integración a gran escala en la escala de la red principal y luego desplegamos los cambios en una red de prueba pública abierta para que todos interactúen. Si se encuentra un fallo durante las pruebas en cualquiera de las redes, se corrige y se empieza desde el primer paso, escribiendo una prueba unitaria para capturar el fallo, desplegando las correcciones en una red privada y así sucesivamente.
Presentación de las herramientas de verificación formal
Ahora, para avanzar en su proceso de pruebas, Zilliqa planea introducir «herramientas de verificación formal» para modelar el sistema. Los desarrolladores podrán entonces verificar formalmente el modelo generado e incluso la implementación. Sin embargo, las herramientas de verificación formal requieren muchas horas de trabajo. Pero, al mismo tiempo, son útiles para verificar «la corrección, la fiabilidad y la confiabilidad de los sistemas de software de misión crítica».
Zilliqa pretende combinar las dos funciones complementarias de las pruebas unitarias y la verificación formal. Esto ayudará a los desarrolladores a detectar cualquier problema de diseño o implementación relacionado con la parte crítica de la base de código.
Para disipar aún más estos problemas, Zilliqa tiene previsto reducir la frecuencia de las actualizaciones de la red. Esto dará más tiempo para probar las características existentes en su blockchain, y en la naturaleza.
En la última resolución de problemas, Zilliqa observó «un par de contratos inteligentes desplegados en la red principal en los que la lógica implementada hace que el estado del contrato crezca con nuevas transacciones». El equipo ahora afinará algunos parámetros que pondrán en evidencia los patrones de diseño subyacentes. Además, aportará mejor estática y dinámica para advertir a los desarrolladores en este sentido. El post de Reddit señala:
Suscríbete a nuestro boletín de noticias semanal.
Sin spam, sin mentiras, solo grande información. Puedes cancelar tu suscripción en cualquier momento.
Tenga en cuenta que estos contratos pueden funcionar bien por ahora, pero tarde o temprano pueden llegar al límite de gas de los bloques, haciendo que estos contratos sean inutilizables e invocables. Animamos a los desarrolladores a tener en cuenta este y otros patrones de diseño similares. Por ejemplo, si un contrato utiliza una lista y esa lista crece con cada transacción, esto puede crear problemas en el futuro para el contrato. Además, los contratos deben evitar los bucles siempre que sea posible, ya que los bucles en una lista o mapa muy grande alcanzarán el límite de gas de los bloques en algún momento.
