La distinction est importante pour les portefeuilles chauds d’échange et les trésoreries dont les contrôles supposent qu’ils ne signent que des transactions ordinaires. Comme The Defiant l’a précédemment rapporté, le co-PDG de Binance, Richard Teng, a déclaré que l’attaquant, dans sa violation, avait utilisé l’EIP-7702 pour obtenir l’approbation d’exécution sur un portefeuille chaud. « Cette délégation n’a pas passé par nos contrôles d’approbation normaux », a-t-il déclaré.
Une transaction en chaîne enregistrée par Etherscan montre un seul appel à Binance 14 transférant environ 167 464 ETH et 1,615 milliard USDT, ainsi que d’autres jetons, à l’attaquant.
Un interrupteur à sens unique
Le projet de spécification réutiliserait une forme actuellement invalide de transaction de type 4 de l’EIP-7702 : une transaction auto-adressée avec une valeur nulle, sans données et des listes d’accès et d’autorisation vides. Il installerait un marqueur non exécutable de trois octets, provisoirement « 0xef0200 », sans exécuter de code délégué existant.
Une fois installé, le marqueur entraînerait l’omission des futures autorisations de délégation, y compris les tentatives d’effacement. Le compte conserverait son adresse, ses virements ordinaires et ses appels contractuels, tandis que les appels entrants n’exécuteraient aucun code. Le tarif fixe proposé est de 33 500 gaz, ce qui, selon l’auteur, n’a pas été comparé.
La protection s’arrête à la délégation. Une clé privée compromise pourrait toujours transférer des fonds, accorder des approbations de jetons ou signer des autorisations de contrat. Les approbations existantes ne seraient pas révoquées. Le projet prévient également que la désinscription pourrait désactiver la récupération dépendante de la délégation ou rendre inaccessibles les actifs nécessitant l’ancien code du délégué.
L’expiration répond à un risque différent
Un projet distinct de Joseph Delong, dans le PR #12601, exigerait que chaque autorisation signe une référence de bloc qui fait partie des 256 ancêtres précédents du bloc d’inclusion. Cela limiterait la fenêtre d’application des autorisations non utilisées, sans faire expirer la délégation déjà installée.
Une autre version, EIP-7851, adopte une approche différente : désactiver définitivement l’autorité au niveau du protocole de la clé de signature d’origine tout en laissant le code du portefeuille capable de mettre à jour la délégation. Le nouvel opt-out préserve les pouvoirs de transaction ordinaires de la clé et supprime la capacité de délégation.
La conception de l’opt-out nécessite encore un travail de compatibilité. Son encodage de marqueur est provisoire, et les contrats ou portefeuilles qui identifient les comptes ordinaires par leur manque de code pourraient rejeter les comptes marqués. Les portefeuilles et les signataires du matériel devraient également reconnaître le nouveau formulaire de transaction et le présenter comme irréversible.
