# Production du DU
**URL:** https://forum.duniter.org/t/production-du-du/8998
**Category:** Ğ1v2 protocol
**Tags:** ud
**Created:** [6 January 2022 08:42 UTC](https://forum.duniter.org/t/production-du-du/8998 "2022-01-06T08:42:06Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [6 January 2022 08:42 UTC](https://forum.duniter.org/t/production-du-du/8998/1 "2022-01-06T08:42:06Z")
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.
---
### Author:  [@Maaltir](https://forum.duniter.org/u/Maaltir)
#### Post date: [6 January 2022 10:44 UTC](https://forum.duniter.org/t/production-du-du/8998/2 "2022-01-06T10:44:31Z")
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 ?
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [6 January 2022 12:15 UTC](https://forum.duniter.org/t/production-du-du/8998/3 "2022-01-06T12:15:25Z")
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). 🙂
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [6 January 2022 13:33 UTC](https://forum.duniter.org/t/production-du-du/8998/4 "2022-01-06T13:33:37Z")
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).
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [6 January 2022 13:40 UTC](https://forum.duniter.org/t/production-du-du/8998/5 "2022-01-06T13:40:20Z")
> [@poka](#):
>
> Une autre solution ne pourrai elle être de traiter n comptes a la fois pour l’écriture du DU ?
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 🤔
---
### Author:  [@Pini](https://forum.duniter.org/u/Pini)
#### Post date: [6 January 2022 13:41 UTC](https://forum.duniter.org/t/production-du-du/8998/6 "2022-01-06T13:41:51Z")
Il y aura forcement des DU qui ne seront jamais réclamés. Comment ça va se passer dans ce cas ?
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [6 January 2022 14:05 UTC](https://forum.duniter.org/t/production-du-du/8998/7 "2022-01-06T14:05:02Z")
Comme aujourd’hui !
---
### Author:  [@matograine](https://forum.duniter.org/u/matograine)
#### Post date: [6 January 2022 17:20 UTC](https://forum.duniter.org/t/production-du-du/8998/8 "2022-01-06T17:20:41Z")
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).
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [6 January 2022 17:35 UTC](https://forum.duniter.org/t/production-du-du/8998/9 "2022-01-06T17:35:12Z")
Oui, c’est ce que j’essayais de signifier :
> [@cgeek](#):
>
> même avec plusieurs périodes de présences
D’ailleurs la fonction doit être appelable même pour un compte révoqué, oui, nous sommes bien d’accord.
---
### Author:  [@tuxmain](https://forum.duniter.org/u/tuxmain)
#### Post date: [9 January 2022 19:19 UTC](https://forum.duniter.org/t/production-du-du/8998/10 "2022-01-09T19:19:57Z")
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.
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [10 January 2022 08:19 UTC](https://forum.duniter.org/t/production-du-du/8998/11 "2022-01-10T08:19:48Z")
Oui, M est calculé par le protocole, indépendamment de la circulation de la monnaie.
> [@tuxmain](#):
>
> ça pourrait être pratique que l’émission d’une transaction produise automatiquement le DU
Oui on peut tout à fait rajouter un paramètre `produce_ud_if_needed` au moment de l’appel à `Dubp.transfer()`, bonne idée 🙂
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.
---
### Author:  [@matograine](https://forum.duniter.org/u/matograine)
#### Post date: [10 January 2022 18:21 UTC](https://forum.duniter.org/t/production-du-du/8998/12 "2022-01-10T18:21:51Z")
> [@cgeek](#):
>
> je rajouterai des frais sur cette option qui seront payés par les non-membres
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](https://forum.duniter.org/t/les-frais-dextrinsics/8941)) 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.
> [@cgeek](#):
>
> De plus j’insiste sur le fait que ce serait une production « si nécessaire »
Sous-entendu : les devs clients, faites en sorte d’exécuter cet appel une fois par jour et par membre eu maximum 😉
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [10 January 2022 19:45 UTC](https://forum.duniter.org/t/production-du-du/8998/13 "2022-01-10T19:45:15Z")
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 🙂
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [11 January 2022 09:19 UTC](https://forum.duniter.org/t/production-du-du/8998/14 "2022-01-11T09:19:56Z")
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 :
> [@IMPORTANT : Proposition de migrer la Ğ1 sur une blockchain substrate](https://forum.duniter.org/t/important-proposition-de-migrer-la-g1-sur-une-blockchain-substrate/8573/49):
>
> Sachant que dans la conf de polkadot le poid maximal d’un bloc est 2000 milliard de poids et qu’une transaction monétaire à un poid de 68885000. La limiti théorique maximale est de 14516 transactions monétaires par bloc, soit **2419 transactions par seconde** soit environ 209 millions de transactions par jour.
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.
---
### Author:  [@Roswell974](https://forum.duniter.org/u/Roswell974)
#### Post date: [12 January 2022 08:48 UTC](https://forum.duniter.org/t/production-du-du/8998/15 "2022-01-12T08:48:10Z")
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
---
### Author:  [@tuxmain](https://forum.duniter.org/u/tuxmain)
#### Post date: [12 January 2022 09:14 UTC](https://forum.duniter.org/t/production-du-du/8998/16 "2022-01-12T09:14:59Z")
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.
---
### Author:  [@tuxmain](https://forum.duniter.org/u/tuxmain)
#### Post date: [12 January 2022 16:39 UTC](https://forum.duniter.org/t/production-du-du/8998/17 "2022-01-12T16:39:34Z")
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.
---
### Author:  [@Pini](https://forum.duniter.org/u/Pini)
#### Post date: [12 January 2022 17:40 UTC](https://forum.duniter.org/t/production-du-du/8998/18 "2022-01-12T17:40:31Z")
> [@tuxmain](#):
>
> Je préfère la 2.
Oui, ça semble le plus juste sans être spécialement coûteux.
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [12 January 2022 19:28 UTC](https://forum.duniter.org/t/production-du-du/8998/19 "2022-01-12T19:28:54Z")
> [@tuxmain](#):
>
> je me lance dans le claim\_ud pour commencer par des choses faciles.
Ce qui est un mauvais choix car c’est en réalité un ticket difficile, j’explique en partie pourquoi dans le ticket gitlab.
> [@tuxmain](#):
>
> - ces DU sont perdus.
> - ces DU sont produits automatiquement lors de la perte du statut de membre.
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).
---
### Author:  [@kimamila](https://forum.duniter.org/u/kimamila)
#### Post date: [12 January 2022 21:24 UTC](https://forum.duniter.org/t/production-du-du/8998/20 "2022-01-12T21:24:24Z")
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.
[Next page](https://forum.duniter.org/t/production-du-du/8998.md?page=2)