Bonsoir à chacun, c’est incroyable de voir le niveau de réflexion ici avec tellement de créativité et d’imagination. C’est beau !!
Dans la vie j’aime bien le principe KeepItStupidSimple, du coup je me demande pourquoi ne pas simplement mettre en place un « coup automatique en pourcentage du montant de la transaction » ?
Il me semble que :
ça tue dans l’oeuf les attaques en faisant pleins de petits virements successif en les limitant dans le temps à cause de la diminution du volume,
ça ne tombe pas dans le piège des frais fixes (c’est dans les 60€ par transaction pour Ethereum en ce moment il me semble, c’est énooorme) et n’avantage pas les riches
En plus laissant ce paramètre libre de varier dans le temps en fonction de la congestion justement ça pourrait pousser certains utilisateurs à choisir de retarder leur transaction de quelques minutes/heures.
Un exemple : je doit faire un virement à un ami pour la soirée pizza, je suis en train de le faire, mais une petite alerte de mon appli me dis que les frais sont haut parce que le réseaux est en saturation. Du coup je clique sur l’option « faire le virement plus tard quand les frais seront moins important », et voilà. Ça reste dans mon appli pour ne pas congestionner le réseau bien sur.
Un autre exemple : je veux faire tomber la june, j’ai un milliard de compte avec le minimum (1G1 si je me souviens bien) soit un milliard de june. Je lance mon script pour faire un milliard de transaction en même temp. Première transaction ça passe, sauf que j’ai perdu 1% et que le système se dit « woooo » y’a du monde, on va augmenter le pourcentage à 10% !!!" De mon côté deuxième tentative, mais là je tombe sous la limite d’existence des portefeuilles et mon attaque s’arrête là. Elle aura duré 1 bloc et m’aura couté 1 milliard !!!
D’autre part, je donne régulièrement à Remuniter, mais « il faut que j’y pense ». Perso je préfèrerai que ce soit automatique lorsque j’utilise la June via la blockchain. Personnellement je me dis que 1% comme valeur de base minimal ça serait pas mal. Et concrètement ça pourrait aller directement à tout les serveurs qui on calculé le blocs et qui donc maintiennent le service.
Pour résumer : quand on utilise un service on devrait le payer → mettre en place des frais de transaction automatique.
Mais si je fais plein de très petites transactions, ça me coûte très peu mais ça coûte énormément au réseau, il faut donc une limite basse aux frais.
Et il y a d’autres transactions que les mouvements de monnaie, par exemple tout ce qui touche à la toile de confiance. Comment calcule-t-on les frais dessus ?
Enfin ce mécanisme de poids fait partie du fonctionnement de Substrate, et c’est ce qui détermine la quantité de transactions à intégrer dans un bloc. Il est plus sûr et optimal de se baser sur le temps de calcul, que sur le montant d’une transaction. On aurait donc deux systèmes différents, les frais et les poids.
Car une transaction n’a pas forcément de montant, ici le terme transaction ne désigne pas “transfer de monnaie”, mais “action en blockchain qui modifie l’état du système”. Avec duniter-v2s il y a de très nombreux types de transactions possibles (plusieurs dizaines), et seulement 3 ou 4 ont un montant.
Aussi comme l’explique bien @tuxmain, il y a un “coût de base” à l’exécution d’une transaction, qui est indépendant de son montant.
Ainsi envoyer 2 transactions de 1Ğ1 coûte 2 fois plus de ressources à la blockchain qu’une seule transaction de 2 Ğ1.
Ta proposition ne peut donc pas convenir pour répartir le temps d’exécution en blockchain, en revanche elle peut convenir pour financer des choses, comme pas exemple (liste non-exhaustive):
La rémunération des créateurs de bloc
La rémunération de ceux qui stockent les données des utilisateurs
L’alimentation d’une trésorerie commune gérée par gouvernance onchain
Ces frais proportionnels additionnels aux poids sont intéressants en fait : ils réduisent l’asymétrie entre riches et pauvres. Avec seulement les poids, les grosses transactions sont taxées autant que les petites, donc elles sont négligeables quand on achète une maison, mais importantes quand on achète une baguette. Est-ce encore une monnaie libre dans ce cas ?
Donc l’introduction d’une faible taxe monétaire (donc prélevée en G1 et non en monnaie-poids), par exemple de formule floor(taux * montant) ne me semble pas une mauvaise idée. Pour un montant assez grand, le poids devient négligeable devant la taxe, ce qui n’avantage pas les grosses transactions par rapport aux petites.
Après, peut-être que privilégier les grosses transactions est utile, notamment pour réduire la fréquence des transactions. Mais il faut voir les conséquences économiques, par exemple l’inégalité entre ceux qui peuvent faire des grosses transactions (les riches) et les autres (les pauvres).
En gros, la taxe est la même pour tous (complètement inégalitaire au même titre que la TVA).
Pour conclure, introduire une taxe qui sera payer par tous en fonction du montant n’équilibre rien. Par contre, le coût de la transaction peut vite faire grimper le coût total d’utilisation si nous faisons de multiples opérations. Donc, ce n’est pas très juste non plus.
Cependant, je ne vois pas trop de solution pour rendre le système plus juste. Je penses que ce sujet mérite vraiment d’être creusé.
Je voulais dire que ça réduisait considérablement l’avantage donné aux grosses transactions.
Mais si on utilise la monnaie-poids transférable, ça ne devrait pas être nécessaire. C’est utile surtout si les poids sont payés en G1 ou que la monnaie-poids n’est pas transférable (et donc que les comptes non-membres doivent payer les poids en équivalent G1).
Il y a des propositions autres que la monnaie-poids :
quota gratuit par unité de temps pour les membres, avec possibilité de déléguer une partie de son quota à des comptes portefeuille.
Implémentation 1 : à chaque transaction, vérifier si l’origine est membre et compter le quota onchain immédiatement
facile à gérer pour les wallets, immédiat, facile à coder
coûteux (2 lectures storages) à chaque transaction
Implémentation 2 : pour profiter du quota, il faut mettre son extrinsic dans un extrinsic wrapper particulier. On ne vérifie le quota que si le wrapper est là.
n’augmente pas la complexité des transactions sans quota, immédiat, facile à coder, facile à gérer côté wallet
augmente la complexité des transactions des membres
Implémentation 3 : oracle de remboursement différé. Un indexeur note les transactions éligibles au quota et périodiquement rembourse (en inhérent) les membres.
n’augmente pas la complexité des transactions
long à coder, non-immédiat, difficile à gérer pour les wallets (afficher un solde futur après remboursement)
PoW côté wallet
facile à coder, léger à vérifier en blockchain, immédiat
revient à payer en € l’électricité plutôt que des G1, coûteux en énergie d’une manière invisibilisée, peut être délégué à un service de PoW commercial
Ici le terme “immédiat” se réfère au ressenti de l’utilisateur, qui n’aura pas l’impression de s’être vu prélever une taxe. Il a été exprimé que ce ressenti était important, et qu’un prélèvement suivi d’un remboursement serait quand même problématique. Les wallets peuvent toutefois minimiser cet effet en affichant le solde futur après remboursement.
Edit: mémo idée pour l’implémentation des quotas. Stocker pour chaque identité (ou membership ?) la dernière session (ou le dernier jour ?) où un extrinsic a été émis par cette identité, ainsi que la somme des frais accumulés non payés sur cette période.
Je propose de partir sur l’implémentation 1 du quota. (cf message précédent)
C’est la plus simple pour tout le monde (wallet et nœud, devs et utilisateurs) et le coût runtime est minime.
Le quota peut être glissant sur 24h avec granularité de 1 bloc : chaque membre a un quota maximum Q. À chaque transaction, on incrémente le quota (sans dépasser Q) proportionnellement au nombre de blocs passés depuis la dernière utilisation du quota, de sorte qu’un quota vide se remplisse complètement en 24h. Ensuite on le décrémente du poids de la transaction. Le reste est payé en G1.
Dites si vous êtes contre ou pensez qu’il y a encore à débattre.
Bien vu. Plutôt que de chercher si l’origine est membre, on peut regarder dans une StorageMap AccountId->IdtyIndex qui associe l’identité à sa clé publique et ses clés déléguées.
Pour commencer on peut se contenter des comptes membres, et l’ouverture aux délégués sera facile à faire.
Quitte à faire en deux temps, je préférerais que tu conserves ta solution initiale : vérifier si le compte est membre ou non.
Pour moi le sujet des comptes portefeuilles sans frais n’est pas assez mûr, je préférerais que l’on ne s’engage pas trop dans une voie technique particulière qu’il faudrait possiblement démonter ensuite.
facile à gérer pour les wallets, immédiat, facile à coder
coûteux (2 lectures storages) à chaque transaction