Quelles sont les précautions à prendre et les risques potentiels à l'approche de la mise à niveau de Cancun ?
TechFlow SélectionTechFlow Sélection
Quelles sont les précautions à prendre et les risques potentiels à l'approche de la mise à niveau de Cancun ?
La mise à niveau de Cancun a été déployée sur les réseaux test Goerli, Sepolia et Holesky d'Ethereum respectivement les 17 janvier, 30 janvier et 7 février, et est prévue pour être activée sur le réseau principal d'Ethereum le 13 mars.
Dédié à des analyses Web3 approfondiesRédaction : Salus Insights
En résumé : la mise à niveau de Cancun approche. Cette mise à jour comprend principalement six modifications au niveau d'exécution proposées par des EIP : EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780 et EIP-7516. L’EIP-4844 est le protagoniste de cette mise à niveau, visant à améliorer l'évolutivité d'Ethereum, à réduire les coûts des transactions et à accélérer leur traitement pour les L2. La mise à jour de Cancun a déjà été déployée sur les réseaux de test Goerli, Sepolia et Holesky d’Ethereum respectivement les 17 janvier, 30 janvier et 7 février, et devrait être activée sur le réseau principal d’Ethereum le 13 mars. Avant cette mise à jour, Salus a compilé les principales précautions de sécurité à prendre en compte, destinées aux développeurs.
Revue des propositions EIP
EIP-1153
L’EIP-1153 introduit des opcodes de stockage temporaire permettant de manipuler l’état de manière similaire au stockage classique, mais dont les données sont effacées à la fin de chaque transaction. Contrairement au stockage persistant, ces données ne sont ni désérialisées depuis ni sérialisées vers le disque, ce qui réduit les coûts grâce à l’élimination des accès disque. Deux nouveaux opcodes, TLOAD et TSTORE (« T » pour « temporaire »), permettent aux contrats intelligents d’accéder à ce stockage temporaire. Cette proposition vise à fournir une solution efficace et spécialisée pour les communications entre plusieurs cadres d’exécution imbriqués lors de l’exécution des transactions sur Ethereum.
EIP-4788
L’EIP-4788 expose dans la machine virtuelle Ethereum (EVM) la racine de l’arbre de hachage des blocs de la Beacon Chain, permettant aux contrats intelligents d’y accéder directement. Cela rend possible un accès fiable à l’état de la couche de consensus, soutenant divers cas d’usage comme les pools de staking, le restaking, les ponts de contrats intelligents ou encore l’atténuation du MEV. La proposition implémente un contrat intelligent stockant ces racines, utilisant un tampon circulaire afin de limiter la consommation de mémoire, garantissant ainsi qu’une quantité constante d’espace suffit pour représenter ces informations par bloc exécuté.
EIP-4844
L’EIP-4844 introduit un nouveau format de transaction appelé « transaction blob fragmentée », conçu pour étendre simplement et de manière compatible avec les évolutions futures la disponibilité des données sur Ethereum. Cette proposition ajoute des « transactions portant des blobs », contenant de grandes quantités de données inaccessibles à l’exécution par l’EVM, mais dont l’engagement peut être consulté. Ce format est entièrement compatible avec celui prévu pour le futur sharding complet, offrant une solution temporaire mais significative pour soulager les problèmes de montée en charge via les rollups.
EIP-5656
L’EIP-5656 introduit une nouvelle instruction EVM, MCOPY, destinée à copier efficacement des zones de mémoire. Cette proposition vise à réduire les frais liés aux opérations de copie en mémoire sur l’EVM, en permettant une copie directe via l’instruction MCOPY. Cette dernière autorise le chevauchement entre les adresses source et cible, tout en assurant la compatibilité ascendante, et cherche à améliorer l’efficacité dans des scénarios variés tels que la construction de structures de données ou l’accès et la duplication rapides d’objets en mémoire.
EIP-6780
L’EIP-6780 modifie le comportement de l’opcode SELFDESTRUCT. Selon cette proposition, SELFDESTRUCT supprime effectivement le compte et transfère tous les ether uniquement si l’appel se produit dans la même transaction que celle ayant créé le contrat. Dans les autres cas, l’exécution de SELFDESTRUCT ne supprime pas le contrat, mais transfère simplement tous les ether vers l’adresse cible. Ce changement vise à s’adapter à l’utilisation future des arbres de Verkle, simplifiant ainsi l’implémentation de l’EVM, réduisant la complexité des modifications d’état, tout en conservant certains cas d’usage courants de SELFDESTRUCT.
EIP-7516
L’EIP-7516 introduit une nouvelle instruction EVM, BLOBBASEFEE, qui renvoie la valeur actuelle des frais de base pour les blobs dans le bloc en cours d’exécution. Similaire à l’opcode BASEFEE défini dans l’EIP-3198, cette instruction retourne spécifiquement les frais de base associés aux blobs selon la définition de l’EIP-4844. Cette fonctionnalité permet aux contrats de prendre en compte programmatiquement le prix du gaz pour les données blob, par exemple en permettant aux contrats rollup de calculer sans confiance le coût d’utilisation des données blob, ou d’implémenter des marchés à terme sur le gaz blob afin d’en lisser le coût.
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 de chaque transaction, certains développeurs pourraient chercher à éviter l’effacement des emplacements afin d’économiser du gaz pendant les appels. Toutefois, cela pourrait empêcher toute interaction ultérieure avec le contrat au sein de la même transaction (par exemple, dans le cas d’un verrou anti-reentrance) ou provoquer d’autres erreurs. Les développeurs doivent donc faire attention à ne conserver des valeurs non nulles dans les emplacements temporaires que si elles doivent être utilisées par des appels futurs dans la même transaction. En dehors de cela, le comportement de ces opcodes est identique à SSTORE et SLOAD, donc toutes les précautions de sécurité classiques s’appliquent, notamment en ce qui concerne les risques de réentrance.
Les développeurs pourraient aussi envisager d’utiliser le stockage temporaire comme alternative à la mémoire. Ils doivent savoir que, contrairement à la mémoire, le stockage temporaire n’est pas effacé lors du retour ou du rollback d’un appel, et que la mémoire doit être privilégiée dans ces cas pour éviter des comportements imprévus lors d’une réentrance au sein de la même transaction. Le coût élevé du stockage temporaire par rapport à la mémoire devrait déjà décourager cet usage. La plupart des cas d’utilisation de mappages en mémoire peuvent être mieux réalisés par des listes d’éléments triés par clé, et les mappages en mémoire sont rarement nécessaires dans les contrats intelligents (l’auteur précise qu’il n’existe aucun cas connu en production).
EIP-4844
Cet EIP augmente d’environ 0,75 Mo le besoin de bande passante par bloc de la Beacon Chain. Cela représente 40 % de plus que la taille théorique maximale actuelle des blocs (30M gas / 16 gas par octet de calldata = 1,875M octets), donc l’impact sur la bande passante dans le pire des cas reste limité. Après la fusion, le temps de bloc est désormais fixe, et non une distribution de Poisson imprévisible, ce qui garantit une période stable pour la propagation des grands blocs.
Même avec une utilisation limitée des données d’appel, la charge continue induite par cet EIP est bien inférieure à celle d’autres solutions visant à réduire les coûts de calldata, car les blobs n’ont pas besoin d’être conservés aussi longtemps que la charge d’exécution. Cela permet de mettre en œuvre une stratégie de conservation minimale pour les blobs. La valeur choisie est MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS, soit environ 18 jours, beaucoup plus courte que la rotation annuelle suggérée (mais non encore implémentée) pour l’historique des charges d’exécution.
EIP-5656
Les clients doivent veiller à ce que leur implémentation n’utilise pas de tampon intermédiaire (par exemple, la fonction memmove de la bibliothèque standard C n’en utilise pas), car cela constituerait un vecteur potentiel de déni de service (DoS). La plupart des fonctions intégrées ou de bibliothèques standard des langages pour déplacer des octets présentent ici les caractéristiques de performance correctes.
Par ailleurs, l’analyse contre les attaques de type déni de service (DoS) ou d’épuisement de mémoire est similaire à celle des autres opcodes manipulant la mémoire, car l’expansion de la mémoire suit les mêmes règles tarifaires.
EIP-6780
Les applications suivantes utilisant SELFDESTRUCT seront compromises, et il ne sera plus sûr d’utiliser SELFDESTRUCT de cette manière :
Lorsque CREATE2 est utilisé pour redéployer un contrat à la même adresse afin de le rendre mis à jour. Cette fonctionnalité n’est plus prise en charge et doit être remplacée par ERC-2535 ou d’autres types de contrats proxy.
Si un contrat repose sur la combustion d’ether via SELFDESTRUCT où le bénéficiaire est un contrat qui n’a pas été créé dans la même transaction.
Risques liés aux contrats intelligents
EIP-1153
Deux scénarios d’utilisation des opcodes TLOAD et TSTORE peuvent être envisagés :
-
Le contrat appelé utilise ces opcodes
-
Le contrat initiateur de l’appel utilise ces opcodes
Risque 1 :
Comparé aux opcodes traditionnels SSTORE et SLOAD, le nouveau stockage temporaire change principalement la durée de conservation des données : les données écrites via TSTORE sont lues via TLOAD, mais sont libérées à la fin de la transaction, au lieu d’être gravées durablement dans le contrat comme avec SSTORE. Les développeurs doivent bien comprendre cette particularité pour éviter des erreurs d’utilisation entraînant une écriture incorrecte des données et des pertes. Par ailleurs, les données TSTORE sont des variables privées, accessibles uniquement par le contrat lui-même. Pour qu’elles soient utilisées en externe, elles doivent être transmises via des paramètres ou temporairement stockées dans une variable publique.
Risque 2 :
Un autre risque potentiel est que, si les développeurs ne gèrent pas correctement le cycle de vie des variables de stockage temporaire, les données pourraient être effacées prématurément ou conservées indûment. Si un contrat attend d'utiliser des données stockées temporairement lors d'appels ultérieurs dans la même transaction, mais ne gère pas correctement leur cycle de vie, cela pourrait entraîner un partage ou une perte inappropriée de données entre différents appels, provoquant des erreurs logiques ou des failles de sécurité. Par exemple, si les données de solde ou d’autorisation (allowance) d’un projet de token ne sont pas correctement stockées, cela pourrait fausser la logique du contrat et causer des pertes. De même, utiliser cet opcode pour définir l’adresse propriétaire pourrait empêcher l’enregistrement correct de l’adresse privilégiée, menant à la perte du contrôle sur des paramètres critiques du contrat.
Prenons un contrat intelligent utilisant le stockage temporaire pour enregistrer temporairement les prix des transactions sur une plateforme de trading de cryptomonnaies. Ce contrat met à jour le prix après chaque transaction et permet aux utilisateurs d'interroger le dernier prix brièvement. Toutefois, si la conception du contrat ne tient pas compte du fait que le stockage temporaire est automatiquement effacé à la fin de chaque transaction, alors entre la fin d'une transaction et le début de la suivante, les utilisateurs pourraient obtenir un prix erroné ou obsolète. Cela pourrait non seulement les amener à prendre des décisions basées sur des informations incorrectes, mais aussi être exploité malicieusement, nuisant à la réputation de la plateforme et à la sécurité des actifs des utilisateurs.
EIP-6780
Cette proposition modifie le comportement précédent de l’opcode selfdestruct : il ne détruit plus le contrat, mais transfère uniquement les tokens, sauf si le contrat a été créé dans la même transaction que l’appel à selfdestruct. L’impact de cet EIP est relativement important.
Utiliser CREATE2 pour redéployer un contrat à la même adresse afin de le mettre à jour n’est plus pris en charge. Il convient désormais d’utiliser ERC-2535 ou d’autres types de contrats proxy. (Cela pourrait affecter la sécurité de contrats déployés sur la blockchain utilisant CREATE2 pour implémenter des contrats mis à jour.)
L’opcode SELFDESTRUCT dans les contrats intelligents permet de détruire le contrat et d’envoyer son solde à une adresse cible. Ici, le contrat utilise SELFDESTRUCT pour brûler des ether et les envoyer à un autre contrat. Toutefois, cela ne fonctionne que si le contrat cible a été créé dans la même transaction (soit par ce contrat, soit par un autre). Sinon, seul le transfert ether aura lieu, sans destruction du contrat (par exemple, un selfdestruct où le bénéficiaire est le contrat lui-même n’aura aucun effet). Cela affectera tous les contrats dépendant de selfdestruct pour des retraits ou d'autres opérations, comme ce contrat.
Un exemple similaire au fonctionnement du Gas Token CHI de 1inch : maintenir un décalage et exécuter systématiquement CREATE2 ou SELFDESTRUCT à cet emplacement. Après cette mise à jour, si le contrat à cet emplacement n’a pas été correctement autodétruit, les futures tentatives de déploiement via CREATE2 échoueront.
Bien que cette mise à jour ne permette pas d’attaquer directement un contrat, elle peut compromettre la logique normale des contrats existants qui dépendent de l’opcode selfdestruct (les contrats ne dépendant que du transfert de fonds via selfdestruct ne sont pas affectés ; ceux nécessitant que le contrat soit supprimé pour des actions ultérieures le sont). Cela peut entraîner un dysfonctionnement inattendu, conduisant à des grèves de contrat ou à des pertes financières (par exemple, un contrat qui mettait à jour en déployant un nouveau contrat à l’ancienne adresse après avoir autodétruit l’ancien ne pourra plus réussir). À long terme, modifier le comportement d’un opcode pourrait poser des problèmes de centralisation.
Prenons un exemple de mise à jour d’un contrat de coffre-fort (vault) :
-
CREATE2 d’un contrat temporaire pour stocker les fonds du vault
-
Autodestruction du contrat vault, transfert des fonds vers le contrat temporaire (seuls les fonds sont transférés, le contrat vault n’est pas détruit)
-
Tentative de CREATE2 d’un nouveau contrat vault à l’adresse d’origine (échec, car l’ancien vault n’a pas été détruit)
-
Autodestruction du contrat temporaire pour rembourser les fonds au vault (perte des fonds, car le nouveau contrat vault n’a pas été créé)
Lectures complémentaires
La mise à niveau de Cancun renforcera davantage la compétitivité d’Ethereum. Toutefois, les modifications apportées au niveau fondamental des contrats intelligents comportent des risques pouvant affecter la sécurité du fonctionnement des DApps existantes. Lors du développement de contrats intelligents, ces changements et les risques potentiels qu’ils engendrent doivent être soigneusement pris en compte.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@salus_sec
