Comment vérifier un contrat intelligent avant de signer

Ce que la vérification prouve réellement

Un contrat déployé sur Ethereum ou toute chaîne EVM est du bytecode. Il est déterministe, auditable en principe, et illisible en pratique.

La vérification consiste à soumettre le code source Solidity ou Vyper original, avec la version exacte du compilateur et les réglages d’optimisation utilisés, pour que n’importe qui puisse le recompiler et confirmer que le résultat correspond au bytecode réellement sur la chaîne. Etherscan effectue cette vérification puis publie le code source.

Ce que cela établit est étroit et important : le code que vous lisez est le code qui s’exécutera. Cela élimine la possibilité qu’un projet ait publié une chose et déployé une autre, une forme de fraude réelle et historiquement courante.

Ce que cela n’établit pas, c’est que le code fait quelque chose de raisonnable. Un contrat vérifié peut contenir une fonction de mint illimitée, un propriétaire pouvant mettre en pause tous les transferts, des frais pouvant être relevés à cent pour cent, ou une fonction transférant les tokens de chacun vers une seule adresse. Tout cela est parfaitement vérifiable et parfaitement hostile.

« Vérifié sur Etherscan » est donc devenu une question de sécurité de premier ordre dans tout l’écosystème, posée par des gens n’ayant jamais lu de Solidity, et cela répond à une question bien plus étroite qu’ils ne le pensent. C’est une condition préalable pour juger un contrat, pas un jugement.

Les proxies, et lire le mauvais code

La plupart des contrats importants aujourd’hui sont des proxies. L’adresse avec laquelle vous interagissez est une coquille mince et permanente qui délègue toute la logique à un contrat d’implémentation séparé, et cette implémentation peut être remplacée par quiconque détient la permission de mise à jour.

Ce modèle existe pour de bonnes raisons — les bugs peuvent être corrigés, des fonctionnalités ajoutées — et cela change fondamentalement la question de sécurité. Le code que vous auditez aujourd’hui n’est pas nécessairement le code qui s’exécutera demain.

Un explorateur naïf vous montre le propre bytecode du proxy, environ quarante lignes de code passe-plat qui ne disent rien du tout. Etherscan détecte les motifs de proxy courants, résout l’implémentation, et propose un bouton « Read as Proxy ». Plusieurs concurrents ne le font pas, et l’échec est silencieux : vous regardez du code réel, vérifié, et tirez une conclusion sur le mauvais contrat.

Les questions à poser sont qui peut mettre à jour, et s’il existe un timelock. Une mise à jour contrôlée par un seul compte à propriété externe sans délai signifie qu’une seule clé compromise change tout. Une mise à jour contrôlée par un multisig avec un timelock de quarante-huit heures signifie que les gens ont un avertissement.

Les deux dispositions sont visibles sur l’explorateur, dans les fonctions d’administration du proxy et dans l’adresse du propriétaire. Que le propriétaire soit un multisig ou une seule clé est lui-même lisible — un multisig a du code de contrat, une seule clé non.

Privilèges du propriétaire : les fonctions qui comptent

Si vous ne lisez rien d’autre dans un contrat, lisez les fonctions protégées par une vérification de propriétaire ou d’administrateur. C’est là que se trouve le pouvoir.

Mint. De nouveaux tokens peuvent-ils être créés après le déploiement, et par qui ? Une fonction de mint illimitée détenue par une seule adresse signifie que l’offre est ce que cette adresse décide, quand elle le décide. C’est le mécanisme derrière une grande part des effondrements de tokens.

Pause ou blacklist. Les transferts peuvent-ils être arrêtés, généralement ou pour des adresses précises ? Les stablecoins légitimes ont cela et l’utilisent pour se conformer à des ordres légaux, ce qui est défendable. Un meme token qui l’a est une tout autre affaire.

Ajustement des frais. Des frais de transfert peuvent-ils être changés après le lancement ? Un contrat avec des frais démarrant à zéro et pouvant être relevés à quatre-vingt-dix-neuf pour cent est un piège à retardement.

Transfert arbitraire. Une adresse privilégiée peut-elle déplacer des tokens qu’elle ne possède pas ? Rare, sans ambiguïté, et disqualifiant.

Aucune de ces fonctions n’est automatiquement malveillante. Le contexte décide. Un stablecoin réglementé a besoin de la capacité de geler ; un token communautaire se prétendant décentralisé non. Le but est de savoir lesquelles existent avant d’engager des fonds plutôt qu’après.

L’approbation que vous accordez réellement

La plupart des pertes ne viennent pas de la logique propre d’un contrat. Elles viennent des approbations, et c’est l’approbation que vous signez réellement.

Quand vous utilisez une plateforme d’échange décentralisée, vous accordez à son contrat la permission de déplacer un token précis depuis votre adresse. Cette permission est généralement illimitée en montant et en durée, et persiste jusqu’à ce que vous la révoquiez — bien après avoir oublié l’existence du protocole.

Deux ans plus tard, ce protocole est exploité. L’exploit n’a pas besoin de briser votre portefeuille ; il lui suffit d’utiliser une permission que vous avez déjà accordée. Les personnes qui perdent de l’argent sont souvent celles qui ont interagi une fois, des années plus tôt, et n’y ont jamais repensé.

L’invite du portefeuille vous dit ce que vous approuvez, et presque personne ne la lit. Les deux champs qui comptent sont le bénéficiaire — quel contrat est autorisé — et le montant. De nombreux portefeuilles vous permettent désormais de fixer un montant fini plutôt qu’illimité, et le petit coût supplémentaire d’approuver par transaction en vaut la peine pour tout ce dont vous ne faites pas pleinement confiance.

Etherscan et BscScan ont tous deux des vérificateurs d’approbations de tokens qui listent chaque approbation active d’une adresse et vous laissent révoquer. Vérifier trimestriellement est l’habitude de sécurité la plus rentable sur toute chaîne EVM, et les approbations sont propres à chaque chaîne, chaque réseau doit donc être vérifié séparément.

Une séquence pratique avant d’interagir

Cela prend environ trois minutes et détecte la plupart de ce qui est détectable sans lire de Solidity.

Commencez par confirmer l’adresse du contrat par rapport à la propre documentation du projet ou à ses comptes sociaux vérifiés. Pas le nom affiché dans un portefeuille, pas un lien depuis un message — l’adresse, depuis une source que le projet contrôle. Les noms et symboles sont arbitraires et librement réutilisables, et l’usurpation est l’attaque la plus courante de toutes.

Ouvrez ensuite cette adresse sur un explorateur et vérifiez qu’elle est vérifiée. Non vérifié n’est pas automatiquement malveillant — beaucoup de contrats légitimes ne sont pas vérifiés, particulièrement sur des chaînes plus petites — mais cela signifie que vous faites confiance sans pouvoir vérifier.

Vérifiez s’il s’agit d’un proxy et, si oui, résolvez l’implémentation. Lisez l’adresse du propriétaire et établissez s’il s’agit d’un multisig ou d’une seule clé.

Parcourez la liste des fonctions à la recherche des opérations privilégiées ci-dessus. Vous n’avez pas besoin de comprendre l’implémentation ; vous devez savoir si la fonction existe.

Et quand l’invite du portefeuille apparaît, lisez le bénéficiaire et le montant. Cette invite est le dernier point où tout cela est encore réversible.

Ce contre quoi cela ne vous protégera pas

Être honnête sur les limites d’une vérification de trois minutes compte plus que de prétendre qu’elle suffit.

Elle ne trouvera pas un bug de logique subtil. Les audits professionnels les ratent, régulièrement, et lire un contrat sur un explorateur n’est pas un audit. Ce qu’elle trouve, c’est la catégorie évidente — les fonctions permettant à quelqu’un de tout prendre, énoncées clairement dans le code.

Elle ne vous dira pas si un projet est économiquement sain, si sa trésorerie est réelle, ou si les personnes derrière ont l’intention de rester. Ce sont des questions auxquelles la chaîne ne peut pas répondre.

Et elle n’aidera pas sur les chaînes dépourvues de cet outillage. Toute l’approche décrite ici est spécifique à l’EVM. Sur Cardano, les actifs natifs sont des objets de ledger sans aucun mécanisme d’approbation. Sur Sui, les paquets sont publiés avec des informations de type et se mettent à jour explicitement. Sur Solana, la question équivalente est quel programme possède un compte et quelle autorité déléguée existe.

Le principe général se transpose même là où la mécanique ne le fait pas : découvrez ce que la chose avec laquelle vous êtes sur le point d’interagir est autorisée à faire, avant de le permettre.