Duniteroxyde - étape 3: pow cluster (+ refacto module prover)
Cette 3ème étape m’a demandé environ 70h de travail (10 jours a temps plein) et n’est pas encore totalement stabilisée, il reste quelques bug mais j’ai suffisamment avancé pour ouvrir la phase de tests 
Attention: pour ceux qui compilent Duniter manuellement (cc @Moul), la procédure a changée :
La procédure pour compiler manuellement est désormais documentée ici : https://git.duniter.org/nodes/typescript/duniter/-/blob/dev/doc/use/manual_compilation.md
Le code Rust devant plus conséquent, son temps de compilation augmente, il est donc désormais compilé en mode « debug » par défaut, ce qui permet de gagner un temps considérable lors du développement.
Mais du coup, quand on veut compiler Duniter pour l’utiliser, il faut setter une variable d’environnement pour indiquer a Neon de compiler le code en mode « release ».
Tester
Pour ceux qui souhaitent tester l’oxydation de la pow, voici les paquets permettant de tester :
server x64: https://pub.librelois.fr/duniter-server-oxyde-pow-linux-x64.deb
server arm: https://pub.librelois.fr/duniter-server-oxyde-pow-linux-armv7l.deb
desktop x64: https://pub.librelois.fr/duniter-desktop-oxyde-pow-linux-x64.deb
Merci de tester uniquement sur la monnaie de test pour le moment !
Votre noeud devrait alors trouver des blocs beaucoup plus rapidement, pensez donc a réduire votre % cpu avant de faire la mise à jours.
Cependant, dès que votre difficulté personnalisée augmentera, votre noeud n’utilisera plus qu’un seul cœur pour calculer la pow, c’est le fameux mode ECO, cela devrais donc éviter un emballement de la difficulté du réseau
1ère étape de migration du code Typescript
Cette étape est la 1ère vrai étape de migration du code Typescript de Duniter. En effet, les deux premières étapes se limitaient au remplacement de addons C/ C++, ici c’est pour la première fois du code Typescrypt qui a été migré.
Migrer la pow était pour moi l’étape parfaite pour monter en compétence, car elle concerne un module (le module prover) relativement « cloisonné » du reste de l’application et que la « logique métier » corresponde est simple, avec assez peu d’entrées/sorties.
Cette étape m’a également demandé d’aller beaucoup plus loin dans les fonctionnalités de Neon (le « framework » qui gère le binding NodeJs<->Rust). En effet, on est plus dans un simple appel de fonction Rust, là il faut que le code Rust vive sa vie indépendamment puis « notifie » le code NodeJs lorsqu’il a trouvé un hash conforme à la pow.
Pour ce faire, je me suis inspiré de cet exemple fourni par Neon afin de créer un EventEmitter wrappant un channel rust.
Le fait qu’il soit possible d’émettre des événements coté Rust et qu’il soient reçus coté NodeJs ouvre des perspective très intéressantes, et me rassure beaucoup quand a la possibilité technique d’une oxydation beaucoup plus poussée.
Tout cela a demandé plus de temps que prévu car je me suis également lancé dans une refonte quasi complète du module prover (en Typescript toujours), donc j’ai aussi bouffé beaucoup de Typescript.
Pourquoi je me suis lancé dans cette refonte :
Au début, le code Rust fonctionnais parfaitement (avec ses tests) mais une fois bindé au module prover rien ne marchais, ça pétais dans tout les sens. J’ai donc du me plongé dans le code du module prover, et il m’a semblé bien trop complexe, avec trop de couches intermédiaires et plein de truc bizarres, je ne m’y retrouvais pas, j’ai failli jeter l’éponge a ce moment là.
Comme la logique métier que doit implémenter le module prover est relativement simple, je me suis dit qu’il serait plus simple pour moi de réécrire quasi entièrement le module prover (toujours en Typescript) plutôt que d’essayer de démêler l’existant, en me basant sur les nombreux tests automatisés écris par @cgeek pour sécuriser mon refactoring.
Et globalement je suis plutôt content du résultat, le module prover semble bien fonctionner, tout les tests passent, j’en ai même ajoutés
Bon comme dit plus haut il reste encore au moins un bug a corriger, un ralentissement du module BMA que @Moul rencontre également. Et je suis sûr qu’avec vos tests on va en débusquer d’autres, mais c’est normal d’avoir quelques régressions quand on fait de si gros changement, les tests automatisés ne peuvent hélas pas tout couvrir.
Maintenant nous allons rentrer dans une phase de tests intenses et de stabilisation, et dès que l’oxydation de la PoW sera stabilisé je livrerai Duniter 1.8.0-beta et je lancerais la campagne de tests associée (avec son cahier des tests).
Pour le moment, je compte sur @Moul @vit @matograine @scanlegentil @Attilax et @cgeek pour tester l’oxydation de la pow, et quand cette feature sera stabilisé et mergée on fera une campagne de tests plus large (incluant plus d’utilisateurs) pour Duniter 1.8 dans sa globalité
Je ne sais pas combien de temps prendra cette stabilisation, et je vais avoir des obligations personnelles entre le 7 et le 17 mai, donc il est probable que la version « stable » de Duniter 1.8 ne sorte que vers le 20/25 mai.
).