🇪🇸 Actualización de Desarrollo Testnet Incentivada Shelley | IOHK 14 Feb 2020

:es: Traducción al español de “Shelley Incentivized Testnet Development Update 14 February 2020

Publicado en el canal de Youtube de IOHK el 14 de Febrero de 2020

Enlace a la versión doblada al español


Hola a todos. Soy Dimitris otra vez, de vuelta por otra semana para compartir una rápida actualización del progreso de la Tesntet Incentivada Shelley. Gracias por todos sus comentarios sobre estas actualizaciones semanales de video. Ha sido genial recibir vuestras opiniones sobre cómo podemos mejorarlas. Nos alegra que las encuentren útiles y seguiremos intentando traerles más información útil en el futuro.

La estabilidad de la red sigue siendo nuestro objetivo y hemos visto mejoras significativas en la disponibilidad de los nodos desde que sacamos 0,8,9 con un aumento del tiempo de funcionamiento a un promedio muy superior al 90%. La semana pasada, decidimos renunciar a la actualización regular del Miércoles de Jormungandr en la Testnet Incentivada para poder apuntar a una versión de extremo a extremo para esta semana y poner a disposición algunas nuevas características también.

Así que eso nos lleva a esta semana. Hemos lanzado una nueva versión del Nodo 0.8.10-2. En el momento en que estoy grabando este video estamos finalizando la integración con Daedalus y el backend de billetera. Esperamos que estén disponibles más tarde o poco después del fin de semana, dependiendo del progreso de las actividades de control de calidad. Juntos, esperamos que esto continúe mejorando la experiencia tanto para los operadores de stake pools como para los titulares de ADA.

El lanzamiento de esta semana de Jormungandr contiene dos semanas de trabajo que debería traer mejoras en la selección y calidad de la cadena y debería ayudar con los problemas de bifurcación. Lo más destacado del lanzamiento incluye mejoras en la gestión asíncrona/multihilo, y un mejor manejo de las conexiones de los clientes por el nodo.

Actualizaciones del código asíncrono. El equipo ha estado ansioso por empezar a portar un año de futuro trabajo 0.1 a la pila async… Esto ha comenzado y nos ha permitido limpiar algunos de los problemas de rendimiento y de bloqueo que teníamos.

Los módulos de liderazgo, la cadena, el REST y el pool de fragmentos del nodo han sido actualizados y mejorados. Ahora hay menos puntos de bloqueo con el riesgo de crear retrasos en los eventos de liderazgo lo cual será apreciado por el operador de stake pools.

Ahora hay un límite en las conexiones gRPC del lado del cliente que se mantienen vivas para recibir las actualizaciones de suscripción de los compañeros, regidas por el parámetro de configuración max_client_connections. La intención es reducir el número total de conexiones ociosas en la red y mejorar la fiabilidad de la conexión para los nodos no públicos detrás de NAT.

Hay varias mejoras en esta versión del nodo, añade las consultas entre pares al protocolo de la red. Esto se usará en una futura actualización para quitar la carga de arranque de los pares de confianza. Integra el Multiverso sin cerraduras en la cadena de simulación. Elimina el bloqueo síncrono de la llamada estructura de datos “multiverso”. Esto es parte del trabajo para eliminar los problemas de rendimiento observados. Mejora el registro del notificador atascado. Impone un límite menor separado a las conexiones persistentes del lado del cliente, por defecto a 8 conexiones a la vez. Esto se hizo limitando el número de conexiones gRPC del cliente, usando GC para cerrar el exceso. Esto debería reducir el número de conexiones ociosas en la red, y hacer la conectividad más robusta para los nodos no públicos detrás de un NAT.

Hay varias correcciones de errores también, sólo estoy mencionando un par aquí, primero que todo estaba el reporte que informaba que se veía el pool seleccionado en vez de todo el sistema y otro estaba relacionado con un observador estando disponible muy tarde, lo que sugería que el tiempo del sistema podría estar apagado… Lo que arregla un molesto error de bloqueo que fue reportado por primera vez en la versión 0.8.6.

También algo de limpieza de la casa que tuvo lugar, asincronización del proceso de entrada. Portando partes de Jormungandr a std::future,la moderna API Rust async. No truncar la lista de pares para la propagación; revertir un cambio hecho en la versión anterior que afectó negativamente la homogeneidad de la red. Actualizar el libro mayor a ed25519 firmando al nuevo cierre de firma

Más detalles pueden ser encontrados como siempre en el repositorio de Jormungandr bajo la etiqueta de último lanzamiento Release v0.8.10-2 · input-output-hk/jormungandr · GitHub

Y también, sólo un pequeño resumen de lo nuevo en Daedalus y el backend de billetera, cuáles son los cambios a implementar, igual les haremos saber en cuanto estén disponibles, pero no lo están, por lo menos al momento de este video.

Básicamente, las nuevas características que introduciremos en Daedalus, junto con los cambios en el backend de billetera, tienen como objetivo mejorar el rendimiento de la sincronización e introducir nuevas capacidades como el soporte de Yoroi y la restauración de billeteras de dispositivo. El equipo también ha añadido la clasificación de stake pools como una característica experimental. Esto necesitará algunos ajustes adicionales en las próximas semanas, pero por favor, compruébalo. También hemos hecho algunos cambios en el backend que deberían ayudar a resolver las ocurrencias de balance cero que todavía están siendo vistas por algunos de los usuarios.

Así que sólo para resumir, tenemos algunos de los elementos clave que incluyen:

Restauración de la billetera de dispositivo Ledger y Trezor

Soporte para la billetera Yoroi

Resincronizar la billetera con la blockchain

Ranking de stake pools basados en la desabilidad

Detalles de stake pools que ahora incluyen la saturación

Arreglo del asunto de balance cero

Le haremos saber, como ya he dicho, tan pronto como esta nueva versión de la Billetera esté disponible. En términos de cuál es el plan para la semana que viene, ahora que la red es más estable que antes, finalmente hemos comenzado el movimiento hacia Rust async/await. Este es un momento muy emocionante para el equipo ya que fue una característica muy esperada del Lenguaje de Programación Rust. Esto nos permitirá escribir un código más limpio y conciso y también mejorar mucho el rendimiento. También hay algunos asuntos que fueron movidos de nuestro backlog para la próxima semana, los principales incluyen la lista negra de la red desde el archivo de configuración. Picos de conexiones TCP antes de quedarse atascado. Enclave para evitar líderes duplicados.

Algunas actualizaciones generales, también tenemos algunas piezas de contenido generado por la comunidad esta semana, pueden mirar eso.

Respecto al soporte, los tickets relacionados con la sincronización y la conexión aún constituyen la mayoría de los tickets recibidos por nuestro equipo de soporte. A medida que continuamos mejorando la red debería haber una reducción de estos incidentes. Para los usuarios que están esperando una solución, los tickets se colocan en estado de espera, contribuyendo a nuestro backlog. Si están esperando una resolución a un problema relacionado con la sincronización o la conexión, pueden esperar una actualización del Escritorio de Soporte Técnico de IOHK en los próximos días.

Algunas estadísticas respecto a los tickets

Nuevos incidentes - 671

Incidentes resueltos - 513

Incidentes atrasados - 1.314

Del lado DevOps también hemos aumentado la cantidad de conexiones permitidas de compañeros sin direcciones IP alcanzables, básicamente los clientes Daedalus.

Espero que esta breve actualización les haya sido útil. Volveré la semana que viene con lo último sobre el progreso de ITN. Gracias por mirar.

1 Like