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