Transcripción al español de “Surprise AMA 03/19/2020”
Del minuto 22:30 al 25:35 del video original
Publicado en el canal de Youtube de Charles Hoskinson el 19 de Marzo de 2020
Enlace a la versión doblada al español
Los nodos están consumiendo más RAM con cada actualización, aproximadamente 2,5 gigabytes en la 8.15, ¿Haskell consumirá menos?
Sí, mucho menos, ha sido perfilado para eso, con suerte tendremos algunos puntos de referencia para ustedes chicos en el reinicio y eso es un buen indicador de cuándo Shelley se va a entregar porque comparten tanto código, es alrededor de un 80% de superposición de código y tienen el mismo diseño de red. Por lo que el lado Haskell no es un gran consumidor de eso, la razón por la que ves una alta utilización de los recursos de la CPU, de red y RAM para el nodo Jormungandr, es casi siempre por una desoptimización o una fuga de espacio o un cierto defecto como consecuencia de la alta velocidad y en general lo que sucede es que arreglan esas cosas de manera iterativa. Así que hemos tenido muchos casos de picos en la red y picos en la CPU y otras cosas que de vez en cuando aparecen y te recortan, tienes que tener una compensación en algún lugar de tu perfil de desarrollo, estás optimizando alrededor de un giro rápido, lo que significa que cada semana empujas algo al usuario, significa que no tienes un tiempo suficiente para tener un ciclo de control de calidad independiente. Lo que significa que la gente que no son los desarrolladores o lo están probando y ejecutándo, examinando y viniendo nuevamente y trabajando con los desarrolladores para corregir los defectos que encuentran en su semana de pruebas y también están cambiando las cosas rápidamente todo el tiempo, así que es difícil de crear pruebas estables semanales, es casi como un virus que muta todo el tiempo, es realmente difícil crear una vacuna para que sea correcta, así que de manera similar es difícil crear un perfil adecuado cuando siguen cambiando las cosas tan rápidamente. Por otro lado, puedes arreglar cosas realmente rápido, así que si no te gusta la 8.15 tal vez 8.16 resuelve tu problemas y hay una regresión en 8.17 pero se obtiene una nueva característica genial o arregla otro error que te preocupaba. El punto de Jormungandr y Cardano Rust no era la estabilidad y no era un producto final, era para probar la experiencia de usuario de staking y nos permite saturar una gran cantidad de stake pools en condiciones económicas reales y esa es una misión cumplida por mucho, más de 1100 stake pools registrados y más de trescientos, cuatrocientos de ellos operando con bastante regularidad y en realidad con nuestro ejercicio de interacción de stake pools estamos viendo a muchos de ellos hacer videos ahora, lo que es súper emocionante, mantén esos videos viniendo.
Como una consecuencia no deseada, porque Vincent y sus chicos son simplemente perfeccionistas, vemos en realidad mucha más estabilidad y corrección de errores con la ITN. Así que si se les hubiera dado unos pocos meses de libertad y el protocolo se estabilizó un poco, el cliente se estabilizó, probablemente hubiéramos visto una gran cantidad de optimización y probablemente sería el caso que el código Rust use menos memoria y CPU que el código Haskell, porque es un lenguaje de nivel inferior y hay más control de esas optimizaciones, sabemos como sería el caso, me refiero al usar tipos lineales con Haskell, probablemente podrías conseguir un rendimiento equivalente, pero eso no está en el alcance o soportado aún.