Ethereum reporte la mise à niveau Glamsterdam après la découverte de huit risques liés aux smart contracts

ETH
Mise à jour Glamsterdamtestnet HoodiChainSecuritytarification du gazEthereumEIP-8037
il y a 1 heureSource: crypto.news
Ethereum reporte la mise à niveau Glamsterdam après la découverte de huit risques liés aux smart contracts

Les développeurs d'Ethereum ont reporté la mise à niveau Glamsterdam sur le testnet Hoodi après que des chercheurs en sécurité ont identifié huit hypothèses existantes de contrats intelligents qui pourraient devenir invalides dans le cadre des modifications proposées à la comptabilisation du gaz.

Résumé

  • Les développeurs d'Ethereum ont reporté la mise à niveau Glamsterdam sur le testnet Hoodi après que ChainSecurity a identifié huit hypothèses de contrats intelligents qui pourraient devenir invalides dans le cadre des modifications proposées au gaz.
  • Les EIP 8037 et EIP 8038 modifieraient la façon dont Ethereum facture le gaz pour certaines opérations, ce qui pourrait affecter les contrats existants qui dépendent de coûts de gaz fixes ou de conditions spécifiques d'échec de transaction.
  • La Fondation Ethereum a demandé aux développeurs et aux auditeurs d'examiner les projets concernés et de signaler les problèmes potentiels avant que les développeurs principaux ne décident si des modifications aux spécifications de la mise à niveau sont nécessaires.
  • Le hard fork de Hoodi restera en suspens jusqu'à ce que les préoccupations identifiées soient résolues, tandis que le développement de la mise à niveau suivante d'Ethereum, Hegota, se poursuit sans interruption.

Dans un article de blog du 6 novembre, la Fondation Ethereum a déclaré que le cabinet d'audit ChainSecurity avait identifié plusieurs projets qui pourraient devenir vulnérables une fois que les EIP-8037 et EIP-8038 prendront effet.

Les deux propositions modifient la façon dont Ethereum facture le gaz pour certaines opérations, en particulier celles impliquant la création et l'accès à l'état de la blockchain. Certains contrats existants dépendent de coûts de gaz fixes ou d'hypothèses sur la quantité de gaz restante après l'échec d'une opération.

Ces conclusions ont incité le groupe All Core Developers (ACD) d'Ethereum à suspendre le hard fork de Hoodi jusqu'à ce que les préoccupations de compatibilité soient résolues.

Les développeurs examinent maintenant si les contrats concernés peuvent être mis à jour de manière indépendante ou si des modifications aux spécifications de la mise à niveau sont nécessaires.

La mise à niveau Glamsterdam d'Ethereum fait face à huit préoccupations de compatibilité

Les préoccupations de sécurité ont été détaillées dans une analyse du 13 octobre par ChainSecurity, qui a examiné comment Glamsterdam pourrait modifier le comportement des contrats qui continuent de s'exécuter après l'échec d'un appel externe.

Selon les règles existantes d'Ethereum, certains contrats dépendent du fait qu'une opération échouée laisse trop peu de gaz pour que les instructions suivantes puissent s'exécuter. La comptabilisation révisée de Glamsterdam pourrait permettre à certaines opérations de se terminer même lorsque les développeurs s'attendaient initialement à ce que l'ensemble de la transaction soit annulé.

ChainSecurity a averti qu'un tel comportement pourrait interférer avec les protections conçues pour empêcher que des transactions échouées soient enregistrées de manière permanente ou que des opérations légitimes perdent leurs options de nouvelle tentative.

Un exemple concerne les contrats qui marquent une opération comme infructueuse après qu'un appel externe a manqué de gaz. Selon les nouvelles règles, du gaz auparavant indisponible pourrait redevenir accessible, permettant au contrat d'enregistrer un échec permanent.

La Fondation Ethereum a publié un dépôt GitHub documentant huit invariants concernés, avec des explications, des exemples et des instructions permettant aux développeurs d'examiner leur propre code.

Parmi les risques identifiés figurent les contrats qui supposent que la consommation de gaz ne peut évoluer que dans une seule direction, que des allocations de gaz fixes resteront suffisantes, ou que des appels annulés ne peuvent pas restituer du gaz déjà dépensé pour la création d'état.

Le dépôt identifie les budgets de gaz fixes et les réserves de gaz comme les problèmes les plus courants trouvés jusqu'à présent, en particulier dans les contrats qui dépendent de coûts de transaction prédéterminés.

Il a été demandé aux développeurs d'examiner à la fois les contrats on-chain et les systèmes off-chain de support, y compris les portefeuilles, les relayeurs et les infrastructures qui peuvent contenir des limites de gaz codées en dur.

L'activation de Hoodi reste en suspens tandis que les examens de sécurité se poursuivent

Les dernières conclusions fournissent davantage de détails sur la décision antérieure d'Ethereum de reporter l'activation de Hoodi, initialement prévue le 26 octobre à 17:42:48 UTC.

Comme crypto.news l'a rapporté précédemment, le report a retiré du calendrier de Hoodi à la fois les activations de la couche d'exécution Amsterdam et de la couche de consensus Gloas, ainsi qu'une augmentation prévue de la limite de gaz du testnet à 200 millions.

Aucune nouvelle date d'activation n'a été annoncée.

Le développeur de la Fondation Ethereum, Marius van der Wijden, a déclaré que l'organisation travaille avec ChainSecurity et Dedaub tout en menant des audits internes pour évaluer les effets possibles sur les applications existantes.

La Fondation a reconnu que ses examens ne peuvent pas couvrir chaque projet Ethereum, en particulier lorsque les vulnérabilités peuvent impliquer des interactions entre les contrats intelligents et l'infrastructure hors chaîne.

Elle a donc demandé aux développeurs et aux auditeurs indépendants d'identifier les applications concernées et de soumettre leurs conclusions avant les prochaines discussions All Core Developers.

Le dépôt demande les détails des contrats concernés, l'invariant spécifique impliqué, les correctifs possibles et les tests de support lorsqu'ils sont disponibles. Les rapports peuvent être soumis en privé à [email protected].

Selon les retours, les développeurs pourraient envisager des ajustements aux EIP-8037 et EIP-8038 avant de poursuivre la mise à niveau.

Les travaux sur la mise à niveau suivante d'Ethereum, Hegotá, se poursuivront en parallèle et restent inchangés par le retard de Glamsterdam, selon la Fondation.

Les changements de mise à l'échelle de Glamsterdam restent en cours de test

Glamsterdam avait déjà été activé sur le réseau de test Sepolia le 6 octobre, où les développeurs ont commencé à examiner ses changements de mise à l'échelle sous une limite de 200 millions de gaz.

La mise à niveau introduit une séparation proposant-constructeur consacrée via l'EIP-7732, qui intègre les responsabilités de construction de blocs dans le protocole de consensus d'Ethereum.

Un autre composant majeur, l'EIP-7928, introduit des listes d'accès au niveau du bloc conçues pour aider les clients à traiter les données de transaction plus efficacement et à prendre en charge l'exécution parallèle.

La réévaluation des prix du gaz constitue une autre partie de la mise à niveau. L'EIP-8037 modifie le coût de création d'un nouvel état de la blockchain, tandis que l'EIP-8038 ajuste les frais d'accès à l'état existant.

Dans une évaluation technique d'août, la Fondation Ethereum a déclaré que les rejeux de transactions historiques montraient que la plupart des contrats intelligents restaient inchangés par les changements de tarification proposés.

Un groupe plus restreint, cependant, nécessitait des limites de gaz plus élevées ou des modifications plus substantielles pour éviter des échecs inattendus.

Séparément, les développeurs ont fusionné un correctif de dépôt de validateur le 26 octobre après avoir identifié une faille qui aurait pu créditer les dépôts de staking aux constructeurs de blocs partageant la même clé publique.

La correction a traité un problème distinct impliquant les changements de consensus Gloas de Glamsterdam, avec des tests de régression ajoutés aux spécifications avant que les implémentations des clients n'intègrent le comportement révisé.