Longue histoire courte : La mise à niveau de Cancun approche, et cette mise à niveau comprend principalement les changements de couche exécutive proposés par les 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é de Ethereum, Goutte Coût de transaction L2, et à augmenter la vitesse des transactions. La mise à niveau de Cancún a été achevée le 17 janvier, le 30 janvier et le 7 février dans Ethereum Testnet Goerli, Sepolia et Holesky, et devrait être activée le 13 mars en Ethereum Mainnet. Avant la mise à niveau, Salus a compilé d’importantes considérations de sécurité pour cette mise à niveau afin que les développeurs puissent les vérifier par eux-mêmes.
Examen de la proposition du PEI
Considérations relatives à la sécurité divulguées officiellement
Risques associés aux Smart Contracts
Lire la suite
Examen de la proposition EIP
EIP-1153
EIP-1153 introduit le code d’opération de stockage éphémère, qui est un code d’opération utilisé pour l’état opérationnel et se comporte presque de la même manière que le stockage, mais est supprimé une fois chaque transaction terminée. Cela signifie que le stockage temporaire ne désérialise pas les valeurs du stockage et ne sérialise pas les valeurs du stockage, de sorte que le stockage temporaire est moins coûteux car il ne nécessite pas d’accès au disque. Avec deux nouveaux codes d’opération, TLOAD et TSTORE (où « T » signifie « temporaire »), Smart Contract peut accéder au stockage temporaire. Cette proposition vise à fournir une solution dédiée et efficace pour la communication entre les frameworks d’exécution imbriqués Long dans l’exécution des transactions d’Ethereum.
EIP-4788
EIP-4788 vise à exposer les racines de l’arbre de hachage des blocs de chaîne de balises à l’EVM pour permettre l’accès à ces racines à l’intérieur du Smart Contract. Cela fournit un accès sans confiance à l’état de la couche Consensus, prenant en charge les cas d’utilisation Long tels que les pools de jalonnement, les structures de reprise, les ponts Smart Contract, l’atténuation MEV, etc. La proposition stocke ces racines via un Smart Contract et utilise un tampon en anneau pour limiter la consommation de stockage, garantissant que chaque bloc d’exécution n’a besoin que d’un Short constant pour représenter ces informations.
EIP-4844
EIP-4844 introduit un nouveau format de transaction appelé « Sharding Blob Transactions » conçu pour faire évoluer la disponibilité des données d’Ethereum de manière simple et compatible avec les versions antérieures. Pour ce faire, cette proposition introduit des « transactions porteuses d’objets blob » qui contiennent une grande quantité de données qui ne peuvent pas être consultées par l’exécution EVM, mais qui peuvent accéder à ses promesses. Ce format est entièrement compatible avec le format utilisé par le Sharding complet à l’avenir, offrant un soulagement temporaire mais significatif pour la mise à l’échelle de roulement.
EIP-5656
L’EIP-5656 introduit une nouvelle instruction EVM, MCOPY, pour une réplication efficace des régions de mémoire. Cette proposition vise à Goutte la surcharge liée à l’exécution d’opérations de copie de mémoire sur l’EVM en permettant directement la réplication des données entre la mémoire via l’instruction MCOPY. MCOPY PERMET AUX Adresse Adresse SOURCE ET CIBLE DE SE CHEVAUCHER, EST CONÇU DANS UN SOUCI DE COMPATIBILITÉ DESCENDANTE ET EST CONÇU POUR AMÉLIORER L’EFFICACITÉ DE L’EXÉCUTION DANS Long SCÉNARIOS, Y COMPRIS LA CONSTRUCTION DE STRUCTURES DE DONNÉES, L’ACCÈS EFFICACE AUX OBJETS EN MÉMOIRE ET LA RÉPLICATION.
EIP-6780
EIP-6780 modifie la fonctionnalité du code d’opération SELFDESTRUCT. Dans cette proposition, SELFDESTRUCT supprimerait uniquement le compte et transférerait tout l’Ether dans la même transaction que celle où le contrat a été créé, sauf que lorsque SELFDESTRUCT était exécuté, le contrat ne serait pas supprimé, mais transférerait simplement tout l’Ether vers la destination spécifiée. Ce changement est destiné à s’adapter à l’utilisation des arbres Verkle à l’avenir, et est destiné à simplifier les implémentations EVM et à réduire la complexité des changements d’état, tout en conservant certains des scénarios courants utilisés par SELFDESTRUCT.
EIP-7516
EIP-7516 introduit une nouvelle instruction EVM, BLOBBASEFEE, qui renvoie la valeur des frais de base de l’objet blob dans l’exécution de bloc actuelle. Cette directive est similaire au code d’opération BASEFEE dans EIP-3198, sauf qu’elle renvoie les frais de base blob tels que définis par EIP-4844. Cette fonctionnalité permet au contrat de prendre en compte de manière programmatique le prix du gaz des données d’objets blob, par exemple, en permettant aux contrats de cumul de calculer en toute confiance le coût d’utilisation des données d’objets blob, ou d’implémenter des contrats à terme sur le gaz d’objets blob en fonction de cela pour lisser les coûts des données d’objets blob.
Considérations de sécurité officiellement divulguées
EIP-1153
Les développeurs de Smart Contract doivent comprendre le cycle de vie des variables de stockage transitoires avant de les utiliser. Étant donné que le stockage temporaire est automatiquement effacé à la fin d’une transaction, les développeurs de Smart Contract peuvent essayer d’éviter de libérer des créneaux pendant les appels pour économiser du gaz. Cependant, cela peut empêcher toute interaction ultérieure avec le contrat dans la même transaction (par exemple, dans le cas d’un verrou réentrant) ou provoquer d’autres erreurs, de sorte que les développeurs de Smart Contract doivent veiller à conserver des valeurs non nulles uniquement lorsque l’emplacement temporaire est réservé. Destiné à être utilisé par de futurs appels dans la même transaction. SSTORE Sinon, ces codes de fonctionnement se comportent exactement de la même manière que SLOAD, de sorte que toutes les considérations de sécurité courantes s’appliquent, en particulier en ce qui concerne les risques de réentrée.
Les développeurs de Smart Contract peuvent également essayer d’utiliser le stockage transitoire comme alternative au mappage de mémoire. Ils doivent être conscients que le stockage éphémère n’est pas supprimé comme la mémoire lorsque l’appel revient ou reprend, et que la mémoire doit être priorisée dans ces cas d’utilisation pour éviter un comportement inattendu lors de la réentrée dans la même transaction. Le stockage transitoire sur la mémoire est nécessairement coûteux, ce qui aurait dû empêcher ce modèle d’utilisation. L’utilisation longue du mappage en mémoire peut être mieux réalisée avec des listes d’entrées triées par clé, et le mappage en mémoire est rarement requis dans Smart Contract (c’est-à-dire que l’auteur sait qu’il n’y a pas de cas d’utilisation connus en production).
EIP-4844
Cette EIP augmente les besoins en bande passante d’environ 0,75 Mo à un Long maximal par bloc de balise. C’est 40% plus grand que la taille de bloc maximale théorique d’aujourd’hui (30 M Gas / 16 Gas par octet calldata = 1,875 M octets), donc cela n’augmente pas significativement la bande passante dans le pire des cas. Après la fusion, le temps de bloc est statique plutôt qu’une distribution de Poisson imprévisible, fournissant une période de temps garantie pour la propagation de grands blocs.
Même avec des données d’appel limitées, la charge soutenue de cette EIP est Long inférieure à celle des alternatives qui peuvent Goutte le coût des données d’appel, car vous n’avez pas besoin de stocker des objets blob aussi longtemps que la charge d’exécution. Cela permet de mettre en œuvre une politique selon laquelle ces blobs doivent être conservés pendant au moins un certain temps. La valeur spécifique sélectionnée est l’époque MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS, qui est d’environ 18 jours, avec une latence de Long par rapport à la rotation d’un an recommandée (mais pas encore implémentée) de l’historique de la charge utile d’exécution.
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). Long des fonctions de bibliothèque intégrées/standard du langage pour déplacer des octets ont les caractéristiques de performance correctes ici.
En dehors de cela, l’analyse des attaques par déni de service (DoS) et d’épuisement de la mémoire est la même que celle des autres codes d’opération pour toucher la mémoire, car l’expansion de la mémoire suit les mêmes règles de tarification.
EIP-6780
LES APPLICATIONS SUIVANTES D’AUTODESTRUCTION SERONT COMPROMISES, ET LES APPLICATIONS QUI L’UTILISENT DE CETTE MANIÈRE NE SONT PLUS SÛRES :
WhereCREATE 2 est utilisé pour redéployer le contrat au même emplacement afin que le contrat puisse être mis à niveau. Cette fonctionnalité n’est plus prise en charge et ERC-2535 ou un autre type de contrat de procuration doit être utilisé à la place.
Si le contrat repose sur la combustion d’Éther en prenant le contrat SELFDESTRUCT comme bénéficiaire, le contrat n’est pas créé dans la même transaction.
Risques associés aux Smart Contracts
EIP 1153
Considérons deux scénarios utilisant le code d’opération TLOAD et TSTORE :
- Le contrat appelé utilise le code d’opération
- Le code d’opération est utilisé pour initier le contrat d’appel
Risque 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 par le tstore sont lues par le tload, et les données seront libérées après l’exécution d’une transaction, au lieu d’être écrites dans le contrat car le sstore est enregistré de manière permanente. Les développeurs doivent reconnaître les caractéristiques du code d’opération lorsqu’ils utilisent le code d’opération, afin d’éviter les pertes causées par une utilisation incorrecte de données qui ne peuvent pas être écrites correctement dans le contrat. De plus, les données du tstore sont une variable privée et ne peuvent être consultées que par le contrat lui-même. Si vous souhaitez utiliser les données en externe, vous ne pouvez les passer qu’en paramètre ou les mettre en scène dans une variable de stockage publique.
Risque 2 :
Un autre risque potentiel est que si les développeurs de Smart Contract ne gèrent pas correctement le cycle de vie des variables de stockage transitoires, cela pourrait entraîner une purge ou une conservation incorrecte des données à des moments injustifiés. Si un contrat prévoit d’utiliser des données stockées dans un stockage transitoire 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 par erreur ou perdues entre différents appels, ce qui entraîne des erreurs logiques ou des failles de sécurité. Étant donné que les données de solde ou d’allocation d’un projet Jeton similaire ne sont pas stockées correctement, cela entraînera des erreurs dans la logique du contrat et entraînera des pertes. Ou l’utilisation de ce code d’opération lors de la définition de l’adresse du propriétaire entraînera l’enregistrement incorrect de l’adresse privilégiée, perdant ainsi la modification des paramètres importants du contrat.
Prenons l’exemple d’un Smart Contract qui utilise le stockage transitoire pour enregistrer temporairement les prix des transactions sur une plateforme de trading de cryptoactifs. Le contrat met à jour le prix au fur et à mesure que chaque transaction est terminée et permet aux utilisateurs de demander le dernier prix pour une courte période. Cependant, si la conception du contrat ne tient pas compte du fait que le stockage transitoire est automatiquement compensé à la fin de la transaction, l’utilisateur peut obtenir un prix erroné ou obsolète dans la période comprise entre la fin d’une transaction et le début de la suivante. Cela peut non seulement amener les utilisateurs à prendre des décisions basées sur des informations erronées, mais cela peut également être exploité de manière malveillante, affectant la réputation de la plateforme et la sécurité des actifs des utilisateurs.
EIP-6780
La proposition modifie le comportement précédent du code d’opération d’autodestruction, en ne détruisant pas le contrat, en transférant uniquement le jeton, et seul le contrat créé dans la même transaction que l’autodestruction sera détruit. L’impact de ce PEI est relativement important.
Redéployez le contrat à la même adresse avec create 2 pour mettre à niveau le contrat. Cette fonctionnalité n’est plus prise en charge et ERC-2535 ou un autre type de contrat de procuration doit être utilisé à la place. (Cela peut affecter la sécurité des contrats on-chain qui utilisent create 2 pour implémenter des contrats évolutifs)
L’opération SELFDESTRUCT dans le Smart Contract permet de détruire le contrat et d’envoyer le solde du contrat à l’adresse de destination spécifiée. Dans ce cas, le contrat utilise SELFDESTRUCT pour brûler de l’éther et envoie l’éther brûlé au contrat. Cependant, le contrat ne peut être qu’un contrat créé dans la même transaction (un contrat créé par ce contrat ou un autre contrat dans la même transaction). Sinon, seul l’Éther sera transféré sans détruire le contrat (par exemple, s’autodétruire et le bénéficiaire est un contrat autodestructeur, ce qui ne changera rien). Cela affectera tous les contrats qui reposent sur l’autodestruction pour les retraits ou d’autres opérations.
Un jeton de gaz similaire au jeton CHI de 1 pouce fonctionne : gardez un décalage, exécutez toujours CREATE 2 ou SELFDESTRUCT à ce décalage. Après cette mise à jour, si le contrat avec le décalage actuel ne s’est pas déjà autodétruit correctement, le CREATE 2 suivant ne sera pas en mesure de déployer correctement le contrat.
La mise en œuvre de cette proposition ne conduira pas à une attaque directe sur le contrat, mais elle endommagera la logique normale du contrat déployé à l’origine qui repose sur l’opération d’autodestruction (le contrat qui ne repose que sur l’autodestruction pour le transfert de fonds ne sera pas affecté, et si l’opération ultérieure doit nécessiter la suppression du contrat d’autodestruction, il sera affecté), ce qui entraînera que le contrat ne fonctionnera pas comme prévu, et uniquement pour le contrat et les utilisateurs, cela peut entraîner la grève du contrat, la perte de fonds et d’autres préjudices (tels que l’utilisation initiale de create 2). Déployez un nouveau contrat à l’adresse d’origine, et le contrat qui autodétruit le contrat d’origine pour la mise à niveau ne peut plus être déployé avec succès). À long terme, la possibilité de modifier un code d’opération peut entraîner des problèmes de centralisation.
Par exemple, il existe un coffre de contrat de coffre existant à mettre à jour :
- Créer 2 contrats de stockage temporaire est utilisé pour réserver temporairement des fonds pour le coffre-fort.
- Contrat de coffre-fort d’autodestruction, transfert de fonds vers un contrat temporaire (seuls les fonds sont transférés, aucun contrat n’est brûlé)
- Nouveau contrat de coffre-fort à l’adresse d’origine créer 2 (échec car le contrat de coffre-fort d’origine n’a pas été détruit)
- Contrat temporaire d’autodestruction pour retourner les fonds dans le coffre-fort (perte de fonds, le contrat du coffre-fort n’a pas été créé)
Lire la suite
La mise à niveau de Cancun renforcera encore l’avantage concurrentiel d’Ethereum. Toutefois, cette mise à niveau présente un risque pour les modifications apportées à la couche Smart Contract de base, ce qui affectera le fonctionnement sécurisé des DApps existantes. Dans le processus de développement de Smart Contract, ces changements et les risques qui peuvent survenir doivent également faire l’objet d’une attention particulière. Vous pouvez contacter Salus pour des vérifications des risques ou une assistance en matière d’audit, ou vous pouvez lire la suite pour comprendre les changements.
Spécification de mise à niveau du réseau de Cancún
EIP-1153
Réf. EIP-4788
EIP-4844
EIP-5656
EIP-6780
EIP-7516
Contrat Metapod
Contrat GasToken 2
