🇫🇷 Architecture de Shelley : un entretien avec Duncan Coutts

Une conversation au coin du feu avec Duncan Coutts, l’architecte technique en chef de Cardano, sur Haskell et la livraison de Shelley

le 7 avril 2020, par Eric Czuleger, RĂ©dacteur en chef
texte original ici : ici
6 minutes de lecture
traduction : @JGA2020

Duncan Coutts a été un guide important sur le chemin du réseau principal de Cardano Shelley. Les supporters de longue date d’IOHK sont sans doute familiers avec ses cheveux longs, sa barbe et son penchant à boire du thé lorsqu’il discute de décentralisation devant un tableau blanc. Il a récemment accordé une interview pour discuter du prochain reboot de Byron, du testnet Haskell Shelley et des conclusions du cycle de développement pré-Shelley. M.Coutts, qui travaille avec IOHK depuis 2016, a une grande richesse de connaissances, qui lui viennent de son travail avec le langage de programmation Haskell depuis près de 20 ans, et de son aide à la création de la société de conseil Well-Typed.

Quel est votre rôle au sein d’IOHK ?

Je suis l’architecte technique en chef du projet Cardano et je suis principalement responsable de la conception et de la mise en œuvre du nœud. Cela signifie que je collabore avec les équipes qui travaillent sur le consensus, le registre, la mise en réseau et d’autres choses encore. En bout de ligne, je m’efforce de rassembler tout le monde autour d’une même réalisation, après discussion avec les chefs d’équipes. La conception de Cardano est le fruit du travail commun de nombreux individus travaillant ensemble.

Qu’est-ce que le langage de programmation Haskell apporte à Cardano ?

Haskell est un facilitateur. Il nous permet de suivre plus facilement l’approche que nous pensons être la bonne, qui est guidée par la science informatique. Nous savons comment faire les choses correctement ; l’informatique nous dit comment. Il nous suffit de choisir les techniques appropriées pour y parvenir. Haskell nous facilite la tâche.
Il convient parfaitement à Cardano parce qu’il est adapté pour des systèmes très fiables, basés sur des protocoles, ce qui est vital pour une blockchaine. Haskell nous aide à trouver des moyens systématiques d’éviter les erreurs. Fondamentalement, c’est une meilleure souricière.

Vous travaillez avec Haskell depuis longtemps. Comment percevez-vous l’évolution du paysage de la programmation fonctionnelle ?

Les gens la prennent maintenant au sérieux. Quand j’ai commencé à faire mes études en 1999, je me suis dit que Haskell était formidable. D’autres étudiants pensaient : « Wow, c’est totalement inutilisable. Comment vas-tu trouver un job plus tard ? ».

À l’époque, la programmation fonctionnelle était une curiosité académique. Il n’y avait pas de code pré-construit et ce n’était pas lisible par une machine, ce qui signifie qu’Haskell était inutilisable pour un grand nombre de personnes. Il n’y avait pas d’outils, de gammes de bibliothèques, ou d’expérience. Cela a changé au fil des ans : l’outillage s’est amélioré, les bibliothèques se sont améliorées. IOHK a aidé à développer l’infrastructure pour construire et distribuer le code open-source de Haskell et le nombre de bibliothèques a explosé. Cela, combiné avec plus d’enseignement et un changement progressif d’attitude dans l’industrie, signifie que les gens prennent cela plus au sérieux maintenant. Haskell n’a pas tellement changé, contrairement à l’industrie qui nous entoure.

Quel est le plus grand changement du point de vue de l’industrie ?

Il y a deux choses. La première est que les attitudes changent, bien que lentement. Les gens changent leurs opinions sur ce qu’ils considèrent comme un choix de langage judicieux. Auparavant, tout devait être en C ou en Java ou éventuellement en Python, mais les bonnes idées finissent par progresser, même si cela prend beaucoup de temps. Vous pouvez faire beaucoup de progrès en reconnaissant simplement qu’une bonne idée est une bonne idée. Le courant dominant reprend les développements importants, même si cela prend 10 ou 15 ans. L’industrie n’a pas encore adopté la programmation fonctionnelle en bloc, mais les programmeurs individuels ont repris diverses idées. Cela donne à Haskell une apparence moins radicale qu’auparavant.

Si vous regardez un langage comme Rust, il a certains des systèmes de type intelligent de Haskell, bien qu’il n’ait pas l’idée de programmation fonctionnelle. Même Java et C++ ont des idées de programmation fonctionnelle de nos jours, donc Haskell n’est plus aussi éloigné du courant de pensée dominant qu’il l’était auparavant.

Le deuxième changement majeur a été la performance, qui s’améliore considérablement. Nous sommes récemment devenus compétitifs par rapport à Java en termes de performances. Cela fait dire aux gens : “Wow, Haskell est super rapide”, mais c’est parce qu’ils le comparent à Python et PHP plutôt qu’à C. C’est donc une autre façon de dire que Haskell s’est légèrement amélioré, mais l’environnement industriel qui l’entoure a aussi évolué.

Vous avez été fortement impliqué dans le reboot Byron qui a été lancé la semaine dernière. Pourquoi ce travail était-il important ?

Le reboot Byron est l’aboutissement de plus de 18 mois de travail acharné de la part de plusieurs équipes de développement d’IOHK, et constitue une révision complète de l’infrastructure du nœud avec un code entièrement nouveau. Le reboot introduit une conception extensible et modulaire au sein du nœud lui-même, en séparant le registre, le consensus et les composants de réseau, ainsi que des améliorations et de nouvelles fonctionnalités dans le backend du portefeuille et dans l’explorateur Cardano.

Pour les utilisateurs de Daedalus, le reboot Byron nous fera passer à une cadence de mise à jour régulière [voir notre récent article à propos de Daedalus Flight pour en savoir plus], après laquelle ils devraient constater que Daedalus est plus rapide, plus fiable et utilise moins de mémoire. Beaucoup de problèmes que les utilisateurs ont rencontrés avec Daedalus dans le passé étaient dus au nœud sous-jacent, plutôt qu’à Daedalus lui-même. Le reboot de Byron contribuera grandement à améliorer les choses, et les utilisateurs devraient voir Daedalus se synchroniser et restaurer les portefeuilles en quelques minutes, même en téléchargeant la chaîne complète de Cardano.

En tant qu’architecte en chef, votre travail consiste à jeter les bases de l’avenir de Cardano. Sur quoi avez-vous mis l’accent pour y parvenir ?

L’aspect le plus important en termes de flexibilité pour l’avenir est de garder les différentes fonctions séparées. L’une des grandes améliorations du reboot Byron est que les règles du registre seront totalement indépendantes de la mise en œuvre du consensus ; cette modularité signifie que les règles du registre sont des fonctions mathématiques parfaitement propres, ce qui est un aspect essentiel de la programmation fonctionnelle.

Par conséquent, tout est plus facile à tester, à ajuster et à modifier, aujourd’hui comme dans le futur. L’algorithme de consensus n’est pas empêtré dans les détails des règles du registre, de sorte que nous pouvons modifier les règles du registre sans changer l’implémentation du consensus. Cela rend l’intégration de Plutus et des fonctionnalités de smart contracts beaucoup plus facile et sera également utile à l’avenir lorsque nous ajouterons des fonctionnalités de trésorerie et de gouvernance.

La mise en œuvre du consensus elle-même a également été paramétrée de manière à ce que nous puissions passer du protocole de consensus Ouroboros Classic au BFT puis au Praos, ce qui offre également une certaine flexibilité pour les futures versions du protocole qui n’ont pas encore été développées.

Shelley est un grand pas vers l’avenir de Cardano, mais quelle est l’importance de compiler Haskell en JavaScript et WebAssembly ?

Nous sommes intéressés par la compilation en JavaScript ou WebAssembly à cause de Plutus. Nous voulons avoir des contrats Plutus ou des applications Plutus qui peuvent être distribués aux utilisateurs, ce qui inclut des interfaces personnalisées et une conception adaptée à l’utilisateur, plutôt que sur un serveur. La compilation en JavaScript nous permet de le faire ; vous pouvez compiler le code Plutus une fois et le distribuer aux utilisateurs sur différentes plateformes.

Merci à Duncan Coutts pour le temps qu’il nous a consacré. En tant qu’architecte technique en chef, il est une pierre angulaire du projet Cardano et a joué un rôle fondamental dans le succès continu de la plateforme. Pour d’autres interviews avec l’équipe, restez connectés à nos chaînes sociales et au blog de l’IOHK.

1 Like