Traducción al español de “Architecting Shelley: an interview with Duncan Coutts”
Publicado por Eric Czuleger en el blog de IOHK el & de Abril de 2020
Una charla junto a con Duncan Coutts, el jefe de arquitectura técnica de Cardano, sobre Haskell y la entrega de Shelley
Duncan Coutts ha sido un guía importante en el camino hacia la red principal de Cardano Shelley. Los partidarios de IOHK están familiarizados con su característico pelo largo, barba y su afición a beber té mientras discuten la descentralización frente a una pizarra blanca. Recientemente se sentó para una entrevista para discutir el próximo reinicio Byron, la red de pruebas de Haskell Shelley, y la conclusión del ciclo de desarrollo previo a Shelley. Coutts, que ha estado trabajando con IOHK desde 2016, aporta una gran cantidad de conocimientos por haber trabajado con el lenguaje de programación de Haskell durante casi 20 años y por haber ayudado a fundar la consultoría Well-Typed.
¿Cuál es su papel en IOHK?
Soy el arquitecto técnico principal del proyecto Cardano y soy el principal responsable del diseño e implementación del nodo. Esto significa que colaboro con los equipos que trabajan en el consenso, el libro mayor, la red y otras cosas. En última instancia, trabajo para reunir a todos en torno al mismo diseño después de una discusión con los líderes de los equipos. El diseño de Cardano es el producto del trabajo conjunto de muchos individuos que trabajan juntos.
¿Qué aporta el lenguaje de programación Haskell a Cardano?
Haskell es un facilitador. Nos facilita seguir el enfoque que creemos correcto, que está impulsado por la informática. Sabemos cómo hacer las cosas correctamente; la informática nos dice cómo. Sólo tenemos que elegir las técnicas apropiadas para hacerlo. Haskell lo hace más fácil.
Es un buen ajuste para Cardano porque se adapta al software de alta seguridad y dirigido por especificaciones que es vital para una cadena de bloques. Haskell nos ayuda a encontrar formas sistemáticas de evitar errores. En esencia, es una mejor trampa para ratones.
Has estado trabajando con Haskell durante mucho tiempo. ¿Cómo ha visto cambiar el panorama de la programación funcional?
La gente se lo toma en serio ahora. Cuando empecé mi carrera en 1999, pensé que Haskell era increíble. Otros estudiantes pensaron: “Vaya, eso es totalmente impráctico”. ¿Cómo vas a conseguir un trabajo?
En ese momento, la programación funcional era una curiosidad académica. No había ningún código preconstruido y no era legible por la máquina, lo que significaba que Haskell no era utilizable para un amplio rango de personas. No había las herramientas, el rango de bibliotecas, o la experiencia. Eso ha cambiado a lo largo de los años: las herramientas mejoraron, las bibliotecas mejoraron. IOHK ha ayudado a desarrollar la infraestructura para construir y distribuir el código abierto de Haskell y el número de bibliotecas explotó. Eso, combinado con más enseñanza y un cambio gradual de actitud en la industria, significa que la gente lo toma más en serio ahora. Haskell no ha cambiado tanto como la industria que nos rodea.
¿Cuál es el mayor cambio desde el punto de vista de la industria?
Hay dos cosas. La primera es que las actitudes están cambiando, aunque lentamente. La gente está cambiando sus opiniones sobre lo que consideran una elección sensata del lenguaje. Antes, todo tenía que estar en C o Java o tal vez en Python, pero eventualmente las buenas ideas progresan, aunque tome mucho tiempo. Se puede progresar mucho con sólo reconocer que una buena idea es una buena idea. La corriente principal recoge los avances importantes, aunque tarde 10 o 15 años. La industria aún no ha adoptado la programación funcional al por mayor, pero los programadores individuales han tomado varias ideas. Eso hace que Haskell parezca menos radical.
Si observamos un lenguaje como Rust, tiene algunos de los sistemas inteligentes de Haskell, aunque no tiene ninguna idea de programación funcional. Incluso Java y C++ tienen algunas ideas de programación funcional en estos días, así que Haskell no está tan lejos de la corriente principal como solía estar.
El segundo gran cambio ha sido el rendimiento, que está mejorando mucho. Recientemente nos hemos vuelto competitivos con Java en términos de rendimiento. Hace que la gente diga: “Vaya, Haskell es muy rápido”, pero eso se debe a que lo comparan con Python y PHP en lugar de C. Así que esa es otra forma de decir que Haskell ha mejorado ligeramente, pero el entorno de la industria que lo rodea también ha cambiado.
Has estado muy involucrado en el reinicio Byron que se inició la semana pasada. ¿Por qué era importante este trabajo?
El reinicio Byron es la culminación de más de 18 meses de duro trabajo a través de múltiples equipos de desarrollo de IOHK, y constituye una completa revisión de la infraestructura del nodo con código 100% fresco. El reinicio introduce un diseño extensible y modular dentro del propio nodo, separando el libro mayor, el consenso y los componentes de red, así como mejoras y nuevas funcionalidades en el backend de billetera y el explorador Cardano.
Para los usuarios Daedalus, el reinicio de Byron nos verá pasar a una cadencia de actualización regular [ver nuestro reciente artículo sobre Daedalus Flight para más información], tras la cual deberían descubrir que el Daedalus es más rápido, más fiable y utiliza menos memoria. Muchos de los problemas que los usuarios han experimentado con Daedalus en el pasado se debieron al nodo subyacente, más que al propio Daedalus. El reinicio Byron mejorará mucho las cosas, y los usuarios deberían ver a Daedalus sincronizar y restaurar las billeteras en cuestión de minutos, incluso cuando se descargue todo la blockchain Cardano.
Como arquitecto jefe, tu trabajo es sentar las bases para el futuro de Cardano. ¿En qué te has centrado para conseguirlo?
El aspecto más importante en términos de flexibilidad para el futuro es mantener las diferentes funciones separadas. Una de las grandes mejoras del reinicio Byron es que las reglas del libro mayor serán totalmente independientes de la implementación del consenso; esta modularidad significa que las reglas del libro mayor son funciones matemáticas perfectamente limpias, lo cual es un aspecto central de la programación funcional.
Como resultado, todo es más fácil de probar, ajustar y cambiar, tanto ahora como en el futuro. El algoritmo de consenso no se enreda con los detalles de las reglas del libro mayor, por lo que podemos alterar las reglas del libro mayor sin cambiar la implementación del consenso. Esto hace que la integración de Plutus y la funcionalidad de los contratos inteligentes sea mucho más fácil y también ayudará en el futuro cuando añadamos características de tesorería y gobierno.
La implementación del consenso en sí misma también ha sido parametrizada de manera que podamos hacer la transición del protocolo de consenso de Ouroboros Classic a BFT y luego a Praos, lo que también proporciona flexibilidad para futuras versiones del protocolo que aún no han sido desarrolladas.
Shelley es un gran paso hacia el futuro de Cardano, pero ¿cuál es el significado de compilar Haskell en JavaScript y WebAssembly?
Estamos interesados en compilar a JavaScript o WebAssembly por Plutus. Queremos tener contratos de Plutus o aplicaciones de Plutus que puedan ser distribuidas a los usuarios, lo que incluiría interfaces personalizadas y lógica personalizada con el usuario en lugar de en un servidor. Compilar a JavaScript nos permite hacer eso; se puede compilar el código de Plutus una vez y distribuirlo a los usuarios en diferentes plataformas.
Gracias a Duncan Coutts por su tiempo. Como arquitecto técnico principal, es una piedra angular del proyecto Cardano y ha sido fundamental para el éxito continuo de la plataforma. Para más entrevistas con el equipo, manténganse en sintonía con nuestros canales sociales y el blog de IOHK.