Oui oui je vois bien ce que tu souhaiterais avoir, on est d’accord 
C’est uniquement possible par full scan. Bref, reste à voir ce qu’en pense @cgeek.
1 Like
C’est cela. Mais surtout : c’est le seul cas de figure qui nécessite ce FULL SCAN (du point de vue d’un logiciel client) 
2 Likes
Désolé de poser une question bête, mais je croyais que la destruction intervenait uniquement quand on faisait une transaction sur un compte vide, et donc que pas de transaction = pas de destruction.
Dans quel cas a-t-on une destruction sans transaction (à part lors d’un roulement de virgule) ?
Aucun mise à part ces deux cas
Je trouve que c’est une très mauvaise idée de vouloir ajouter des champs aux blocks dans la mesure on l’on peut faire autrement. La blockchain doit être la plus légère possible, il y a déjà quelque champs que j’aimerai supprimer, je ferai des propositions de modification substantielle du protocole quand durs sera abouti
Supprimer la destruction de monnaie fait notamment parti des propositions que je ferai. Je me rend compte a l’usage que cela demande beaucoup de traitements pour être gérer et nécessité aux nœuds de stoker des infos supplémentaires (notamment la balance des comptes) pour traiter cette destruction de monnaie en un temps acceptable.
Ça semblais être une très bonne idée au début, que j’avais totalement approuvé a l’époque, mais avec l’expérience il me semble que c’est contre-productif par rapport a l’objectif de départ qui était d’empêcher un spam de l’index des sources.
Il vaut mieux interdire les transactions contenant des sources d’un montant inférieur a 1G1. Et pour les besoins de micro-paiement ça resterait possible, supposons que je doit effectuer un micro-paiement de 0,05 G1 a un tiers. JE peut verser 1,05 a ce tiers qui s’engagerait a me rendre 1,00 G dans une transaction suivante.
Si on fait le bilan des avantages et inconvénients de chaque solution il me semble que la limitation du montant minimal des sources et plus intéressante que la destruction de monnaie
2 Likes
Est-ce qu’une “blockchain lègre” se limite uniquement au volume de ses blocs ? Ne faut il pas également considérer les infos nécessaire à son traitement (l’exploitation de ses données), avant de parler de solution “légère” ou pas ?
Aujourd’hui, bien que les blocs paraissent “léger” quant à l’information de la destruction, le traitement qu’impose son absence est très volumineux : cela revient à reconstituer les tables index !
Et les perfs dans tout ca ? N’est-ce pas aussi un problème de volume (de temps) ? Sans parler du volume de travail pour obtenir l’information… Cela ne comptes pas ?
Une manière de concevoir une blockchain dont les traitements et les analyses sont légers, est de mettre des infos de manière explicites (comme ce qui est déjà fait sauf pour la destruction).
Ainsi, on peut découper le travail entre des noeuds spécialisés, donc plus efficaces :
- les noeuds qui vérifient l’intégrité et calculent les blocs : aujourd’hui les noeud Duniter, DURS, etc.
- les noeuds qui analysent (en ayant délégué l’intégrité aux précédents) et qui diffusent les données : aujourd’hui les pod Cesium+
Cette possibilité de spécialisation des noeuds, suivant leur responsabilité, me semblent un découpage des rôle intéressant. Cela découpe le travail, et isole les fonctionnalités. => cf ce qui se passe quand vous avez bati des outils (g1-monit) sur la BDD de Duniter, qui a évoluée : boom, plus rien de marche !
Cela colle aussi avec l’intuition de @cgeek de ne plus stocker l’historique des TX (par défaut) dans Duniter v1.7. Si les blocs sont explicites (création, destruction, transfert), alors d’autres noeuds spécialisés peuvent le faire facillement…
1 Like
Pardon, mais si la destruction n’arrive que lors des transactions, on limite le traitement aux blocs avec transaction. Ça réduit déjà pas mal.
Pour connaître la masse monétaire il faut déjà tous les blocs DU & tous les blocs avec une action membership. Rajouter les transactions est lourd, mais peut-être pas exponentiellement lourd ?
Sinon, idée qui marche pas, au lieu d’interdire un versement qui passerait un solde trop bas, ne pourrait-on pas forcer l’envoi de la monnaie détruite sur un compte spécial verrouillé ?
2 Likes
Oui tu as raison. @kimamila : qu’est-ce qui t’empêches de traiter les destructions en même temps que les transactions ? Tu parses déja tout les blocs avec des transactions, il s’agit juste de gérer les destructions à ce moment là.
Je ne comprends pas très bien pourquoi tu veux faire ça ? 
L’indexation faite aujourd’hui par les pods Cesium+ n’est pas contextuelle (=pas de déduction).
Comment veux tu déduire la destruction à partir des TX, sans connaitre le solde du compte ?
Et comment connaître le solde du compte sans un traitement, de toute la BC, bloc après bloc, sans parrallèlisation ? Avec des temps de traitement énormes qui vont avec…
Ben justement, tu regardes les sources existantes post-transaction, si des sources ont disparu alors que la transaction est censé les avoir générées => destruction.
J’ai compris ce que tu me dis, mais en pratique ca ne marche pas.
“tu regardes les sources existantes post-transaction” => mais je ne les ai pas ! (A moins - encore une fois - d’avoir toutes les tables index).
En interrogeant un noeud Duniter, je ne peux pas accéder aux sources à un instant t de la BC (le temps du bloc que je traite), mais seulement aux sources correspondant à l’état courant de la BC.
Ceci empêche tout traitement stateless (qui permet de paralléliser). C’est bête, non, juste pour un petit champs manquants ?!
1 Like
Ok, je comprends. Ben j’ai pas de réponse à t’apporter, à part que la destruction de monnaie me parait pas adaptée à notre besoin avec le recul 
Je préfèrerais la suppression de la destruction de monnaie et favoriser l’interdiction à la place à choisir. Et donc pas besoin de champs supplémentaire, on touche pas aux blocs, juste au protocole.
1 Like
@inso, @elois je ne dis pas que c’est la solution “la plus parfaite”.
Je demande juste que soit étudier ici un compromis, qui au moins pendant quelques années, pourraient simplifier la vie de ceux qui (comme moi) indexent et exploitent les blocs de manière simple (sans maintenir une balance bloc à bloc) pour ajouter des fonctionnalités aux logiciels clients.
Noubliez pas aussi que les noeuds de traitements et d’indexation (comme les pod Cs+) ont aussi besoin de faire des rollback (en cas résolution de fork). S’il faut maintenant gérer le solde de chaque compte, cela signifierait un revert bloc à bloc… cela complexifiera vraiment la gestion des rollback…
1 Like
L’une ou l’autre des solutions me convient. reste à voir ce que @cgeek en pense… et surtout ce qu’il a le temps de faire.
Oui, ce serait bien mieux.
Moi je n’y vois aucun problème.
L’indexation des données
Comme vous le savez, le nœud est le cœur du réseau. S’il bug, c’est tout le reste qui s’effondre. Or il est un fait établi désormais que plus un programme comporte de lignes de code et plus statistiquement celui-ci comporte des bugs. Donc, évitons de lui faire porter la responsabilité de répondre à des besoins qui ne sont pas les siens.
D’ailleurs vous comprenez bien que les besoins d’un client ne sont pas forcément ceux d’un autre, par exemple Cesium touche un peu à toutes les données (WoT, transactions) tandis que WotWizard se fiche des transactions. Et donc si l’on commence à assouvir les besoins de ces clients, où allons-nous nous arrêter ? Faudra-t-il demain créer un index très spécial pour pouvoir remonter les transactions insérées un jour de pleine lune pour le fameux service “Transactions Haute Marée” ?
Par conséquent vous comprenez ma position : le nœud doit avoir le moins de responsabilités possible et se concentrer sur son unique rôle : assurer le respect du protocole. C’était le sens de WS2P, qui permet à la fois aux nœuds de se protéger d’attaques DoS et de limiter le trafic réseau à l’exécution du protocole, donc d’éviter le trafic lié aux clients.
J’ai bien conscience aussi que sans clients, on a beau avoir un protocole hyper secure et un code sans bugs, ce même code ne sert alors à rien !
Mais c’est justement là qu’entrent en jeu les indexeurs, programmes tiers capables d’extraire l’état d’un nœud, de le transformer afin de rendre ces données exploitables dans un but précis. Ainsi un indexeur dont le rôle est de fournir des infos pour un WotWizard n’organise pas ses données de la même façon qu’une place de change qui elle ne s’intéresse qu’aux transactions, ou que ne le fait le Pod Cesium+ qui s’intéresse aux données de façon plus large mais toujours orientée vers l’utilisateur lambda, ou encore que ne le ferait l’indexeur Haute Marée.
Existe-t-il déjà un indexeur qui serait capable de fournir rapidement les informations demandées par @kimamila ? La réponse est oui ! Le nœud Duniter peut fonctionner en mode miroir, son rôle n’est alors pas tant de faire respecter le protocole que d’en conserver une image, pour des besoins d’exploitation qui regardent son hébergeur. Celui-ci pourrait par exemple y installer le module GVA API afin de répondre à un besoin d’extraction de données plus performant et adapté que BMA aux besoins basiques de clients Duniter.
Et la suppression de sources ?
Un module Duniter peut tout à fait stocker ses propres données, et par exemple mémoriser les sources supprimées ainsi que les oublier en cas de revert. C’est très simple à réaliser.
Je résume donc ma pensée :
- le code du cœur doit se concentrer uniquement sur le protocole, et ce code est pensé exclusivement pour les membres calculants
- pour les besoins externes, créer des services tiers qui indexent eux-mêmes les données des blocs. Il existe déjà un indexeur facile à réutiliser : le nœud Duniter en mode miroir, auquel il faut simplement rajouter une API. Si le mode de stockage du nœud n’est pas adapté aux besoins, privilégier le service externe au module Duniter.
Pas sûr que ma réponse vous satisfasse !
7 Likes
Tiens, dans la même veine : le cœur doit-il, en plus de tenir la charge protocolaire pour des milliers d’utilisateurs, être capable de haute disponibilité pour toutes les requêtes clients ?
On voit bien que ça ne tient pas. En tout cas moi, ça me saute aux yeux.
yen a meme deux, dont un en java qui se grefferais très bien sur Cesium, pas besoin d’un noeud, pas besoin de changer le protocole…
1 Like
S’appuyer sur des noeuds Duniter en mode mirroir me va très bien. C’est ce que je fais pour le pod Cesium+ du Sou (https://g1.data.le-sou.org -> g1.le-sou.org qui est un mirroir).
Cependant, je rappelle que, très concrètement, aujourd’hui la plupart des noeuds n’indexent pas l’historique des TX, et qu’en conséquence quasiment plus aucun utilisateur de la G1 (sauf @bpresles ) ne peut voir ses opérations de compte…
Si nous décidons (dans un client) de passer par des noeuds tiers (spécialisés) pour certains services (historique des TX par exemple) il faut avoir en tete :
- que les données qu’ils diffuseront seront potentiellement en décalage avec celles du noeud Duniter interrogé pour les autres services.
- qu’il va falloir coder : coté noeuds et coté client. Pendant ce temps, la situation va perdurer sans accès aux opérations ?
Une fois les services spécialisés codés, dans des noeuds tiers, les utilisateurs n’auront il pas tendance, alors :
- a nous remonté sans cesse des problèmes d’incohérence ?
- a chercher à brancher leur client uniquement sur des noeuds offrant tous les services d’un coup, pour au moins sont cohérents dans les informations qu’ils émettent ?
Je ne parle pas à long terme, mais bien à court terme, dans les prochains mois. C’est à dire avec de fort risque de fork, donc d’incohérence entre les noeuds calculants, mirroirs/spécialisés…
Il faut réfléchir avec nos faibles moyens de développement d’aujourd’hui. Enfin il me semble…
Ne peut on pas gérer cela dans BMA pour le moment ? et activer l’option de stockaqge des TX par défaut ? le temps de s’organiser
Je suis assez d’accord par vos arguments côté client que côté serveur.
Côté client, actuellement BMA c’est un casse-tête chinois pour fournir une fonctionnalité avancée. Actuellement, je suis sur l’affichage de l’historique des transactions. Pour avoir un affichage des champs intéressants formatés pour une lecture humaine, il faut retourner dans tous les sens les résultats.
Je pense que GVA n’améliorera ça pas tant que ça.
Côté serveur, je trouve ça bien de limiter les nœuds calculant à faire avancer la chaîne et à recevoir de nouveaux documents. Mais, faire office de serveur d’information pour les clients, c’est pas nécessaire. Ça peut-être fait par un second cercle comme par des nœuds miroir avec interface BMA, GVA ou un indexeur qui travaille les donnés comme ElasticSearch aujourd’hui.
2 Likes