Contrats vérifiés, proxys et la clé de mise à niveau dont personne ne parle
Sur l’explorateur de blocs figure une coche verte indiquant Code source du contrat vérifié, et un nombre considérable de gens la lisent comme « ce contrat est sûr ».
Ce n’est pas ce qu’elle signifie. Elle signifie quelque chose de bien plus étroit et de bien plus utile, et confondre les deux est la manière dont des personnes prudentes finissent par autoriser des choses qu’elles n’auraient jamais acceptées.
Ce que « vérifié » certifie réellement
Les contrats sont déployés sous forme de bytecode — des instructions machine, illisibles en pratique. La vérification consiste à téléverser le code source d’origine et à faire confirmer par l’explorateur que sa compilation, avec la version et les réglages de compilateur déclarés, produit exactement le bytecode qui vit déjà à cette adresse.
Voilà toute l’affirmation : le code source que vous lisez est bien celui qui s’exécute.
C’est une garantie réelle et précieuse. Sans elle, vous n’auriez aucun moyen de savoir si le joli code présent sur le GitHub d’un projet entretient le moindre rapport avec ce que votre transaction s’apprête à toucher.
Mais observez tout ce qu’elle ne dit pas. La vérification n’est pas un audit. Personne n’a évalué si le code est correct, s’il comporte des bogues, ou s’il fait quoi que ce soit de ce que ses noms de fonctions laissent entendre. Un contrat doté d’une fonction nommée claimRewards qui transfère tout votre solde au déployeur peut être vérifié, et la vérification serait parfaitement honnête : elle attesterait fidèlement que le vol est exactement ce que le code dit faire.
Vérifié signifie lisible, pas digne de confiance. Cela déplace la question de « qu’est-ce que cette chose ? » vers « est-ce que je comprends ce que je viens de lire ? », ce qui est un progrès, mais ne répond pas à la seconde à votre place.
L’inverse compte aussi. Un contrat non vérifié n’est pas une preuve de malveillance — quantité de déploiements légitimes ne se font jamais vérifier. Mais cela signifie que personne — aucun outil que vous utilisez, aucun chercheur qui aurait pu vous alerter — ne peut lire ce avec quoi vous allez interagir. Il est raisonnable de s’en méfier.
Et puis les proxys aggravent les choses
C’est ici que le sol se dérobe, et c’est la partie qui reste le plus souvent tue.
La plupart des contrats non triviaux avec lesquels vous interagirez ne sont pas des contrats uniques. Ce sont des proxys. Le proxy est l’adresse que vous voyez, et il détient toutes les données — soldes, autorisations, état. Mais il ne contient presque aucune logique. Il transmet chaque appel à un contrat d’implémentation distinct et exécute simplement ce que celui-ci dit.
La raison en est la capacité de mise à niveau. Les contrats immuables ne peuvent être corrigés : un bogue est donc permanent et une fonctionnalité manquante l’est pour toujours. Faire pointer un proxy vers une nouvelle implémentation permet à une équipe de corriger des bogues et de livrer des améliorations sans demander à chaque utilisateur de migrer. Vu la valeur perdue à cause de bogues incorrigibles, c’est un choix d’ingénierie défendable.
Il a une conséquence facile à manquer. Quand vous consultez un proxy sur un explorateur et le voyez vérifié, vous avez vérifié la logique de transmission, pas le comportement. Le code qui décide réellement du sort de votre argent vit à l’adresse d’implémentation, que l’explorateur met ou non en évidence, et qui peut être remplacée.
La vraie question n’a donc jamais été « ce contrat est-il vérifié ? ». Elle est :
Qui peut changer le comportement de ce contrat, et à quelle vitesse ?
La clé d’administration est le véritable modèle de sécurité
Tout contrat évolutif a quelqu’un qui peut effectuer la mise à niveau. Cette autorité est le modèle de sécurité, quelle que soit la qualité du code actuel.
L’éventail va d’alarmant à raisonnable :
Un unique compte détenu en externe. Une clé privée, sur la machine de quelqu’un, peut remplacer la logique du contrat qui détient vos fonds. Si elle est hameçonnée, volée, ou son propriétaire contraint, le contrat devient ce que l’attaquant veut. Cet arrangement est plus courant qu’il ne devrait l’être.
Un multisig. Plusieurs signataires doivent s’accorder. Nettement mieux — cela supprime le point de défaillance unique — même s’il vaut la peine de savoir combien ils sont, et s’il s’agit vraiment de personnes indépendantes ou de quatre portables appartenant à la même équipe.
Un multisig derrière un verrou temporel. Une mise à niveau est annoncée sur la chaîne et ne peut s’exécuter qu’après un délai fixe, souvent de 24 à 72 heures. C’est le cas qui compte, car il change entièrement votre position : vous êtes prévenu à l’avance et disposez d’une fenêtre pour retirer avant l’entrée en vigueur. Un verrou temporel n’empêche pas une mise à niveau malveillante. Il la rend survivable.
Aucune voie de mise à niveau. Le contrat est immuable. Prévisibilité maximale, aucun recours si un bogue est découvert. Choix légitime, généralement fait par des protocoles éprouvés assez longtemps pour parier là-dessus.
Aucune de ces options n’est automatiquement la bonne. Mais l’écart entre « une clé » et « multisig plus deux jours de délai » est l’écart entre espérer que personne ne se trompe et avoir le temps de réagir quand cela arrive.
Pourquoi cela mord précisément sur les autorisations
C’est la partie qui rejoint quelque chose que vous faites réellement, et régulièrement.
Lorsque vous accordez une autorisation de jetons, vous habilitez une adresse à déplacer vos jetons. Pas un morceau de code — une adresse. L’autorisation réside dans le stockage du contrat du jeton et persiste indéfiniment.
Si cette adresse est un proxy évolutif, alors la logique habilitée à déplacer vos jetons peut être remplacée après votre autorisation, sans votre intervention et sans nouvelle signature de votre part. Vous avez audité une chose et restez exposé à une autre.
Voilà pourquoi le conseil permanent de révoquer les autorisations dont vous ne vous servez plus pèse plus lourd qu’il n’y paraît. Il ne s’agit pas seulement d’un contrat qui se révélerait bogué. Il s’agit du fait qu’une autorisation illimitée à un contrat évolutif est une permission accordée à quiconque contrôle la clé de mise à niveau, aussi longtemps que vous la laissez ouverte.
C’est aussi la limite la plus nette de la simulation de transactions. Simuler avant de signer vous dit ce que fait une transaction face à l’état actuel et à l’implémentation actuelle. C’est réellement utile, et cela ne peut pas vous dire ce que la même autorisation permettra le mois prochain.
Ce que SSP vous montre, et où il s’arrête
Quand SSP Key présente une autorisation, il décode les données d’appel au lieu de vous montrer de l’hexadécimal brut. Il reconnaît les sélecteurs ERC-20 standard — approve, transfer, transferFrom, increaseAllowance, setApprovalForAll — et les restitue en langage clair, en signalant notamment les autorisations illimitées, définies dans le code comme tout montant égal ou supérieur à 2^255.
Le décodeur est délibérément prudent. Son propre en-tête le décrit comme relevant uniquement de la couche de présentation : il ne modifie jamais ce qui est signé, et il échoue en se fermant. Un sélecteur inconnu, une longueur erronée, de l’hexadécimal malformé ou un remplissage d’adresse non standard le font ne rien renvoyer et se replier sur une action générique avec l’hexadécimal brut derrière une vue « Avancé ». Il préfère admettre qu’il ne sait pas plutôt que deviner avec assurance et se tromper. Symboles et décimales des jetons ne sont joints que lorsqu’ils sont connus du registre embarqué, jamais déduits.
Vient maintenant la frontière honnête. Le décodeur n’a aucune notion de proxy. Aucun concept de contrat d’implémentation n’y figure. Il peut vous dire, correctement et clairement : « vous accordez une autorisation USDC illimitée à 0xABC… » — et il ne peut pas vous dire que 0xABC est un proxy, qui en détient la clé de mise à niveau, ou que son comportement pourra être tout autre la semaine prochaine.
Ce n’est pas tant un oubli qu’une frontière qu’aucun décodeur de portefeuille ne peut franchir. Décoder décrit l’appel qui est devant vous. Savoir si la contrepartie est évolutive, et qui la gouverne, relève d’une propriété du monde extérieur à vérifier séparément. Nous préférons énoncer la frontière plutôt que laisser un écran d’autorisation d’apparence assurée suggérer une exhaustivité qu’il n’a pas.
Une vérification pratique avant d’autoriser quelque chose d’important
Est-il vérifié ? Sinon, comprenez que vous vous fiez à la seule réputation.
Est-ce un proxy ? Les explorateurs l’indiquent — cherchez une mention de proxy, ou une option « Read as Proxy ». Si elle est là, c’est l’implémentation qui compte.
Qui peut le mettre à niveau, et y a-t-il un délai ? C’est la question la plus précieuse de la liste et celle que presque personne ne pose. Un projet qui y a réfléchi le documentera. Un projet qui ne l’a pas fait, ou qui refuse de le dire, vous a déjà appris quelque chose.
L’autorisation doit-elle être illimitée ? En général non. Autoriser le montant que vous comptez réellement dépenser borne votre exposition à cela exactement, quoi que devienne le contrat ensuite.
Révoquez quand vous avez fini. Une autorisation ouverte est une permission permanente, et elle survit à votre attention.
L’ajustement mental qui en vaut la peine est mince mais change beaucoup. La vérification vous dit quel code s’exécute en ce moment. L’évolutivité vous dit qui décide de ce qui s’exécutera demain. Presque tout le risque loge dans la seconde question, et presque toute la réassurance proposée ne traite que la première.
