La plupart des contrats de gouvernance présentent une vulnérabilité prochaine à laquelle nous devrions tous prêter attention – ne vous affolez pas pour l’instant

Laissez-moi commencer par vous dire : « Ne paniquez pas. »

Cette vulnérabilité permet aux utilisateurs d’obtenir plus de votes qu’ils n’auraient dû, mais elle ne se traduira probablement pas encore par une prise de contrôle complète de la gouvernance et ne deviendra vraiment pénible qu’avec les progrès à venir.

Le but de cet article est d’attirer l’attention sur ce qui deviendra un problème avant qu’il ne le soit. Nous pensons que le fait d’en parler publiquement ne causera aucun préjudice et incitera les communautés à améliorer leur gouvernance plus que des rapports privés.

La vulnérabilité aujourd’hui

Une chose sur laquelle nous nous sommes concentrés pendant la chasse était MMEV (multi-block maximum extractable value).

Concept basé sur la MEV, la MMEV se produit lorsque les validateurs savent qu’ils ont un contrôle total sur plusieurs blocs consécutifs et peuvent donc faire des choses qui seraient auparavant extrêmement risquées, comme manipuler le prix d’un jeton dans un bloc et le corriger dans le suivant.

C’est un concept qui est devenu beaucoup plus facile avec PoS, et nous avons pensé qu’il y avait un potentiel de bogues généralisés qui l’impliquaient.

Bien que les TWAP soient la plus grande faiblesse que nous ayons trouvée jusqu’à présent à cause de MMEV, il y en a d’autres. La faiblesse la plus répandue est celle qui fait l’objet de cet article sur MMEV dans les modèles de gouverneurs composés.

• De nombreux contrats de gouvernance reposent sur le comptage des votes d’un utilisateur à un bloc spécifique.
• Cette vérification est toujours effectuée sur un bloc avant que le vote ne soit effectué afin d’éviter les attaques de type « flash loan » et le vote avec les mêmes tokens sur plusieurs adresses.
• En outre, les contrats de gouvernance prévoient un « délai » pour le début du vote après la soumission d’une proposition.
• Lorsqu’un vote commence, le montant avec lequel un utilisateur peut voter est son solde sur le bloc de départ, qui doit être au moins un bloc dans le passé au moment du vote.

Le problème du retard d’un bloc

Nous commencerons par le délai d’un bloc qui est généralement utilisé aujourd’hui.

Le délai d’un bloc constitue une menace immédiate pour les protocoles. Il permet à un utilisateur qui peut tirer parti de MMEV de faire ce qui suit.

• Acheter tous les jetons liquides sur les DEX
• Enregistrer leur vote
• Vendre les jetons sur le bloc suivant

Le seul coût dépensé par un utilisateur pour voter avec tous les jetons sur les DEX serait les frais d’échange. Les étapes détaillées sont les suivantes.

• Le validateur voit qu’il a deux blocs à la suite.
• Ils ouvrent une proposition doivent avoir assez de tokens pour le faire sur le bloc avant le premier bloc ‘possédé’. Le bloc de départ est fixé à block.number+1 parce que le contrat du gouverneur a un votingDelay d’un bloc.
• Ils achètent tous les jetons possibles sur les DEX, même en cas de dérapage important sur le bloc de départ.
• Au startBlock+1, ils revendent les jetons achetés aux DEX, ne payant au final que des frais d’échange. Grâce au MMEV, ils ne risquent pas de perdre quoi que ce soit à cause des arb bots.
• Ils votent sur la proposition avec tous les jetons qui étaient en vente sur les DEX à tout moment pendant la proposition, éventuellement à la dernière seconde.

Sans MMEV, cette méthode est incroyablement risquée car un robot d’arbitrage vous empêchera presque à coup sûr de revendre les jetons utilisés pour voter à un prix raisonnable.

Avec le MMEV, il n’y a aucun risque, et le seul coût dépensé est le même que si vous pouviez voter avec des flash loans.

Il faut de l’argent pour gagner de l’argent

Aujourd’hui, les mises en garde sont les suivantes : vous devez disposer des éléments suivants.

• Des validateurs adéquats pour exécuter cette attaque
• Le capital nécessaire à l’achat initial de jetons

Une quantité de validateurs à exécuter en temps voulu coûterait plus de 20 millions de dollars.

Cela peut sembler beaucoup d’argent, mais les acteurs malveillants ont continué à gagner de plus en plus de capital pour exécuter des attaques de ce type.

Sans oublier que quelqu’un qui profite de MMEV n’essaie peut-être pas de faire passer une proposition malveillante, mais plutôt un utilisateur moyen qui veut amplifier son vote sur une certaine proposition.

Il a exactement les mêmes effets que les prêts flash sur le vote dans le passé.

Aujourd’hui, une personne qui tenterait de tirer profit de la MMEV le ferait dans les buts suivants.

• Manipuler les TWAP pour arrêter les flux de prix de Compound pendant un certain temps.
• Lancer une proposition sur Maker pour laquelle ils veulent beaucoup de votes supplémentaires
• Essayer de manipuler les DEX pour les agrégateurs hors chaîne et enfin, le retour de Chainlink
  mauvaises données

ils peuvent faire tout cela en un seul bloc plutôt que d’avoir à attendre quelques mois pour avoir la chance de le faire.

La vulnérabilité demain

L’exigence de validateur mentionnée précédemment pourrait disparaître dans le futur.

Il y a quelques années, de nombreux protocoles n’acceptaient pas les primes concernant le MEV à bloc unique car il était peu probable qu’un mineur sacrifie sa réputation pour en profiter.

L’apparition de protocoles tels que les Flashbots a changé la donne. La même chose pourrait se produire ici.

Si les protocoles MEV comme Flashbots commencent à intégrer le MEV multi-blocs, le coût des validateurs est soudain éliminé et la probabilité de pouvoir contrôler deux blocs à la suite sur un bloc spécifique monte en flèche.

Cette avancée rend la gouvernance avec un délai de vote important plus vulnérable, car l’utilisateur n’a plus qu’à détenir les jetons de vote sur une période d’un bloc.

Vous pouvez simplement attendre de voir si le bloc de départ d’une proposition et celui qui le précède peuvent faire l’objet d’une MMEV.

Toute personne saine d’esprit qui est prête à payer un peu pour qu’une proposition soit adoptée et qui ne veut pas que l’autre partie le fasse peut tirer parti de la VME pour obtenir tous les votes DEX de son côté.

Sévérité

La gravité de ce problème ne vient pas des dommages eux-mêmes mais de la criticité des contrats qu’ils endommagent.

• Quelqu’un pourra-t-il prendre le contrôle de la gouvernance en exploitant MMEV ? Probablement pas. Les gens peuvent toujours voter contre, et il y a souvent des mesures supplémentaires pour empêcher les propositions malveillantes d’être adoptées.
• Quelqu’un pourra-t-il tirer parti du code pour obtenir un énorme avantage électoral à bon marché ? Absolument.
• Cet avantage sera-t-il le point de basculement dans une affaire cruciale ? Peut-être.
• Une telle action érodera-t-elle la confiance dans la gouvernance du protocole concerné ? Probablement.

Une précaution possible

Une précaution pour l’instant serait d’avoir une sorte de verrouillage sur votre jeton de gouvernance/vote.

Les GvTokens et les veTokens ne sont généralement pas vulnérables à ce problème.

Certains protocoles comme Maker, par exemple, ne seraient pas non plus vulnérables s’ils augmentaient le temps nécessaire pour qu’un utilisateur ait des jetons verrouillés à plus de 32 blocs.

Un délai plus long pour le démarrage du vote est utile pour le moment, mais ne le sera plus si, à l’avenir, la plupart des blocs peuvent faire l’objet d’une MMEV.

Chaque protocole a ses propres exigences et doit résoudre ce problème de la manière qu’il juge la meilleure.

Conclusion

Le but de cet article n’est pas de dire que le ciel nous tombe sur la tête. Le but de cet article est de s’assurer que notre écosystème est aussi sûr qu’il peut l’être.

Avec les prêts éclair et le MEV, les équipes ont ignoré les progrès à venir, ce qui a potentiellement rendu leurs contrats relativement sûrs soudainement facilement exploitables.

Le MEV multi-blocs est quelque chose sur lequel il faut se concentrer maintenant pour qu’il ne soit plus jamais un problème à l’avenir.

---