Demandes récurrentes sur Cesium => évolution de Duniter ?

[kimamila]

Hello à tous !

J’ai plusieurs demandes que je ne peux pas honorer (du moins pas sans un grosse quantité de travail), sauf si Duniter évolue sur ces points.
Je vais essayer de les résumer ici, pour discuter de ce qu’on peut faire ou pas…

Merci en particulier à @cgeek de me donner son avis (moyen et long terme).

1. Historique des transactions

Problématique

Beaucoup d’utilisateurs sont désireux d’avoir l’historique de leur transactions. Au moins les dernières…
Pour la comptabilité, il faut parfois ressortir un an de transactions.

Par ailleurs, les clients n’ont pas de moyens de savoir si un noeud propose l’historique des transactions ou non.

Contournement

J’ai commencé à réaliser un historique des transactions, sur les pod Cesium+.
cf ici : https://g1.data.le-sou.org/g1/movement/_search?pretty
Mais il me manque pas mal de champs, pour permettre le même affichage qu’actuellement.

Le plus embêtant est surtout la dépendance vers Cesium+, qui sera alors nécessaire.
Concrètement, si Cesium+ est désactivé, nous n’aurons plus accès à l’historique…
N’est-ce pas gênant ?

Aujourd’hui, toutes les fonctionnalités de base sont opérationnelles sans les pod Cesium+.

Solution proposée

• Ne faudrait-il pas activer par défaut l’option --store-txs de Duniter v1.7 ?
• 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…

2. Destruction de monnaie

Problématique

Aujourd’hui, la création monétaire est visible dans le bloc qui créé le DU.
En revanche, rien n’est indiqué quand il y a destruction de monnaie.
Je trouve cela gênant, car il impossible de connaître la masse monétaire sans balayer tous les blocs. Indiquer dans les blocs (via une liste de clés publiques) me parait cohérent, par symétrie.

Ainsi, des outils d’analyse de la blockchain pourront requêter une partie seulement des blocs, comme je le fait dans les graphique pour la création des DU.
Aujourd’hui, aucun requetage sur les destruction n’est possible, à partir seulement des blocs : il faut la table (index) complète.

La conséquence est que les graphiques sur les soldes des comptes sont faux… car il ne tiennent pas compte de cette destruction.

Proposition

Je propose l’ajout d’un champ dans le document de bloc :

destroy: 
<PUBKEY1>
<PUBKEY2>

ou un truc du genre…

[Inso]

@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.

[kimamila]

@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.

[Inso]

@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 ?

[kimamila]

@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.

[Inso]

@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.

[kimamila]

@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)

[Nartagnan]

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) ?

[Inso]

@Nartagnan

Dans quel cas a-t-on une destruction sans transaction (à part lors d’un roulement de virgule) ?

Aucun mise à part ces deux cas

[elois]

@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

[kimamila]

@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…

[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.

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é ?

[Inso]

@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 ?

[kimamila]

@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…

[Inso]

@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.

[kimamila]

@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 ?!

[Inso]

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.

[kimamila]

@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…

[kimamila]

@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.