Le proof_size est abandonné au profit d’un contrôle sur la taille de l’extrinsic. Le seul extrinsic problématique pour ce cas de figure est le remark, que je pense devrait être limité en taille dans le cas des frais nuls.
1 Like
J’ai essayé ce genre d’attaque, qui est en fait assez difficile en pratique. En l’état, on est de l’ordre de 900 transactions par bloc pour atteindre 25 %. Il faudrait donc au minimum 500 comptes (500 ED) avant de pouvoir commencer l’attaque, qui ne pourra être effectuée qu’un bloc sur deux sous peine de payer des frais.
À noter que cela n’impactera pas les membres, qui seront toujours remboursés de leurs frais grâce aux quotas.
Pour le cas du Remark, on pourrait très bien ajouter une condition stipulant que si un extrinsic est vraiment gros, il occasionnera des frais de longueur quel que soit le remplissage du bloc.
4 Likes
Quels seraient les impacts d’une telle attaque ?
Ralentissement emcombrement ?
Le ralentissement est limité dans le temps, l’encombrement c’est pour toujours…
Je n’ai aucune idée de à quel point c’est gênant…
Pendant l’attaque : les utilisateurs paient les frais de transaction (remboursés pour les membres) une fois la limite atteinte. Après l’attaque : dans le bloc suivant l’attaque, tout le monde paie les frais (remboursés pour les membres). Si l’attaque continue, les frais sont encore augmentés pour le bloc suivant ; si l’attaque cesse, les frais repassent progressivement (suivant la durée de l’attaque) à zéro. Comme la limite pour le paiement des frais est fixée à 25% du bloc pour l’instant, il n’y a aucun impact sur le ralentissement ni encombrement (excepté si l’attaquant est capable de payer les frais pour remplir les 75% restants du bloc, ce qui est théoriquement impossible si les valeurs de conversion poids→frais sont bien choisies).
3 Likes
Dans la MR !278 pour régler la question des commentaires de transaction, @bgallois introduit un nouveau critère pour que les frais soient gratuits : la taille de l’extrinsic.
@tuxmain je t’ai mis en reviewer pour cette MR assez rapide à lire et qui introduit un nouveau comportement.
Si je comprends bien, en fonctionnement normal, il n’y aura aucun frais de prélevés.
C’est seulement en cas de saturation du réseau de la blockchain que des frais seront prélevés. Et remboursé aux membres (identités ?) et compte lié à ces identités.
J’ai cru comprendre que les frais ne pourrais pas être remboursé en cas de fermeture de compte.
Est-ce que j’ai bon ?
1 Like
Merci, tu fais bien de tout poser au clair parce que ça a bougé dans tous les sens, et en plus, on n’a fait le runtime upgrade que récemment sur la gdev donc la pratique de la gdev a évolué. J’en profite pour faire un test pour illustrer :
Sur ce compte non membre et non lié à une identité, j’ai ajouté 1+9 ĞD puis fait une transaction sortante de 1 ĞD, et le solde du compte est bien de 9 ǦD, aucun frais n’a été payé.
Je n’ai pas envie de spammer la monnaie tout de suite, mais on a des tests d’intégration qui couvrent ces cas : runtime/gdev/tests/fee_tests.rs · master · nodes / rust / Duniter v2S · GitLab. En cas de fort remplissage, des frais seraient prélevés sur la transaction.
Pour un compte lié à une identité (pas nécessairement la clé qui gère l’identité, mais une simple déclaration en blockchain), ces frais seraient remboursés dans la logique des quotas. Normalement on ne devrait pas en arriver là, mais si on souffre de problème de spam, les utilisateurs auront une manière d’échapper aux frais en liant leurs comptes à leur identité.
Effectivement, un des seuls cas où le remboursement ne peut pas se faire est quand le compte est détruit : si je vire les ĞD qui restent sur un compte lié à mon identité alors qu’il y a 20 cĞD de frais, le remboursement de ces frais ne permet pas de passer le seuil du dépôt existentiel et donc le remboursement échoue et retourne au pot commun. Donc vider un compte en période de frais coûte les frais de l’opération.
Effectivement, pour l’instant, les quotas sont dispo dès que l’identité existe, quel que soit son statut. C’était pour éviter de faire payer des frais pour valider son identité, mais vu que maintenant ça ne s’applique plus qu’en période de spam, on pourrait réserver ça aux identités membres, c’est le but de #247.
Voilà, j’espère que c’est clair et que ça ne bougera plus. Il nous aura fallu longtemps pour arriver à cette solution, mais ça nous distinguera beaucoup des autres blockchains !
1 Like
Donc uniquement en cas de saturation du réseau, des frais seront prélevés.
Et remboursés aux comptes membres et compte lié aux membres, pas à ceux en attente de passer membres ?
J’ai encore une question sur les frais.
Les frais de création de compte ont-ils disparus ?
Si oui, comment on évite la création de millions de comptes à 1 ğ1 ? Est-ce gênant ?
Sinon comment ça marche.
En fait “compte membre” au sens “clé qui gère une identité membre” n’est pas pris en compte par les quotas. La seule information regardée est celle du compte lié. Or on lie par défaut un compte à l’identité membre qu’il contrôle. On peut délier son compte membre de son identité membre, même si c’est tordu.
Pour l’instant, si, quand #247 sera réglée, ce ne sera plus le cas.
Oui. C’était plutôt une “taxe” qu’un frais, et son comportement était étrange. On l’a retiré après pas mal de discussions. Donc oui, si tu as un million de ğ1, tu peux les mettre sur un million de comptes différents. C’est un peu chiant parce que comme tout spam, ça coûte des ressources blockchain, mais ce n’est pas plus gênant que ça. La contre-mesure principale serait d’augmenter le dépôt existentiel.
Les oneshot accounts sont plus adaptés à cet usage, donc si quelqu’un souhaite imprimer un million de billets de 1 Ğ1, on lui recommandera ça plutôt.
1 Like