L'État Déplorable de l'Audit Web3, et ce qui Peut Être Fait

Balancer, un protocole ancien et bien audité, a récemment été « piraté ». Yearn Finance, également bien audité, l'a été aussi. Il y a des années, Euler Finance a été « piraté » via une fonction introduite en réponse à un audit antérieur. USPD a été audité avant le déploiement, puis le processus de déploiement non audité lui-même a été piraté, entraînant une perte totale environ 3 mois après le lancement. Personne qui prête attention ne croit que les audits garantissent la sécurité de quelque chose. Beaucoup se demandent s'ils valent quoi que ce soit.

Ce n'est pas nouveau. Ce n'est pas un problème Web3. Et vraiment, ce n'est pas une observation particulièrement profonde. Mais les audits sont toujours très présents. Les projets paient pour des audits. Les projets vantent les audits. Les gens prétendent lire les audits. Souvent, lorsqu'un produit audité est exploité, les gens demandent pourquoi et comment cela s'est produit.

Plutôt que de répondre directement à tout cela, nous allons examiner quelques audits récents pour des produits récemment lancés. L'objectif ici n'est pas de se moquer ou de critiquer qui que ce soit. Ils sont sélectionnés au hasard, principalement en raison de l'accent mis sur les choses récentes. Cela ne signifie pas qu'ils sont particulièrement mauvais. Ils ne sont même pas si mauvais !

Notre point ici n'est pas que les auditeurs font quelque chose de mal. Les auditeurs font ce que les projets qui les engagent demandent. La portée de l'audit est définie par le projet. Pour ne citer qu'un exemple extrême : si Do Kwon avait engagé des auditeurs pour son schéma de stablecoin, ils auraient noté qu'il était potentiellement instable. Le problème aurait été marqué « reconnu » et rien n'aurait été fait ou modifié.

Ce problème n'a absolument rien à voir avec des études comme celles qui prétendaient que l'écosystème Terra-LUNA de Do était très robuste. Il est difficile de prédire l'avenir et ces sortes d'études sont à juste titre considérées comme du marketing intéressé qui, à la limite, reconnaît les problèmes fondamentaux. La recherche sponsorisée par le projet est censée présenter les choses sous un jour positif. L'objectif même des audits est de fournir une perspective objective de partie tierce. Le battage publicitaire ne doit pas être cru et les audits ne sont ni des garanties ni des assurances. C'est la vie.

L'objectif de cette enquête est de marteler que le vrai problème ici n'est pas les erreurs de programmation de base du type que les auditeurs sont bien placés pour identifier et que le processus d'audit est bien conçu pour résoudre. Les auditeurs sont assez bons pour détecter ceux-là. Les programmeurs qui construisent ces choses en premier lieu le sont aussi, d'ailleurs. Empiriquement, ce type de retour parvient aux bonnes personnes et les problèmes étroits sont corrigés.

Non, le vrai problème est les produits qui fonctionnent exactement comme prévu et où un « risque » connu se matérialise pour tout faire tomber. Ce que vous allez voir maintenant, ce sont des auditeurs essayant de se protéger contre tous les problèmes connus-inconnus futurs. En tant qu'exercice de protection contre la responsabilité et la moquerie, c'est peut-être une chose précieuse. Mais, en général, cela n'aide personne.

Et puis à la fin, nous allons discuter de ce qu'une gamme de parties peut faire qui aiderait et servirait leurs propres intérêts étroits. Si votre prescription sur la façon d'améliorer les audits implique l'altruisme alors, eh bien, ce n'est pas très utile.

Jovay

Jovay est une L2 associée à Ant Financial ou Alibaba ou quelque chose dans ce domaine général. Mais ce que fait Jovay n'a pas vraiment d'importance. C'est une chose construite en logiciel par une organisation grande et bien financée. Cet audit liste huit problèmes :

1. Une erreur de programmation légitime qui a ensuite été corrigée.
2. Que le protocole n'est pas sans confiance. C'est un problème en quelque sorte, mais c'est aussi une partie essentielle de la conception.
3. L'attaque de « faux rechargement » qui s'applique à une large partie de l'écosystème et n'est pas spécifique au projet.
4. Les serveurs RPC utilisent HTTP plutôt que HTTPS. Ces interfaces ne traitent pas d'informations secrètes. Cela s'applique à des milliards de sites web en lecture seule parfaitement sûrs.
5. L'informatique quantique pose un risque pour Ethereum. OK. Très pertinent celui-là.
6. Les Smart Contract (Contrat Intelligent) EVM peuvent être vulnérables. Non sérieusement. Il est dit « Les Smart Contract (Contrat Intelligent) EVM sont sensibles à divers vecteurs d'attaque en raison du déploiement de code immuable et des interactions complexes, pouvant potentiellement conduire au vol de fonds,.. » Ok. Encore une fois, en respectant vraiment la portée étroite de cet audit.
7. La conception du séquenceur est sujette au MEV. Comme tout le reste de l'écosystème Ethereum. Il fait aussi trop sombre la nuit.
8. La qualité du code pourrait être améliorée. Contrairement à la plupart des autres codes écrits depuis l'aube de l'informatique.

Un seul de ceux-ci est un vrai problème. Oui, il vaut la peine de noter que le produit lui-même n'est pas sans confiance si la documentation indique autrement qu'il est sans confiance. Mais ce produit est à peu près correct sur ce front. Noter que l'informatique quantique pose potentiellement un risque futur et que les Smart Contract (Contrat Intelligent) peuvent être risqués... ce sont soit des tentatives de rendre le rapport plus long en trouvant des problèmes inventés, soit des tentatives de fournir une sorte de « ce n'est pas notre faute » si quelque chose est finalement piraté. Probablement un mélange des deux.

Dans l'esprit de ces points, nous proposons comme neuvième problème que le réseau tombera en panne lorsque le soleil mourra à moins que nous ne devenions une espèce interstellaire et que nous trouvions d'une manière ou d'une autre une communication plus rapide que la lumière. Sinon, la relativité limite la durée de vie utile de ce système à environ 5 milliards d'années. Honnêtement, c'est plus utile que de dire que la qualité du code pourrait être améliorée car même après la mort du Soleil, il y aura encore du mauvais code qui s'exécutera quelque part. Mais nous plaisantons.

Hyperliquid

Hyperliquid a publié quelques Rapport de l'audit du smart contract . Le premier Rapport de l'audit du smart contract a trouvé six problèmes et le deuxième rapport a confirmé que ceux-ci étaient résolus. Mais la portée de l'audit excluait :

1. Autres Smart Contract (Contrat Intelligent) faisant partie du système Hyperliquid
2. Composants off-chain, tels que les validateurs
3. Composants front-end
4. Infrastructure liée au projet
5. Garde de clés

Ceux-ci semblent être des zones à problèmes potentiels ! Tout ce qui a été audité était un seul contrat de pont. Mais le système est, eh bien, beaucoup plus compliqué que cela.

Auditer un petit coin du système qui ne fait que quelques choses étroitement définies est assez inutile. La façon dont Hyperliquid est conçu, le contrat audité est le point d'entrée et de sortie externe pour tout le monde. Il serait donc un problème grave si ce contrat était truffé d'erreurs. Mais confirmer que le contrat fonctionne procure peu ou pas de confort.

Ondo

Cet audit met en évidence « RISQUE DE CENTRALISATION POUR LES ENTITÉS ET RÔLES DE CONFIANCE » que l'équipe a reconnu. C'est en majuscules comme ça dans le rapport. D'accord.

Cet audit note que le système pourrait s'effondrer si un stablecoin impliqué se désamarre trop fort. Ils formulent cela comme le système « permettra un minting excessif de jetons OUSG pendant l'événement de dépeg USDC ». Au final, la « solution » qu'ils ont mise en place était une référence à un oracle Chainlink et un interrupteur d'arrêt au cas où le prix serait signalé comme trop bas. Donc plutôt que d'imploser avec la valeur qui s'effondre, le protocole s'arrêtera avec la valeur qui s'effondre. D'accord. Ce n'est pas un problème résolvable en ce sens qu'il n'y a aucun mécanisme pour éviter un résultat de perte de valeur si USDC explose. Et, conformément à ce fait, la solution ne résout vraiment rien.

Ces audits sont relativement récents. Mais pour donner un contexte, cet audit d'octobre 2022 identifie beaucoup de vrais problèmes. Près de 200 d'entre eux. La plupart ont été corrigés, certains étaient similaires à ce qui précède et simplement reconnus. Le point est que l'audit avait l'habitude de faire quelque chose de concret et de substantiel : rechercher des erreurs de programmation qui ne pouvaient pas avoir été l'intention du programmeur. Les programmeurs avaient l'habitude de corriger ces erreurs parce qu'elles étaient, vous savez, de véritables erreurs et non simplement des décisions de conception discutables intégrées au produit.

Et puis en 2024, nous voyons des audits qui trouvent relativement peu de problèmes techniques et déclarent hors de portée les attaques liées aux finances. La seule façon sensée d'interpréter ce changement au fil du temps est que les programmeurs, et les programmeurs en tant qu'auditeurs, ont reconnu que le code fonctionnel n'était pas le seul risque. Bien sûr, les bogues de programmation étaient exploités de temps en temps. Mais à la mi-2024, tout le monde pouvait voir que les mécanismes économiques défectueux étaient également un risque massif. C'était le plus grand risque.

Les projets qui fonctionnaient exactement comme prévu – pas comme rêvé, comme prévu en réalité – explosent de temps en temps parce que les rêves de stabilité des concepteurs se brisent face au monde réel.

Vous pouvez voir cette évolution dans les audits de ce projet.

Mutuum Finance

Maintenant nous avons la reductio ad absurdum des audits. Celui-ci identifie un seul problème :

Le problème est le manque de transparence autour de la distribution initiale des jetons et comment cela pourrait être lié aux problèmes de centralisation. Il a été « atténué » parce que :

Ensuite, il y a beaucoup de détails multisig. Et enfin la réponse de l'auditeur :

Donc le risque avec le projet est qu'une petite équipe contrôle tout et la manière dont ce contrôle sera, ou peut-être ne sera pas, dispersé est complètement non transparente. Et la solution proposée par l'équipe d'écrire un article de blog pour clarifier leur intention ne résout pas cela, au sens strict.

Pour mémoire, l'équipe a publié une liste détaillée de ce que les jetons iront où et quand. Et ils reconnaissent que c'est incomplet avec des commentaires comme « Nous envisageons soit un modèle de distribution bloc par bloc, soit hebdomadaire ». Ils reconnaissent également que tout sera géré à partir de multisigs manuels. Donc ils sont honnêtes. C'est juste que l'honnêteté revient à « ouais nous pouvons encore faire ce que nous voulons et vous devez nous faire confiance ».

Quel est le but de cet audit ? Si le code n'avait pas de bogues identifiables, l'auditeur pourrait simplement écrire cela. Parfois, une visite chez le médecin ou le mécanicien produit un certificat de bonne santé. Nous nous demandons donc si seulement une quantité triviale de code a été auditée ? Ou peut-être que le projet lui-même n'est qu'une quantité triviale de code ? L'auditeur a-t-il ressenti le besoin de mettre quelque chose dans le rapport parce que tout était trop vide autrement ? Pourquoi quelqu'un s'est-il donné la peine de faire tout cela ?

Encore une fois, nous ne blâmons pas vraiment les auditeurs ici. Dans la mesure où quelqu'un fait quelque chose de mal ici, c'est presque certainement un problème d'incitations avec celui qui a commandé l'audit. Et le fait qu'ils dépensent l'argent des investisseurs pour produire un document la plupart du temps inutile à des fins de marketing. Ce n'est pas la faute de l'auditeur !

Améliorations

C'est une chose sans équivoque bonne que plus de bogues soient détectés, moins de code cassé soit publié en production et plus de correctifs proposés soient implémentés. Et nous ne sommes pas assez immatures pour suggérer que le problème est que les utilisateurs et les investisseurs se soucient des mauvaises choses comme, par exemple, placer de la valeur et de la confiance dans des audits qui ne signifient pas grand-chose. Les gens se soucient de ce dont ils se soucient et essayer de changer cela est une mission insensée.

Mais il y a quelques améliorations réelles que nous pouvons suggérer. Ethena a ouvert la voie en expliquant d'emblée certains des nombreux modes de défaillance de leur produit. L'équipe était cohérente avec le message que USDe n'était pas sans risque. Et ils ont décrit les façons dont il pourrait avoir des problèmes. Le produit a survécu, avec quelques bosses, et est assez grand aujourd'hui. Cela nous donne un point d'action pour les investisseurs : insister pour que les projets soient honnêtes sur toutes les « attaques liées aux finances » qui pourraient exister.

Ethena montre qu'être honnête ne condamne pas le projet ! On peut soutenir qu'en étant plus honnête, le projet a attiré plus d'intérêt. L'honnêteté a également l'avantage supplémentaire de fournir plus de couverture juridique si quelque chose tourne mal. Les projets devraient déjà vouloir faire cela.

Les auditeurs aussi peuvent réorganiser la façon dont ils font leur analyse pour rendre leur travail plus utile. Ou au moins moins inutile et potentiellement trompeur. Ne mettez pas les problèmes d'incitation économique ou les préoccupations générales comme la sécurité quantique dans la même section que les bogues. À l'heure actuelle, ceux-ci sont normalement étiquetés d'une manière qui les différencie légèrement des erreurs de codage. Ou ils sont répertoriés comme « informatifs » par opposition à « critiques ».

Mais cela passe à côté du point. La sécurité quantique peut bien être un risque « critique » pour un système – mais c'est d'un caractère entièrement différent d'une mauvaise vérification de signature ou d'un signe moins errant ! Mettez ces choses dans des sections séparées. De même, « ce schéma de stablecoin est instable dans des conditions raisonnablement probables » n'est rien comme un bogue logique dans le code. Clarifier cette confusion devrait améliorer l'apparence des documents d'audit et polir la réputation de l'auditeur.

Enfin, les exchanges peuvent aider à cela. Les grands exchanges reçoivent beaucoup de critiques pour avoir listé des projets terribles, ou des memecoins risqués qui fluctuent énormément et coûtent de l'argent aux gens, ou toutes sortes d'autres décisions commerciales étranges infligeant des pertes. Et si les exchanges insistaient sur des audits raisonnables qui couvrent honnêtement la stabilité économique et ne confondent pas les risques comme « les Smart Contract (Contrat Intelligent) peuvent être vulnérables » avec de vraies vérifications logiques ?

Une façon d'interpréter un auditeur qui gonfle ses résultats avec ce genre de remplissage est que personne ne prendra au sérieux un résultat d'audit vide. C'est assez juste qu'un tel document soulèverait des questions. Mais si un exchange majeur listait un jeton avec, disons, deux résultats d'audit « vides » correspondants qui n'incluaient aucun problème spécifique au projet et prenait la position que c'était une bonne chose... cela pourrait aider à faire avancer un peu les choses. Nous sommes également à un point du cycle où être un exchange plus « honnête » et « raisonnable » devrait vous apporter plus de clients que le manque de marketing ridicule jusqu'à la lune ne vous en coûte.

De même, il ne devrait y avoir aucun stigmate attaché à l'audit d'un projet et à dire qu'il a l'air correct. Celui-ci concerne les auditeurs. Peut-être qu'un groupe d'auditeurs pourrait émettre des déclarations conjointes dans ce domaine. Oui, nous pouvons comprendre que les auditeurs voudront mettre des mises en garde pour les problèmes potentiels qui ont été exclus de la portée au début de l'engagement. Assez juste aussi. Mais gonfler les résultats avec des problèmes potentiels généraux inutiles n'est pas la réponse. Pas plus que de dire que l'équipe a atténué le risque de centralisation en faisant un article de blog sur la distribution des jetons qu'ils ont l'intention de trier manuellement, bientôt, selon un calendrier qui reste à déterminer.

Les audits peuvent être utiles. Les audits peuvent aider. Et la vérité est que les audits Web3 ont détecté de vrais problèmes et, pendant une période significative, étaient remplis de contenu utile et intéressant. Mais les ingénieurs se sont améliorés au fil du temps parce qu'ils sont, vous savez, des ingénieurs et c'est ce qu'ils font. Les auditeurs doivent suivre le rythme et, pour emprunter un mot, Soyez vigilant et ouvert à l'innovation un peu. Et de nombreuses parties plus importantes de l'écosystème, comme les exchanges, peuvent aussi aider à faire avancer cela.