Comment mettre à niveau un contrat intelligent à l'aide d'un modèle de proxy ?

Comprendre le modèle de proxy dans Ethereum

1. Le modèle de proxy dissocie la logique du contrat du stockage en déployant deux contrats distincts : un proxy et une implémentation.

2. Les utilisateurs interagissent exclusivement avec le proxy, qui transmet tous les appels au contrat de mise en œuvre en cours à l'aide de déléguécall.

3. La disposition du stockage doit rester cohérente lors des mises à niveau de mise en œuvre afin d'éviter toute corruption ou désalignement des données.

4. Le proxy conserve un seul emplacement de stockage pour l'adresse d'implémentation, ce qui permet de la mettre à jour sans affecter l'état de l'utilisateur.

5. Cette architecture permet des changements rétrocompatibles tout en préservant les soldes, les allocations et les interactions historiques en chaîne.

Composants clés d'un proxy transparent

1. Le contrat proxy comprend une fonction de secours qui achemine les appels externes via un délégué vers l'implémentation désignée.

2. Un rôle d'administrateur est appliqué pour restreindre les autorisations de mise à niveau : seules les adresses autorisées peuvent modifier le pointeur d'implémentation.

3. Un modificateur vérifie si l'appelant est l'administrateur avant d'exécuter la logique de mise à niveau, empêchant ainsi toute reconfiguration non autorisée.

4. Le contrat de mise en œuvre doit hériter d'un contrat de base qui définit la structure de stockage, garantissant l'alignement avec l'agencement du proxy.

5. Les sélecteurs de fonctions sont conservés dans toutes les versions ; les nouvelles fonctions doivent éviter les collisions avec celles existantes, à moins de remplacer intentionnellement le comportement.

Étapes de déploiement et de mise à niveau

1. Déployez le contrat de mise en œuvre initial contenant la logique métier principale et les variables d'état requises.

2. Déployez le contrat proxy, en initialisant son stockage avec l'adresse de la première implémentation et en définissant l'adresse administrateur.

3. Vérifiez que le proxy délègue correctement les appels en appelant des fonctions de test et en confirmant que les valeurs de retour correspondent aux sorties attendues.

4. Lors de la mise à niveau, compilez et déployez un nouveau contrat de mise en œuvre avec une logique modifiée mais une disposition de stockage identique.

5. Appelez la fonction updateTo du proxy avec la nouvelle adresse d'implémentation, en vous assurant que seul l'administrateur déclenche cette transaction.

Considérations et pièges en matière de sécurité

1. Un alignement manquant ou incorrect de la disposition du stockage entre les implémentations entraîne une corruption silencieuse des données : les variables peuvent être lues à partir de mauvais emplacements.

2. Ne pas sécuriser le rôle d'administrateur expose l'ensemble du système à des mises à niveau malveillantes ; des portefeuilles multi-signatures ou des timelocks doivent être envisagés.

3. Les fonctions d'initialisation doivent être appelées séparément après le déploiement puisque les constructeurs ne s'exécutent pas dans des contextes d'appel délégué.

4. Les dépendances de bibliothèques externes intégrées dans le code d'implémentation doivent également être mises à niveau de manière cohérente, car leur bytecode fait partie du contrat logique.

5. Les risques de réentrée augmentent si la logique de mise à niveau ne protège pas correctement contre les appels récursifs de délégués pendant les transitions critiques.

Foire aux questions

Q : Puis-je modifier l'adresse de l'administrateur après le déploiement ? Oui, la plupart des implémentations de proxy incluent une fonction changeAdmin qui permet de mettre à jour l'adresse de l'administrateur, à condition que l'administrateur actuel lance l'appel.

Q : Que se passe-t-il si j'oublie d'initialiser l'implémentation mise à niveau ? L'état du contrat reste non initialisé, laissant potentiellement les variables critiques à des valeurs par défaut comme des adresses nulles ou vides, conduisant à un comportement inattendu.

Q : Est-il possible de revenir à une version d'implémentation précédente ? Oui, les rétrogradations sont techniquement prises en charge tant que le contrat de mise en œuvre précédent existe toujours en chaîne et conserve une disposition de stockage compatible.

Q : Les événements émis lors de l'appel délégué apparaissent-ils sous l'adresse du proxy ou sous l'adresse de l'implémentation ? Les événements sont émis sous l' adresse du proxy , car l'EVM enregistre le contexte appelant (et non la cible appelée par le délégué) lors de l'émission des événements.