En essayant de comparer les paramètres actuels de la Ğ1 avec ceux précisés pour chaque monnaie (et alerter des différences), je crois détecter que le paramètre msPeriod (voir protocole v1) a disparu avec Duniter V2S, ce qui autoriserait un membre à “spammer” la blockchain avec cette demande.
Me trompes-je ?
edit : je vois que l’on a déjà évoqué le sujet ici : nous avons bien un paramètre dans Duniter V2S MembershipPeriod mais celui-ci correspond plutôt à msValidity de Duniter V1.
Donc effectivement, le spam de cet extrinsic semble autorisé pour renouveler son adhésion. D’autant que si l’on rembourse les frais d’extrinsics aux membres, alors nous avons là une faille.
Le spam de renouvellement d’adhésion n’a rien de fondamentalement différent du spam de transaction. C’est pour ça que la même solution est appliquée à tous les extrinsics : les frais. Les quotas sont juste une marge additionnelle qui donnent un droit supplémentaire (limité) d’écrire des choses en blockchain.
Dit autrement, le coût pour la blockchain d’écrire un renouvellement d’adhésion est mesuré de la même manière que le coût d’écriture d’une transaction. Il n’y a donc pas de raison de contraindre davantage l’utilisateur sur la fréquence d’appel d’un call donné. D’où le retrait de ce paramètre.
J’avais cru comprendre qu’il n’y avait plus de renouvellement d’adhésion.
Mais que l’adhésion tombais après un certain délai depuis la dernière action sur le compte…
En fait il faut distinguer ce qu’on fait côté Duniter et ce qu’on fait côté client. Rien ne nous empêche de faire un client qui à chaque action (certification, transfert…) effectue également le renouvellement d’identité dans un batch, mais implémenter ça côté Duniter serait une mauvaise idée.
C’est une partie de la difficulté de conception côté Duniter : il faut mettre en place un système assez général et assez clair qui permette de développer simplement les usages qu’on veut côté client.
Et ça montre que la conception des clients doit aussi se faire en discussion avec la communauté. Mais pour l’instant on n’a pas de développeurs de clients v2. Ce serait bien qu’on avance un peu là dessus avant la dernière minute.
C’est bien Duniter qui décide quand un compte n’est plus créateur de DU ? ??
Donc cela ne me parait pas déconnant de voir à ce moment-là de quand date la dernière action, et de reporter le délai en conséquence.
Maintenant, je ne sais pas si ce que je dis est faisable simplement…
Le problème est qu’on ne peut attendre de Duniter que de connaître l’état au bloc précédent, pas tout l’historique. Donc si on veut savoir de quand date la dernière action, comme Duniter ne peut pas explorer l’historique, il faut stocker cette information dans l’état. Ajouter une information dans l’état qui est modifiée à chaque action est coûteux en ressources (mémoire et calcul), c’est une mauvaise idée de l’imposer. D’où le choix de découpler ces deux fonctionnalités, ce qui permettrait par exemple de faire un client avec une option activée par défaut “renouveler automatiquement mon identité” qui s’activerait lorsque l’identité soumet une transaction et que son adhésion expire dans une durée inférieur à 3 mois par exemple.
