Ce qu’un audit de contrat intelligent vous dit, et ce qu’il ne vous dit pas
« Audité » est employé comme synonyme de sûr. Un audit est une revue limitée dans le temps d’un code précis face à des préoccupations précises, et sa section de périmètre est la partie qui mérite d’être lue.
« Audité » apparaît sur les pages d’atterrissage comme s’il s’agissait d’une certification au sens défini. Ce n’en est pas une. C’est une prestation professionnelle au périmètre variable, et la différence entre une revue approfondie et une revue superficielle est invisible depuis le badge.
Ce qu’est réellement un audit
Un cabinet est mandaté pour examiner un ensemble spécifié de contrats à un commit spécifié, sur une période spécifiée, à la recherche de défauts face à un modèle de menaces spécifié. Il produit un rapport listant les constats par sévérité, le projet répond, et un rapport final consigne généralement ce qui a été corrigé.
Chaque occurrence de « spécifié » y accomplit un travail. Le périmètre est négocié, et un rapport portant sur trois contrats ne dit rien du quatrième, celui qui détient les fonds.
Lisez d’abord la section de périmètre
Le périmètre vous indique quels fichiers ont été examinés et à quel hash de commit. Deux questions en découlent, et toutes deux trouvent une réponse en quelques minutes.
Le périmètre inclut-il les contrats qui détiennent ou déplacent réellement de la valeur, ou seulement des contrats périphériques ? Et le commit examiné correspond-il à ce qui est déployé ? Le code change après un audit, et un rapport portant sur un commit antérieur à plusieurs mises à niveau décrit un logiciel qui n’existe plus. Vérifier le bytecode déployé face au code source audité est le contrôle qui comble cet écart, et il est rarement effectué par ceux qui lisent le badge.
Les constats et leur résolution
Les rapports classent les constats par sévérité. Ce qui compte plus que les décomptes, c’est la résolution : corrigé, reconnu ou contesté.
« Reconnu » signifie que le projet a lu le constat et a choisi de ne rien changer. Cela peut être tout à fait raisonnable — le constat décrit peut-être un arbitrage accepté — mais cela signifie qu’un problème connu est en production, et il n’apparaîtra pas dans un résumé qui ne rapporte que le badge.
Un rapport sans aucun constat n’est pas un triomphe. Cela signifie généralement un périmètre étroit ou une revue superficielle. Les revues compétentes de systèmes non triviaux trouvent des choses.
Ce que les audits font structurellement mal
Certaines catégories sont difficiles à détecter en examinant le code :
- Défauts de conception économique. Du code qui se comporte exactement comme il est écrit, mais dont les incitations créées sont exploitables. Cela demande de modéliser l’économie du système, ce qui est une discipline différente et fréquemment hors périmètre.
- Composabilité. Un contrat peut être sain isolément et dangereux une fois combiné à un autre protocole que personne n’avait anticipé.
- Hypothèses sur l’oracle. Les contrats qui reposent sur des données de prix externes héritent de la fiabilité de ces données, et l’oracle est généralement hors périmètre.
- Gouvernance et clés. Un contrat évolutif contrôlé par un petit multisig comporte un risque qu’aucune revue de code ne traite, parce que le code autorise la mise à niveau par conception.
Ce dernier point mérite d’être souligné. Si un contrat peut être mis à niveau, l’audit décrit l’implémentation actuelle et les détenteurs des clés de mise à niveau peuvent la remplacer. Ce qui compte alors, c’est qui sont ces détenteurs et quelle procédure les encadre — une question de gouvernance déguisée en badge technique.
À quoi ressemble un bon rapport
Publié intégralement plutôt que résumé. Périmètre indiqué avec des hashes de commit. Constats avec sévérité, description et résolution. Une section de méthodologie décrivant ce qui a été examiné et ce qui ne l’a pas été. Et une date, pour que vous puissiez le comparer à l’historique de déploiement.
Un projet qui publie tout cela fait quelque chose de sensiblement différent d’un projet qui affiche un logo. Le logo est la partie qui coûte le moins cher.
Comment s’en servir
Traitez un audit comme la preuve qu’un projet a dépensé de l’argent en examen et a accepté d’en publier le résultat, ce qui est un vrai signal sur sa façon de fonctionner. Ne le traitez pas comme une garantie de sécurité, car le rapport ne prétend pas en être une — l’avertissement qu’il contient le dit généralement de façon explicite, dans la section que personne ne cite.
Les questions pratiques demeurent : quelle proportion de vos avoirs est exposée à ce contrat, pourriez-vous tolérer de la perdre, et le rendement proposé est-il plausiblement une compensation pour ce risque ? La présence d’un rapport n’y change rien, et c’est exactement pour cela que le badge est utilisé comme il l’est.
Toutes les revues n’ont pas la même profondeur
« Audit » recouvre un éventail d’activités au coût et à la rigueur très différents, et le rapport ne rend pas toujours la distinction évidente.
Une revue manuelle par des spécialistes expérimentés qui lisent le code est l’extrémité coûteuse. L’analyse automatisée repère les schémas connus à bas coût et manque tout ce qui est nouveau. La vérification formelle prouve mathématiquement qu’un code satisfait une spécification, ce qui est puissant et ne vaut que la spécification. Les plateformes d’audit compétitif confient la revue à la foule, ce qui trouve un large éventail de problèmes mais produit une couverture moins régulière.
Chacune a son rôle. Ce qui compte, c’est de savoir laquelle vous avez sous les yeux, et la section de méthodologie le dit. Un rapport qui ne décrit pas sa méthode demande à être cru sur la force du logo.
Les primes aux bugs disent quelque chose qu’un rapport ne peut pas dire
Un audit est un instantané ; une prime aux bugs est continue. Un projet qui fait tourner une prime substantielle et bien délimitée, avec un historique public de versements, est exposé à un examen continu qu’une revue ponctuelle n’offre pas.
La taille compte. Un versement maximal très inférieur à ce que rapporterait un exploit n’est pas une incitation, c’est un geste — une personne qui trouve une faille critique dans un contrat détenant une grosse somme se heurte à un problème arithmétique évident si la prime est triviale en comparaison. Des primes calibrées sur la valeur exposée sont un vrai signal du sérieux avec lequel un projet envisage la possibilité de se tromper.
Le temps en production est aussi une preuve
Les contrats qui ont détenu une valeur importante pendant longtemps sans incident ont subi la revue la plus rigoureuse qui soit : l’attention soutenue de personnes financièrement motivées pour les casser.
Ce n’est pas une preuve — des failles dormantes existent et plusieurs protocoles de longue date ont échoué tardivement. Mais un contrat récemment déployé, avec un rapport et sans historique d’exploitation, a été examiné par un cabinet pendant quelques semaines. Un contrat plus ancien avec le même rapport a en plus survécu à des années d’intérêt hostile, et c’est une qualité de preuve différente.
Combiner les deux est l’approche pratique : lisez le rapport pour ce qui a été examiné, et pesez l’historique de déploiement pour ce que le rapport ne pouvait pas couvrir.