EIP-7702: Code-Delegation bei EOA und Risiken

Ein übliches EOA signiert Transaktionen mit einem privaten Schlüssel und hat selbst keinen ausführbaren Code. EIP-7702 lässt das Konto auf Code verweisen, der bereits an einer anderen Adresse bereitgestellt wurde. Wird das delegierte Konto aufgerufen, lädt der Client den Zielcode und führt ihn im Kontext des Kontos aus. Der Code liegt an einer anderen Adresse; Adresse, Guthaben und Speicher-Kontext stammen weiterhin vom delegierenden Konto.

Das ist weder ein Umzug auf eine neue Vertragsadresse noch ein Austausch des privaten Schlüssels. Adresse und Schlüssel des EOA bleiben bestehen. Ein Konto mit gültigem Delegationsmarker kann weiterhin Transaktionen starten. Neu ist der Ausführungspfad, über den Aufrufe Kontologik ausführen können; der Standard teilt einen einzelnen Schlüssel nicht automatisch in sicherere Rollen auf.

Die EIP-7702-Spezifikation definiert dafür eine neue Type-4-Set-Code-Transaktion mit einer Autorisierungsliste. Auch der Pectra-Leitfaden von Ethereum.org beschreibt den Verweis auf bereits bereitgestellten Code. Die Anzeige „Smart Account aktiviert“ in einer Wallet verrät weder die tatsächlichen Prüfregeln noch Wiederherstellungsmethoden oder Delegationscode.

Unterscheiden Sie, wer den privaten Schlüssel hält und wer den Delegationscode bereitgestellt hat oder ändern kann. Prüfen Sie Änderungs- und Upgrade-Rechte sowie mögliche Auswirkungen auf Vermögen und Kontospeicher. Diese Sicherheitsfragen beantwortet das EIP selbst nicht.

Die Set-Code-Transaktion ist am Transaktionstyp-Byte 0x04 zu erkennen. Neben den üblichen äußeren Transaktionsfeldern enthält sie eine Autorisierungsliste. Jeder Eintrag umfasst Chain-ID, Codeadresse, Nonce des berechtigenden Kontos und dessen Signatur. Das autorisierende Konto signiert den Eintrag; der Absender signiert separat die äußere Transaktion. Beide Rollen können derselben Person gehören, müssen es aber nicht.

Da ein Absender eine gültige Autorisierung einer anderen Person einfügen kann, muss klar sein, was das autorisierende Konto tatsächlich freigibt. Eine Chain-ID begrenzt die Autorisierung üblicherweise auf eine Chain; die ID 0 ermöglicht eine breitere Nutzung auf unterstützenden Chains. Daraus folgt nicht, dass dieselbe Signatur überall funktioniert: Die Chain muss EIP-7702 unterstützen, und Nonce sowie Kontozustand müssen passen. Ein breiter Geltungsbereich kann die Signatur jedoch auch auf einer anderen unterstützten Chain nutzbar machen.

Ein Eintrag kann übersprungen werden, wenn die Nonce nicht zum autorisierenden Konto passt oder eine andere Prüfung scheitert. Ein falsches Zeichen in der Zieladresse kann auf anderen Code verweisen. Vergleichen Sie Netzwerk, Konto und vollständige Zieladresse in der Wallet-Vorschau mit einem vertrauenswürdigen Block-Explorer. Eine vage Meldung wie „Upgrade“ oder „Gas sparen“ erklärt die Berechtigung nicht.

Die Transaktionsdokumentation von Ethereum.org führt Type-4-Transaktionen mit Autorisierungsliste auf. Für die äußere Transaktion gelten weiterhin Gasbedingungen und ein Gebührenschuldner. Ein anderer Einreicher macht die Ausführung nicht automatisch kostenlos. Type-4 ist außerdem nicht dasselbe wie ERC-4337-UserOperations und Paymaster; diese Mechanismen erklärt der separate Smart-Account-Leitfaden.

Nach einer gültigen Autorisierung erhält der EOA-Code einen Marker aus dem Präfix 0xef0100 und der Zieladresse. Der Client erkennt ihn und lädt den Code dieser Zieladresse, wenn ein Aufruf ausgeführt wird. Die in der Wallet angezeigte Kontoadresse kann sich also von der Adresse unterscheiden, deren Code läuft. Prüfen Sie beide.

Der Code wird auf der Chain ausgeführt, auf der die Delegation verwendet wird. Eine Zieladresse auf einem anderen Netzwerk führt nicht dazu, dass dessen Code hier läuft. Dieselbe 20-Byte-Adresse kann auf verschiedenen Chains unterschiedlichen oder gar keinen Code haben. Prüfen Sie Bereitstellung und verifizierte Quelle je Chain, statt sich nur auf Namen, Symbole oder übereinstimmende Adressen zu verlassen.

Delegierter Code arbeitet im Ausführungskontext des berechtigenden Kontos und kann dessen Speicher verwenden. Je nach Logik kann er ETH und Token senden, andere Verträge aufrufen und gespeicherte Werte ändern. EIP-7702 fügt selbst keine Regeln wie „nur dieser Token“ oder „ein Aufruf täglich“ hinzu. Solche Beschränkungen müssen korrekt im delegierten System implementiert sein.

Ist das Ziel ein Proxy oder anderweitig aktualisierbar, muss der heute geprüfte Code nicht dauerhaft derselbe bleiben. Prüfen Sie Administratoren, Implementierungswechsel, Verzögerungen und öffentliche Upgrade-Verfahren. Unbekannte Änderungsrechte bleiben ein Vertrauensrisiko, solange die Delegation besteht.

Das Protokoll beschränkt delegierten Code nicht automatisch auf eine kleine Berechtigungsmenge. Fehler in der Prüfung können Transfers, Token-Freigaben, beliebige externe Aufrufe oder Änderungen am Kontospeicher ermöglichen. Ein Audit-Hinweis belegt nicht, dass die angefragte Adresse und Version zum geprüften Code und Prüfungsumfang passen.

Die Sicherheitsbetrachtungen des EIP weisen darauf hin, dass Delegationslogik Replay-Schutz, Ziel und Calldata, ETH-Wert sowie Gasbedingungen an eine Signatur binden sollte. Fehlen solche Felder, können Sponsoren oder andere Parteien Anfragen mit abweichender Absicht einreichen oder eine Transaktion scheitern lassen. Prüfen Sie, welche Aufrufe der Code validiert und ob externe Aufrufer diese Prüfungen umgehen können.

Eine Wallet kann zum Beispiel Token-Freigabe und Tausch in einer Bestätigung bündeln. Prüfen Sie, ob beide Schritte gemeinsam zurückgerollt werden, ob die Freigabe auf den nötigen Betrag begrenzt ist und ob sie später reduziert werden kann. Übernimmt ein Paymaster Gebühren, lesen Sie, wer unter welchen Bedingungen zahlt. Eine „kostenlose“ Anzeige darf die autorisierten Aufrufe und Rechte nicht verdecken.

Sicherheit hängt von tatsächlichen Rechten und Upgrade-Kontrolle ab, nicht nur vom Ruf des Ziels. Prüfen Sie aufrufbare Verträge, Signaturprüfung, Notfall- und Upgrade-Befugnisse sowie die Übereinstimmung des Codes mit der verifizierten Quelle. Bei unbekannten Adressen oder unaufgeforderten Links sollten Sie pausieren und die offizielle Wallet-Dokumentation vergleichen.

EIP-7702 verarbeitet die Autorisierungsliste vor der Ausführung der äußeren Transaktion. Laut Spezifikation werden bereits verarbeitete Delegationsmarker nicht zurückgesetzt, wenn die spätere Ausführung fehlschlägt oder zurückrollt. Gehen Sie daher nicht davon aus, dass der Kontozustand allein wegen eines fehlgeschlagenen Receipts zum Anfangszustand zurückkehrt. Prüfen Sie Receipt und aktuellen Kontocode separat.

Das ist bei gebündelten Aufrufen, Initialisierung und durch Sponsoren eingereichten Transaktionen wichtig. Eine Autorisierung kann gültig sein, während ein späterer Aufruf scheitert. Dann kann die Delegation aktiv bleiben, obwohl die gewünschte Einrichtung nicht abgeschlossen wurde. War bereits der Autorisierungseintrag ungültig, wurde er möglicherweise nicht angewandt. Prüfen Sie Type-4-Transaktion, autorisierendes Konto, Nonce und aktuellen Codeverweis statt nur ein Erfolgs- oder Fehlersymbol.

Eine Wallet-Meldung „fehlgeschlagen“ kann Fehler bei der Autorisierung, einem externen Aufruf oder einem anderen Ausführungsschritt zusammenfassen. Vergleichen Sie bei Unklarheit Transaktions-Hash, autorisierendes Konto, Nonce und aktuellen Kontocode über ein vertrauenswürdiges Chain-Werkzeug. Bei einem erneuten Versuch kann eine geänderte Nonce die frühere Autorisierung ungültig machen. Prüfen Sie vorher auf doppelte oder bereits verarbeitete Einreichungen.

Die Unterscheidung ist wichtig, wenn eine Bestätigung scheinbar alle Schritte atomar rückgängig machen sollte. Ein Testkonto oder kleiner Betrag kann das Verhalten zeigen, beweist aber nicht die Sicherheit des Codes. Vor Nutzung eines finanzierten Kontos sollten Sie Chain-Geltungsbereich, Ziel, Calldata und möglichen Restzustand nach einem Fehler prüfen können.

Eine neue Autorisierung kann auf anderen Code verweisen. Das EIP definiert außerdem das Löschen des Markers durch Autorisierung der Nulladresse, wodurch der Codezustand des Kontos wieder leer wird. Dabei wird nur der Delegationsmarker entfernt, kein allgemeiner Bereinigungs- oder Wiederherstellungsbefehl ausgeführt.

Hat der delegierte Code Werte im Kontospeicher abgelegt, löscht das Entfernen des Markers sie nicht automatisch. Eine von einem ERC-20-Vertrag gespeicherte Token-Freigabe ist ebenfalls getrennt vom Kontocode. Eine frühere unbegrenzte Freigabe muss möglicherweise beim Token-Vertrag widerrufen werden. Übertragene Token, Änderungen externer Verträge und abgeschlossene Transaktionen werden durch das Löschen nicht rückgängig gemacht.

Neuer Code kann denselben Kontospeicher verwenden. Wenn zwei Versionen Speicherplätze unterschiedlich interpretieren, kann es zu Konflikten kommen. Prüfen Sie Layout und Migration vor dem Wechsel. Ohne Kompatibilität können Kontosperren oder unerwartete Zustände entstehen; das Protokoll bietet beim Wechsel keinen allgemeinen Speicher-Reset.

Richten Sie die Reaktion nach dem Problem aus. Bei möglichem Schadcode prüfen Sie umgehend einen von der Wallet unterstützten Lösch- oder vertrauenswürdigen Ersatzablauf. Für Token-Freigaben lesen Sie den separaten Leitfaden zu Token-Freigaben und Allowances. Ist Schlüssel oder Seed offengelegt, stellt das Löschen der Delegation die Kontrolle nicht wieder her; nutzen Sie den Leitfaden zur Wallet-Wiederherstellung und bewerten Sie einen Umzug der Assets.

Prüfen Sie zuerst in der offiziellen Wallet-Dokumentation, ob EIP-7702 auf dem ausgewählten Netzwerk unterstützt wird. Vergleichen Sie Netzwerk und Chain-ID, Konto, genaue Zieladresse, verifizierten Code sowie Proxy- und Upgrade-Administratoren. Verstehen Sie, ob Chain-ID 0 den Geltungsbereich erweitert oder die Signatur auf eine Chain begrenzt ist. Bei unklarer Signieransicht suchen Sie vor der Freigabe eine Erklärung der Autorisierungsdaten.

Unterscheiden Sie dann Autorisierungssignatur, Absender der äußeren Transaktion und Gebührenschuldner. Ein anderer Absender ändert nicht, was das berechtigende Konto signiert hat. Sponsoring macht den Code weder sicher noch auf erwartete Aufrufe beschränkt. Stimmen Transaktionstyp, Autorisierungsliste, Ziele, Calldata und Token-Freigabe mit der Vorschau überein?

Ist eine Delegation bereits aktiv, prüfen Sie neben dem Erfolg der Transaktion auch den aktuellen Marker und die Zieladresse. Weicht sie von Ihrer Erwartung ab, pausieren Sie weitere Aufrufe und Freigaben; senden Sie nicht wiederholt willkürliche Ersatzautorisierungen. Für äußere Transaktionsgebühren nutzen Sie den Leitfaden zu Ethereum-Gasgebühren; für Nonce und ausstehende EOA-Transaktionen den Leitfaden zu ausstehenden Transaktionen.

EIP-7702 standardisiert ein Transaktionsformat, das ein EOA mit bereitgestelltem Code verbindet. Bündelung, gesponserte Gebühren, Sitzungsschlüssel und Wiederherstellung können darauf aufbauen, sind aber Funktionen bestimmter Codes und Dienste. Nicht jede Wallet oder Delegation verwendet dieselben Regeln oder unterstützt alle Funktionen.

Die Anzeige „Smart Account“ erklärt nicht, wer den Schlüssel hält, wer Code aktualisieren kann oder wer die Wiederherstellung ändert. Prüfen Sie die tatsächliche Implementierung und Konfiguration. Unterstützt eine Wallet die Chain oder Funktion nicht, kann sie den Delegationszustand anders anzeigen als erwartet. Prüfen Sie die Unterstützung, bevor Sie ein finanziertes Konto ändern.

Die Pectra-Mainnet-Ankündigung der Ethereum Foundation beschreibt, wie EOAs auf delegierten Code verweisen und eine Autorisierung ersetzen oder widerrufen können. Die Funktionen des Standards und ihre verständliche Darstellung durch eine konkrete Wallet sind unterschiedliche Fragen. ERC-4337-UserOperations und Paymaster sind ein anderer Weg zur Account-Abstraktion, nicht die Type-4-Autorisierung selbst.

Dieser Leitfaden erklärt Kontomechanik und empfiehlt weder eine bestimmte Wallet noch Delegation. Legen Sie zuerst das Ziel fest: gebündelte Aktionen, Gebührensponsoring, Sitzungserlaubnisse oder Wiederherstellung. Ermitteln Sie dann, welcher Code und Dienst die Funktion bereitstellt und welches Vertrauen nötig ist. Ergänzend erklärt der Smart-Account- und ERC-4337-Leitfaden benachbarte Mechanismen.