Proxy évolutif non initialisé : risque de prise de contrôle de l'initialiseur

Les proxies évolutifs initialisent leur propre stockage par un appel d'initialisation plutôt que par le constructeur de l'implémentation. Cet article explique le front-running, le verrouillage de l'implémentation et les contrôles de déploiement.

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Réponse directe

Les contrats évolutifs n’utilisent pas de constructeur pour définir l’état de l’agent, mais s’appuient sur l’initialiseur. Cet article explique les agents non initialisés, le verrouillage de l’implémentation et les contrôles de déploiement.

Lorsque la nouvelle adresse proxy est déployée mais que la transaction d’initialisation n’a pas encore été confirmée, n’importe qui peut d’abord essayer d’acheter l’initialiseur public et devenir le propriétaire.

Lorsque l’agent est déployé, le constructeur n’exécutera pas la logique d’initialisation du contrat dans le stockage de l’agent. Par conséquent, les systèmes évolutifs utilisent souvent un initialiseur qui ne peut être appelé qu’une seule fois pour définir le propriétaire, les paramètres du jeton et les modules. Si la fonction n’est pas correctement protégée, ou si le déploiement et l’initialisation sont divisés en deux transactions, un attaquant peut choisir de l’acheter en premier.

Comment ça marche

Le processus de sécurité place les données d’appel de déploiement et d’initialisation dans la même transaction atomique et désactive l’initialisation lors de la mise en œuvre de la construction du contrat pour empêcher la mise en œuvre elle-même d’être prise en charge. Le réinitialiseur est utilisé pour ajouter un nouveau statut à la nouvelle version et doit également limiter la version et les autorisations d’appel. Vérifier uniquement le propriétaire de l’agent sans vérifier l’état d’initialisation de l’implémentation peut toujours présenter des risques de fuite.

Les opérations en chaîne sont divisées en quatre couches : le portefeuille est responsable de l’affichage et de la signature, RPC est responsable de la lecture et de la diffusion, le code du contrat détermine le changement de statut et le consensus de bloc détermine si la transaction est finalement confirmée. L’affichage du « succès » à n’importe quel niveau ne peut remplacer la vérification aux autres niveaux.

Exemple

Le projet déploie d’abord l’agent et prévoit ensuite l’option d’achat initialize(team). L’attaquant surveille le pool de mémoire et les premières options d’achat d’initialisation (attaquant) avec des frais plus élevés, devient administrateur, puis passe à une implémentation malveillante et transfère des fonds. La propre transaction d’initialisation de l’équipe est annulée, mais à ce stade, le contrôle est perdu.

Le gaz, le glissement et le temps de blocage dans le cas sont utilisés pour démontrer la méthode de calcul. Avant l’opération réelle, le prix, la liquidité, les autorisations et l’état du contrat de la chaîne actuelle et du bloc actuel doivent être lus. Le montant enregistre simultanément le nombre de jetons, la valeur en dollars et l’entier brut sur la chaîne.

Risques

Les rendements doivent être calculés sur la base de la valeur réelle de sortie :

Valeur nette de sortie = valeur marchande de l’actif - choc de prix - frais de protocole - droits de mutation - Gaz - décote du risque d’attente

Établissez trois scénarios de stress de congestion du réseau, d’exception Oracle et de mise à niveau de l’administrateur. Supposons que Gas se développe cinq fois, que la profondeur du pool diminue de 50 %, que le stablecoin soit réduit de 5 % et que vous ne puissiez pas sortir pendant un jour. Si un revenu mensuel ne peut pas couvrir les frictions de pression, un revenu élevé ne fournit pas une compensation suffisante.

Un protocole unique, une chaîne unique, un pont unique et une monnaie stable unique fixent respectivement des limites supérieures. Tous les postes qui nécessitent que les administrateurs, les oracles, les ponts, les frontaux et un seul RPC soient normaux en même temps pour quitter doivent être davantage restreints, et les dépendances multiples liées ne doivent pas être confondues avec une dispersion.

Idées fausses courantes

Mythe 1 : La balance initiale est le fait sur la chaîne. Le frontal peut être mis en cache, indexé tardivement ou connecté au mauvais réseau et doit être validé de manière croisée avec des lectures de contrat.
Mythe 2 : L’augmentation des gaz ou du glissement peut résoudre n’importe quelle panne. Le gaz n’affecte que le tri, et les dérapages ne font que détendre les prix ; Les erreurs d’autorisation, de nonce et de conditions du contrat ne seront pas automatiquement réparées.
Mythe 3 : La réussite de tests en petite quantité signifie une sécurité permanente. Les mises à niveau de l’administrateur, les paramètres dynamiques et les changements de liquidité modifieront les résultats et doivent être examinés avant chaque expansion de position.

Sujets connexes

Sources faisant autorite

API Proxy et Initializable - OpenZeppelin (consulté : 20 août 2026)
Écrire des contrats évolutifs - OpenZeppelin (consulté : 20 août 2026)
Mise à niveau des contrats intelligents - Ethereum.org (consulté : 20 août 2026)