En terme de communication, concernant la Ğ1v2 il y a un point sur lequel nous avons 2 choix:
“Les transactions entre comptes membres sont totalement gratuites”
“Les transactions entre membre ne coûtes que 0.001 Ğ1 de frais de fonctionnement indispensables blabla…”
Nous préférons l’option 1.
Donc étant donné que par conception, ne devons taxer au moins 0.001 Ğ1v2 par transactions, même entre membre, alors je propose:
Rembourser chaque transaction entre comptes membres depuis une caisse commune
Un simple compteur incrémental représentant le nombre de transaction à rembourser
Chaque client compense le solde affiché en ajoutant autant de centimes que de chiffre au compteur pour l’utilisateur
Une transaction de remboursement est faite en batch par le client si:
Le compteur atteins 20 (ou 50, ou…) → puis compteur reset
Ou si le solde réel n’est pas suffisant pour effectuer la transaction demandé
Ainsi on pourra réellement affirmer aux gens “Les transactions entre comptes membres sont gratuites.”
Qu’en pensez-vous ?
edit: bon ce n’est pas exactement le même système que claimud, qui n’est pas un compteur incrémental, mais un numéro de premier DU non réclamé.
Du coup, je ne suis pas certains qu’incrémenter un compteur en storage soit une quelconque optimisation par rapport à effectuer une transaction de 0.001 Ğ1… Je veux bien vos avis là dessus.
Ça me fait penser que si on part sur le remboursement des frais de transaction, on pourrait abandonner la notion de quota.
Les frais de transaction des remboursements eux-mêmes peuvent être pris sans problème sur la caisse commune du moment qu’elle est alimentée par des dons.
mais du coup je me demande, ce compteur incrémental dont je parle, l’extrinsic pour l’executer, on sera obliger de le charger aussi ? Du coup ça ne sert à rien ?
Sauf si on considère qu’entre membre, pas de risque de spam, donc pas de frais, mais dans ce cas est-ce vraiment utile de passer par un compteur intermédiaire ?
En fait le compteur dont je parle n’a rien a voir avec le système de claimud j’ai dit des bêtises.
De toute façon il faut des frais. Deux membres malveillants ne devraient pas pouvoir remplir les blocs en s’échangeant des transactions. D’où l’utilité des quotas (par exemple pour chaque membre, 50 transactions/jour sans frais).
Il faut aussi différencier les frais d’extrinsics (qui sont nécessaires – au moins hors quota – pour empêcher le spam) des frais proportionnels à la valeur de la transaction (qui n’existent pas encore mais à considérer, car leurs conséquences économiques sont différentes, je me souviens qu’on en a parlé en détail dans un topic plus ancien).
Attention les frais fixes de 0.001 Ğ1 sont une béquille temporaire pour la ĞDev mais pas du tout utilisables en production.
Il vous faut finir l’étalonnage des poids que j’avais commencer puis implémenter dans la configuration de la pallet transaction-payment une formule pour déterminer les frais à partir de cesr 2 paramètres:
Poid de l’extrinsic en temps d’exécution benchmarké
Taille de l’extrinsic en octets
Cette formule est le seul rempart contre le spam en temps d’exécution ou en taille, car chaque bloc est limité dans les 2 grandeurs (2secondes et 5Mo).
La formule ne doit pas être purement linéaire, du moins plus au delà d’un certain seuil, pour prévenir les attaques avec grosses transactions.
Les frais peuvent être remboursés à la fin de l’exécution du call en retournant Pays::No si et seulement si certaines conditions sont réunies, mais l’utilisateur doit quand même avoir le solde nécessaire pour soumettre la transaction.
Et les conditions de remboursement doivent définir leurs propres limites sinon c’est open bar pour spammer.
Est-ce que la formule pourra aussi évoluer dans le temps ? J’imagine que oui grâce à une mise à jour de runtime.
Du coup on pourra tout à faire mettre en oeuvre des contraintes plus fortes (ou plus fines) avec le temps, non ?
Oui vous pouvez, mais ça augmente les risques de hack de la Ğ1v2. Car un attaquant peut remplir les blocs de manière à ce qu’aucune transaction des autres utilisateurs ne puisse jamais passer (ou très peu), et ainsi rendre la Ğ1v2 très lente en pratique pour l’utilisateur voire inutilisable.
D’ailleurs c’est déjà faisable sur la Ğ1v1, mais la différence c’est que les hackers ne connaissent pas notre implémentation custom, alors que les blockchains basées sur substrate sont légion, et que les outils pour interagir avec sont beaucoup plus connus et répandus. Le passage sur substrate a pour inconvénient de nous exposer d’avantages à de potentielles attaques à cause de l’effet “système connu”.
C’est pourquoi je suggère plutôt de partir dès le départ sur une formule un peu robuste, surtout que c’est très simple à implémenter, ce n’est quasiment que de la config
Ce qui est difficile c’est l’étalonnage des poids, qu’il faut de toute façon faire pour d’autres raisons, notamment savoir combien de transactions ont peu insérer dans un bloc en restant dans un temps d’exécution max de 2s.
