Tout ou partie de cette roadmap peut changer à tout moment en fonction des nouvelles informations que je reçois, des demandes de priorisation des autres dev, où des contraintes techniques rencontrées.
Cette roadmap est donnée à titre purement indicatif et n’engage à rien. Ne lisez pas ceci comme ce qui va se passer (il est très probable que le déroulé réel soit très différent).
Roadmap Duniter 2021
Développement d’un crawler GVA dans duniter-launcher pour télécharger les chunk de la blockchain en local, avec une nouvelle commande sync transparente qui téléchargerait les chunk coté rust puis ferait une sync locale coté nodejs).
Développement d’un module d’administration en Rust, exposant une API d’administration (via websocket en server et via socket unix en desktop. Cette nouvelle API d’administration devra permettre notamment de configurer GVA (mais aussi WS2P).
Développement d’une nouvelle interface graphique en Rust/Wasm qui remplacera duniter-ui, qui n’est plus maintenu et qui reprendra le plus de fonctionnalités possibles.
Finalisation de l’API GVA (requetage des mempool sans migration, en tapant directement dans SQLite).
Intégrer à GVA un client GVA qui fait régulièrement des mutations sur les autres noeuds GVA pour leur partager le contenu de sa mempool.
Stabilisation et tests de charge sur g1-test
Campagne de test Duniter 2.0
Sortie de Duniter 2.0 (date espérée: décembre 2021).
Si j’arrive à faire tout ça dans les huit mois (je ne pourrais commencer qu’en mai) ce serait déjà énorme !
Ça va beaucoup dépendre du temps que je pourrais consacrer à la Ğ1 en fonction de l’évolution de ma situation personnelle, ainsi que des problématiques techniques que je vais rencontrer.
Sachez que mon temps consacré à la Ğ1 n’est pas exclusif à Duniter, je travaille aussi sur Ğcli et sur Ğecko (enfin principalement sur la lib Rust commune à Ğcli et Ğecko, un équivalent de duniterpy mais en Rust).
Il y a aussi tout le temps consacré à expliquer des choses sur ce forum, à rédiger, relire corriger des RFC, etc
La complétion d’une nouvelle API client, plus tout ce qui est listé ici, plus le temps entre la précédente et la prochaine version majeure, plus l’oxydation, plus la reprise du lead du projet du logiciel Duniter par toi, je partirais sur une v2. Ça peut se justifier par cette nouvelle interface cliente qui est renouvelée. C’est un détail, mais c’est du marketing et c’est motivant. Sinon, je ne vois pas quand faire une v2. C’est juste une idée, ça peut rester ainsi, c’est pas un problème.
Initialement, j’avais prévu de passer en v2.0 quand la migration en Rust sera totalement terminée, mais je crois que tu as raison, c’est pertinent de faire une v2.0 pour la sortie de GVA en prod
Cette roadmap 2021 ne comporte pas le développement de la nouvelle couche réseau DUNPv2, développement qui ne commencerait donc que en 2022 au mieux.
J’aimerais reprioriser DUNPv2 pour plusieurs raisons :
Cela résoudrait les problèmes de synchronisation de la blockchain qui sont de plus en plus problématiques, il devient vraiment difficile de resynchroniser un nœud duniter.
Cela résoudrait les problèmes de synchronisation des mempools qui sont pointés par les utilisateurs depuis des années et qui causent de nombreux problèmes pour certifier.
Cela résoudrait le problème des nœuds avec même clé publique (plus de fiche de pair partagée).
Cela ouvrirait la porte à de nouveaux services (stockage libre pour commentaires de transactions, méta-données des comptes opaques, et tout ce qu’on veut tant que le volume est faible)
Et sans doute d’autres avantages que j’oublie
Le problème c’est que je ne peux pas être sur tous les fronts.
Si je repriorise DUNPv2 je suis obligé de déprioriser plusieurs points de la roadmap 2021 (c’est-à-dire les repousser à 2022 ).
Tous les points de la roadmap ne sont pas égaux, ni en charge de travail, ni en plus-value, et certains dépendent d’autres.
La migration des mempool est urne grosse tache (plusieurs mois), mais elle est nécessaire pour DUNPv2, donc la dépriorisée pour DUNPv2 n’aurait aucun sens.
La migration des mempool est également nécessaire pour finaliser l’API GVA, c’est d’ailleurs le plus gros du boulot, une fois toutes les mempool migrées, il sera facile de finaliser l’API GVA.
Tous les autres point de la roadmap 2021 sont liées à DUBPv13, il nous faut donc choisir entre DUBPv13 et DUNPv2 pour cette année, à moyen-long terme on aura les deux, mais à court-terme (1 an), il faut choisir.
J’aurais besoin que l’on tranche ce point lors de la réunion mensuelle de mai. Afin que je sache sur quoi me lancer. En attendant, je peux partir sur la migration des mempool, car cette tâche restera dans la roadmap dans tous les cas.
Ton message m’amène à publier ceci : Force identity mempools sync qui devrait résoudre ces #$£€ de problèmes d’affichage, sur les noeuds les plus consultés.
Je n’ai pas lu de souci de désynchro des piscines depuis que j’ai mis en place ce script.
Merci @matograine pour ce pansement court-terme, ça aide dans l’urgence, mais ça ne doit pas inciter à retarder le traitement de la cause.
Au contraire, le problème de sync des mempool deviens tellement gênant qu’un contributeur en vient à coder un contournement, c’est pour moi un signe que le problème s’aggrave et qu’il faut donc re-prioriser ce point !
Cela me rend davantage convaincu qu’il faut reprioriser la migration de la couche réseau.
Le problème des piscines mal coordonnées se pose essentiellement parce que les deux clients activement développés (Cesium et Silkaj) sont « naifs », croient un seul noeud et lui envoient leurs requêtes. Avec des clients multi-noeuds :
les infos en pool seraient plus complètes pour le client
les documents seraient mieux propagés
Il me semble au contraire que la priorité va au DUBPv13, qui permettra :
le rejeu de transactions en cas de fork (meilleure résilience du réseau)
un début de développement de canaux de paiements
Par ailleurs, les requêtes facilitant la création de clients multi-noeuds sont en cours de merge dans GVA (si j’ai bien suivi), ce qui facilitera la création de clients multi-noeuds et les avantages liés.
Pour moi, DUBPv13 + GVA sont prioritaires. Mais il y a peut-être des considérations qui m’échappent.
Mon pansement peut rester en place pour 1 an ou 2. Même si je l’arrête, quelqu’un pourra le relancer.
En revanche, j’ai eu deux fois le cas de révocations présentes sur un noeud miroir, et non propagées. Ceci est plus gênant.
NB : un problème de piscines mal coordonnées est remonté 1 à 2 fois par mois, avec parfois une intervention manuelle de ma part. Ca a été la crise il y a 2 semaines avec la resynchro de g1.duniter.org et g1-monit, mais c’est rare. C’est ceci qui a provoqué le débuguage + publication de ce script.
Peux-tu préciser en quoi un client p2p améliorerait la propagation des documents entre les nœuds, sauf à servir de relai (mais moins fiable et moins prédictible que la diffusion entre serveur puisque les algos peuvent choisir les serveurs aléatoirement ou en fonction de la charge).
Pour moi faire des clients p2p n’est pas si simple (sinon ce serait fait depuis longtemps), et même si cela améliore la qualité de service côté client, c’est encore une rustine sur un problème plus profond côté serveurs qu’il faut résoudre. Une meilleure répartition des documents entre serveurs facilitera la mise en place de client p2p à coup sûr.
Après, je suis comme toi, il y a peut-être quelque chose qui m’échappe, mais je fait confiance à Elois pour gérer les priorités.
La propagation des documents se fait par “ricochet” entre les noeuds. Qd un noeud reçoit un doc qu’il n’a pas, il le transmet à d’autres.
Dans le cas d’un client multi-noeuds, les docs sont envoyés en plusieurs points du réseau, ils vont donc à priori être propagés plus vite. C’est ce que je voulais dire.
Ca ne change rien à la rapidité de “remplissage” des pools d’un noeud qu’on vient de resynchroniser.
(il y a sans doute d’autres processus de synchro actives des piscines, que je ne maîtrise pas).
Je ne suis pas d’accord avec ça. Ce n’est pas aux clients de compenser une mauvaise synchronisation des mempool, c’est la couche réseau inter-nœud qui doit être améliorée.
Le rejeu de transaction en cas de fork est déjà parfaitement fonctionnel en DUBPv12. Il suffit de bockstamnper les documents transactions à 101 blocs dans le passé.
C’est ce qu’on fait dans Ğcli et Ğecko, et ça fonctionne super bien
Il est déjà possible de développer des canaux de paiement (lightning network), leur durée de vie est simplement limitée à une semaine.
Mais personne n’a commencé à se pencher sur une implémentation de canaux de paiements, c’est un procédé complexe et qui n’a d’intérêts que pour échanger des petits montants entre personnes qui ne se font pas confiances.
En l’état actuel de l’économie Ğ1 je pense que les canaux de paiement ne sont pas la priorité.
Ce que les utilisateurs demandent sur le terrain ce n’est pas des paiements plus rapides, mais des paiements qui marchent, moins de bug, ce à quoi répondrait une meilleure synchronisation des nœuds.
Un problème de plus qui serait résolu par le développement d’une nouvelle couche réseau.
C’est ainsi parce que cgeek a décidé de le coder comme ça, mais rien n’oblige à faire ainsi coter noeuds.
Ça fait des années que je réfléchis aux problèmes de synchro des mempools, et j’ai plusieurs idées pour faire beaucoup mieux, notamment issues de mes recherches sur les autres crypto et sur des idées que ma donné nanocryk
Pour moi ça me parait évident que la priorité est à la stabilité de Duniter, sa synchro, ainsi que la bonne propagation des documents en mempool.
Tout le reste ne vient que après. Ce n’est que mon avis.
Pour la gestion des forks, je sais très bien ce que j’ai à faire dans Gecko pour cela, ce n’est pas compliqué, je ferai un poste dédié pour ça dans 15 jours quand j’aurais implémenté ça.
Excusez ma question naïve, mais je ne comprends pas bien en quoi les clients - type gecko ou autre - ont un rôle à jouer dans la gestion des forks. N’est-ce pas une problématique uniquement « noeud » ?
Les choix du client peuvent avoir des conséquences en cas de fork : actuellement, les transactions contiennent le numéro et le hash d’un bloc (qui ne doit pas être trop ancien, sinon la transaction expire et n’est plus valide). Si un fork arrive et que le bloc référencé dans la transaction n’est plus dans la blockchain, alors la transaction n’est plus valide.
Dans ce cas-là, on peut mettre un numéro de bloc un peu plus ancien, mais pas trop, pour réduire considérablement le risque que le bloc soit annulé par un fork.
D’autres clients ont besoin de stratégies spécifiques pour gérer les forks, par exemple un vérificateur de paiement en ligne : le paiement peut avoir été fait, mais il peut être annulé à tout moment à cause d’un fork.
Cela n’est vrai que si le blockstamp de la transaction est trop récente. Sinon,il est impossible que le paiement soit annulé à cause d’un fork (sauf bug majeur où hard fork manuel).
Développement d’un crawler GVA dans duniter-launcher pour télécharger les chunk de la blockchain en local, avec une nouvelle commande sync transparente qui téléchargerait les chunk coté rust puis ferait une sync locale coté nodejs).
Développement d’un module d’administration en Rust, exposant une API d’administration (via websocket en server et via socket unix en desktop. Cette nouvelle API d’administration devra permettre notamment de configurer GVA (mais aussi WS2P).
Développement d’une nouvelle interface graphique en Rust/Wasm qui remplacera duniter-ui, qui n’est plus maintenu et qui reprendra le plus de fonctionnalités possibles.
Finalisation de l’API GVA (requetage des mempool sans migration, en tapant directement dans SQLite).
Intégrer à GVA un client GVA qui fait régulièrement des mutations sur les autres noeuds GVA pour leur partager le contenu de sa mempool.
Stabilisation et tests de charge sur g1-test
Campagne de test Duniter 2.0
Sortie de Duniter 2.0 (date espérée: décembre 2021).
Cette roadmap c’est le minimum nécessaire pour :
Sortir une version de Duniter complète en soi (ce qui sous-entend avec GVA configurable graphiquement) et avec une API
Avec une API GVA complète qui puisse intégralement remplacer BMA (ce qui implique de ne plus avoir besoin de BMA pour synchroniser la blockchain, d’où le point 1.).
Corriger le bug le plus bloquant de Duniter aujourd’hui : il est impossible (ou très difficile) de réussir une synchro de la blockchain via le réseau.
Résoudre le problème de synchro des mempools.
La nouvelle interface graphique permettra également de mieux mettre en avant (et de configurer) les mécanismes « d’invitations » entre nœuds (prefered et privilegied), ce qui n’a jamais été fait dans duniter-ui.
Je ne trouve pas ces développements très intéressants pour les résultats escomptés à la vue du travail requis pour l’accomplir. Tant que c’est faisable en CLI, je pense les administrateurs de nœuds Duniter s’en sortent sans problèmes. Pourquoi prioriser cette interface graphique par rapport à DUBPv13 ?
Duniter-ui n’est plus maintenu et à de nombreuses vulnérabilités de sécurité dans ses dépendances et je ne souhaite pas reprendre ce projet. De plus, on a besoin que l’interface graphique de Duniter permette de configurer la nouvelle API GVA.
Soit on migre l’interface graphique, soit on la supprime purement et simplement, mais je ne suis pas favorable à cette 2ème option. Et puis le fait de développer une interface graphique pour laquelle je maîtrise la stack va me permettre ensuite d’y intégrer des stats et indicateurs qui nous aiderons à mieux comprendre comment les noeuds Duniter se comportent, et donc nous aider à stabiliser Duniter.
Il est encore bien trop tôt pour faire évoluer significativement le protocole.
Ma logique, c’est aussi de migrer en premier ce qui marche le moins bien, pour améliorer duniter maintenant et pas dans 5 ans. Le protocole DUBP en lui-même est la partie de Duniter qui marche le mieux (car la mieux testée), c’est donc la moins prioritaire à migrer.
