```
ou un truc du genre…
---
### Author:  [@Inso](https://forum.duniter.org/u/Inso)
#### Post date: [2 April 2019 11:06 UTC](https://forum.duniter.org/t/demandes-recurrentes-sur-cesium-evolution-de-duniter/5929/2 "2019-04-02T11:06:15Z")
> [@kimamila](#):
>
> - Si l’option est désactivée, ne faudrait il pas que Duniter renvoi une exception, lors de l’appel de /tx/history, plutot que de renvoyer une liste partielle ? Cela permettre aux clients d’information l’utilisateur qu’ils devront changer de noeud…
+1 pour ça
> [@kimamila](#):
>
> ### Proposition
>
> Je propose l’ajout d’un champ dans le document de bloc :
Ce n’est pas nécessaire, la destruction étant implicite dans le protocole, pas besoin qu’elle soit explicite. Mais une API devrait permettre de récupérer les destructions de source de monnaie sans avoir à parser l’historique complet.
Aujourd’hui c’est faisable ainsi :
- On récupère les sources existantes
- On récupère toutes les transactions
- Toute source qui est dans un output mais pas dans les sources existantes a été détruite
Le problème est qu’on doit parser la totalité des sources de monnaie pour ce faire. Pas très efficient à moyen terme.
Une API qui retournerait les destructions de monnaie pose aussi problème : la base de donnée ne serait pas limitée en taille, et continuerait à croitre alors qu’on cherche justement à faire l’inverse.
Une autre solution serait de modifier le protocole : pas de destruction monétaire, mais interdiction d’accepter des virements vers des output trop petits pour limiter l’inflation de la BDD. La rotation monétaire interdisant petit à petit les virements en provenance de source de monnaie trop petite, les noeuds pouront effacer ces sources de leur base. Ces sources étant minuscule comparé à la masse totale, le calcul de la masse monétaire restera globalement juste à l’arrondi prêt.
---
### Author:  [@kimamila](https://forum.duniter.org/u/kimamila)
#### Post date: [2 April 2019 12:13 UTC](https://forum.duniter.org/t/demandes-recurrentes-sur-cesium-evolution-de-duniter/5929/3 "2019-04-02T12:13:57Z")
> [@Inso](#):
>
> Le problème est qu’on doit parser la totalité des sources de monnaie pour ce faire. Pas très efficient à moyen terme.
Voila, c’est pourquoi ta solution n’en est pas une, d’un point de vue d’un client, mais seulement d’un point de vue d’un nœud (ou autre Pod).
Je ne comprends pas l’argument au sujet de ce qui est explicite. Plein de choses sont explicites, dans ce cas, comme le DU, les exclusions, etc. En bref, toutes les sorties (hors révocation)…
Le problème (cas d’utilisation) peut-être simplement reformulé ainsi : _“Comment à partir des blocs, retrouver rapidement la quantité de monnaie exacte d’un compte ?”_.
Dans les nœuds Cesium+ pod, j’arrive à détecter tous les événements de la BC, par de simples analyses bloc à bloc, sauf pour les destructions de monnaie.
Je me demande ce que cela coûterait d’ajouter cette destruction de manière explicite… Quels risques ?
Celui du volume du bloc, sans doute ? Donc un angle d’attaque potentiel (création de petits portefeuilles pour générer de gros blocs ?)
> [@Inso](#):
>
> Une autre solution serait de modifier le protocole : pas de destruction monétaire, mais interdiction d’accepter des virements vers des outputs trop petits pour limiter l’inflation de la BDD. La rotation monétaire interdisant petit à petit les virements en provenance de source de monnaie trop petite, les noeuds pouront effacer ces sources de leur base. Ces sources étant minuscule comparé à la masse totale, le calcul de la masse monétaire restera globalement juste à l’arrondi prêt.
Je laisse Cédric nous dire ce qu’il en pense.
---
### Author:  [@Inso](https://forum.duniter.org/u/Inso)
#### Post date: [2 April 2019 12:32 UTC](https://forum.duniter.org/t/demandes-recurrentes-sur-cesium-evolution-de-duniter/5929/4 "2019-04-02T12:32:34Z")
> [@kimamila](#):
>
> Dans les nœuds Cesium+ pod, j’arrive à détecter tous les événements de la BC, par de simples analyses bloc à bloc, sauf pour les destructions de monnaie.
Ben tu devrais pourtant savoir le faire en bloc à bloc y compris pour les destructions de monnaie… J’y arrivais bien dans Sakia ? 🤔
---
### Author:  [@kimamila](https://forum.duniter.org/u/kimamila)
#### Post date: [2 April 2019 14:26 UTC](https://forum.duniter.org/t/demandes-recurrentes-sur-cesium-evolution-de-duniter/5929/5 "2019-04-02T14:26:47Z")
> [@Inso](#):
>
> Ben tu devrais pourtant savoir le faire en bloc à bloc y compris pour les destructions de monnaie… J’y arrivais bien dans Sakia ?
Alors, comment de te dire pour que tu comprennes…
Vois tu la différence entre :
- une analyser bloc à bloc : soit sur 200 000 blocs. Autrement dit, ce qu’on appelles un `FULL SCAN` en base de données
- une analyse à partir d’un **sous-ensemble** de blocs : uniquement ceux ayant des destructions, soit N bloc sélectionnés par requetes (via un index - donc très rapide). Comme je le fais pour les blocs avec DU ou encore les bloc avec des transactions, etc.
Si nous avions une destruction explicite dans le document de bloc, je pourrais faire le même genre de requetes (très rapides) en sélectionnant uniquement les blocs ayant une destruction, et même sélectionner QUE ceux concernant un compte précis, ou sur un sous-ensemble de compte, etc.
Mais actuellement, c’est impossible avec une simple indexation de la BC dans ES…
Tu vois ?
> [@Inso](#):
>
> J’y arrivais bien dans Sakia ?
L’approche que tu as eu dans Sakia engendrait justement des performances désastreuses.
Imagines toi que plein d’utilisateurs qui trouvent Cesium trop lent (notamment car les requetes sur les noeud v1.6 sont parfois \> 15s !). Alors avec une telle approche, j’imagines même pas…
Nan, pas possible pour moi.
---
### Author:  [@Inso](https://forum.duniter.org/u/Inso)
#### Post date: [2 April 2019 14:34 UTC](https://forum.duniter.org/t/demandes-recurrentes-sur-cesium-evolution-de-duniter/5929/6 "2019-04-02T14:34:04Z")
> [@kimamila](#):
>
> Tu vois ?
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.
---
### Author:  [@kimamila](https://forum.duniter.org/u/kimamila)
#### Post date: [2 April 2019 14:52 UTC](https://forum.duniter.org/t/demandes-recurrentes-sur-cesium-evolution-de-duniter/5929/7 "2019-04-02T14:52:21Z")
> [@Inso](#):
>
> C’est uniquement possible par full scan
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) ☹
---
### Author:  [@Nartagnan](https://forum.duniter.org/u/Nartagnan)
#### Post date: [2 April 2019 15:16 UTC](https://forum.duniter.org/t/demandes-recurrentes-sur-cesium-evolution-de-duniter/5929/8 "2019-04-02T15:16:00Z")
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) ?
---
### Author:  [@Inso](https://forum.duniter.org/u/Inso)
#### Post date: [2 April 2019 15:59 UTC](https://forum.duniter.org/t/demandes-recurrentes-sur-cesium-evolution-de-duniter/5929/9 "2019-04-02T15:59:11Z")
> [@Nartagnan](#):
>
> Dans quel cas a-t-on une destruction sans transaction (à part lors d’un roulement de virgule) ?
Aucun mise à part ces deux cas 🙂
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [2 April 2019 20:12 UTC](https://forum.duniter.org/t/demandes-recurrentes-sur-cesium-evolution-de-duniter/5929/10 "2019-04-02T20:12:06Z")
> [@kimamila](#):
>
> Je propose l’ajout d’un champ dans le document de bloc :
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 🙂
> [@Inso](#):
>
> Une autre solution serait de modifier le protocole : pas de destruction monétaire, mais interdiction d’accepter des virements vers des output trop petits pour limiter l’inflation de la BDD. La rotation monétaire interdisant petit à petit les virements en provenance de source de monnaie trop petite, les noeuds pouront effacer ces sources de leur base. Ces sources étant minuscule comparé à la masse totale, le calcul de la masse monétaire restera globalement juste à l’arrondi prêt.
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 🙂
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [3 April 2019 17:22 UTC](https://forum.duniter.org/t/demandes-recurrentes-sur-cesium-evolution-de-duniter/5929/11 "2019-04-03T17:22:46Z")
8 messages ont été scindés en un nouveau sujet : [Interdire les transactions avec source \< 1,00 Ğ1](https://forum.duniter.org/t/interdire-les-transactions-avec-source-1-00-g1/5938)
---
### Author:  [@kimamila](https://forum.duniter.org/u/kimamila)
#### Post date: [3 April 2019 08:14 UTC](https://forum.duniter.org/t/demandes-recurrentes-sur-cesium-evolution-de-duniter/5929/19 "2019-04-03T08:14:21Z")
> [@elois](#):
>
> La blockchain doit être la plus légère possible
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** …
---
### Author:  [@Nartagnan](https://forum.duniter.org/u/Nartagnan)
#### Post date: [3 April 2019 08:48 UTC](https://forum.duniter.org/t/demandes-recurrentes-sur-cesium-evolution-de-duniter/5929/20 "2019-04-03T08:48:25Z")
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é ?
---
### Author:  [@Inso](https://forum.duniter.org/u/Inso)
#### Post date: [3 April 2019 08:55 UTC](https://forum.duniter.org/t/demandes-recurrentes-sur-cesium-evolution-de-duniter/5929/21 "2019-04-03T08:55:15Z")
> [@Nartagnan](#):
>
> 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.
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à.
> [@Nartagnan](#):
>
> 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é ?
Je ne comprends pas très bien pourquoi tu veux faire ça ? 🤔
---
### Author:  [@kimamila](https://forum.duniter.org/u/kimamila)
#### Post date: [3 April 2019 09:08 UTC](https://forum.duniter.org/t/demandes-recurrentes-sur-cesium-evolution-de-duniter/5929/22 "2019-04-03T09:08:29Z")
> [@Inso](#):
>
> @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à.
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…
---
### Author:  [@Inso](https://forum.duniter.org/u/Inso)
#### Post date: [3 April 2019 09:09 UTC](https://forum.duniter.org/t/demandes-recurrentes-sur-cesium-evolution-de-duniter/5929/23 "2019-04-03T09:09:23Z")
> [@kimamila](#):
>
> Comment veut tu déduire la destruction à partir des TX, sans connaitre le solde du compte ?
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.
---
### Author:  [@kimamila](https://forum.duniter.org/u/kimamila)
#### Post date: [3 April 2019 09:13 UTC](https://forum.duniter.org/t/demandes-recurrentes-sur-cesium-evolution-de-duniter/5929/24 "2019-04-03T09:13:30Z")
> [@Inso](#):
>
> 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 ?!
---
### Author:  [@Inso](https://forum.duniter.org/u/Inso)
#### Post date: [3 April 2019 09:17 UTC](https://forum.duniter.org/t/demandes-recurrentes-sur-cesium-evolution-de-duniter/5929/25 "2019-04-03T09:17:41Z")
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.
---
### Author:  [@kimamila](https://forum.duniter.org/u/kimamila)
#### Post date: [3 April 2019 09:24 UTC](https://forum.duniter.org/t/demandes-recurrentes-sur-cesium-evolution-de-duniter/5929/26 "2019-04-03T09:24:14Z")
@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…
---
### Author:  [@kimamila](https://forum.duniter.org/u/kimamila)
#### Post date: [3 April 2019 09:27 UTC](https://forum.duniter.org/t/demandes-recurrentes-sur-cesium-evolution-de-duniter/5929/27 "2019-04-03T09:27:22Z")
> [@Inso](#):
>
> 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.
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.
[Next page](https://forum.duniter.org/t/demandes-recurrentes-sur-cesium-evolution-de-duniter/5929.md?page=2)