Pour faire court : la mise à niveau de Cancún approche. 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.
EIP-1153 introduit des opcodes de stockage temporaire, ces opcodes sont utilisés pour faire fonctionner l'état, leur comportement est presque le même que celui du stockage, mais le stockage temporaire sera supprimé après chaque transaction jeter. 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ù le « 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 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 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 introduit une nouvelle instruction EVM, MCOPY, conçue pour améliorer l'efficacité de la copie des zones mémoire. Le but de cette proposition est de réduire le coût d'exécution des opérations de copie de mémoire sur l'EVM et de réaliser une copie directe des données de mémoire via l'instruction MCOPY. MCOPY permet aux adresses source et cible de se chevaucher tout en prenant en compte la rétrocompatibilité, dans le but d'améliorer l'efficacité d'exécution dans divers scénarios tels que la construction de structures de données, l'accès aux objets mémoire et la copie.
EIP-6780 Modifie la fonctionnalité de l'opcode SELFDESTRUCT. Dans cette proposition, SELFDESTRUCT supprimera uniquement le compte et transférera toutes les pièces d'é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 toutes les pièces d'éther seront transférées 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 introduit une nouvelle instruction EVM BLOBBASEFEE, qui est utilisée pour renvoyer la valeur des frais de base du blob dans l'exécution du bloc en cours. Cette instruction est similaire à l'opcode BASEFEE dans 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 sur cette base pour lisser les coûts des données blob.
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. SSTORE Sinon, ces opcodes se comportent exactement comme SLOAD 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. Les coûts de stockage transitoire sur la mémoire sont forcément élevés, ce qui aurait dû décourager 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).
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 est un délai beaucoup plus court par rapport à la rotation d'un an recommandée (mais pas encore mise en œuvre) pour l'exécution de l'historique de la charge utile.
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 caractéristiques de performances correctes.
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.
L'application suivante SELFDESTRUCT sera interrompue 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'Ether en ayant le contrat SELFDESTRUCT comme bénéficiaire, le contrat n'a pas été créé dans la même transaction.
Considérez deux scénarios utilisant les opcodes TLOAD et TSTORE :
Le contrat appelé utilise cet opcode
Le contrat appelant utilise cet opcode
Risques 1 :
Par rapport au SSTORE et au 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, au lieu d'écrire le contrat. être enregistré en permanence comme en magasin. 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 au 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.
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 le 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, s'il s'autodétruit et que le bénéficiaire est le contrat autodestructeur, cela n'entraînera 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éer2 contrat de stockage temporaire est utilisé pour réserver temporairement des fonds dans le coffre-fort
Autodestruction du contrat de coffre-fort et les fonds sont transférés vers le contrat temporaire (seuls 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)
Autodétruire le contrat temporaire et restituer les fonds à le coffre-fort (les fonds sont perdus, le contrat de coffre-fort n'est pas créé)
La mise à niveau de Cancun renforcera encore l'avantage concurrentiel d'Ethereum. Cependant, cette mise à niveau comporte des risques concernant les modifications apportées à la couche principale des contrats intelligents, ce qui affectera le fonctionnement sûr des DApps existantes. Lors du développement des contrats intelligents, ces changements et les risques qu’ils peuvent engendrer nécessitent également une grande attention. Vous pouvez contacter Salus pour une évaluation des risques ou une assistance en matière d'audit, ou poursuivre votre lecture pour en savoir plus sur les changements.
Spécifications de mise à niveau du réseau de Cancun
EIP-1153
EIP-4788
EIP-4844
EIP-5656
EIP-6780
EIP-7516
Contrat métapode
Contrat GasToken2
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!
Plateforme formelle de trading de devises numériques
Qu'est-ce que la crypto-monnaie kol
La pièce la plus prometteuse en 2024
Jusqu'où ira Ethereum ?
Cotations de prix Ethereum
Prix du marché d'Ethereum aujourd'hui
Découvrez les dix principales crypto-monnaies dans lesquelles il vaut la peine d'investir
Pourquoi ne puis-je pas accéder au navigateur Ethereum ?
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
