Remboursement des frais de transaction en cas de bloc non-plein

Idée à creuser pour réduire l’impact des frais de transaction la plupart du temps (voire quasiment tout le temps) : remboursement en cas de bloc rempli en-dessous d’un certain seuil (par exemple 50%), pour tous les comptes, sans user les quotas.

En cas de dépassement du seuil de remplissage du bloc, les règles actuelles s’appliquent (frais et remboursement des membres par quota).

Il faut tout de même faire attention à ce qu’on ne puisse spammer en augmentant le temps de calcul du code chargé du remboursement. C’est pourquoi le seuil doit être strictement inférieur à 100%, voire significativement plus petit.

  • souhaitable ?
  • effets secondaires inattendus ?
  • facile à implémenter ?

Inconvénients potentiels :

  • peut augmenter la charge des indexeurs et le remplissage de l’archivage car le spam est moins cher.
  • frais impossibles à prédire à coup sûr par les clients
  • surcoût sur toutes les transactions (comparable à celui induit par les quotas)
5 Likes

Ça a le très grand mérite d’être simple comme solution. Si ça fait le travail c’est probablement la meilleure solution à ce stade.

On pourrait définir un quota global dans la pallet Quota réinitialisé à chaque bloc. Ce serait un quota disponible pour tous et associé à aucune identité. Pour chaque transaction anonyme (compte non lié à une identité), un remboursement serait planifié en prélevant sur ce quota global. Quand le quota global est excédé ou la queue de remboursements anonymes est dépassée, les remboursements pour comptes anonymes ne sont plus déclenchés. L’intérêt de ce fonctionnement est qu’on bénéficie des traitements “on_idle” de la pallet quota et qu’on peut prioriser les remboursements de membres par rapport aux remboursements anonymes.

Oui, je le souhaite :slight_smile:

“Inattendus” on n’y a par définition pas pensé, mais le traitement “on_idle” peut apaiser les craintes. Par contre, ça double le nombre d’événements “withdraw” et “deposit” associés aux frais. Il faudrait en estimer le coût.

Avec ma proposition, oui, c’est assez peu de lignes puisqu’il suffit de réutiliser le mécanisme des quotas et de l’appliquer également aux comptes non liés avec une deuxième queue de remboursements moins prioritaire.

Oui, le spam est remboursé :slight_smile:. Un système de sécurité sociale à l’épreuve des placebo chers ^^

Ah oui, ça je n’y avais pas pensé. Mais on peut avoir une heuristique basée sur le bloc précédent qui regarde :

  • si le quota global a été consommé en grande partie
  • si la queue de remboursements globale a été presque remplie

et prévient l’utilisateur anonyme que les frais de transaction pourraient ne pas lui être remboursés.

Oui. C’est le ×2 qu’il faut apparemment accepter avec l’implémentation actuelle. Mais on pourrait aussi toucher directement à la pallet transaction_payment. J’ai hésité à le faire par peur de casses les protections qu’elle offre contre le spam, et c’est pour ça que je me suis tourné vers le système de remboursements, cf historique sur Implémentation des quotas.

1 Like

Je voyais plutôt un remboursement soit pour tout le monde, soit pour personne.

Si un spammeur a la chance d’avoir les premiers extrinsics (tiens, comment est déterminé l’ordre d’exécution des extrinsics ?) il profite du quota, et laisse les utilisateurs légitimes payer les frais.

Avec un remboursement égalitaire, tout le monde paierait les frais y compris le spammeur, dès qu’on dépasse le seuil.

On peut aussi faire un remboursement progressif pour réduire les effets de seuil : par exemple une courbe allant de 100% de remboursement à 25% de remplissage du bloc, jusqu’à 0% de remboursement à 75% de remplissage du bloc. Ainsi les prédictions des clients seront moins souvent justes mais moins souvent très éloignées de la réalité. Mais ok c’est pas prioritaire.

3 Likes

Si j’avais pu j’aurais mis plusieurs étoiles à cette idée. C’est vraiment top ! Il y a du CPU de dispo ? Allez la blockchain est gratuite d’utilisation !

Certes mais c’est binaire : soit les frais calculés sont les bons, soient les frais sont finalement de zéro. C’est plutôt acceptable comme “erreur du client”.

Autre proposition : les transactions sans frais

L’idée peut paraître absurde parce qu’en cas d’attaque (spam) il est impossible de ponctionner l’attaquant. Mais je rappelle que tout nœud Duniter (v2) dispose d’une transaction pool dans laquelle celui-ci “pioche” les transactions pour les mettre dans un bloc, et qu’à cette étape le nœud fait déjà quelques contrôles.

Nous pourrions ainsi, je suppose, ajouter des transactions sans frais que le nœud choisirait à loisir d’inclure ou non dans le bloc, et qu’en cas d’échec de transaction le montant des frais soit prélevé sur le compte du forgeron (c’est déjà le cas me semble-t-il pour les inhérents).

L’avantage : les utilisateurs peuvent explicitement choisir de ne pas payer pour l’utilisation de la blockchain, et qu’en cas de congestion leur transaction passe après les autres à l’instar de ce qui se fait sur Bitcoin.

Inconvénient : possible surcoût caché d’utilisation CPU pour piocher dans la transaction pool. Mais ce pourrait être une option à activer pour chaque nœud forgeron.

3 Likes

On peut faire ça aussi : si le quota disponible atteint zéro, on vide la liste de remboursement et saute cette étape.

Le forgeron peut écrire un algorithme de priorisation, je crois que par défaut ça trie en fonction des tips (= pourboire). @flodef m’avait expliqué que chez Solana, les frais étant très bas et l’utilisation (légitime) très grande, il était fréquent que les clients déterminent le tip de manière algorithmique en fonction de la latence d’exécution qu’ils visaient.

Pourquoi pas, ça me semble lourd en R&D, mais ce serait propre.

Est-ce que ça vous va si pour l’instant on part sur l’option “quota global” avec remboursement pour tous si non atteint et pour personne si atteint ?

Ça permettrait à @bgallois de s’en charger sans partir dans des directions trop incertaines. Et ça me semble assez intéressant à implémenter dans le cadre de l’objectif “migration sans fork”.

4 Likes

On pourrait aussi se servir du FeeMultiplier (Transaction Fees · Polkadot Wiki) pour avoir des frais nuls (à tester) ou quasi nuls pour des blocs peu saturés et qui augmentent proportionnellement à la saturation pour éviter le spam.
Cela permettrait de réduire les frais pour tout le monde en temps normal et de se servir des quotas, comme implémenté actuellement, en cas de saturation.

4 Likes

Oui :+1:

3 Likes