La mise à niveau de Cancun arrive bientôt, à quels points faut-il prêter attention et risques potentiels ?

Pour faire court : la mise à niveau de Cancún approche et cette mise à niveau contient principalement des modifications de couche exécutive proposées par six EIP, EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780 et EIP-7516. . EIP-4844 est le protagoniste de cette mise à niveau, qui vise à améliorer l'évolutivité d'Ethereum, à réduire les coûts de transaction et à augmenter la vitesse de transaction pour L2. La mise à niveau de Cancun a été achevée sur les réseaux de test Ethereum Goerli, Sepolia et Holesky respectivement les 17 janvier, 30 janvier et 7 février, et devrait être activée sur le réseau principal Ethereum le 13 mars. Avant la mise à niveau, Salus a compilé d'importantes précautions de sécurité pour cette mise à niveau que les développeurs peuvent vérifier par eux-mêmes.

Examen de la proposition EIP

EIP-1153

EIP-1153 introduit des opcodes de stockage temporaire, qui sont utilisés pour manipuler l'état et se comportent presque de la même manière que le stockage, mais le stockage temporaire sera supprimé après chaque transaction. Cela signifie que le stockage temporaire ne désérialise pas les valeurs du stockage ni ne les sérialise. Le stockage temporaire est donc moins coûteux car aucun accès au disque n'est requis. Les contrats intelligents peuvent accéder au stockage temporaire via deux nouveaux opcodes, TLOAD et TSTORE (où « T » signifie « temporaire »). Cette proposition vise à fournir une solution dédiée et efficace pour la communication entre plusieurs cadres d'exécution imbriqués dans l'exécution des transactions d'Ethereum.

EIP-4788

EIP-4788 est conçu pour exposer les racines de l'arbre de hachage des blocs de chaîne de balise à l'EVM afin de permettre l'accès à ces racines dans les contrats intelligents. Cela fournit un accès sans confiance à l'état de la couche de consensus, prenant en charge plusieurs cas d'utilisation tels que les pools de jalonnement, les structures de remise en jeu, les ponts de contrats intelligents, l'atténuation MEV, etc. La proposition stocke ces racines via un contrat intelligent et utilise un tampon en anneau pour limiter la consommation de stockage, garantissant que chaque bloc d'exécution ne nécessite qu'un espace constant pour représenter ces informations.

EIP-4844

EIP-4844 introduit un nouveau format de transaction appelé « transactions blob fragmentées » conçu pour étendre la disponibilité des données d'Ethereum d'une manière simple et compatible avec les versions ultérieures. Cette proposition fonctionne en introduisant des « transactions portant des objets blob » qui contiennent de grandes quantités de données auxquelles l'exécution de l'EVM ne peut pas accéder, mais qui peuvent accéder à ses engagements. Ce format est entièrement compatible avec le format utilisé par le partitionnement complet à l'avenir, offrant un soulagement temporaire mais significatif pour l'expansion continue.

EIP-5656

EIP-5656 introduit une nouvelle instruction EVM, MCOPY, conçue pour améliorer l'efficacité de la copie des zones mémoire. Cette proposition vise à réduire le coût des opérations de copie mémoire sur l'EVM et à copier directement les données entre mémoires via l'instruction MCOPY. MCOPY permet aux adresses source et cible de se chevaucher tout en prenant en compte la rétrocompatibilité, et vise à optimiser l'efficacité d'exécution dans divers scénarios tels que la construction de structures de données et l'accès et la copie efficaces des objets de mémoire.

EIP-6780

EIP-6780 Modification de la fonctionnalité de l'opcode SELFDESTRUCT. Dans cette proposition, SELFDESTRUCT supprimera uniquement le compte et transférera tout l'éther dans la même transaction que la création du contrat. De plus, lors de l'exécution de SELFDESTRUCT, le contrat ne sera pas supprimé, mais tout l'éther sera transféré vers la destination spécifiée. Ce changement vise à s'adapter à l'utilisation future des arbres Verkle, visant à simplifier la mise en œuvre d'EVM et à réduire la complexité des changements d'état, tout en conservant certains scénarios courants de SELFDESTRUCT.

EIP-7516

EIP-7516 introduit une nouvelle instruction EVM BLOBBASEFEE qui renvoie la valeur des frais de base du blob dans l'exécution du bloc en cours. Cette commande est similaire à l'opcode BASEFEE de EIP-3198, sauf qu'elle renvoie les frais de base du blob tels que définis dans EIP-4844. Cette fonctionnalité permet aux contrats de prendre en compte par programmation le prix du gaz des données blob, par exemple, permettant aux contrats de cumul de calculer en toute confiance les coûts d'utilisation des données blob, ou de mettre en œuvre des contrats à terme sur le gaz blob basés sur cela pour lisser les coûts des données blob.

Considérations de sécurité officiellement divulguées

EIP-1153

Les développeurs de contrats intelligents doivent comprendre le cycle de vie des variables de stockage transitoires avant utilisation. Étant donné que le stockage temporaire est automatiquement libéré à la fin d'une transaction, les développeurs de contrats intelligents peuvent essayer d'éviter de libérer des créneaux horaires pendant les appels pour économiser du gaz. Cependant, cela peut empêcher toute interaction ultérieure avec le contrat au sein de la même transaction (par exemple, dans le cas de verrous réentrants) ou provoquer d'autres erreurs. Les développeurs de contrats intelligents doivent donc veiller à réserver uniquement des emplacements de stockage non temporaires lorsqu'ils sont réservés. Valeur nulle. Destiné à être utilisé lors d’appels futurs au sein de la même transaction. Sinon, ces opcodes se comportent exactement comme SSTORE et SLOAD , donc toutes les considérations de sécurité habituelles s'appliquent, notamment en ce qui concerne les risques de réentrée.

Les développeurs de contrats intelligents peuvent également essayer d'utiliser le stockage transitoire comme alternative au mappage de mémoire. Ils doivent être conscients que le stockage temporaire n'est pas supprimé comme la mémoire lorsqu'un appel revient ou reprend, et la mémoire doit être préférée dans ces cas d'utilisation pour éviter un comportement inattendu lors de la réentrée au sein de la même transaction. Le coût du stockage transitoire sur mémoire est nécessairement élevé, ce qui aurait dû empêcher ce modèle d'utilisation. La plupart des utilisations du mappage en mémoire sont mieux mises en œuvre avec une liste d'entrées classées par clé, et le mappage en mémoire est rarement nécessaire dans les contrats intelligents (c'est-à-dire que les auteurs ne connaissent aucun cas d'utilisation connu en production).

EIP-4844

Cet EIP augmente les besoins en bande passante jusqu'à environ 0,75 Mo par bloc de balise. C'est 40 % plus grand que la taille maximale théorique des blocs actuels (30 M de gaz / 16 gaz par octet de données d'appel = 1,875 M d'octets), cela n'augmente donc pas de manière significative la bande passante dans le pire des cas. Après la fusion, les temps de bloc sont une distribution de Poisson statique plutôt qu'imprévisible, offrant une période de temps garantie pour la propagation de gros blocs.

Même avec des données d'appel limitées, la charge soutenue de cet EIP est bien inférieure à celle des alternatives qui réduisent le coût des données d'appel, car les blobs n'ont pas besoin d'être stockés tant que la charge est exécutée. Cela permet de mettre en œuvre une politique où ces blobs doivent être conservés pendant au moins un certain temps. La valeur spécifique choisie est l'époque MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS, qui est d'environ 18 jours, ce qui représente une latence beaucoup plus courte que la rotation d'un an recommandée (mais pas encore implémentée) pour l'exécution de l'historique de la charge utile.

EIP-5656

Les clients doivent être conscients que leurs implémentations n'utilisent pas de tampons intermédiaires (par exemple, la fonction C stdlibmemmove n'utilise pas de tampons intermédiaires) car il s'agit d'un vecteur potentiel de déni de service (DoS). La plupart des fonctions de bibliothèque intégrées/standard du langage pour le déplacement d'octets ont ici les bonnes caractéristiques de performances.

Par ailleurs, l'analyse des attaques par déni de service (DoS) et par épuisement de la mémoire est la même que pour les autres opcodes touchant la mémoire, car les extensions de mémoire suivent les mêmes règles de tarification.

EIP-6780

Les applications suivantes SELFDESTRUCT seront interrompues et les applications qui l'utilisent de cette manière ne sont plus sûres :

WhereCREATE2 est utilisé pour redéployer le contrat au même endroit afin de rendre le contrat évolutif. Cette fonctionnalité n'est plus prise en charge et l'ERC-2535 ou un autre type de contrat proxy doit être utilisé à la place.

Si un contrat repose sur la combustion d'éther en ayant un contrat d'AUTODESTRUCTION comme bénéficiaire, le contrat n'a pas été créé dans la même transaction.

Risques liés aux contrats intelligents

EIP1153

Considérez deux scénarios utilisant les opcodes TLOAD et TSTORE :

1. Le contrat appelé utilise cet opcode
2. Le contrat appelant utilise cet opcode

Risque 1 :

Comparé avec SSTORE et SLOAD traditionnels, le nouveau stockage transitoire modifie principalement la période de stockage des données. Les données stockées dans tstore sont lues via tload, et les données seront libérées après l'exécution d'une transaction. Le contrat écrit n'est pas enregistré de manière permanente comme sstore. . Les développeurs doivent reconnaître les caractéristiques de cet opcode lorsqu'ils l'utilisent pour éviter une utilisation incorrecte qui pourrait entraîner une mauvaise écriture des données dans le contrat et entraîner des pertes. De plus, les données du tstore sont des variables privées et ne sont accessibles que par le contrat lui-même. Si vous souhaitez utiliser les données en externe, vous pouvez uniquement les transmettre sous forme de paramètres ou les stocker temporairement dans une variable de stockage publique.

Risque 2 :

Un autre risque potentiel est que si les développeurs de contrats intelligents ne gèrent pas correctement le cycle de vie des variables de stockage transitoires, cela peut entraîner l'effacement des données alors qu'elles ne devraient pas l'être ou leur conservation incorrecte. Si un contrat prévoit d'utiliser des données stockées dans un stockage temporaire lors d'appels ultérieurs à une transaction, mais ne parvient pas à gérer correctement le cycle de vie de ces données, les données peuvent être partagées de manière incorrecte ou perdues entre les appels, entraînant des erreurs logiques ou des vulnérabilités de sécurité. Étant donné que les données de solde ou d'allocation similaires à celles du projet Token ne peuvent pas être stockées correctement, cela entraînera des erreurs dans la logique du contrat et entraînera des pertes. Ou bien l'utilisation de cet opcode lors de la définition de l'adresse du propriétaire entraînera un enregistrement incorrect de l'adresse privilégiée et donc la perte de la modification de paramètres importants du contrat.

Considérez un contrat intelligent qui utilise le stockage transitoire pour enregistrer temporairement les prix des transactions sur un échange de crypto-monnaie. Le contrat met à jour le prix lorsque chaque transaction est terminée et permet aux utilisateurs de consulter le dernier prix pendant une courte période de temps. Cependant, si la conception du contrat ne prend pas en compte la fonctionnalité selon laquelle le stockage transitoire est automatiquement effacé à la fin d'une transaction, les utilisateurs peuvent alors obtenir une transaction incorrecte ou obsolète pendant la période allant de la fin d'une transaction au début de la suivante. prix de transaction. Cela peut non seulement amener les utilisateurs à prendre des décisions basées sur des informations erronées, mais peut également être utilisé de manière malveillante, affectant la crédibilité de la plateforme et la sécurité des actifs des utilisateurs.

EIP-6780

Cette proposition modifie le comportement de l'opcode d'autodestruction précédent. Le contrat n'est pas détruit, seul le jeton est transféré. Seuls les contrats créés dans la même transaction que l'autodestruction seront détruits. L’impact de cet EIP est relativement important.

Utilisez create2 pour redéployer le contrat à la même adresse afin de mettre à niveau le contrat. Cette fonctionnalité n'est plus prise en charge et l'ERC-2535 ou un autre type de contrat proxy doit être utilisé à la place. (Cela peut affecter la sécurité des contrats en chaîne utilisant create2 pour implémenter des contrats évolutifs)

L'opération SELFDESTRUCT dans un contrat intelligent permet de détruire le contrat et d'envoyer le solde du contrat à l'adresse cible spécifiée. Dans ce cas, le contrat utilise SELFDESTRUCT pour détruire l'éther et envoie l'éther détruit au contrat. Mais le contrat ne peut être qu'un contrat créé dans la même transaction (un contrat créé par ce contrat ou d'autres contrats dans la même transaction). Sinon, seul l'éther sera transféré sans détruire le contrat (par exemple, autodestruction et le bénéficiaire est le contrat autodestructeur, ce qui ne produira aucun changement). Cela affectera tous les contrats qui reposent sur l’autodestruction pour les retraits ou autres opérations.

Un jeton de gaz similaire au jeton CHI de 1 pouce fonctionne en maintenant un décalage et en exécutant toujours CREATE2 ou SELFDESTRUCT à ce décalage. Après cette mise à jour, si le contrat au décalage actuel ne s'est pas correctement autodétruit, CREATE2 ultérieur ne pourra pas déployer avec succès le contrat.

La mise en œuvre de cette proposition ne conduira pas à des attaques directes contre le contrat, mais nuira à la logique normale des contrats initialement déployés qui reposent sur des opérations d'autodestruction (les contrats qui reposent uniquement sur l'autodestruction pour le transfert de fonds ne seront pas affectés. Si les opérations ultérieures doivent nécessiter une autodestruction. Si le contrat détruit est supprimé, il sera affecté), provoquant un fonctionnement inattendu du contrat Uniquement pour le contrat et l'utilisateur, cela peut entraîner la grève du contrat, la perte de fonds et d'autres dangers (. par exemple, en utilisant à l'origine create2 pour déployer un nouveau contrat à l'adresse d'origine, autodétruisant le contrat d'origine (le contrat mis à niveau ne peut plus être déployé avec succès). À long terme, modifier la fonctionnalité d'un opcode peut entraîner des problèmes de centralisation.

Par exemple, un coffre-fort de contrat de trésorerie existant est mis à jour :

• créer 2 contrats de stockage temporaire est utilisé pour réserver temporairement des fonds dans le coffre-fort
• Autodétruire le contrat de coffre-fort et les fonds sont transférés vers le contrat temporaire (seul le les fonds sont transférés sans détruire le contrat)
• Créer 2 nouveaux contrats de coffre-fort à l'adresse d'origine (échec car le contrat de coffre-fort d'origine n'a pas été détruit)
• Le contrat temporaire autodestructeur renvoie les fonds dans le coffre-fort (les fonds sont perdus, le coffre-fort le contrat n'est pas créé)

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!