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
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
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 
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
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 
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 
1 Like
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
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
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
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 :
- ces DU sont perdus.
- ces DU sont produits automatiquement lors de la perte du statut de membre.
Je préfère la 2.
4 Likes
Oui, ça semble le plus juste sans être spécialement coûteux.
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).
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
Produire plein de DU d’un coup sur un même compte n’est pas tellement plus lourd avec les approches 1 et 2 (à part si ils se répartissent sur plusieurs périodes de réévaluation mais ça reste un surcoût négligeable, quelques opérations arithmétiques par période de réévaluation). C’est justement plus rapide de tout faire en une requête que de faire DU par DU.
D’ailleurs les clients pourraient même invisibiliser ce mécanisme la plupart du temps, en comptant les DU non produits dans le montant du portefeuille, et en ne les réclamant qu’au besoin. Si on fait un bouton “réclamer mon DU”, les gens risquent de vouloir le spammer et ça fera un sujet d’incompréhension récurrent de plus sur le forum ML.
Il est évident qu’en termes d’UX les wallet devrait cacher cette complexité, et afficher les DU produit même s’ils n’ont pas été réclamés, et ne les réclamer que si l’utilisateur en a besoin pour un transfer par exemple. C’est d’ailleurs faisable en un seul et même extrinsic, on peut en effet soumettre plusieurs extrinsics en 1 seul grâce à l’extrinsic batch.
Donc par exemple, lors d’un transfer, le wallet pourrait soumetter l’extrinsic batch([claim_uds(), transfer(amount, to)]), ainsi une seule “transaction” à signer et envoyer au réseau.
Cela étant, je pense qu’a court-moyen terme on n’a pas besoin de cette optimisation, et que tant qu’on est pas au moins 100000 membres, il est plus simple et suffisant de simplement étaler la création du DU sur plusieurs blocs.
Je sais qu’on en à pas besoin avant car c’est ce qu’on fait chez moonbeam pour transférer des staking rewards à 64000 delegators, et ça fonctionne, on réalise 1000 transfer par bloc sur 64 blocs.
C’est pour cela que j’ai affecté la priorité la plus basse à ce ticket gitlab, ce sera implémenté un jour, mais ce n’est pas nécessaire pour la migration, sauf à ce que la toile Ğ1 explose x100 en moins d’un an, ce qui me semble très improbable.
1 Like
Bonjour à tous,
Je penses que l’idée de création du DU par l’utilisateur est une bonne idée.
Il faudrait que ce soit transparent pour l’utilisateur. Cependant, il faut être sûr que tous les clients soient prêt à le faire avant de l’activer sur Duniter. Cela évitera que des membres co-créateurs ne puissent pas créer leur DU.
Je penses que la logistique de synchronisation de ce développement risque d’être plutôt lourd.
P.S. : Je penses sérieusement à donner un coup de main pour les développements futurs, étant développeur dans ma vie professionnelle.
3 Likes
Bonjour et bienvenue !
Sauf usages particuliers, je ne vois pas l’intérêt à ce que l’utilisateur contrôle ceci. Une gestion automatisée par le client permettrait au contraire de minimiser le coût côté nœuds et blockchain.
Ça ferait une notion de plus à assimiler, avec des cas particuliers non intuitifs et des incompréhensions.
De toute façon les clients actuels ne sont pas compatibles avec DuniterV2, la migration ne se fera que quand le nœud ET les clients seront prêts. Un intérêt de faire rapidement cette optimisation du DU est qu’il ne sera pas nécessaire de modifier les clients après la migration (ça fait un changement de protocole).
1 Like
Bonjour et bienvenue !
Merci 
Sauf usages particuliers, je ne vois pas l’intérêt à ce que l’utilisateur contrôle ceci. Une gestion automatisée par le client permettrait au contraire de minimiser le coût côté nœuds et blockchain.
Nous sommes d’accord
De toute façon les clients actuels ne sont pas compatibles avec DuniterV2, la migration ne se fera que quand le nœud ET les clients seront prêts
Je n’ai pas la vision globale du système étant donné que je suis le sujet que depuis peu. Merci pour l’information.
Cet argument n’est pas valide, car de toute façon il continuera d’y avoir des changements de protocole après la migration, et une coordination avec les développeurs des wallet pour s’assurer qu’ils supportent changements cassant (quand ils sont cassants, ce qui ne sera pas toujours le cas).
Chaque changement de protocole implique nécessairement d’incrémenter la spec version du runtime, qui est fournie par l’api RPC, donc les wallet et autres logiciels interagissant avec la blockchain, devront dabord requeter la spec version puis agir différemment en fonction de cette dernière.
L’une de mes principales motivations pour migrer sur substrate, c’est pour avoir enfin un écosystème technique qui soit capable d’évoluer, en fonction des besoins en envies des utilisateurs.
Le but n’est pas de construire quelque chose de figé qui ne bougerait plus après la migration sur substrate, enfin si c’est votre but c’est sans moi.
Duniter v1 est figé depuis trop longtemps, il y a plusieurs nouvelles fonctionnalités qu’on veut intégrer depuis des années (comme les virements automatiques par exemple) mais qu’on n’a pas pu intégrer car dès qu’on essaye de modifier duniter v1 ça devient trop instable.
Tant qu’on a pas migré sur substrate, l’écosystème technique est complètement bloqué, donc il me semble que nous devons prioriser et travailler d’abord sur ce qui est nécessaire à la migration.
Il y a déjà énormément à faire pour pouvoir migrer la Ğ1, alors si vous voulez que ça ne prenne pas 10 ans, je vous prie de bien vouloir me faire confiance pour la priorisation, et mettre de côté pour le moment les changements qui ne sont pas nécessaires à cette migration.
Pour moi la migration de la Ğ1 sur substrate n’est pas une fin en soi, c’est uniquement une 1ère étape, le début d’une nouvelle ère où la Ğ1 va enfin pourvoir évoluée et ne plus rester figée.
Mais cette première étape est la plus difficile, et va demander énormément de travail de la part du plus grand nombre, alors si en plus vous compliquez la tache en voulant intégrer trop de choses d’un coup, vous allez rajouter trop d’efforts, ça va me démotiver et je vais de nouveau partir pour plusieurs mois, voir définitivement 
Étant donnée que la solution de répartir la création des DU par tranches sur plusieurs blocs me semble suffisante et beaucoup plus simple à implémenter, je suis également de cet avis.
Tout ce qui n’est pas nécessaire ne doit pas être considéré pour cette migration.
Cette proposition de claim_uds semble séduire la plupart des dev ici (ce n’est pas mon cas mais je suis finalement assez neutre là dessus, je n’ai pas encore compris les arguments d’optimisations des bases qu’expliquait cgeek), mais son implémentation précise risque d’être sujet à débat:
Ca ne me semble pas si évident pour tout le monde.
J’ai l’impression que les effets de bords de ce claim_uds sont assez nombreux, et que cela implique donc une couverture de test imposante, donc beaucoup de travail.
Répartir les DU sur plusieurs bocs me semble largement moins risqué, plus facile à couvrir, et je ne comprends pas encore quels inconvénients cela aurait.
Et elle me séduit également, je pense que ça sera nécessaire si un jour on passe à une toute autre échelle (plusieurs centaines de milliers de membres).
Le gain se fait sur les utilisateurs qui ne réclame pas leur DU, alors qu’en mode automatique on doit transférer tous les DU, qu’importe si l’utilisateur les demandera un jour ou jamais.
Ça permet aussi de faire payer à l’utilisateur le temps d’exécution nécessaire à la livraison de son DU, alors que tout ce qui est fait automatiquement (dans les hook), ce n’est payé par personne, et prend à tout le monde une ressource commune limitée : le temps d’exécution sur la blockchain.
Mais nous somme à des années lumières de ces problématiques, vu la charge ridicule de la Ğ1 en nombre d’utilisateurs et en nombre de transactions par seconde.
3 Likes