Les frais, ça devient concret

[HugoTrentesaux]

Dans la MR !227, @bgallois a fait un travail d’analyse qu’il me semble important de partager ici, pour ceux qui n’ont pas le courage d’aller lire sur GitLab

Si quelqu’un est motivé pour traduire en français en dessous, ça permettrait à ceux qui ne lisent pas l’anglais de suivre.

@bgallois

Summary

• Introduce a constant fees model for testing with the constant-fees feature.
• Implement a non-constant fees model for production (details below).
• Change the naming in pallet_certification to enhance documentation generation and improve readability for users.
• Resolve benchmark weight files naming.

Fee

Fee paid by the user when executing an extrinsic is computed as:
(base_fee + length_fee + weight_fee) * fee_multiplier

With:

• base_fee = weight_to_fee(base_weight)
• weight_fee = weight_to_fee(extrinsic_weight)
• length_fee = length_to_fee(extrinsic_length_bytes)
• fee_multiplier can be adjusted after each block.

Transaction fees should provide an incentive to limit on-chain resource consumption (storage, computation) and avoid malicious attacks.

Choosing parameters

Common guidelines to set these arbitrary functions (multiplier, weight_to_fee and length_to_fee) are:

• How many extrinsics could fit in a block.
• How much people should pay at a minimum to fill a whole block with their transactions.

A fee too low will make the network vulnerable to attacks, and too high will inhibit the incentive to participate in the network. In our case, with the quota system, members will be refunded after each transaction if the network is not saturated.

Duniter-v1

Taking some statistics from the Duniter-v1 network over the past year, we observe that the mean transaction frequency is 0.01, representing 0.06 transactions per block of Duniter-v2s. At peak usage (occurring for less than a week cumulatively throughout the year), there were 0.09 transactions per second, equating to 0.54 transactions per Duniter-v2s block.

The maximum wallet value is 269 029 ĞD, while the median value of non-empty wallets is 450 ĞD. Additionally, only 25% of non-empty wallets have currently a balance exceeding 3 700 ĞD and the DU is currently at 10.78 ĞD.

Duniter-v2

To get an order of magnitude, on the actual reference machine, 26 482 700 base extrinsics can fill a block. The most computationally intensive calls are create_identity, revoke_membership, and remove_member, and will take approximately 2 000 extrinsics to fill the block. Most calls are of the order of magnitude similar to a balance transfer that takes 8 264 calls to fill a block.

First proposition

To start implementing the logic, a good starting point could be:

• Use WeightToFeePolynomial with a 1-degree polynomial to map 5 cĞD to 1 base extrinsic weight so that filling a block with base extrinsics will cost 1 324 135 ĞD, and filling a block with the most common extrinsics will cost 1 300 ĞD.
• Use 1 cĞD for each 100 bytes of extrinsic lengths (not much vulnerability to attacks with our extrinsics on this side).
• FeeMultiplier can be used to account for the variation of demand on the network. As the data from duniter-v1 shows that we are far from overcharging the network, it can be initially set to one, but it can be adjusted in the future to account for monetary mass and user growth.

With these values, a simple balance transfer will cost 17 cĞD (0.016 DU), which is not prohibitively high for legitimate transactions (as it will be refunded). However, a malicious attacker would need to commit (and partially lose) at least 1 400 ĞD (130 DU) to fill one block that is more than 60% of the non-empty wallets in the current network.

This MR will put in place the logic to implement a non-constant weight-to-fee conversion, but the final exact parameters will also need discussion and adjustment, taking into account the final reference machine and the dynamics of the network at deployment.

À noter que les données Duniter-v2 fournies ici sont sur CPU: 12th Gen Intel(R) Core(TM) i3-12100F, peut-être un peu supérieur à un Broadcom BCM2711, Quad core Cortex-A72 (ARM v8) 64-bit SoC @ 1.8GHz de raspberry pi 4.

[bgallois]

Frais

Les frais payés par l’utilisateur lors de l’exécution d’un extrinsic sont calculés comme suit :
(base_fee + length_fee + weight_fee) * fee_multiplier

Avec :

• base_fee = weight_to_fee(base_weight)
• weight_fee = weight_to_fee(extrinsic_weight)
• length_fee = length_to_fee(extrinsic_length_bytes)
• fee_multiplier peut être ajusté après chaque bloc.

Les frais de transaction devraient fournir une incitation à limiter la consommation de ressources on-chain (stockage, calcul) et éviter les attaques malveillantes.

Choix des paramètres

Des guidelines pour définir ces fonctions arbitraires (multiplier, weight_to_fee et length_to_fee) sont :

• Combien d’extrinsics peuvent s’insérer dans un bloc.
• Combien les utilisateurs devraient payer au minimum pour remplir un bloc entier avec leurs transactions.

Des frais trop bas rendront le réseau vulnérable aux attaques et des frais trop élevés réduiront l’incitation à participer au réseau. Dans notre cas, avec le système de quota, les membres seront remboursés après chaque transaction si le réseau n’est pas saturé.

Duniter-v1

En prenant des statistiques du réseau Duniter-v1 au cours de la dernière année, on observe que la fréquence moyenne des transactions est de 0,01 Hz, représentant 0,06 transactions par bloc de Duniter-v2s. En utilisation maximale (se produisant pendant moins d’une semaine cumulativement tout au long de l’année), il y avait 0,09 transactions par seconde, équivalent à 0,54 transactions par bloc Duniter-v2s.

La valeur maximale des portefeuilles est de 269 029 ĞD, tandis que la valeur médiane des portefeuilles non vides est de 450 ĞD. De plus, seuls 25% des portefeuilles non vides ont actuellement un solde dépassant 3 700 ĞD et le DU est actuellement à 10,78 ĞD.

Duniter-v2

Pour avoir une idée de l’ordre de grandeur, sur la machine de référence actuelle, 26 482 700 extrinsics de base peuvent remplir un bloc. Les appels les plus intensifs en calcul sont create_identity, revoke_membership, et remove_member, et prendront environ 2 000 extrinsics pour remplir le bloc. La plupart des appels sont de l’ordre de grandeur similaire à un transfert de solde qui prend 8 264 appels pour remplir un bloc.

Première proposition

Pour commencer la mise en œuvre de la logique, un bon point de départ pourrait être :

• Utiliser WeightToFeePolynomial avec un polynôme de degré 1 pour mapper 5 cĞD à 1 poids d’extrinsic de base, de sorte que le remplissage d’un bloc avec des extrinsics de base coûtera 1 324 135 ĞD, et le remplissage d’un bloc avec les extrinsics les plus courantes coûtera 1 300 ĞD.
• Utiliser 1 cĞD pour chaque 100 bytes de longueur d’extrinsics.
• FeeMultiplier peut être utilisé pour prendre en compte la variation de la demande sur le réseau. Comme les données de duniter-v1 montrent que nous sommes loin de surcharger le réseau, il peut être initialement réglé à un, mais il peut être ajusté à l’avenir pour tenir compte de la masse monétaire et de la croissance des utilisateurs.

Avec ces valeurs, un simple transfert d’argent coûtera 17 cĞD (0,016 DU), ce qui n’est pas prohibitif pour les transactions légitimes (car il sera remboursé). Cependant, un attaquant malveillant devrait engager (et perdre partiellement) au moins 1 400 ĞD (130 DU) pour remplir un bloc, ce qui représente une somme plus importante que 60% des portefeuilles non vides dans le réseau actuel.

[leduigou]

Duniter V2 : frais de transaction

Bonjour,
Le prélèvement de frais sur les transactions est-il décidé pour la V2 de Duniter ?
Le titre du présent post est : Propositions.

Si oui : peut-on avoir un descriptif rédigé en français courant de la mécanique qui sera instaurée ?
Comment seront distribués les frais, par qui et sous quel mode de gouvernance ?

Je n’ai rien vu dans la documentation rédigée par @HugoTrentesaux
Merci à vous

[HugoTrentesaux]

@leduigou

Je n’ai rien vu dans la documentation rédigée par @HugoTrentesaux

Pour l’instant c’est en anglais ici : https://duniter.org/wiki/g1v2/create-account/. On y lit ceci :

A blockchain is a common good. In order to protect it from ill-intentioned people, some rules are defined collectively to ensure everybody can benefit from it.

The transfer operation has a computational cost. Anonymous accounts pay a fee for that. The order of magnitude of fees are 0.07 Ğ1 per transaction.

To get free of charge transactions, you have to link your account to an identity by joining the web of trust. Read become member for that.

Et dans la page sur les membres est expliqué comment les membres peuvent se faire rembourser les frais de transaction. Il y a également beaucoup d’informations sur ce forum sous le tag fees incluant toutes les réflexions qui ont abouti à ce résultat.

J’en profite pour rappeler que ça fait plus de deux ans qu’on appelle à l’aide pour expliquer ces concepts, traduire, vulgariser, décliner en illustrations, audio, vidéos… L’association Axiom Team constitue un début d’organisation pour faire ce travail, mais ce n’est pas encore suffisant. S’il vous plaît respectez le travail des développeurs et n’attendez pas qu’en plus de :

• structurer le projet
• concevoir les protocoles
• réaliser les implémentations
• publier des release avec des paquets pour tous les OS et toutes les architectures
• publier des documentations technique
• tester les programmes
• héberger l’infrastructure
• designer les applications
• les publier sur les store en payant pour ça
• publier des changelogs

(ce qui est effectivement notre travail et que nous faisons en totale transparence sur GitLab et ce forum), nous faisions en plus :

• des vidéos explicatives
• la traduction en français, espagnol, italien &autres
• la communication sur les réseaux sociaux
• des documents synthétiques à destination du grand public
• de la vulgarisation technique

qui vous tombent dans le bec tout prêts et gratuitement. Tout ça est hors de portée pour l’instant. Personne n’aide à ça bénévolement, ni pour des Ğ1, et les dons en euro sont est largement insuffisants pour financer ce genre de tâches.

[joss.rendall]

@HugoTrentesaux

qui vous tombent dans le bec tout prêts et gratuitement.

Bravo @HugoTrentesaux !!!

[Maaltir]

@Keverineke

Ou pouvons nous trouver plus d’info a ce sujet?

Quel sujet ?

Grâce à substrate, Duniter V2 permettra de développer plus facilement de nombreuses fonctionnalités : connexion avec d’autres monnaies, délégation de pouvoir sur d’autres comptes, paiements automatiques, systèmes de votes, etc.

Il n’y a rien encore de précisément prévu.
N’importe quel développeur pourra créer des fonctionnalités plus facilement qu’il aura envie, À voir ce qui sera adopté par les utilisateurs ou pas.

[leduigou]

@HugoTrentesaux ,

Tu sais bien que MLeT a été monté pour deux raisons :

• que la gouvernance soit partagée avec les utilisateurs, que les développeurs de réseaux qui sont sur le terrain soient reconnus au même titre que les informaticiens.
• que le travail de développement soit financé en euros.

Pour l’instant MLeT est toujours ostracisé, puisqu’il n’a pas accès au forum pour des raisons qui restent nébuleuses sur une décision prise pas quelques développeurs puisque le forum n’est pas géré par Axiom Team. (Je reproduis la réponse que tu m’as faite).

Ta réponse présente me laisse comprendre que tu n’as pas encore intégré la quantité de travail qui était faite sur le terrain par ceux que j’appelle les développeurs de réseaux.

Tout ça rend la collaboration difficile. J’espère qu’un de ces jours, nous pourrons remettre tout cela à plat sur la table et que nous pourrons repartir sur de bonnes bases, c’est à dire en tant qu’humains égaux qui œuvrent dans la même direction, avec des compétences différentes.

J’ai une grande expérience associative et je ne peux que témoigner de ceci :
tout ce que je fais, je le fais comme un don sans en attendre de retour personnel autre que mon seul plaisir de participer à un projet qui m’intéresse.
Ce principe vital m’évite de tomber dans le ressentiment.

Merci quand même pour la réponse à me demande d’information.

Cordialement

[leduigou]

Je viens de lire les documents disponibles (merci google translator).

Pour l’instant je n’ai qu’une question à poser : avez-vous pensé aux conséquences pour les comptables des entreprises ?
Les comptables sont des prescripteurs, c’est à dire que ce sont eux qui indiquent à leur client ce qu’ils doivent faire ou non. En, gros accepter ou non la June.

Par anticipation, et juste avec ce que j’ai lu.
1°) enregistrement de la transaction (en espérant que les frais soient sur une ligne distincte)
2°) enregistrement des frais dans un compte d’attente
3°) Demande de remboursement (je ne connais pas encore la méthode)
4°) Pointage des frais payés et de remboursements effectués.

• soit le comptable est pointilleux et veut vérifier pour chaque transaction sui le rbt a été effectué.
• soit le comptable a une vision globale et verse les rbts dans le compte d’attente. Il enregistre le solde du compte au bilan en fin d’année.

Pour moi, l’impératif est que les frais de transaction soient enregistrés dans une ligne distincte de la transaction.

En espérant que ça peut aider.
Cordialement.

[joss.rendall]

le remboursement des frais ne sera accessible uniquement pour les comptes membres, pas les comptes portefeuilles… donc pas pour les comptes entreprise gérés par les comptables…

[HugoTrentesaux]

@leduigou

avez-vous pensé aux conséquences pour les comptables des entreprises ?

Oui, c’est un point qui m’a occupé la tête, même pour la comptabilité des particuliers (mais pour ça la solution est le remboursement transparent). Je suis d’accord qu’il faudrait faire apparaître les frais de gestion de compte sur une ligne différente pour les comptabilités d’entreprise. Cette donnée est évidemment disponible en blockchain, la question est plutôt de savoir comment on la fera apparaître dans le logiciel de comptabilité de l’entreprise. J’aimerais bien réfléchir à cette question avec @vit dans Tikka.
Je me dis qu’un solution mensualisée pourrait être satisfaisante, par exemple en agrégeant les frais sur un mois. On aurait donc une ligne qui ressemble à ça :

raison	quantité	individel	total
frais de compte février	27	0.07 Ğ1	1.89 Ğ1
frais de compte mars	361	0.07 Ğ1	25.27 Ğ1

Je trouverai ça intéressant parce qu’on pourrait alors comparer avec les frais bancaires des banques euros (frais de terminal de paiement, frais de tenue de compte, frais de moyen de paiement…).

[leduigou]

@HugoTrentesaux

|raison|quantité|individel|total|

|frais de compte février|27|0.07 Ğ1|1.89 Ğ1|
|frais de compte mars|361|0.07 Ğ1|25.27 Ğ1|

Excellent

[kimamila]

Bof, dans un export CSV, je ne vois la difficulté de sortir un colonne avec les frais. Ensuite on peut soit laisser le comptable faire ce qu’il veut : deux lignes d’écriture comptable. Pas un soucis à mon avis.
Ou alors sortir les frais dans une deuxième ligne, mais pas mensuelle car la date doit être celle du mouvement, c’est a dire de la transaction