Je n’avais pas encore pris le temps de relire le whitepaper, je viens juste de commencer l’intro et je vois un problème :
Duniter is a software to create and manage “libre currencies”.
Non Duniter est un logiciel dédié uniquement a la monnaie Ğ1, ce n’est pas un moteur de monnaie libre “générique”. Beaucoup de code dans Duniter est spécifique a la Ğ1 et a sa monnaie" de test associée. Lancer une autre monnaie libre demanderait de forker Duniter ET de modifier significativement ce fork.
C’est d’autant plus important que ce whitepaper va devenir la référence, il ne doit pas laisser penser que des gens pourront utiliser Duniter pour lancer leur propre monnaie.
Ils pourront bien entendu s’inspirer de nos choix techniques, mais ils devront créer leur propre logiciel
J’avance une réponse, Elois me corrigera si je me trompe.
Le code de Duniter contient actuellement des conditions de déclenchement à une date/heure donnée pour changer de protocole ou corriger un bug. Aussi un nombre de % de nœud qui sont à jour avant de déclencher un changement de protocole.
Bref, en forkant le code de Duniter pour faire une nouvelle monnaie, il faudra purger le code de tous les déclencheurs historique de la Ğ1.
Et de tout ce qui concerne uniquement la Ğ1 dans le code.
Lancer une nouvelle monnaie demanderait déjà une remise à plat de tout le protocole pour s’éviter beaucoup de mécanismes qui ne sont présents que pour des raisons liées à l’historique de la Ğ1.
Quant au code actuel il est de toute façon en voie d’être réécris entièrement dans un autre langage, c’est un processus lent et progressif qui a déjà commencé, donc je déconseille très fortement de se baser sur le code actuel pour une autre monnaie sachant qu’il va disparaître.
Il y a aussi beaucoup de “choix” qui ne sont pas dans les paramètres du bloc zéro, et qui ne ferait peut-être pas sens du tout dans une autre monnaie.
Le code actuel a aussi plusieurs traitements qui sont spécifiques aux anciennes versions de DUBP, pour pouvoir continuer d’indexer et valider les blocs passés, tous ses traitements ne serviraient a rien dans une nouvelle monnaie.
Le plus important c’est aussi que techniquement @cgeek n’a pas assuré le découplage du code aux spécificités de la Ğ1 dans les développements de ces 2/3 dernières années. Et c’est à dessein, il ne souhaite pas que l’on se retrouve à assurer la maintenance pour une autre monnaie.
Très sincèrement, si des gens veulent lancer une nouvelle monnaie libre je pense que ça sera moins de boulot de concevoir un nouveau protocole de zéro et de l’implémenter plutôt que d’essayer d’adapter Duniter et DUBP.
Merci pour les infos. Ceci dit, rien n’empêche personne de créer une monnaie avec l’existant et de suivre vos évolutions de son côté - voire de créer les siennes. Ce n’est pas idéal et demande pas mal d’investissement, mais tout refaire from scratch ne serait pas encore plus de boulot ?
Merci pour cette précision car effectivement depuis le temps j’étais persuadé que Duniter pouvait servir à créer autant de monnaies libres que l’on souhaite… Oops !
Ce serait une grave erreur, @kimamila en a déjà fait les frais avec la monnaie “le Sou”.
Certaines évolutions du logiciel sont une nécessité causée par l’historique de la G1 (sig de blocs invalides, règle de distance pas respectée pour tels blocs, etc).
Toute nouvelle monnaie aura nécessairement sont propres historique différent et ses propres “écarts” avec l’attendu, le logiciel qui porte cette monnaie devra donc nécessairement évoluer différemment.
C’est pourquoi toute nouvelle monnaie doit impérativement avoir ses développeurs dédiés. Que ces derniers choisissent de forker Duniter ou de réécrire from scratch est un choix technique qu’ils devront étudier, mais réécrire from scratch n’est pas forcément plus de boulot, ça permet de partir sur son propre protocole sans être contraints par l’existant, ce qui est infiniment plus simple.
Si j’étais l’un des développeurs de cette nouvelle monnaie, je concevrais mon propre protocole et mon propre logiciel en m’inspirant des choix techniques généraux de Duniter (pow avec diff personnalisée, règles métier de la wot, etc).
De mon point de vue personnel, devoir maintenir un code que l’on a pas écrit et qui contient beaucoup de spécificités historiques qui ne nous concernent pas est plus difficile que d’écrire son propre code.
Après, ce sera aux développeurs de cette nouvelle monnaie de choisir en fonction de ce qui leur semble de le plus simple pour eux. Mais quel que soit leur choix, le logiciel de cette monnaie évoluera nécessairement différemment.
En tout les cas, toute nouvelle monnaie de prod doit avoir ses propres développeurs et son propre cœur, qu’il s’agisse ou non d’un fork de Duniter.
Le projet Duniter, n’ayant pas le manpower (les développeurs) suffisant pour le faire évoluer selon les attentes de sa communauté, doit avant tout se concentrer à maintenir sa monnaie libre la Ğ1. Les grands projets d’évolutions sont entre autres, la migration en Rust, la nouvelle API cliente GVA, l’évolution des logiciels clients…
Bien sûr, le projet Duniter peut garder en tête de faire des choix qui permettent d’avoir un code plus ou moins prêt pour un potentiel fork pour que d’autres personnes y fasse tourner une autre monnaie libre. Mais ça ne doit pas être la priorité du projet Duniter d’en faire un framework blockchain pour lancer des monnaies libres, car ça mettrait les développeurs de Duniter en position de maintenance d’un même code pour d’autres monnaies libres. Ça n’est pas souhaitable dans l’état actuel des choses.
Pour ma part, je pense qu’il est plus simple de forker Duniter, de nettoyer ce qui est relatif à la Ğ1 et repartir sur des fondations propres, mettre à jour le protocole. Ne pas réinventer la roue, mais la perfectionner. Mais bon, ne perdons pas de temps sur ces détails, on a une monnaie à développer et à maintenir, laissons ces choix aux futurs développeurs qui lanceront une autre monnaie libre si tel est leurs choix.
