Les frais, ça devient concret

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

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

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

1 Like

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.

6 Likes