Discussions autour du developpement de duniter-rs (Duniter en Rust)

Un tutoriel en français sur Rust qui me semble bien plus professionnel : https://blog.guillaume-gomez.fr/Rust

3 « J'aime »

Si des personnes sont intéressées pour contribuer ou simplement pour s’entraîner en Rust, plusieurs issues ont été ouvertes. N’hésitez pas à poser des questions en commentaire de l’issue ou ici si vous avez besoin d’aide :slight_smile:

Note : peut-être déplacer tous les messages qui n’ont pas de rapport avec l’encodage des documents dans un nouveau sujet ?

1 « J'aime »

Tu peux le faire en tant que modo.

Je sais pas comment faire, et j’aimerais éviter de faire n’importe quoi x)

La petite clé à molette en haut à droite > Sélectionner les messages > Déplacer vers un nouveau sujet.

Modération : Séparation de la discution sur l’implémentation de Duniter en Rust et de celle s’attardant sur le format des documents.

Vu que la forme du nouveau protocole se dessine de plus en plus et qu’il ne requiert pas de comprendre les anciens documents (sauf la révocation, et sauf au lancement de la nouvelle blockchain ou les anciens documents sont convertis dans l’état initial), est-ce qu’il ne serait pas mieux de directement implémenter ce nouveau protocole dans duniter-rs pour le tester, et après l’implémenter sur duniter-ts ? @cgeek @elois @Inso

La conversion pourrait être faite par une crate différente, et ne serait pas nécessaire pour plus tard créer d’autres monnaie directement avec ce nouveau protocole. En effet, ce nouveau protocole n’interagit pas avec l’ancien et pour passer g1/g1test il suffira de convertir l’état final de la blockchain et obtenir l’état initial de la nouvelle. Le code faisant ça devra être revue de manière intensive pour vérifier que tous les locks définis en v10 donnent le même résultat en v11, que les durées de validité soient égales, etc. Pour le tester on pourrait simuler le fonctionnement des 2 blockchains en parallèle et vérifier qu’il n’y a pas de divergences par exemple.

Oui je suis assez d’accord, c’est aussi sur une idée similaire que je partais lorsque je songeais à la migration et au développement :slight_smile: je vois ça en 3 phases :

  • phase expérimentale avec construction de plusieurs monnaies de test temporaires sur duniter-rs. Utilisation de clients cli pour les tests.
  • phase préparatoire : une fois le protocole validé et testé, test de migration de g1-test sur un réseau protocole v11. Développement des API clients et des clients.
  • phase de tests de migration : Les travaux peuvent démarrer plus sereinement sur duniter-ts. On continue de valider le fonctionnement de duniter-rs en parallèle des développements de duniter-ts.
  • Phase de migration : On migre la ğ1 sur le réseau duniter v11. C’est la partie la plus touchy (en décentralisé, les impacts sont larges… Il faudra prévenir des mois à l’avance à travers les groupes locaux des préparations à effectuer). Le risque étant que des transactions émises sur le réseau v10 soient perdues lors de la migration sur le v11.

Il faudra par ailleurs archiver la chaine du protocole v10 quelque part pour que tout le monde puisse vérifier le premier bloc de la v11.

On ne pourra pas arrêter le réseau v10 puisqu’il est décentralisé… Tant que des noeuds tourneront, les clients pourront l’utiliser. C’est ce qui est le plus compliqué à mon sens. Ou alors il faudra mettre à jour les clients longtemps en avance pour qu’ils soient capable d’émettre les tx en double. Lors de la migration, elles pourront être intégrées aux deux réseaux.

2 « J'aime »

Tout à fait d’accord. En plus ça permettrais de mieux se rendre compte des difficultés d’implémentation qu’on ne voit pas forcement en écrivant des RFC :slight_smile:

En effet très important. Je pense que ça serait une bonne idée de la stocker sur IPFS, de même pour le nouveau bloc genesis. Il faudra aussi faire une campagne de com autour des nouveaux concepts : les comptes, le nouveau format d’adresses pour tout le monde, et les scripts pour les personnes plus techniques.

Vu qu’on est encore peu nombreux je pense que ça pourra se faire, tant qu’on communique longtemps à l’avance, que tout est bien organisé et que les tests sur g1test sont probants. Si des gens ne veulent vraiment pas la nouvelle version, il y aura G1 et G1 Classic :stuck_out_tongue: qui ne sera plus maintenant.

Oui alors vu le temps de travail prévu, ça sera pas avant 1 an ou 2 que ça sortira… Et le réseau sera alors beauuucoup plus grand :slight_smile:

Il y a une autre option qui est de développer les fonctions petit à petit. Par exemple :

  • Nouveau format de TX dans la v12
  • Nouveau format de chaine dans la v13
  • Ajout des merkleTree de la Wot dans la v14
  • Oublie de la chaine <=v10 dans la v19
  • Ainsi de suite jusqu’à la v20 par exemple

Pendant que duniter-ts évolue de manière incrémentale sur ces version, duniter-rs est implémenté directement en objectif “protocole v20”.

Je penses que ça va être compliqué de le faire comme ça, surtout quand les éléments sont inter-dépendants. Aussi, à chaque étape il faudra faire quelque chose qui est sur et certain de bien s’intégrer avec la suite sans aucune modifications, ce qui est très improbable. Il faudrait aussi à chaque fois déclancher ces hard-forks, que tout le monde se coordonne une 10ène de fois, etc.

Vu que l’on part très clairement sur un hard-fork (vu qu’on change casi tout le protocole), alors autant le faire en une fois et bien testé avant. Après il y aura surement plein d’autres choses à rajouter au nouveau protocole qu’on imagine, et qu’on ne rajoutera qu’après. C’est pour ça que je pense qu’il serait mieux de faire une première brique solide et extensible, et qui propose déjà des outils pour faire ces améliorations : champs d’extensions, opcodes Nop remplaçables, procédure de vote d’activation de features, etc. A partir de cette base solide on pourra faire plus de chose, et surtout les faire bien :slight_smile:

1 « J'aime »

Je ne vois pas trop ce qui est interdépendant dans le protocole. Je vois plusieurs couches bien distinctes en fait :

  • Le format des TX
  • Le merkle tree des TX
  • Le merkle tree de la WoT
  • Le merkle tree de l’historique de la chaine de blocs

Pour le stockage dans les documents textes des infos binaires, de l’encodage en b64 fera l’affaire je pense. Ca sera beaucoup plus simple et safe pour faire évoluer le réseau sans risque de coupure de services dans 2 ans quand on aura fini les travaux.

Un autre avantage : c’est beaucoup plus encourageant de voir le code être utilisé petit à petit que d’espérer sortir une grosse brique d’un seul coup.

Ca rajoute plus de contraintes, car chaque ajout doit donc être rétrocompatible et forward compatible. Autant repartir de zero avec le protocole, le faire proprement en en profitant pour corriger d’éventuelles erreurs de conceptions de l’ancien protocole, puis de faire un lancement unique, même avec une légère coupure.

Pour lancer le nouveau protocole on pourrait faire tourner les 2 versions en même temps, et quand le nouveau voit le genesis apparaitre, il le vérifie (comme ça il y a même consensus décentralisé sur le genesis) et si c’est bon il coupe l’ancien et calcule sur le nouveau. On aura le temps d’expérimenter sur une nouvelle monnaie de test et sur g1test.

On pourra le faire sur une monnaie de test dédiée, d’abord avec des simples transactions, puis la WoT, puis les DU, etc. Dès que la structure de l’arbre sera définie et la logique des transactions implémenté, le plus gros sera fait.

Dés que je passe en temps partiel je compte consacrer un temps conséquent de mon temps à Duniter. Ne t’en fais pas, il y aura des premiers résultats très vite :stuck_out_tongue:

2 « J'aime »

Oui je plussoie @nanocryk, de mon coté je suis pour tout faire en 1 seule fois ce sera considérablement plus simple et plus rapide. Et je pense aussi que les premiers tests concluants de duniter-rs se feront dans moins d’un ans, d’autant que @nanocryk ne sera pas seul, je l’aiderai. Je suis justement en train de dev un truc en Rust pour m’entrainer là, vous saurez de quoi il s’agit le moment venu :wink:

4 « J'aime »

Ow, j’ai hate de voir ça :smiley:

1 « J'aime »

Roooo, ce teasing… :rofl:

2 « J'aime »

“Agile” ou “pas Agile” ? That is the question…

Un avis du “Dictateur bienveillant à vie” ?

2 « J'aime »

Oui pourquoi pas. Ça permet de défricher le terrain et dans un contexte neuf.

Non ce n’est pas obligé justement. C’est vrai que si duniter-rs ne gère pas le protocole v10 alors c’est via duniter-ts que reposera la bascule des blockchains existantes vers le protocole v11. Sans cela, il faut passer par le hard fork, ce que je ne souhaite vraiment pas (c’est trop violent, on risque de perdre la continuité de service).

Oui, je suis de l’avis d’@elois et de @nanocryk. Déjà le protocole v11 est pensé sur la base de documents en binaire, donc quitte à avoir une telle radicalité autant faire tous les changements d’un seul coup (et puis on a aussi la PoW à changer, cf la proposition d’aeris).

Et c’est plus simple pour les développeurs à mon avis, qui peuvent se concentrer sur l’essentiel des changements qui seront déjà bien compliqués, sans avoir à s’ajouter la grosse difficulté de la rétro-compatibilité.

Et puis je suis aussi de l’avis d’@Inso (qui finalement est un peu d’accord quand même !) concernant :

Duniter-ts pourra bénéficier aussi de développements sereins grâce au travail déjà effectué sur Duniter-rs.

Elle est pas belle la vie ?

Par contre très clairement, @nanocryk, @elois, je vous conseille de vous y investir à fond. Il y a besoin de concentration, et c’est pas en codant 2h par soirée que ça va fonctionner :slight_smile:

Je considère le passage (incompatible) en la V10 et la V11 un hard fork :wink: Passer de duniter-ts à duniter-rs, ou un mecanisme de bascule sur duniter-ts qui n’était évidement pas depuis le debut : c’est une mise à jour obligatoire des utilisateurs sans quoi ils ne peuvent plus utiliser la monnaie : un hard-fork.

lance une campagne de don pour m’acheter 500L de jus d’orange

1 « J'aime »

Le passage sera compatible pour duniter-ts, puisqu’il saura gérer l’ancien et le nouveau protocole.

C’est juste que le code du protocole v10 sera soudainement inutilisé quand le fork passera grâce à la mise à jour progressive des nœuds.