Resumen del progreso del desarrollo y anuncio de prueba de carga

¡El equipo de Credits se complace en presentar una nueva actualización de “Diario del Desarrollador”! Este artículo resume lo que se hizo desde la última versión del software en detalle y lo que debe hacerse aún más antes del próximo lanzamiento del software.
Además, estamos listos para anunciar la fecha de la Prueba interna de carga de la plataforma de Credits: el 31 de agosto. Podrá seguir el proceso de prueba en el canal oficial de Youtube y en el Monitor de Credits. Publicaremos un informe exhaustivo de pruebas técnicas unos días después del final de las pruebas.
Por el momento, la nueva versión del software está bajo prueba interna, estamos ejecutando el proceso de eliminación de errores y fallas. Los desarrolladores han encontrado soluciones a problemas importantes que se han determinado antes, por ejemplo, enrutamiento o VPN y problemas de sincronización. Puede usar la pestaña de la página principal del Monitor de Credits para descubrir que el problema de la VPN se ha solucionado y que cada dirección IP de nodo está visible ahora.
¿Qué se ha hecho desde la última actualización?
1) Problema de enrutamiento ha sido resuelto (VPN)
Los problemas de enrutamiento con los nodos que operan con NAT se han corregido de la siguiente manera en tres niveles:
1. La red ahora funciona bajo el protocolo IPv6;
2. Algunos proveedores de Internet no son compatibles con este protocolo, en este caso se usarán direcciones IPv4 blancas;
3. Los nodos que están más allá de NAT y no tienen dirección en blanco usarán el enrutamiento según el protocolo Bittorrent y en este caso un nodo “Blanco” servirá como enrutador para 3 o más nodos “grises”.
Por lo tanto, podremos involucrar un rango de direcciones disponibles para la conexión a la plataforma de Credits.
2) Se solucionó el problema de sincronización
Se requiere tener una base de datos de cadenas de bloques actualizada que contenga todos los bloques que se hayan firmado y enviado antes para que un nodo sea confiable y para participar en el proceso de validación de transacciones y en el procesamiento de bloques.
Para resolver este problema, se ha implementado la sincronización según el orden numérico. Por lo tanto, en ausencia de cualquier bloqueo, un nodo no podrá calcular el hash de toda la cadena y, por lo tanto, confirmará su derecho a convertirse en un nodo confiable.
3) Se optimizó el algoritmo de consenso y la arquitectura de red
La creación de un nuevo protocolo de red y la sincronización de bloques requirió una revisión importante de la parte de arquitectura de red. Cambiar el nivel de red e implementar la sincronización total y parcial afectó significativamente el trabajo de consenso de la red y requirió la implementación de funciones de verificación adicionales no solo en el protocolo de Tolerancia a fallas bizantinas (BFT), sino también en el nivel de verificación de paquetes entrantes, etc. .
Para evitar transferencias excesivas de bloques alrededor de la red y para minimizar el tiempo de entrega de bloques a todos los nodos de la red, se implementó un mecanismo de transferencia a todos los nodos vecinos a través del árbol de expansión. La lectura de un volumen de datos tan grande de la cadena consume mucho tiempo. El almacenamiento en caché se implementó para reducir el tiempo requerido para este proceso en la memoria, sin embargo, los requisitos de RAM se han aumentado a 6 GB.
¿En qué están trabajando actualmente los desarrolladores?
1) Incremento del volumen de memoria del monitor CREDITS.
Los desarrolladores llegaron a una conclusión, que el monitor de la plataforma requiere un mayor volumen de memoria, ya que está leyendo todos los datos de la plataforma. Esto se traduce en un consumo considerable de tiempo, especialmente al cargar todas las transacciones de una billetera o un contrato inteligente. Decidimos usar una base de datos relacional para resolver este problema, leyendo datos de los cuales es mucho más rápido que directamente desde una cadena de bloques.
2) Expansión de la funcionalidad de contratos inteligentes
Para que un contrato inteligente sea ejecutado simultáneamente por varios usuarios, se requiere un cambio dinámico en su estado varias veces por ronda. Para contratos inteligentes, getter mutante o estado es una transacción con una variable, su cambio puede ocurrir una vez por ronda. Una forma apropiada de resolver este tipo de tareas es usar el estado de contrato inteligente dividido. Es un cambio en el código del mismo contrato inteligente para múltiples usuarios. Al final de una ronda, el estado del contrato inteligente se combina y continúa funcionando dentro de ese contrato inteligente.
3) Implementación del conjunto de transacción
Para aumentar la velocidad de procesamiento de las transacciones, se planea usar el denominado ensamblaje de transacciones, en el que cada nodo sigue recopilando transacciones constantemente. Esto elimina la necesidad de enviar transacciones al nodo principal para su procesamiento por consenso de red; de lo contrario, estamos limitados por el ancho de banda del nodo principal en el momento de generar el grupo de transacciones no confirmadas.
4) Actualización de firma digital electrónica (EDS)
El tamaño de una transacción es un factor clave para lograr la velocidad de procesamiento requerida. Por lo tanto, EDS es una parte significativa de ese tamaño (64 bytes). En el caso de un rendimiento de 1 millón de transacciones por segundo, tenemos 64 MB de datos para enviar a toda la red en un segundo y la cuestión del tamaño es crítica para la plataforma en general. Estamos considerando la posibilidad de utilizar la firma Schnorr, cuya seguridad criptográfica comprobable tiene una longitud de firma de 48 bytes. También estamos considerando la posibilidad de usar multi firma.
El equipo de desarrolladores decidió que la próxima actualización de software debe cumplir con los requisitos de la versión estable de Lanzamiento de Candidato, que no tendrá errores serios y que estará lista para pruebas de valor completo por parte de socios y desarrolladores independientes. La versión actual en la que se realizará la prueba de carga interna es una versión intermedia y no presenta los problemas descritos anteriormente. Para resolver los problemas mencionados en el artículo, los desarrolladores requieren aproximadamente 3 semanas. Planeamos publicar una nueva versión en la segunda parte de septiembre. Siga nuestras actualizaciones en las redes sociales y verifique la primera etapa del proceso de prueba. Estén atentos, chicos!
