Les anciens smart contracts peuvent rester dangereux longtemps après qu'un protocole a évolué.
Une analyse de SlowMist portant sur un vol de 2,19 millions de dollars sur Aztec Connect a remis ce problème sous les projecteurs. Le contrat concerné faisait partie d'un système hérité obsolète, et non du réseau Aztec actif, mais l'incident reste un avertissement important pour les utilisateurs et les développeurs DeFi / Finance Décentralisée.
Dans les logiciels traditionnels, un produit abandonné peut souvent être corrigé, arrêté ou entièrement retiré de la portée des utilisateurs. Les systèmes on-chain sont différents. Si un Smart Contract (Contrat Intelligent) est immuable et détient encore des actifs ou des autorisations, il peut continuer à exister comme une surface d'attaque active.
C'est la leçon inconfortable tirée de l'exploit d'Aztec Connect analysé par SlowMist. Le contrat faisait partie d'un système hérité déjà obsolète, mais les attaquants ont tout de même pu le cibler. Les rapports autour de l'incident ont également pointé des préoccupations supplémentaires liées aux contrats hérités, mais la source primaire la plus fiable appuie le cas Aztec Connect à 2,19 millions de dollars.
Cette distinction est importante. Il ne s'agit pas d'une histoire sur la compromission du réseau Aztec actuel. Il s'agit d'une histoire sur la longue traîne des anciens smart contracts, où les utilisateurs peuvent supposer que le risque a disparu simplement parce qu'un produit n'est plus promu.
Le secteur crypto traite souvent l'immuabilité comme une fonctionnalité, et à bien des égards, c'en est une. Les utilisateurs ne veulent pas que les opérateurs de protocoles réécrivent les règles chaque fois que les conditions de marché deviennent inconfortables. Mais l'immuabilité a un second côté : si un contrat défectueux ou exposé ne peut pas être mis en pause ou mis à niveau, les développeurs peuvent avoir peu de marge pour intervenir lorsque quelque chose tourne mal.
Le problème hérité d'Aztec s'inscrit dans ce compromis plus large. L'infrastructure obsolète peut rester on-chain même lorsque l'équipe est passée à des systèmes plus récents. Si les utilisateurs laissent des fonds derrière eux ou continuent d'interagir avec d'anciens contrats, la feuille de route de développement actuelle du protocole pourrait ne pas les protéger.
Cela crée un problème de sécurité complexe pour la DeFi / Finance Décentralisée. Les développeurs peuvent publier des avertissements, fermer progressivement les interfaces et recommander des migrations, mais ils peuvent ne pas être en mesure d'effacer chaque ancien contrat. Les attaquants, quant à eux, peuvent continuer à scanner les actifs, les cas limites et les autorisations oubliées.
Pour les utilisateurs ordinaires, la leçon pratique est de traiter les anciens contrats avec prudence. Un nom de protocole familier ne signifie pas automatiquement qu'une ancienne Interface ou un ancien pont reste sûr. Avant d'interagir avec un contrat hérité, les utilisateurs doivent vérifier si le protocole le prend encore en charge, si les fonds sont toujours surveillés, et si un chemin de migration officiel existe.
Pour les développeurs, l'incident rappelle que les plans de mise hors service doivent faire partie de la conception du protocole. Rendre un système obsolète n'est pas la même chose que supprimer le risque. Des avertissements clairs, des fenêtres de retrait, une surveillance et des procédures d'urgence ont tous de l'importance, en particulier lorsque les contrôles administratifs sont intentionnellement limités.
Le point clé n'est pas que le code immuable est mauvais. Le point clé est que l'immuabilité rend la discipline opérationnelle encore plus importante. Une fois que le code est en ligne et immuable, l'infrastructure abandonnée peut faire partie du périmètre de sécurité pendant des années.
Cet article a été rédigé par le News Desk et édité par Samuel Rae.
Ce rapport est basé sur des informations de SlowMist. chez SlowMist


