Comment fonctionne le stockage en baie dans Solidity et quels sont ses coûts ?

Comprendre le stockage sur baie dans Solidity

1. Les tableaux dans Solidity sont stockés dans un stockage sous contrat, qui est persistant dans les appels de fonction et les transactions. Lorsqu'un tableau dynamique est déclaré, tel que uint[] public values ​​, l'emplacement attribué au tableau ne contient que la longueur du tableau. Les éléments de données réels sont stockés dans un hachage keccak256 du numéro d'emplacement de la baie, permettant un mappage d'emplacement sécurisé et déterministe.

2. Chaque élément du tableau est placé dans un emplacement de stockage dérivé de la formule : keccak256(slot) + index . Ce mécanisme garantit que même si plusieurs tableaux existent dans un contrat, leurs données n'entrent pas en collision. Étant donné que le stockage Ethereum est aligné sur 256 bits, chaque emplacement peut contenir un uint256 complet ou une valeur de taille équivalente. Les types plus grands peuvent s'étendre sur plusieurs emplacements.

3. Pour les tableaux de taille fixe, le compilateur réserve des emplacements de stockage consécutifs à partir de la position déclarée de la variable. Un tableau fixe comme les identifiants uint[3] utilise exactement trois emplacements adjacents. Aucune métadonnée telle que la longueur n'est stockée puisque la taille est connue au moment de la compilation, ce qui rend l'accès plus direct et légèrement moins cher en termes de gaz.

4. Les tableaux imbriqués augmentent considérablement la complexité. Un tableau dynamique bidimensionnel calcule l'emplacement de base à l'aide de la même méthode de hachage, puis applique des décalages basés sur les indices internes du tableau. Les modèles d'accès deviennent plus coûteux en raison des multiples niveaux de hachage et de l'augmentation des opérations SLOAD lors des lectures ou des écritures.

5. Regrouper les valeurs dans des structures ou utiliser des types entiers plus petits (par exemple, uint128 au lieu de uint256) lorsque cela est possible permet à plusieurs variables de tenir dans un seul emplacement de stockage. Cela réduit le nombre total d'emplacements utilisés et diminue les coûts de gaz pour le déploiement et les modifications d'état impliquant ces variables.

Coûts du gaz associés aux opérations des baies

1. L'ajout à un tableau dynamique via push() entraîne un coût qui varie selon que l'élément ajouté est nul ou non nul. Si la valeur stockée est différente de zéro, cela entraîne une opération SSTORE avec un coût en gaz de 20 000 lors de la définition d'un emplacement précédemment vide. Les écrasements ultérieurs de valeurs non nulles coûtent 5 000 gaz selon les règles EIP-1283, en supposant que l'emplacement contient déjà des données.

2. La lecture d'un élément d'un tableau déclenche une opération SLOAD, coûtant 2 100 gaz par accès. Les itérations fréquentes sur de grands tableaux doivent être évitées dans la logique en chaîne, car chaque lecture multiplie ce coût de base. Les services d'indexation hors chaîne sont mieux adaptés à la récupération d'ensembles de données complets.

3. La suppression d'éléments n'est pas intrinsèquement prise en charge pour les tableaux dynamiques, sauf si le décalage manuel est implémenté. L'appel de pop() supprime le dernier élément et rembourse 15 000 gaz lors de la libération d'un emplacement de stockage, incitant ainsi au nettoyage de l'état inutilisé. Cependant, supprimer des éléments du milieu nécessite de déplacer tous les éléments suivants, ce qui conduit à un calcul O(n) et à une consommation de gaz élevée.

4. L'initialisation de grandes baies lors de la création du contrat augmente considérablement les coûts de déploiement. Chaque valeur prédéfinie consomme du gaz d'initialisation du stockage. Il est souvent plus efficace d'initialiser des tableaux vides et de les remplir progressivement grâce aux interactions des utilisateurs, en répartissant le coût sur plusieurs transactions.

5. Les matrices de mémoire utilisées temporairement dans les fonctions n'écrivent pas sur le stockage persistant et évitent ainsi entièrement les coûts de STOCKE. Ceux-ci sont idéaux pour les calculs intermédiaires mais ne peuvent pas conserver les données au-delà du périmètre de la transaction. L’utilisation de matrices de mémoire pour le traitement par lots avant d’écrire les résultats sélectifs dans le stockage optimise l’efficacité globale.

Techniques d'optimisation pour une utilisation efficace des baies

1. Préférez les mappages aux tableaux lorsqu'un accès aléatoire par clé est nécessaire. Un mappage tel que mapping(uint => address) fournit des recherches à temps constant sans la surcharge d'itération ou de gestion de la longueur. Les mappages éliminent également les problèmes liés aux limites d'index et au redimensionnement.

2. Utilisez delete avec parcimonie sur les éléments individuels du tableau. Mettre manuellement un élément à zéro peut s'avérer moins coûteux que de recourir à la suppression, en particulier lorsqu'aucun remboursement ne s'applique. Pour un nettoyage complet, appeler pop() à plusieurs reprises jusqu'à ce que la baie soit vide maximise les remboursements de gaz des emplacements de stockage libérés.

3. Limitez l’exposition en chaîne du contenu du tableau. L'émission d'événements avec des données de tableau permet aux systèmes externes de reconstruire l'état sans lire directement à partir du stockage. Les événements coûtent moins cher que les écritures de stockage permanent et prennent en charge le filtrage via des paramètres indexés.

4. Implémentez des modèles de points de contrôle ou de liste chaînée pour les charges de travail lourdes en ajout. En stockant uniquement les deltas ou les références entre les entrées, les contrats réduisent le stockage de données redondant et minimisent les réorganisations coûteuses. Cette approche fonctionne bien pour suivre les états historiques ou les journaux d’activité des utilisateurs.

5. Tirez parti des optimisations au niveau de l’assemblage avec prudence. Le code Yul en ligne peut calculer les emplacements de stockage plus rapidement que les constructions Solidity de haut niveau, mais introduit des risques d'adressage incorrect. Seuls les développeurs avancés doivent tenter une manipulation de stockage de bas niveau, garantissant ainsi des tests approfondis sur différentes versions du compilateur.

Foire aux questions

Que se passe-t-il lorsque vous accédez à un index de tableau hors limites ? L'accès à un index en dehors de la longueur actuelle du tableau déclenche un opcode invalide, consommant tout le gaz restant et annulant la transaction. La vérification des limites doit être gérée explicitement dans le code avant l'accès.

Les tableaux peuvent-ils être transmis entre contrats comme arguments ? Oui, les tableaux peuvent être transmis dans les appels de fonctions internes et externes. Les tableaux Calldata sont efficaces pour les entrées volumineuses car ils évitent la copie en mémoire. Les interfaces externes nécessitent un codage ABI, prenant en charge les types statiques et dynamiques.

Y a-t-il une limite à la taille d’un tableau dynamique ? La limite théorique est limitée par les limites de gaz disponible et de taille de bloc. Les contraintes pratiques incluent le coût croissant de l’ajout et de l’itération. Les contrats risquent d’atteindre les limites de transaction lors de la gestion de tableaux en chaîne excessivement grands.

Les déclarations de tableaux vides consomment-elles de l'espace de stockage ? Déclarer un tableau sans l'initialiser met sa longueur à zéro et occupe un emplacement de stockage. Aucun emplacement supplémentaire n'est alloué jusqu'à ce que des éléments soient ajoutés. Cet encombrement minimal rend les baies non initialisées rentables pour une population différée.