🇫🇷 Le "Combinateur" facilite la bifurcation vers Shelley

[Psychomb]

Auteur : Anthony Quinn

Traduction : @psychomb

Depuis que le lancement du testnet incitatif (ITN) a marqué l’arrivée de l’ère Shelley l’année dernière, la plateforme Cardano est entrée dans une période de développement rapide. Le protocole de consensus Ouroboros Classic fait vivre Cardano Byron et la cryptomonnaie ada depuis 30 mois, et nous allons bientôt passer à Ouroboros Praos. C’est la version de notre protocole de preuve d’enjeu (PoS) qui, dans un premier temps, permettra à Shelley de fonctionner au fur et à mesure de la décentralisation de Cardano. Il intègre le processus de mise d’enjeu avec des récompenses monétaires pour les détenteurs d’ada et les propriétaires de groupe d’enjeu.

Nous avons mis à jour Cardano le 20 février dernier avec une bifurcation (ou “hard fork”) qui a fait passer le réseau principal du protocole de consensus original, Ouroboros Classic, à une version mise à jour, Ouroboros BFT. Cette bifurcation utilisant Ouroboros BFT, une version allégée du protocole conçue pour nous aider à passer à Praos, a entamé une période de transition tout en empêchant tout comportement malveillant. Beaucoup ne l’ont probablement même pas remarqué. Pour les utilisateurs du portefeuille Daedalus, cela signifiait une mise à jour logicielle standard. Les plateformes d’échanges devaient faire la mise à jour manuellement, mais elles avaient plusieurs semaines pour le faire et nous étions là pour les aider.

L’événement suivant a été le “Byron reboot”, le 30 mars. Ce dernier a permis la mise en place d’un code totalement nouveau pour de nombreux composants de Cardano, y compris un nouveau nœud pour soutenir la délégation et la décentralisation, ainsi que les futures fonctionnalités de Shelley. Un grand avantage de ce nouveau code est qu’il a été conçu pour être modulaire, de sorte que de nombreux composants peuvent être modifiés sans affecter les autres.

Ouroboros BFT servira à son tour de point de départ pour la bifurcation Shelley, qui se produira une fois que nous serons satisfaits du réseau de test Haskell (“Testnet Haskell”). Cette deuxième bifurcation sera un processus similaire à celle du mois de février pour les plasteformes d’échanges, les détenteurs d’ada et les utilisateurs de portefeuilles, et sera aussi, espérons-le, non-événement tout comme la première.

Cependant, si tout semble lisse en surface, beaucoup d’activités se déroulent cachées. Comme un canard qui nage sereinement dans un étang - alors que ses pattes pagaient furieusement sous les eaux calmes - nos ingénieurs travaillent au maximum.

Nous avons donc réuni deux des principaux ingénieurs du projet Cardano, Duncan Coutts et Edsko de Vries, pour savoir comment ils s’y sont pris. Duncan est le responsable de l’architecture de Cardano depuis trois ans, et à eux deux, Duncan et Edsko cumulent 35 ans d’expériences de Haskell, le langage de programmation utilisé pour développer Cardano.

Duncan, comment vous y êtes-vous pris ?

Comme décrit dans la feuille de route Cardano, les ingénieurs d’I.O.H.K. croient en des mises à jour de code sans heurts. Au lieu d’essayer de faire le saut de Ouroboros Classic à Praos en une seule mise à jour - ce qui aurait été une tâche incroyablement complexe - il s’agit ici d’une approche en deux étapes utilisant Ouroboros BFT comme intermédiaire (figure ci-dessous). Le code BFT est compatible à la fois avec les nœuds fédérés de l’ère Byron et les nœuds de type Shelley mis en place lors du redémarrage de Byron (Byron Reboot). C’est comme une course de relais : un coureur (dans notre cas, exécutant un protocole) entre dans la zone de transfert où l’autre coureur l’attend ; ils synchronisent leurs vitesses (de sorte qu’elles sont parfaitement compatibles entre elles) et se passent le témoin (le réseau principal), puis le nouveau coureur avec le témoin continue à partir de cette zone de transfert pour le tour suivant.

Le programme Daedalus Flight nous a permis de développer et de tester rapidement un nouveau portefeuille et, une fois que tout le monde l’utilise sur le réseau principal, et que nous avons fini de changer les nœuds principaux, l’ancien code devient alors inutile. Nous sommes actuellement dans cette phase de transition, avec un nouveau portefeuille Daedalus sur le réseau principal, sorti le 24 avril.

Notre objectif est d’avoir une “entrée gracieuse dans Shelley”, comme le décrit Charles Hoskinson, C.E.O. d’I.O.H.K., dans sa vidéo concernant la bifurcation à venir. Un outil essentiel pour y parvenir a été la création d’un combinateur de bifurcation.

Cela ressemble à un nom de machine infernale. Qu’est-ce que c’est ?

Un combinateur est juste un terme technique désignant quelque chose qui arrange plusieurs choses entre elles. Par exemple, l’addition est une combinatoire sur des nombres. Un combinateur de bifurcation combine deux protocoles en un seul. Nous appelons cela une combinaison séquentielle des deux protocoles parce qu’il exécute le premier protocole pendant un certain temps et à un moment donné, il passe au second. Dans notre cas, il s’agit de deux versions d’Ouroboros lorsque nous passons de Ouroboros BTF à Praos.

L’astuce a consisté en l’utilisation de modules distincts, faisant leur travail le plus indépendamment possible les uns des autres et aussi de la blockchain. La simplicité est ici la clé, ainsi que l’abstraction - processus qui consiste à éliminer les détails. La plupart des modules de consensus n’ont même pas besoin de savoir qu’ils traitent une cryptomonnaie et pourraient mettre à peu près n’importe quoi sur une blockchain. Par exemple, nous avons organisé des séminaires en utilisant l’exemple d’un registre de Pokémons sur une blockchain Ouroboros. La seule chose qui diffère, ce sont les règles du registre ; le consensus est le même. Il suffit de le mettre en place - “l’instancier” dans le jargon de la programmation - avec les règles permettant de jouer aux Pokémons plutôt que pour gérer une comptabilité de type UTXO [pour les lecteurs ayant un intérêt technique, Edsko approfondira le processus d’“abstraction” et les combinateurs dans un prochain billet de blog].

Quand vous le dites, cela a l’air simple

En réalité, c’est délicat parce que Cardano gère la cryptomonnaie ada, et plein d’autres choses en même temps. Imaginez vous changer toutes les roues d’une voiture pendant que vous roulez avec en plus une une caravane. Nous devons donc nous assurer que nous pouvons le faire de manière totalement sûre.

Nous aurions pu nous attaquer à ce problème de manière ponctuelle, mais il était logique de le faire de manière générique en utilisant un combinateur de protocole. Nous avons choisi cette voie parce que nous obtenons un meilleur résultat et que les tests qui sont essentiels pour garantir le fonctionnement du code sont beaucoup plus faciles. De plus, il y aura d’autres bifurcations difficiles à venir, ce qui a rendu ce choix encore plus clair. Par exemple, lorsque nous approcherons du point culminant du développement de Cardano et que nous traverserons pour cela les époques Goguen, Basho et Voltaire, il y faudra prévoir au moins une bifurcation à chacune de ces étapes.

Comment avez-vous fait face aux difficultés ?

Eh bien, tout d’abord, nous avons dû le faire sans nous tourner vers la recherche. Les chercheurs décrivent un seulement un protocole en tant que chose parfaite et autonome. Mais nous n’en sommes pas là. Nous essayons de faire fonctionner Ouroboros Praos après avoir commencé avec une blockchain qui utilisait quelque chose d’autre. Ce sur quoi Edsko travaille, passer d’un protocole à l’autre de manière générique, n’est tout simplement pas étudié par la recherche. Et c’est difficile, c’est compliqué. Tous les détails nécessitent beaucoup de réflexion, de se creuser la tête. Mais passer d’un code Cardano à l’autre n’est pas le genre de chose que les universitaires peuvent s’attendre à voir publié. Cela n’a pas d’aspect nouveau et est donc considéré comme une simple question de mise en œuvre.

Edsko, pouvez-vous nous donner un exemple ?

Comme l’a dit Duncan, pour les chercheurs, ces questions de mise en œuvre sont insignifiantes, mais les traiter représente 99 % de ce que nous faisons. Prenez le problème du temps pour une blockchain. C’est ce contre quoi je me suis battu pendant quelques semaines. Le temps est divisé en créneaux où la blockchain peut contenir au maximum un bloc par créneau. Dans le monde réel, nous devons souvent faire la conversion entre le nombre de créneaux et le temps réel, par exemple lorsqu’un nœud doit savoir que c’est son tour de générer le bloc suivant. C’est fondamental pour Cardano, mais la longueur d’un créneau changera après la bifurcation. Pour Byron, un créneau dure 20 secondes ; pour Shelley, il sera de deux secondes, voire peut-être même d’une seconde. Pour compliquer les choses, le moment exact de la bifurcation est décidé sur la blockchain elle-même. Or, je dois savoir quand le point de bascule est atteint. C’est un dilemme : pour faire des conversions de créneaux en temps, j’ai besoin de connaître l’état de la blockchain, mais pour en connaître l’état, j’ai besoin de connaître les conversions de créneaux !

C’est un véritable dilemme de la poule et de l’œuf, avec de nombreuses choses complexes à démêler. Nous devons être très précis dans notre façon de faire les choses. C’est peut-être insignifiant en théorie, mais il est très difficile de démêler les choses et de s’assurer que ce n’est pas un problème circulaire.

Nous ne pouvons pas nous permettre de nous tromper, alors comment savez-vous que vous avez raison ?

Duncan : C’est une excellente question. Ma réponse est que l’on attaque cela sur deux plans. Le premier est intellectuel : vous analysez le problème, vous faites les calculs, vous discutez avec vos collègues et vous luttez avec ce problème jusqu’à ce que vous puissiez voir comment tout cela s’assemble. Deuxièmement, nous faisons tous nos tests avec QuickCheck pour nous assurer que le code fait bien ce que nous pensons qu’il fait. Nous effectuons des tests approfondis qui nous amènent vraiment dans des cas de figure inhabituels auxquels personne ne pourrait penser, y compris dans le cas de ce changement de consensus. Nous pouvons effectuer 100 000 tests chaque fois que nous changeons une ligne de code. [Lars Brünjes a écrit sur la façon dont John Hughes, un des créateurs de Haskell, a aidé I.O.H.K. à développer ses stratégies de test].

Edsko : Oui, je suis d’accord avec ces deux points. En ce qui concerne le combinateur, je résous ces choses en pensant aux garanties que le code que j’écris doit fournir, et aux garanties qu’il doit, à son tour, obtenir du registre. J’esquisse une preuve mathématique que ce raisonnement “si - alors” est effectivement justifié, puis je me tourne vers les équipes de la méthode formelle. Les équipes de méthodes formelles sont les personnes qui établissent les règles mathématiques qui décrivent la blockchain et elles peuvent ensuite en modifier les règles de manière à ce qu’elles fournissent les garanties requises.

En ce qui concerne le deuxième point de Duncan, je sais que le problème de temps que j’ai mentionné plus haut est correct en réfléchissant bien, mathématiquement, et en testant. Il est facile de prendre des décisions en matière de temps lorsque nous disposons de toute la blockchain, mais c’est difficile lorsque nous devons faire des prévisions sur l’avenir. Heureusement, la façon dont nous organisons les choses me permet de créer facilement des blockchains de tests. Ainsi, je peux créer une blockchain complète, puis la couper en deux. Je prends la première moitié et je la considère comme étant dans le présent ; et je place l’autre moitié dans le futur. Ensuite, je peux utiliser le “présent” (première moitié) pour faire des prédictions sur le “futur” (deuxième moitié) et vérifier ces prédictions par rapport à l’ensemble (sur lequel les calculs sont faciles). Si les deux correspondent, je sais que tout est correct.

Quand avez-vous commencé à travailler là-dessus ?

Juste après que Duncan eut l’idée géniale d’Ouroboros BFT. J’ai donc pensé au combinateur pendant environ 18 mois. C’était un objectif de conception dès le début de notre réécriture modulaire d’Ouroboros à partir d’octobre 2018, avec mes premières lignes de code dans le dépôt GitHub. Nous avons eu une démonstration du prototype avec Ouroboros BFT et Praos peu après, en décembre 2018.

Et combien de personnes ont été impliquées ?

Duncan : Beaucoup de gens ont travaillé sur le code de consensus, mais chaque fois que nous avons quelque chose de vraiment difficile, comme ce combinateur, nous le donnons à Edsko : c’est notre ingénieur logiciel hors pair ! C’est de la programmation Haskell telle de l’escalade libre, sans les cordes de sécurité apportées par les méthodes formelles.

Un dernier mot ?

Duncan : Le code qui fonctionnait il y a un mois est en train d’être supprimé et bientôt il n’existera plus. Une fois que tout le monde aura basculé sur le nouveau code sur le réseau et que nous aurons fini de changer les nœuds principaux, l’ancien code sera inutile. Nous sommes actuellement dans cette phase de transition et personne ne crie que le ciel nous tombe sur la tête. Personne ne l’a remarqué.

Edsko : C’est une belle réussite en soi. L’idée de Ouroboros BFT était cruciale pour la transition, mais elle ne sera plus pertinente une fois que nous aurons fait la transition vers Shelley. Cela a été une façon pour nous de nous débarrasser véritablement de l’ancien code, ce qui est souvent très difficile à faire, comme les banques le savent à leurs dépens.

Duncan : Et si tout fonctionne bien, vous ne remarquerez rien.

Traduction de : https://iohk.io/en/blog/posts/2020/05/07/combinator-makes-easy-work-of-shelley-hard-fork/