Ethereum : l’EIP-8246 atteint son échéance de consultation sur les destructions d’ETH

Une échéance de revue, pas une activation

L’EIP-8246, intitulée « Remove SELFDESTRUCT Burn », arrive le 4 novembre 2026 à la date de fin de dernière consultation indiquée dans le registre officiel des propositions Ethereum. Créé le 1er mai par Paweł Bylica, le document reste affiché au statut Last Call lors de notre lecture. Son objectif est de supprimer les derniers cas où l’instruction SELFDESTRUCT fait disparaître des ethers du solde d’un contrat. Cette étape documentaire ne constitue pas une décision de déploiement : le texte précise que sa mise en œuvre nécessiterait une modification des règles de consensus, donc une mise à niveau du réseau.

Le périmètre est étroit. Depuis l’EIP-6780, les cas concernés portent sur un contrat créé puis soumis à SELFDESTRUCT dans une même transaction. Un solde peut encore être détruit lorsque le contrat se désigne lui-même comme bénéficiaire, ou reçoit de nouveaux ethers après l’instruction mais avant la finalisation de la transaction. L’auteur veut retirer ces exceptions, qu’il juge très peu utilisées, pour simplifier les implémentations, les spécifications et les tests de la machine virtuelle Ethereum.

Le solde resterait après l’effacement du contrat

Le changement proposé conserverait le solde lorsque le bénéficiaire est l’adresse du contrat lui-même. À la finalisation, le code et le stockage seraient effacés et le nonce remis à zéro, tandis que les fonds restants seraient préservés. Un compte sans solde serait toujours supprimé selon les règles existantes. Un compte conservant des fonds pourrait subsister comme simple compte de solde, sans code exécutable. Les autres comportements de SELFDESTRUCT resteraient ceux décrits par l’EIP-6780.

Cette distinction entre le programme et sa valeur évite de confondre suppression du code et disparition des fonds. Elle n’équivaut toutefois pas à garantir que le solde soit librement récupérable par son ancien utilisateur. La proposition prévoit notamment qu’un contrat puisse être recréé à la même adresse via CREATE2 dans une transaction ultérieure. Les développeurs doivent donc examiner les conditions de redéploiement, plutôt que supposer qu’une adresse ayant perdu son code est définitivement inutilisable ou contrôlée par une seule personne.

Des adaptations particulières pour certains réseaux secondaires

Le document signale une différence entre Ethereum et certains réseaux secondaires. Dans l’OP Stack, le contrat de passage des messages vers la couche principale utilise ce mécanisme de destruction pour traiter des soldes liés aux retraits. Les chaînes qui dépendent de cette logique auraient besoin d’un plan de migration séparé si elles adoptaient la modification. Il ne s’agit donc pas d’un changement à appliquer mécaniquement à toutes les implémentations compatibles avec Ethereum sans examiner leurs contrats système et leur comptabilité.

La section de sécurité demande un effort de test important, notamment pour les interactions entre appels, créations de contrats et annulations de transactions. Elle relève aussi qu’une fabrique ouverte à tous pourrait permettre à un tiers de recréer une adresse et de prendre le solde préservé lorsque les conditions de CREATE2 sont réunies. L’information du 4 novembre reste ainsi une échéance de consultation : le statut ultérieur, les tests, les éventuelles adaptations et un calendrier d’activation devront être vérifiés séparément. Aucun changement de solde des utilisateurs n’est établi par la seule arrivée de cette date.