Production du DU

Protocols Ğ1v2 protocol
1

Autre point qui va changer au niveau du protocole : ne plus produire le DU à la place des utilisateurs, qui devront manuellement intervenir pour le produire via leur wallet. Je m’explique.

C’est un problème technique : lorsque le DU “tombe”, il faut modifier N comptes dans la base de données, où N est le nombre de membres. Sur Duniter v1 c’est déjà coûteux d’insérer N UTXO avec N = 4000, or Duniter V2S vise un N bien plus gros (a minima 100 000).

Pour permettre une production de bloc en 2" max, il faut lever cette contrainte.

Une façon de le faire est de répartir le coût de mise à jour de la BDD au besoin. Concrètement, lorsque le DU tombe nous ajouterions une entrée dans la table des DU “dernier DU de valeur 10,42 Ğ1 le 05/01/2022”, ce qui est très rapide, puis quand les utilisateurs voudront produire leur monnaie, il leur suffira de dire “produire les DU de la date X à Y”. Bien évidemment dans le compte de l’utilisateur seront inscrites 2 données afin d’éviter la double production :

  • les dates d’entrées et sortie du statut de membre (a)
  • la date de dernière production du DU (b)

De plus, une contrainte sera ajoutée pour que l’utilisateur produise les DUs de façon continue, et intégralement à chaque fois. Dans les faits nous aurons donc un extrinsic Dubp.produce_ud qui crédite le compte du montant des DUs non-encore produits pour le compte.

Je pingue @kimamila, @vit, @poka, @Moul car cela va impacter les clients : suite à cette modification, le solde du compte nécessitera quelques calculs supplémentaires pour être affiché. Aussi, réaliser une dépense pourra nécessiter d’appeler Dubp.produce_ud au préalable.

Mais le gain en termes de performances côté nœud Duniter sera considérable.

7 Likes
2

Si j’ai bien compris cela vas être gênant pour afficher la masse monétaire globale, ou j’ai mal compris.
Pour avoir le DU produit il faudra que le client fasse une action, pas forcément avec la signature de l’utilisateur, sinon cela empêchera de consulté le solde réel d’un compte membre. Me trompe-je ?

1 Like
3

Non ce n’est pas gênant, la masse monétaire globale est toujours calculée quotidiennement sans regarder dans le détail des unités monétaires circulantes, dans Duniter v1 comme v2.

Et pour connaître le montant disponible sur un compte, le client doit faire le calcul suivant :

SOMME(balance_du_compte, dividendes_disponibles)

Où dividendes_disponibles est simplement la somme des dividendes officialisés par la blockchain où le membre était présent. C’est assez facile, je donne un exemple :

  • Intervalles de présence du membre :
    • présent du 01/07/2021 à maintenant
  • DU [21/03/2021 au 19/09/2021] = 10,32
  • DU [20/09/2021 à maintenant (06/01/2022)] = 10,42

Le membre aura droit à 81j de DU à 10,32 Ğ1 et 109j à 10,42 Ğ1.

Je ne vais pas écrire la fonction, mais bon c’est assez trivial même avec plusieurs périodes de présences (cas d’un membre qui a perdu son statut de membre mais revient). :slight_smile:

4 Likes
4

Une autre solution ne pourrai elle être de traiter n comptes a la fois pour l’écriture du DU ?
Par exemple par tranche de 5000 comptes par bloc.
Pour 100 000 membres cela ferait simplement 20 blocs d’écart, donc 40s d’écart si 1 bloc émis toutes les 2 secondes non ?

On peut aussi envisager d’augmenter la fenêtre d’émission de bloc, pour 5s par exemple, en fonction des benchmarks si on se rends compte que même pour 5000 comptes cela fait juste à appliquer en moins de 2s pour une petite machine ?

Si on choisi n=1000 comptes, pour 100 000 comptes on serait à 200s soit moins de 4 minutes, cela me semble tout à fait respectable.
(On pourrait bien sûr randomiser l’ordre de passage des comptes chaque jour).

1 Like
5

Oui j’y ai pensé aussi, mais je me suis dit que c’était quand même plus efficace d’attendre l’utilisateur car :

  1. On ne sollicite pas la base pour les inactifs
  2. Pour les actifs, on fait 1 seule opération pour N DU plutôt que N opérations d’un DU

Je doute même qu’on puisse encore moins solliciter la base :thinking:

2 Likes
6

Il y aura forcement des DU qui ne seront jamais réclamés. Comment ça va se passer dans ce cas ?

1 Like
7

Comme aujourd’hui !

1 Like
8

Je pense à un point d’attention :

Un membre devient membre, son compte génère des DU qu’il ne réclame pas. Il perd le statut de membre. Il le renouvelle après quelques semaines.Lors de sa réclamation de DUs, attention à prendre en compte tous les DUs auquel il a droit.

De même pour un compte qui réclamerait les DUs après la révocation du compte (implicite ou explicite).

1 Like
9

Oui, c’est ce que j’essayais de signifier :

D’ailleurs la fonction doit être appelable même pour un compte révoqué, oui, nous sommes bien d’accord.

1 Like
10

Les DU disponibles non produits sont-ils comptés dans M lors de la réévaluation ?

Si on utilise des virements automatiques, que ce soit on-chain ou via un client, ou pour faire des « chèques », ça pourrait être pratique que l’émission d’une transaction produise automatiquement le DU, au moins si nécessaire à l’exécution de la transaction.

2 Likes
11

Oui, M est calculé par le protocole, indépendamment de la circulation de la monnaie.

Oui on peut tout à fait rajouter un paramètre produce_ud_if_needed au moment de l’appel à Dubp.transfer(), bonne idée :slight_smile:

Par contre je rajouterai des frais sur cette option qui seront payés par les non-membres, car le fait de regarder si le compte dispose du DU provoque un coût en ressources qu’il ne faudrait pas utiliser pour rien.

De plus j’insiste sur le fait que ce serait une production “si nécessaire” afin de minimiser l’appel à la fonction Dubp.produce_ud() sous-jacente, afin toujours d’économiser les ressources.

4 Likes
12

Un membre pourrait spammer en exécutant cet appel Dubp.produce_ud à répétition, non ? Des frais remboursés si l’appel aboutit (comme tu le mentionnes dans ce sujet) me paraît plus général.

Mais dans ce cas, comment gérer le cas d’un membre qui n’a rien sur son compte au moment du retrait ? Je ne sais pas.

Sous-entendu : les devs clients, faites en sorte d’exécuter cet appel une fois par jour et par membre eu maximum :wink:

13

Je suis d’accord que ce serait une super optimisation, mais elle n’est pas nécessaire pour migrer la Ğ1 sur substrate vu la charge actuelle, je propose donc de migrer sans cette optimisation, c’est à dire que les DU soient versés automatiquement, comme le fait déjà ma PoC.

Une fois la G1 migrée, les développements continueront de toute façon, et sans doute avec plus de contributeurs qu’aujourd’hui :slight_smile:

1 Like
14

On verra en fonction des développeurs qui rejoindront le mouvement pour la migration.

La Ğ1 a déjà 4,000 membres, l’opération DU est déjà coûteuse si je m’en réfère aux chiffres que tu donnais en juillet dernier :

Personnellement, comme pour d’autres sujets “mal faits” de Duniter v1, je préférerais que l’on s’en occupe tout de suite.

Il y a d’autres sujets qu’on peut mettre de côté par contre, comme le nombre de chiffres requis pour le DU (unitBase du protocole v1) qui est bien plus long terme.

3 Likes
15

Bonjour à tous.

J’ai une petite question de débutant, je vous ai bien tous suivis, je me pose maintenant la question comment allez vous trancher et valider une décision?
Il y aura t’il un vote ?
Quand est ce que cela sera appliqué réellement?

Belle journée à vous et bon courage pour la suite

1 Like
16

Avant de voter on discute pour trouver la meilleure solution et essayer de se mettre d’accord. Sur cette question il n’y a pas d’enjeu idéologique ou personnel donc le vote n’apporterait pas la solution technique mais seulement le consensus. Ce serait un dernier recours (c’est-celui-qui-fait-qui-a-raison étant un autre dernier recours).

Ça sera appliqué réellement quand ça sera codé, et utilisé réellement quand DuniterV2S sera déployé, soit pas avant plusieurs mois.

4 Likes
17

Même si c’est clairement optionnel, je me lance dans le claim_ud pour commencer par des choses faciles. (ça faisait longtemps que je n’y avais pas touché)

Et les problèmes apparaissent en faisant. Si on peut réclamer des DU créés avant la perte du statut de membre, ça oblige à stocker l’historique de l’état de membre de chaque compte à partir de son premier DU non réclamé. J’ai deux solutions :

  1. ces DU sont perdus.
  2. ces DU sont produits automatiquement lors de la perte du statut de membre.

Je préfère la 2.

4 Likes
18

Oui, ça semble le plus juste sans être spécialement coûteux.

19

Ce qui est un mauvais choix car c’est en réalité un ticket difficile, j’explique en partie pourquoi dans le ticket gitlab.

1 n’est pas envisageable, en outre, il y a aussi une solution 3: mémoriser dans le storage l’historique des obtentions et pertes du droit au DU.

J’avoue que je n’avais pas pensé à 2., ça serait clairement puls simple que 3. et moins gournand en storage, mais on y perd en optimisation, on peut même se retrouver avec trop de traitement à faire en cas d’expiration en masse de droit au DU lors d’un même bloc.

Donc si tu pars sur 2 il faut un mécanisme d’étalement des opérations sur plusieurs blocs (ce qu’il faudrait aussi à moyen-terme si on n’implémente pas ce ticket).

20

En tous cas, je trouve que proposer que les utilisateurs produisent eux même leur DU fait sens, dans une monnaie co-produite !

Cela va effectivement repartie naturellement la charge, en fonction des usages de chacun. Un peu comme de l’aléatoire.

Pour résoudre le problème de spam, il suffit d’obliger à produire tous les DU en attente d’un coup. Par exemple si on a dix jours de retard, il faut empêcher de produire seulement 1 DU, ou 5 ou 7, etc.

1 Like