Quelle est la différence entre call, déléguécall et staticcall dans Solidity ?

Comprendre les distinctions entre appel, appel délégué et appel statique est essentiel pour le développement de contrats intelligents sécurisé et efficace dans Solidity. Ces fonctions de bas niveau permettent d'interagir avec d'autres contrats ou comptes externes mais se comportent différemment en termes de contexte, de modification d'état et d'environnement d'exécution.

appel

1. La fonction d'appel invoque la fonction d'un autre contrat tout en transmettant une quantité spécifiée d'Ether et en exécutant du code dans le contexte du contrat appelé.

2. Il utilise le stockage, le code et le solde de l'appelé, ce qui signifie que tout changement d'état se produit dans le cadre du contrat cible.
3. Cette méthode est couramment utilisée lors de l'interaction avec des contrats externes dont l'ABI peut ne pas être connu au moment de la compilation.
4. Les développeurs doivent gérer soigneusement les données renvoyées, car call renvoie un booléen indiquant le succès ou l'échec, ainsi que des octets de retour facultatifs.
5. Une mauvaise utilisation peut conduire à des vulnérabilités de réentrée si les modèles appropriés de vérification, d'effet et d'interaction ne sont pas suivis.

appel délégué

1. déléguécall exécute le code d'un contrat différent mais conserve le stockage, le contexte et le solde de l'appelant.

2. Il est souvent utilisé dans les modèles de proxy où la logique est séparée des données, permettant ainsi des contrats évolutifs.
3. Étant donné que les modifications d'état affectent le stockage du contrat appelant, une extrême prudence est requise lors de l'alignement des dispositions de stockage entre le proxy et l'implémentation.
4. Contrairement à call , aucun Ether n'est transféré lors d'un appel délégué à moins qu'il ne soit explicitement envoyé via des mécanismes supplémentaires.
5. Les risques de sécurité incluent des contrats de mise en œuvre malveillants modifiant des variables critiques telles que la propriété ou les soldes du proxy.

appel statique

1. staticcall est conçu pour invoquer des fonctions qui ne modifient pas l'état de la blockchain.

2. Toute tentative d'écriture dans le stockage, d'émission d'événements ou d'exécution d'opérations modifiant l'état entraînera l'annulation de l'appel.
3. Cette fonction est utile pour lire en toute sécurité les données des contrats externes sans risquer d'effets secondaires involontaires.
4. Comme call , il fonctionne dans le code du contrat cible mais applique un mode lecture seule lors de l'exécution.
5. Son principal cas d'utilisation consiste à interroger les soldes de jetons, à vérifier les allocations ou à récupérer des valeurs immuables à partir de contrats tiers.

Questions courantes

Que se passe-t-il si un appel de délégué cible un contrat avec une disposition de stockage incompatible ? Si les emplacements de stockage du contrat appelant ne correspondent pas à ceux attendus par la logique du contrat appelé, les variables peuvent être écrasées de manière incorrecte. Par exemple, une adresse stockée dans un emplacement peut être interprétée comme un uint256, entraînant des données corrompues ou un accès non autorisé.

staticcall peut-il être utilisé pour interagir avec des fonctions payantes ? Oui, staticcall peut cibler les fonctions payantes tant qu'elles ne modifient pas réellement l'état. Cependant, l'envoi d'Ether via un appel statique est redondant car les transferts de valeurs impliquent intrinsèquement des changements d'état et entraîneraient l'échec de l'appel.

Pourquoi l'appel est-il considéré comme plus risqué que l'appel statique dans certains scénarios ? Étant donné que l’appel permet à la fois les changements d’état et les transferts d’Ether, il ouvre des vecteurs d’attaque tels que les attaques de réentrée. Sans validation stricte des entrées et gestion des flux de contrôle, un contrat externe pourrait drainer des fonds de manière récursive lors d’un rappel.

Le déléguécall est-il compatible avec tous les types de mises à niveau de contrat ? Bien que déléguécall permette une évolutivité, il nécessite une conception minutieuse. Les collisions de stockage, les conflits de sélecteurs de fonctions et les problèmes d'initialisation peuvent interrompre les fonctionnalités. Les proxys transparents et les modèles UUPS aident à atténuer ces risques mais exigent des tests et des audits rigoureux.