Fortifier nos murs : la sécurité V1 renforcée par Certik Audit

Par DeHub Team — 2021-07-04

À la suite de la vulnérabilité du contrat intelligent v1, nous avons commandé une audit complète avec Certik au T3 2021 et avons corrigé ce qu’ils ont trouvé.

Les audits sont utilisés comme marketing dans cette industrie, il vaut donc la peine d'écrire celui-ci avec précision : ce que nous l'avons fait faire, ce qu'il a couvert et ce qu'il n'a pas empêché.

Pourquoi après, pas avant

La réponse inconfortable est que la v1 a été expédiée sans. La communauté avait voté sur les fondamentaux du jeton, le lancement bougeait, et un audit complet représente des semaines de temps calendaire et un coût significatif pour un projet qui n'avait pas encore été répertorié.

C'était le mauvais commerce et la vulnérabilité l'a prouvé. Chaque contrat que nous avons déployé depuis a été audité avant sa mise en service, pas après. C'est une politique qui existe à cause de ce trimestre.

Ce qu’est réellement l’audit

Un audit est une lecture structurée et contradictoire du code par des personnes qui sont payées pour trouver des choses et qui n'ont aucun intérêt dans le résultat. Un bon produit une liste de résultats par gravité, un ensemble de changements recommandés et un enregistrement de ceux que vous avez réellement faits.

Cette dernière partie est celle où les audits sont déformés. « Audité par Certik » n'est pas une constatation — un rapport avec des critiques non résolues est toujours un audit. L'affirmation utile est que les conclusions ont été résolues et les résolutions vérifiées, ce que nous avons fait ici, et c'est la version que nous avons publiée depuis.

Ce qu'un audit ne vous achète pas

Être direct sur les limites, parce que nous avons appris plus tard certaines d'entre elles à la dure :

• Il couvre le code, pas le design. Un contrat peut être exempt de bugs exploitables et toujours se comporter mal dans des conditions que personne n'a modélisées.
• C'est un instantané. Elle s'applique à la version auditée. Toute modification ultérieure n'est pas auditée tant qu'elle ne l'est pas.
• Il ne peut pas voir les pièces qui ne sont pas du code. Notre incident le plus dommageable cette année-là n'était pas du tout technique — il s'agissait d'une annonce frauduleuse agent, et aucun audit de contrat existant ne l'aurait détecté.

L’illustration la plus claire est Q4 2022. Le contrat v2 déclenchait des taxes qui ont mal fonctionné dans des conditions de marché réelles et ont gelé à la fois le token et notre pool de liquidité. C’était un problème de conception, pas un bug non corrigé, et c’est pourquoi nous avons finalement migré vers une tokenomics ERC‑20 standard simple sans aucune astuce dans le chemin de transfert.

## Ce que nous avons conservé

L'audit a fait son travail. Les détenteurs ont été rétablis grâce à un parachutage automatique 1:1, le contrat renforcé a porté DHB l'année suivante et le processus est devenu standard.

La leçon la plus importante était moins chère à apprendre ici qu'elle ne l'aurait été plus tard : l'audit n'est pas la sécurité. La sécurité est l'habitude de supposer que votre contrat est erroné jusqu'à ce que quelqu'un sans raison d'être gentil ait essayé de le prouver.

Comment nous en parlons

Nous n'utilisons pas le mot « audité » comme une revendication en soi, et nous encourageons toute personne évaluant un projet à traiter le mot comme le début d'une question plutôt que comme la fin d'une question.

Les questions utiles sont : audité par qui, contre quelle version, ce qu'ils ont trouvé et ce qui a été réellement changé en conséquence. Un rapport avec des constatations critiques non résolues est toujours un audit. Un rapport sur un contrat qui a depuis été modifié décrit quelque chose qui n'est plus déployé.

Ces questions sont la raison pour laquelle les rapports de transparence et éventuellement dhbscan.com existent. Ils y répondent sans demander à personne.