Aller au contenu
Financial Context Wiki

Attaques de stake grinding : biaiser l'aléa de la preuve d'enjeu

Une attaque de stake grinding cherche, parmi des clés, blocs ou contributions aléatoires autorisés, un résultat améliorant la sélection future des validateurs. Découvrez les chemins d'attaque, l'avantage de recherche et les défenses propres au protocole.

Mis à jour

Analyse pédagogique de la sécurité des protocoles uniquement. L’aléa, la sélection des leaders, les pénalités et les coûts d’attaque dépendent du protocole et de sa version ; vérifiez la spécification et l’implémentation actives avant toute conclusion sur la sécurité ou le staking.

Réponse directe

Une attaque de stake grinding exploite les choix qu’un participant à la preuve d’enjeu peut faire avant que l’aléa du protocole soit fixé. Il évalue plusieurs clés, blocs candidats ou contributions aléatoires valides, puis conserve ou révèle l’option qui favorise une future sélection de proposant, de comité ou de branche. Cette recherche transforme un tirage en plusieurs tirages candidats et peut lui donner une influence supérieure à sa part nominale d’enjeu.

Le grinding désigne une famille d’attaques, pas une procédure universelle. Dans le broyage de bloc ou de graine, un producteur modifie le contenu ou l’ascendance autorisés d’un bloc dont le hachage alimente l’aléa futur. Dans le broyage de clés, il crée de nombreuses clés avant inscription et ne garde que les identités dont l’éligibilité est favorable. Dans la révélation sélective, il retient ou publie un engagement, une révélation, une signature ou un bloc après avoir appris l’effet de chaque choix permis sur la graine.

Un hachage, une fonction aléatoire vérifiable (VRF) ou un schéma d’engagement-révélation ne rend pas à lui seul tout le processus impartial. La sécurité dépend de l’auteur de chaque entrée, du moment où l’éligibilité devient connue, du nombre d’alternatives testables, du choix supplémentaire créé par un abandon et de la durée séparant la graine des leaders qu’elle sélectionne. L’analyse doit porter sur la version exacte du protocole, et non déduire sa sûreté du nom d’une primitive.

Parcours d’attaque et d’analyse

  1. Fixer la règle de sélection. Consignez réseau, version, époque ou ronde, instantané de l’enjeu actif, dérivation de la graine, test d’éligibilité, choix de branche et règles de récompense et de pénalité.
  2. Cartographier tous les choix adverses. Incluez clés créées avant inscription, ordres de transactions valides, champs facultatifs, parents candidats, publication de blocs, révélations aléatoires et abandons. Un champ ne compte que si sa modification influence un état ou une graine futurs acceptés.
  3. Mesurer le budget de recherche. Estimez le nombre de candidats évaluables avant l’échéance, l’indépendance des essais et leur coût en calcul, récompenses manquées, dépôts, délais ou actes passibles de slashing.
  4. Relier la graine au pouvoir futur. Déterminez à quel horizon elle sélectionne proposants ou comités, si l’attaquant voit le résultat avant de s’engager et si une sélection favorable ouvre une nouvelle occasion de grinding.
  5. Évaluer acceptation et accumulation. Un candidat doit respecter les règles de transition d’état, de temps, de signature et de choix de branche. Modélisez l’influence répétée comme un processus à état ; n’extrapolez pas une probabilité sur un tour en supposant les tours indépendants.
  6. Tester chaque défense contre chaque choix. Graines différées, VRF, inscription des clés, pénalités, balises à seuil et fonctions de délai vérifiables couvrent des capacités différentes et ajoutent leurs propres hypothèses de disponibilité et d’implémentation.

Le dossier de preuve doit conserver blocs candidats ou engagements, hachages et domaines exacts, données temporelles, instantanés d’enjeu, calcul de graine implémenté et sélections contrefactuelles. Une série de propositions ne suffit pas : une loterie honnête pondérée par l’enjeu produit naturellement des regroupements.

Exemple détaillé

Supposons qu’un protocole simplifié donne à l’attaquant 10% de probabilité d’être le prochain proposant. Avec une seule graine fixe, sa probabilité est 0.10. Une faille lui permet désormais d’évaluer presque gratuitement 20 graines candidates indépendantes et toutes valides, puis d’en publier une.

La probabilité qu’au moins une candidate sélectionne l’attaquant vaut 1 - (1 - 0.10)^20, soit environ 87.8%. Cela ne signifie pas qu’il possède 87.8% de l’enjeu : le protocole lui a accidentellement accordé 20 tirages et le droit de choisir après observation.

Ce calcul illustre un mécanisme, il ne prédit pas une chaîne déployée. Les résultats peuvent être corrélés, les délais limiter les essais, certaines variantes coûter frais ou récompenses, la rétention être pénalisée et la prochaine proposition favorable ne pas créer d’influence durable sur le choix de branche. Il faut mesurer ces contraintes avant d’attribuer un impact économique ou de consensus.

Défenses et liste de contrôle

Construction de l’aléa

  • Dérivez l’aléa de sélection d’entrées engagées avant que les participants concernés puissent connaître ou contrôler les affectations obtenues.
  • Séparez suffisamment contribution, engagement, révélation et utilisation pour que le leader actuel ne puisse rechercher à faible coût la graine de son successeur immédiat.
  • Traitez le dernier révélateur : l’engagement-révélation reste biaisable si retenir sa révélation lui permet de choisir entre des résultats.
  • N’utilisez des balises à seuil ou distribuées qu’avec des hypothèses explicites de participation honnête, vivacité, récupération et changement de membres.

Éligibilité et identité

  • Liez clés VRF et enjeu à un instantané d’inscription antérieur à la graine pertinente ; sinon, la génération hors ligne devient broyage de clés.
  • Séparez les domaines aléatoires par chaîne, version, ronde, rôle et usage afin qu’une preuve ne soit pas réutilisable dans un autre contexte.
  • Préférez l’éligibilité privée si utile, tout en sachant qu’elle réduit le ciblage anticipé mais ne corrige pas une graine biaisée.
  • Limitez la rotation peu coûteuse des identités et définissez l’entrée dans la loterie de l’enjeu délégué, des pools et des ensembles changeants.

Économie et exploitation

  • Chiffrez blocs manqués, récompenses perdues, capital immobilisé, équivoque détectable et pénalités corrélées ; tout choix légal n’est pas passible de slashing.
  • Surveillez contributions aux graines, échecs de révélation, production candidate inhabituelle, fréquence des proposants et diversité logicielle sur une fenêtre significative.
  • Isolez l’aléa critique du consensus des interfaces discrétionnaires de builder, relay ou ordonnancement, sauf preuve de leur innocuité dans la spécification.
  • Testez les replis. Un mécanisme impartial seulement si tous répondent peut échanger la résistance au biais contre une panne de vivacité.

Idées reçues

  • Les sorties de hachage sont aléatoires, donc le grinding est impossible. Un hachage imprévisible pour une entrée fixe peut être biaisé par qui choisit parmi de nombreuses entrées.
  • Une VRF élimine toutes les attaques de grinding. Elle prouve une sortie pour une clé et une entrée ; génération des clés, contrôle de la graine, calendrier d’inscription et publication sélective restent distincts.
  • L’engagement-révélation est automatiquement impartial. Le dernier participant peut choisir entre révéler et abandonner si le protocole ne neutralise ni ne tarifie cette option.
  • Le grinding exige la majorité de l’enjeu. Une minorité obtenant plusieurs essais bon marché peut accroître sa probabilité ; transformer cet avantage en défaillance de sûreté exige d’autres conditions propres au protocole.
  • Des propositions consécutives prouvent une manipulation. La sélection aléatoire crée des séries. La détection demande un modèle statistique prédéfini et des preuves du protocole et de l’implémentation.
  • Grinding et nothing at stake sont identiques. Le premier biaise aléa ou éligibilité ; le second concerne l’incitation à soutenir des historiques concurrents. Ils peuvent interagir, mais restent distincts.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...