*Forward the Original Title: Avant la mise à niveau de Cancún, quelques vérifications de sécurité indispensables pour les développeurs de projets

TL;DR: Avec l'approche de la mise à niveau de Cancun, celle-ci inclut six modifications proposées par l'EIP, principalement l'EIP-1153, l'EIP-4788, l'EIP-4844, l'EIP-5656, l'EIP-6780 et l'EIP-7516. L'EIP-4844 se concentre sur l'amélioration de la scalabilité d'Ethereum, la réduction des coûts de transaction et l'accélération des transactions pour les solutions de couche 2. La mise à niveau a été testée sur les testnets d'Ethereum et est prévue pour être activée sur le mainnet le 13 mars. Salus a compilé des considérations de sécurité importantes pour que les développeurs les vérifient avant la mise à niveau.

Examen des propositions EIP

Considérations officielles en matière de sécurité

Risques liés aux contrats intelligents

Lecture supplémentaire

Examen des propositions EIP

EIP-1153

L'EIP-1153 introduit des opcodes de stockage temporaire, qui sont utilisés pour manipuler l'état de manière similaire au stockage, mais avec le stockage temporaire étant jeté après chaque transaction. Cela signifie que le stockage temporaire ne désérialise pas les valeurs du stockage, ni ne sérialise les valeurs vers le stockage, ce qui entraîne des coûts plus bas en évitant l'accès au disque. Avec l'introduction de deux nouveaux opcodes, TLOAD et TSTORE (où “T” signifie “temporaire”), les contrats intelligents peuvent accéder au stockage temporaire. Cette proposition vise à fournir une solution dédiée et efficace pour la communication entre plusieurs cadres d'exécution imbriqués lors de l'exécution de transactions sur Ethereum.

EIP-4788

EIP-4788 vise à exposer les racines de l'arbre de hachage des blocs de la chaîne de balises à l'EVM, permettant à ces racines d'être accessibles au sein des contrats intelligents. Cela permet d'accéder à l'état de la couche de consensus sans confiance, en soutenant divers cas d'utilisation tels que les pools de mise, les structures de restaking, les ponts de contrats intelligents et l'atténuation de l'EMV. La proposition réalise cela en stockant ces racines dans un contrat intelligent et en utilisant un tampon circulaire pour limiter la consommation de stockage, en veillant à ce que chaque bloc d'exécution ne nécessite qu'un espace constant pour représenter cette information.

EIP-4844

EIP-4844 introduit un nouveau format de transaction appelé “Shard Blob Transactions” conçu pour étendre la disponibilité des données d'Ethereum de manière simple et rétrocompatible. Cette proposition atteint son objectif en introduisant des “transactions de transport de blob” contenant de grandes quantités de données qui ne peuvent pas être accédées par l'EVM, mais peuvent être accédées par leurs engagements. Ce format est entièrement compatible avec le format utilisé par le futur sharding complet, offrant un soulagement temporaire mais significatif pour la scalabilité du rollup.

EIP-5656

EIP-5656 introduit une nouvelle instruction EVM, MCOPY, pour une copie efficace des régions de mémoire. Cette proposition vise à réduire les frais généraux des opérations de copie de mémoire sur l'EVM en copiant directement des données entre les mémoires à l'aide de l'instruction MCOPY. MCOPY permet le chevauchement des adresses source et destination, conçu en gardant à l'esprit la compatibilité ascendante, et vise à améliorer l'efficacité d'exécution dans divers scénarios, y compris la construction de structures de données, l'accès efficace, et la copie d'objets en mémoire.

EIP-6780

EIP-6780 modifie la fonctionnalité de l'opcode SELFDESTRUCT. Dans cette proposition, SELFDESTRUCT supprime uniquement les comptes et transfère 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 transférera tout l'éther à une cible spécifiée. Ce changement prend en compte l'utilisation future des arbres Verkle, visant à simplifier l'implémentation de l'EVM, à réduire la complexité des changements d'état, tout en conservant certains cas d'utilisation courants de SELFDESTRUCT.

EIP-7516

L'EIP-7516 introduit une nouvelle instruction EVM, BLOBBASEFEE, pour retourner la valeur de frais de base pour les blobs dans l'exécution du bloc actuel. Cette instruction est similaire à l'opcode BASEFEE introduit dans l'EIP-3198, à la différence qu'elle retourne le frais de base du blob défini selon l'EIP-4844. Cette fonctionnalité permet aux contrats de considérer de manière programmatique le prix du gaz des données de blob, permettant aux contrats rollup de calculer les coûts d'utilisation des données de blob sans confiance ou de mettre en œuvre des contrats à terme sur le gaz de blob pour lisser les coûts des données de blob.

Considérations de sécurité officielles

EIP-1153

Les développeurs de contrats intelligents doivent comprendre le cycle de vie des variables de stockage temporaire avant de les utiliser. Étant donné que le stockage temporaire est automatiquement effacé à la fin d'une transaction, les développeurs de contrats intelligents pourraient tenter d'éviter de vider les emplacements lors d'un appel pour économiser du gaz. Cependant, cela pourrait empêcher toute interaction ultérieure avec le contrat dans la même transaction (par exemple, dans le cas de verrous réentrants) ou entraîner d'autres erreurs. Par conséquent, les développeurs de contrats intelligents doivent être prudents et ne conserver que des valeurs non nulles lorsque l'emplacement de stockage temporaire est réservé pour les appels futurs dans la même transaction. Sinon, le comportement de ces opcodes est identique à SLOAD et SSTORE, donc toutes les considérations de sécurité courantes s'appliquent, en particulier en ce qui concerne les risques de réentrance.

Les développeurs de contrats intelligents peuvent également tenter d'utiliser un stockage temporaire comme alternative à la cartographie mémoire. Ils doivent savoir que le stockage temporaire n'est pas supprimé comme la mémoire lorsque qu'un appel est renvoyé ou annulé et doivent donner la priorité à la mémoire dans de tels cas d'utilisation pour éviter un comportement inattendu lors de la réentrée dans la même transaction. Le coût élevé du stockage temporaire en mémoire devrait déjà dissuader ce modèle d'utilisation. La plupart des cas d'utilisation des mappages en mémoire peuvent être mieux implémentés à travers une liste triée d'entrées par clé, et le stockage temporaire dans les mappages en mémoire est rarement nécessaire dans les contrats intelligents (c'est-à-dire aucun cas d'utilisation connu en production).

EIP-4844

Cet EIP augmente les exigences de bande passante pour chaque bloc de phare jusqu'à environ 0,75 Mo. Il s'agit d'une augmentation de 40% par rapport à la taille maximale théorique des blocs d'aujourd'hui (30M Gas / 16 Gas par octet de calldata = 1,875M octets), donc cela n'augmente pas significativement la bande passante dans les scénarios les pires. Après fusion, les temps de bloc sont statiques plutôt que distribués de manière imprévisible selon la loi de Poisson, fournissant une période garantie pour la propagation des grands blocs.

Même avec des données d'appel limitées, la charge soutenue de cet EIP est significativement plus basse que les solutions alternatives qui pourraient réduire le coût des données d'appel car le stockage Blob n'a pas besoin d'être conservé pendant la même durée que la charge d'exécution. Cela rend possible la mise en place de stratégies nécessitant que ces blobs soient conservés pendant au moins une période de temps. La valeur spécifique choisie est l'époque MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS, qui est d'environ 18 jours, beaucoup plus courte que le temps de rotation d'un an proposé (mais non encore implémenté) pour l'exécution des historiques de charge utile valides.

EIP-5656

Les clients doivent être conscients que leurs implémentations n'utilisent pas de tampons intermédiaires (par exemple, la fonction memmove de la bibliothèque standard C 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 intégrées au langage / des fonctions de bibliothèque standard utilisées pour déplacer des octets ont les bonnes caractéristiques de performance ici.

De plus, l'analyse des attaques de déni de service (DoS) et d'épuisement de la mémoire est la même que pour les autres opcodes touchant la mémoire car l'expansion de la mémoire suit les mêmes règles de tarification.

EIP-6780

Les applications suivantes de SELFDESTRUCT seront rompues, et les applications l'utilisant de cette manière ne sont plus sécurisées :

Lorsque CREATE2 est utilisé pour redéployer un contrat au même emplacement afin de rendre les contrats évolutifs. Cette fonctionnalité n'est plus prise en charge et doit être remplacée par ERC-2535 ou d'autres types de contrats de procuration.

Si un contrat repose sur la combustion de l'éther à un contrat via SELFDESTRUCT en tant que bénéficiaire, le contrat n'est pas 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. Les contrats appelés utilisent ces opcodes.
2. Les contrats d'appel utilisent ces opcodes.

Risque 1:

Par rapport aux traditionnels SSTORE et SLOAD, l'introduction du stockage temporaire modifie principalement la durée de stockage des données. Les données stockées par TSTORE sont lues via TLOAD et seront libérées après l'exécution d'une transaction, plutôt que d'être enregistrées de manière permanente dans le contrat comme SSTORE. Les développeurs doivent comprendre les caractéristiques de ces opcodes lors de leur utilisation pour éviter de les utiliser de manière incorrecte, ce qui pourrait entraîner une écriture incorrecte des données dans le contrat, entraînant des pertes. De plus, les données stockées par TSTORE sont privées et ne peuvent être accédées que par le contrat lui-même. Si un accès externe à ces données est nécessaire, il doit être transmis par des paramètres ou temporairement stocké dans une variable de stockage public.

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 la suppression de données à des moments inappropriés ou une rétention incorrecte. Si un contrat s'attend à utiliser des données stockées dans le stockage transitoire lors d'appels ultérieurs d'une transaction mais échoue à gérer correctement le cycle de vie de ces données, il peut partager ou perdre des données entre différents appels de manière erronée, ce qui entraîne des erreurs logiques ou des vulnérabilités de sécurité. Ne pas stocker correctement les données, telles que les soldes ou les données d'autorisation dans les projets de jetons, peut entraîner des erreurs logiques dans les contrats, causant des pertes. De même, l'utilisation de ces opcodes pour définir l'adresse du propriétaire peut entraîner le fait que l'adresse privilégiée ne soit pas correctement enregistrée, entraînant la perte des modifications apportées aux paramètres importants du contrat.

Considérez un contrat intelligent qui utilise un stockage temporaire pour enregistrer temporairement le prix de la transaction sur une plateforme de trading de cryptomonnaies. Le contrat met à jour le prix après chaque transaction et permet aux utilisateurs de consulter le dernier prix dans un court laps de temps. Cependant, si la conception du contrat ne prend pas en compte la compensation automatique du stockage temporaire à la fin d'une transaction, il peut y avoir une période entre la fin d'une transaction et le début de la suivante où les utilisateurs peuvent recevoir un prix incorrect ou obsolète. Cela pourrait non seulement conduire les utilisateurs à prendre des décisions basées sur des informations incorrectes, mais aussi être exploité de manière malveillante, affectant la réputation de la plateforme et la sécurité des actifs des utilisateurs.

EIP-6780

Cette proposition modifie le comportement de l'opcode de selfdestruct précédent, où le contrat n'est pas brûlé mais seulement le transfert de jetons se produit, et seuls les contrats créés dans la même transaction que le contrat de selfdestruct seront brûlés. L'impact de cet EIP est relativement important.

L'utilisation de create2 pour redéployer des contrats à la même adresse pour des mises à niveau de contrat n'est plus prise en charge. Cette fonctionnalité devrait être remplacée par ERC-2535 ou d'autres types de contrats proxies. (Cela peut affecter la sécurité de contrats sur chaînemise en œuvre de contrats évolutifs en utilisant create2).

L'opération SELFDESTRUCT dans les contrats intelligents permet de brûler les contrats et d'envoyer le solde du contrat à une adresse cible spécifiée. Dans ce cas, le contrat utilise SELFDESTRUCT pour brûler de l'Ether et envoie l'Ether brûlé au contrat. Cependant, ce contrat ne doit être créé que dans la même transaction que d'autres contrats (contrats créés par ce contrat ou d'autres contrats dans la même transaction). Sinon, l'Ether sera uniquement transféré sans brûler le contrat (par exemple, selfdestruct avec le bénéficiaire étant le contrat selfdestruct, ce qui ne produira aucun changement). Cela affectera tous lescontratsqui reposent sur la fonction selfdestruct pour les retraits ou d'autres opérations.

Un jeton de gaz similaire au jeton CHI 1inch fonctionne comme suit : maintenir un décalage, déployer toujours CREATE2 ou SELFDESTRUCT à ce décalage. Après cette mise à jour, si le contrat au décalage actuel n'a pas été correctement auto-détruit, les déploiements CREATE2 ultérieurs ne pourront pas déployer de contrats avec succès.

Cette mise en œuvre de proposition ne peut pas attaquer directement les contrats, mais elle endommagera la logique normale des contrats existants qui reposent sur des opérations de self-destruction (les contrats qui ne reposent que sur la self-destruction pour les transferts de fonds ne sont pas affectés, mais les contrats qui nécessitent des opérations ultérieures pour supprimer les contrats de self-destruction sont affectés), provoquant un fonctionnement inattendu des contrats et pouvant entraîner des désaccords contractuels, une perte de fonds, etc. (par exemple, les contrats qui utilisaient initialement create2 pour déployer de nouveaux contrats à l'adresse d'origine et qui se sont auto-détruits pour la mise à niveau, ne peuvent plus être déployés avec succès). À long terme, la modification de la fonctionnalité d'un code opérationnel peut entraîner des problèmes de centralisation.

Par exemple, il existe un contrat de coffre existant pour les mises à jour :

• Les contrats de stockage temporaires, create2, sont utilisés pour réserver temporairement des fonds pour le coffre-fort.
• Autodétruisez le contrat de coffre-fort, transférez les fonds au contrat temporaire (seuls les fonds sont transférés sans brûler le contrat).
• Créez un nouveau contrat de coffre-fort à l'adresse d'origine en utilisant create2 (échoue car le contrat de coffre-fort d'origine n'a pas été brûlé).
• Auto-destructez le contrat temporaire pour retourner les fonds au coffre (fonds perdus, le contrat de coffre n'a pas été créé).

Lecture approfondie :

La mise à niveau de Cancun renforcera encore l'avantage concurrentiel d'Ethereum. Cependant, les modifications apportées à la couche de contrat intelligent de base dans cette mise à niveau comportent des risques qui affecteront le fonctionnement sécurisé des DApps existants. Lors du développement de contrats intelligents, ces changements et les risques potentiels qu'ils peuvent entraîner doivent être étroitement surveillés. Vous pouvez contacter Salus pour des vérifications de risque ou un soutien à l'audit, ou pour une lecture complémentaire afin de comprendre les changements.

Spécification de mise à niveau du réseau Cancun

EIP-1153

EIP-4788

EIP-4844

EIP-5656

EIP-6780

EIP-7516

Contrat Metapod

contrat GasToken2

Avertissement：

1. Cet article est repris de [ Aicoin]Transférer le titre original ‘Salus Insights：坎昆升级前，项目开发者必看的几项安全检查’. Tous les droits d'auteur appartiennent à l'auteur original [*Odaily Planète Quotidien]. Si vous avez des objections à cette réimpression, veuillez contacter le Gate Apprendreéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité: Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont réalisées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.