Die Abkürzung von Ethereum zu Smart-Wallet-Verhalten brachte ein neues Vertrauensproblem mit sich: Eine Wallet kann eine reguläre Adresse programmierbar machen, ohne die Vermögenswerte des Nutzers zu bewegen, während der delegierte Code die Macht erhält, mit der Autorität dieses Kontos zu handeln.
Eine von Experten begutachtete Studie, die für die USENIX Security '26 veröffentlicht wurde, stellte fest, dass angreiferverknüpfte Verträge mit 2.322.548 der 3.664.166 EIP-7702-Autorisierungstransaktionen assoziiert waren, die sie bis zum 15. Juli 2025 über sieben Blockchains beobachteten. Das sind 63 % des historischen Transaktionsvolumens im Datensatz der Forscher.
Die Autoren verbanden eine relativ kleine Anzahl bösartiger Verträge mit wiederholten Autorisierungen und beschrieben einige von Angreifern kontrollierte Aktivitäten als wahrscheinlich Übung oder Proof-of-Concept-Tests während einer frühen, explorativen Phase.
Die Zahl misst Transaktionen, während die Prävalenz von verschiedenen Wallets und die aktuelle Angriffsrate von 2026 außerhalb des Umfangs der Studie liegen.
Ethereum aktivierte Pectra, einschließlich EIP-7702, am 7. Mai 2025. Die endgültige Spezifikation führte eine Transaktion vom Typ 4 ein, die es einem extern besessenen Konto ermöglicht, einen Zeiger auf den bereitgestellten Vertragscode zu setzen.
Die Adresse bleibt gleich, der ursprüngliche private Schlüssel behält die Kontrolle, und Aufrufe an das Konto können den delegierten Code im Kontext des Kontos ausführen.
Dieses Design kann einer herkömmlichen Wallet Funktionen verleihen, die mit Smart Accounts verbunden sind, einschließlich gebündelter Aufrufe und gesponserter Transaktionen, ohne den Benutzer zu zwingen, zu einer neuen Adresse zu migrieren. Es verwandelt auch das Delegationsziel in eine Wallet-Infrastruktur.
Fehlerhafter oder feindlicher Code könnte in der Lage sein, Genehmigungen, Übertragungen und Anwendungsaufrufe im Namen des Kontos durchzuführen.
Es wird gesagt, dass Anwendungen nicht erwarten sollten, von Benutzern willkürliche Autorisierungsunterschriften zu verlangen, da es keine sichere generische Schnittstelle gibt, um den Code mit uneingeschränktem Kontozugriff zu bewerten. Wallets sollten die Implementierung überprüfen.
Angreifer könnten Autorisierungsfelder außerhalb der Blockchain vorbereiten und ein Opfer bitten, zu unterschreiben, und eine Wallet könnte die Entscheidung auf eine hochrangige Aufforderung zur Kontenaktualisierung reduzieren, während sie die Vertragsadresse oder den Code, der die Autorität erhält, verschleiert.
Das Protokoll überprüft die Unterschrift des Kontoinhabers, während die Wallet immer noch feststellen muss, ob der ausgewählte Code die Kontrolle verdient.
Die Forscher analysierten mehr als 22,8 Milliarden historische Transaktionen auf Ethereum, Binance Smart Chain, Polygon, Optimism, Arbitrum, Base und Gnosis.
Innerhalb dieser Daten untersuchten sie 3.664.166 EIP-7702-Autorisierungen bis zur Frist und verwendeten Transaktionsfilter, Bytecode-Analyse und manuelle Überprüfung, um 924 bösartige Verträge zu identifizieren. Sie klassifizierten 793 als EOA-zielgerichtet, 124 als vertragskontozielgerichtet und sieben als zusammengesetzte Angriffe.
| Studienmaß | Was es erfasst |
|---|---|
| 3.664.166 Autorisierungen | Historische EIP-7702-Transaktionen über sieben Blockchains bis zum 15. Juli 2025 |
| 2.322.548 Autorisierungen, oder 63 % | Historische Transaktionen, die mit bösartigen EOA-zielgerichteten Verträgen assoziiert sind |
| 924 bösartige Verträge | Die unter der Methode der Forscher erfasste und manuell überprüfte Menge |
| 2,36 Millionen USD | Festgestellter realisierter Verlust über drei Angriffsarten |
| Etwa 10,14 Millionen USD | Potenzielle Exposition in einem separaten Erbe-Vertragsunterbereich |
Eine EIP-7702-Risikokarte zeigt 63 % der Autorisierungen, 2,36 Millionen USD an erkannten Verlusten und 10,14 Millionen USD an potenzieller Exposition.
Die Studie besagt, dass bösartige Verträge unverhältnismäßig häufig wiederverwendet wurden, sodass die Transaktionszahlen viel schneller steigen können als die Anzahl der unterschiedlichen Verträge oder betroffenen Benutzer. In einem jungen Autorisierungsmarkt hatte diese wiederholte Angreiferaktivität einen überproportionalen Einfluss auf den Nenner.
Angreifer fanden einen wiederholbaren Weg zur Kontoberechtigung, bevor Wallets die Vertrauensentscheidung so lesbar und eingeschränkt gemacht hatten, wie die Macht, die sie übertrugen.
Die Studie maß 2.362.848,76 USD an realisierten Verlusten in ihren drei Angriffs Kategorien. Eine separate Schätzung umfasste ältere Verträge, deren Verteidigungen davon ausgingen, dass programmierbare EOAs nicht existieren konnten.
EIP-7702 bricht die alte Annahme, dass msg.sender == tx.origin zuverlässig einen einfachen EOA identifiziert oder vertraglich vermittelte Verhaltensweisen blockiert.
Die Forscher identifizierten 967 aktive Ethereum-Verträge in einer Teilmenge, die diese Überprüfung als Flash-Darlehen-Verteidigung verwendeten, und schätzten, dass etwa 10,1 Millionen USD an Vermögenswerten einem potenziell hohen Risiko ausgesetzt waren.
Der erkannte Diebstahl belief sich auf etwa 2,36 Millionen USD, sodass die 10,14 Millionen USD Vermögenswerte darstellen, die durch eine defensive Annahme exponiert wurden, die nicht mehr gültig war.
Die Forscher beobachteten, dass Angreifer Konten nach einem Angriff an harmlose Codes neu banden, was eine Überwachung des aktuellen Zustands unzuverlässig machte. Sie fanden auch 500 spezielle nicht-null Delegationsziele ohne implementierten Code.
Eine vorab berechnete CREATE2-Adresse könnte später Code empfangen, was ändert, was das Konto ausführt, während das aufgezeichnete Ziel dasselbe bleibt.
Diese Muster machen die Autorisierungsgeschichte zu einem Teil der Sicherheitsgrenze. Wallets und Überwachungstools müssen sich daran erinnern, wo ein Konto zuvor hingewiesen hat, Änderungen im delegierten Code bewerten und ein nicht implementiertes Ziel als ungelöst und nicht harmlos behandeln.
Die Regeln der Autoren könnten bösartige Verträge übersehen, bevor Vorbereitungstransaktionen sichtbar werden oder Angriffe mit neuartigen Schnittstellen außerhalb des Deckungsbereichs der Methode stattfinden. Die 924 Verträge sind die erkannten und manuell verifizierten Sätze, während das gesamte Universum des Missbrauchs unbekannt bleibt.
Sichere Standardverhalten beginnen damit, die Delegation zu einer von der Wallet kontrollierten Installationsentscheidung zu machen. Die nach der Studie veröffentlichten Richtlinien von ethereum.org fordern die Whitelistung von Delegationsverträgen, die prominente Anzeige des Ziels, die Vermeidung willkürlicher Delegationen auf Hardware-Wallets und die Abhängigkeit von geprüften Implementierungen.
Ein Vorschlag zur Fähigkeit der Kontobstraktion Wallet geht in dieselbe Richtung und fordert eine strenge Liste bekannter, öffentlich geprüfter Smart-Account-Implementierungen. Diese Dokumente messen nicht, wie konsequent Produktions-Wallets dies übernommen haben.
Anwendungen sollten die benötigte Funktion anfordern und die Kontoinimplementierung der Wallet überlassen. Für eine Genehmigung und einen Tausch in einem Fluss weist die aktuelle Anleitung der Ethereum Foundation Entwickler auf eine Wallet-Schnittstelle wie ERC-5792 hin.
Die Wallet kann dann EIP-7702, ERC-4337 oder ein anderes Kontosystem wählen, ohne den Benutzer zu bitten, den von der Anwendung ausgewählten Low-Level-Delegationscode zu genehmigen.
Aktuelle Richtlinien empfehlen, die Initialisierungsparameter zu signieren oder die Einrichtung auf den ERC-4337 EntryPoint zu beschränken, um einen Front-Running-Weg zu schließen, bei dem ein Angreifer seine eigenen Werte substituiert.
Die Studie identifizierte einen verwandten Fehlermodus im Legacy-Wallet-Code: Konstruktoren werden nicht erneut ausgeführt, wenn ein Konto an einen bestehenden Vertrag delegiert, was dazu führen kann, dass das Eigentum nicht festgelegt und extern beanspruchbar bleibt.
Ein harmloser aktueller Zeiger kann eine böswillige Historie nicht löschen, und ein Ziel ohne Code kann später Verhalten annehmen. Wallets benötigen dauerhafte Autorisierungsprotokolle, klare Warnungen, wenn sich die Delegation ändert, und einen Entfernungsweg, den die Benutzer verstehen können.
Um die EIP-7702-Wallet-Programmierung standardmäßig sicher zu machen, müssen Wallets die Delegation als Installation der Kontrollinstanz des Kontos behandeln: einschränken, wer sie anfordern kann, genau offenlegen, was das Konto steuern wird, überprüfen, wie es initialisiert wird, und weiterhin beobachten, nachdem sich der Zeiger ändert.
Dieser Inhalt wird nur zu allgemeinen Informationszwecken bereitgestellt und stellt keine finanzielle, Anlage-, Rechts- oder Steuerberatung dar. Alle erwähnten Ereignisse, Prämien, Online-Aktionen oder zugehörige Informationen sollten nicht als Empfehlung, Aufforderung oder Einladung zum Kauf, Verkauf, Handel oder anderweitigem Umgang mit Krypto-Assets betrachtet werden. Krypto-Assets sind sehr volatil und können zu Verlusten führen. Die Verfügbarkeit von WEEX Services, Produkten und zugehörigen Aktionen kann je nach Region unterschiedlich sein. Sie sind dafür verantwortlich sicherzustellen, dass Ihre Teilnahme mit geltenden lokalen Gesetzen und Vorschriften übereinstimmt.




![[SCAN 2026 Finale Interview] ⑫ Lv1x: Cybersecurity-Student aus Malaysia tritt im Finale an](/public-static/10_5acc261b9b.png?format=avif)
























