Production du DU

Protocols Ğ1v2 protocol
, , , ,
21

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.

22

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
23

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
24

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
25

Bonjour et bienvenue !

Merci :smiley:

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 :wink:

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.

26

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 :confused:

27

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

28

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
29

La méthode de migration proposée par @elois me semble très bonne. Il faut en effet y aller par étapes. L’objectif le plus important à mon sens et d’après ma propre expérience est d’abord et avant tout de se familiariser avec substrate.

Migrer vers substrate est un bond qualitatif tout à fait considérable, qui doit faire économiser au final énormément de temps de développement et de maintenance étant donné que tout un tas de fonctionnalités blockchain codées directement dans Duniter v1 vont se trouver déportées dans substrate qui lui même est maintenu et développé par d’autres informaticiens.

Aussi in-fine c’est comme si ces informaticiens qui réalisent substrate avaient rejoint d’un coup l’équipe de développement de Duniter !

Accepter cet apport considérable, l’étudier, le comprendre, le mettre en oeuvre est déjà en soi un gros effort d’adaptation à une autre façon de penser, développer et réaliser un logiciel.

Cette migration substrate qui se fait maintenant avec un nombre considérablement plus important d’informaticiens intéressés par le projet Duniter/Ğ1 par rapport à Duniter v1, est une occasion exceptionnelle de monter en compétences techniques groupés, et donc de consolider toute l’infrastructure de la Ğ1.

Je rappelle à cette occasion que les RML16 se préparent bien, dans un lieu tout à fait exceptionnel, qu’elles seront justement dédiées à souder les équipes informatiques autour de ce projet, et que seuls les informaticiens déjà inscrits dans le groupe de travail des RML16 peuvent en recommander d’autres pour rejoindre cet événement extraordinaire !

9 Likes
30

J’ai avancé sur l’implémentation, et j’y vois maintenant plus clair, je me suis donc lancé dans un gros refactoring pour simplifier et clarifier, et je me suis rendu compte que j’étais obligé de garder certains bouts de code complexes que je pourrais purement supprimer si la création du DU étai manuelle.

Je me rends compte également qu’avec mon implémentation actuelle, il serait plus facile que je ne le pensais d’implémenter la création manuelle du DU.

Enfin, en faisant le point sur tout ce que je stocke dans le onchain storage et pourquoi, je me suis rendu compte qu’il y a une quantité non négligeable de données que je n’aurais pas besoin de stocker si la création du DU étai manuelle.

Tout cela, je ne pouvais pas le deviner avant d’implémenter, j’ai besoin de coder d’abord pour y voir plus clair, puis de refactorer au fur et à mesure.

Tout cela pour dire que je vais finalement reprioriser et implémenter la création manuelle du DU (où laisser @tuxmain le faire s’il préfère).
Je pense toujours que l’optimisation apportée sur le temps d’exécution du bloc est négligeable et inutile en dessous de 100000 membres, ce n’est donc pas pour cette raison que l’on va finalement implémenter la création manuelle du DU, on va le faire car :

  1. Ça permettra d’avoir une codebase plus simple, et donc plus facile à maintenir et à comprendre et avec moins de bug potentielles.
  2. L’alternative que je proposais (étalement sur plusieurs blocs avec X comptes traités par blocs s’avère plus complexe que la proposition originale (création manuelle lorsque l’utilisateur réclame ses DU).
6 Likes
31

@elois Du coup, avec la re-priorisation dont tu parle, qu’est ce qui va être implémenté ou l’a déjà été ?

En lisant ça :

J’imagine plutôt l’option 3 ?

32

Si cette proposition est implémentée ce ne sera aucune des 3, le problème ne se posera plus, il suffira de stocker pour chaque identité un champ last_claimed_ud_or_in_at: BlockNumber, qui contiendra le numéro de bloc du dernier DU réclamé ou le numéro de bloc de validation de l’identité si aucun DU n’a jamais été réclamé.

33

Je ne comprends pas en quoi ça répondrait au problème soulevé par @tuxmain mais n’étant pas sur le point de l’implémenter, ce n’est pas dramatique si tu ne prends pas le temps de me l’expliquer. :wink:

34

Le problème c’était de se souvenir des différentes entrées et sorties, et donc différentes périodes de droits au DU, s’il n’est plus possible de réentrer après une sortie de la wot, ce problème n’existe plus.

1 Like
36

Je trouve très intéressant de pouvoir permettre a l’utilisateur de produire son DU, et on peut même imaginer au niveau des clients que l’utilisateur puisse choisir une périodicité différente que juste journalière. Cela permettrait de ne pas être noyé sous les transactions.

Quelques idées pour optimiser plus :

  • la perte du statut de membre pourrait rester virtuelle et ne pas être stockée sur la chaîne. Seul serait stocké la date limite du statut de membre.
  • tout compte ayant été membre peut réclamer son DU. Si il n’est plus membre, il ne peut pas réclamer son DU au delà de la date où il est membre bien sûr
  • si un compte a perdu son statut de membre souhaite redevenir membre, il doit d’abord réclamer ses DU en attente si il en a avant de pouvoir renouveler son adhésion afin d’éviter des calculs de DU compliqués.

Du coup, toutes les actions seraient initiées par les utilisateurs et il n’y aurait pas d’actions automatiques qui prendraient des ressources sur la chaîne.

3 Likes
37

En relisant je me rends compte du nombre d’évolutions qui ont eu lien en 1 an !!

Résumé

Par ailleurs, ce sujet semble assez relié à Proposition de supprimer la notion d'identité désactivée mais non révoquée et la notion d'adhésion :

Je pense qu’il y a une manière de s’en sortir assez simplement en forçant le claim_ud au moment de la perte d’adhésion.

3 Likes
38

Personnellement je ne vois toujours pas en quoi c’est compliqué de stocker une liste d’entrées et de sorties pour un membre dans Substrate, et de calculer les DU là-dessus.

C’est aussi pour ça que j’avais trouvé (et trouve toujours) que c’était important de d’abord s’abstraire un peu de Substrate avec un protocole qui définit les grandes lignes du métier sans trop se poser de questions.

Le seul risque étant de mal jauger une hypothèse qui s’avérerait fausse (ex. ici “c’est facile de stocker la liste des entrées-sorties d’un membre”, qui si elle est vraie autorise une façon simple de produrie le DU manuellement, si elle est fausse oblige à passer par un système de claim_ud forcé). Mais quand même, là, je ne vois pas :slight_smile:

3 Likes
39

Je pense qu’on a intérêt à limiter au maximum le nombre de données dans le storage on chain parce que ça impacte la consommation mémoire, le stockage, le trafic réseau, en particulier pour les nœuds archive. La solution du claim_ud automatique me paraît bonne, et bien implémentée avec l’événement UdsAutoPaidAtRemoval.

2 Likes
40

Oui d’accord, mais sais-tu dire dans quelle mesure a-t-on cet intérêt ?

Je veux dire par là que je lis beaucoup de sujets où le souci c’est plus l’optimisation que d’atteindre l’objectif de migration. Or les deux sont assez antinomiques.

La solution claim_ud automatique est sûrement très bien, hein, ce n’est pas mon propos. Mais les entrées/sorties ça me semble suffisant aussi.

Je veux dire que l’on peut très bien se contenter de solutions “moyennes” à 10k membres, car l’objectif principal c’est bien la migration pour 10k membres, et pas de s’occuper du gain de consommation mémoire pour une blockchain qui sera de toute façon sous-utilisée pendant plusieurs mois au moins après sa migration.

3 Likes
41

Je suis évidemment entièrement d’accords avec @cgeek sur la non urgence d’optimiser un max ce protocole au vue des prévisions d’utilisation qui sont devant nous. Je suis content que tu remettes ces démarches sur le tapis. Les runtime upgrades à chaud sont rassurants en ce sens.

Cependant du coup, la question que je me pose pour ce point précis, c’est que vue que le système de claim_ud semble bien fonctionner actuellement, pourquoi vouloir revenir en arrière pour quelque chose de moins optimisé ?

2 Likes