Comment un contrat intelligent stocke-t-il les données et quelle est la différence entre le stockage, la mémoire et les données d'appel ?

Comment les contrats intelligents stockent les données sur la blockchain

1. Les contrats intelligents sur les plateformes blockchain comme Ethereum utilisent un registre décentralisé pour maintenir les changements d'état et stocker les données en permanence. Chaque fois qu'une fonction contractuelle modifie une variable, cette modification est enregistrée sur tous les nœuds du réseau. Cela garantit la transparence et l’immuabilité. Les données stockées dans un contrat intelligent persistent au-delà des transactions individuelles et restent accessibles aussi longtemps que le contrat existe.

2. Le stockage des données dans les contrats intelligents s'effectue via des variables déclarées au niveau du contrat. Ces variables sont enregistrées dans ce que l'on appelle le « stockage », qui fait partie de l'architecture de la machine virtuelle Ethereum (EVM). Chaque contrat dispose de son propre espace de stockage dédié, dont la modification est persistante et coûteuse en raison des coûts du gaz. Lorsqu'une transaction met à jour une variable d'état, les mineurs valident le changement et l'écrivent dans le fichier d'état de la blockchain.

3. L'EVM traite le stockage comme un grand magasin clé-valeur où chaque emplacement contient 32 octets. Les variables sont regroupées efficacement pour minimiser l'utilisation de l'espace. Par exemple, plusieurs valeurs booléennes peuvent être stockées dans un seul emplacement. Les développeurs doivent être prudents dans la manière dont ils déclarent les variables, car un emballage inefficace augmente la consommation de gaz.

4. La lecture et l'écriture sur le stockage entraînent des coûts de gaz différents. Les opérations d'écriture coûtent beaucoup plus cher que la lecture, et l'initialisation d'une valeur non nulle coûte plus cher que la mise à zéro. Une fois les données écrites, elles ne peuvent pas être entièrement supprimées ; au lieu de cela, fixer une valeur à zéro rembourse une partie du gaz, incitant les développeurs à nettoyer les données inutilisées.

Différences entre le stockage, la mémoire et les données d'appel

1. Le stockage fait référence à la zone de données permanente associée à un contrat, où sont conservées les variables d'état. Il est persistant dans les appels de fonction et les transactions. Toute variable déclarée en dehors des fonctions, telle que uint balance ou mapping(address => bool) whitelist, réside dans le stockage par défaut. L'accès au stockage est lent et coûteux en raison de sa permanence et de sa réplication globale.

2. La mémoire est un espace temporaire utilisé pour conserver les données pendant l'exécution d'une fonction. Il est effacé une fois l'appel de fonction terminé et est idéal pour les variables locales et les types complexes tels que les tableaux ou les structures utilisés dans une fonction. Contrairement au stockage, la mémoire est moins coûteuse à accéder mais ne conserve pas les données entre les appels. Les chaînes, les tableaux dynamiques et les arguments de fonction résident souvent ici, sauf indication contraire explicite.

3. Calldata est une zone spéciale en lecture seule où les arguments de fonction sont stockés, en particulier pour les appels de fonction externes. Il évite de copier des données en mémoire, ce qui le rend efficace pour les entrées volumineuses telles que les tableaux d'octets transmis à des fonctions publiques ou externes. Étant donné que les données d'appel ne peuvent pas être modifiées, elles ne conviennent qu'aux paramètres d'entrée qui n'ont pas besoin d'être modifiés pendant l'exécution.

4. Le mot-clé location dans Solidity, tel que stockage, mémoire ou données d'appel, doit être spécifié lorsqu'il s'agit de types de référence tels que des tableaux, des chaînes et des structures. Une mauvaise utilisation peut entraîner des copies inutiles, une augmentation des frais de gaz ou des erreurs d'exécution. Par exemple, transmettre un grand tableau à une fonction sans utiliser les données d'appel le charge inutilement en mémoire, augmentant ainsi la surcharge de calcul.

Implications de l'emplacement des données dans la conception des fonctions

1. Lors de la conception de fonctions, le choix du bon emplacement des données affecte à la fois les performances et les coûts. Les fonctions externes acceptant des charges utiles volumineuses doivent déclarer les paramètres comme données d'appel pour éviter l'allocation de mémoire. Cette optimisation réduit la consommation de gaz et améliore l'évolutivité, en particulier pour les contrats traitant d'opérations groupées telles que les transferts de jetons ou les enregistrements par lots.

2. Les fonctions internes et privées ne peuvent pas utiliser les données d'appel puisqu'elles ne sont pas appelées en externe. Au lieu de cela, ils s'appuient sur la mémoire ou le stockage selon que les données doivent persister ou non. Le calcul local impliquant des structures temporaires bénéficie de la vitesse de la mémoire tout en évitant le coût élevé des écritures de stockage.

3. Une attribution incorrecte de types de référence peut créer un comportement inattendu. Déclarer une variable locale comme stockage et l'attribuer à une variable d'état crée un alias plutôt qu'une copie. La modification de la variable locale modifiera directement l'état d'origine, ce qui peut être souhaitable dans certains cas mais dangereux si cela est effectué involontairement.

4. Les opérations complexes telles que le tri ou le filtrage doivent s'effectuer sur les copies de mémoire, sauf si une manipulation directe de l'état est requise. La création d'un instantané de mémoire d'une matrice de stockage permet une transformation sûre sans risquer des changements d'état incohérents en cours d'exécution. Après traitement, les résultats peuvent être réécrits dans le stockage si nécessaire.

Foire aux questions

Que se passe-t-il si j'essaie de modifier les données dans calldata ? Toute tentative de modification des données situées dans calldata entraîne une erreur de compilation. Calldata est strictement en lecture seule, conçu pour contenir les paramètres d'entrée pour les appels de fonctions externes sans autoriser la mutation pendant l'exécution.

Les données de la mémoire peuvent-elles être accessibles par d'autres fonctions dans la même transaction ? Non, la mémoire est isolée de la fonction en cours d'exécution. Même au sein de la même transaction, chaque appel de fonction obtient son propre espace mémoire. Cependant, les changements d'état apportés au stockage lors d'un appel de fonction sont visibles pour les appels suivants dans la même transaction.

Pourquoi ne puis-je pas renvoyer une valeur directement depuis le stockage sans la copier en mémoire ? Lors du renvoi de types complexes tels que des tableaux ou des chaînes, l'EVM exige qu'ils soient placés en mémoire avant d'être inclus dans la réponse. Le stockage ne peut pas être directement sérialisé pour les valeurs de retour ; ainsi, une copie temporaire en mémoire est nécessaire même si la source est une variable d'état.

Y a-t-il une limite à la quantité de données que je peux stocker dans calldata ? Bien qu'il n'y ait pas de limite de taille fixe définie dans la spécification EVM, les contraintes pratiques proviennent des limites de gaz de bloc. Des données d'appel excessivement volumineuses peuvent rendre les transactions trop coûteuses à inclure dans un bloc, limitant ainsi la taille utilisable en fonction des conditions actuelles du réseau et des prix du gaz.