Was ist EIP-7702?

EIP-7702 ist ein zentraler Protokollvorschlag, der die Fähigkeiten von Ethereum-Konten verändert. EIP steht für Ethereum Improvement Proposal, also einen Verbesserungsvorschlag für Ethereum; 7702 ist die Nummer des Vorschlags. Er erlaubt einem extern kontrollierten Konto, seine Codeausführung an bereits bereitgestellten Smart-Contract-Code zu delegieren und dabei die ursprüngliche Adresse, das Guthaben und die Kontrolle durch den privaten Schlüssel beizubehalten.

Ein extern kontrolliertes Konto (Externally Owned Account, EOA) ist ein Ethereum-Konto, das durch einen privaten Schlüssel kontrolliert und üblicherweise von einer persönlichen Wallet verwendet wird. Ein herkömmliches EOA kann Transaktionen signieren und auslösen, aber nicht wie ein Smart-Contract-Konto gebündelte Vorgänge, Berechtigungsregeln oder Wiederherstellungslogik in das Konto selbst programmieren. EIP-7702 verbindet beide Kontomodelle: Ein EOA kann bestimmten Contract-Code in seinem eigenen Kontokontext ausführen, ohne Vermögenswerte an eine neue Adresse zu verschieben.

Der Vorschlag hat den Status Final erreicht und wurde am 7. Mai 2025 mit dem Netzwerk-Upgrade Pectra im Ethereum Mainnet aktiviert. Er definiert einen grundlegenden Delegationsmechanismus und kein vollständiges Wallet-Produkt. Ob Funktionen wie gebündelte Vorgänge, Gas-Sponsoring, Sitzungsberechtigungen oder Kontowiederherstellung verfügbar sind, hängt vom gewählten Delegate Contract der Wallet und dessen Implementierung ab.

Welches Problem löst der Vorschlag?

Ein herkömmliches EOA ist einfach aufgebaut: Wer den zugehörigen privaten Schlüssel verwenden kann, kann das Konto signieren und kontrollieren. Das Konto besitzt jedoch keine programmierbare Logik. Möchte eine Person ein Token freigeben, einen Vermögenswert tauschen und das Ergebnis in ein anderes Protokoll einzahlen, muss sie normalerweise mehrere Transaktionen getrennt bestätigen. Gas-Gebühren werden außerdem üblicherweise mit ETH, dem nativen Vermögenswert von Ethereum, aus dem Konto bezahlt.

Ein Smart-Contract-Konto kann komplexere Validierungs- und Ausführungsregeln hinzufügen. Die Erstellung eines neuen Contract-Kontos kann jedoch eine neue Adresse erfordern und Fragen der Vermögensmigration, Anwendungskompatibilität sowie der Kontinuität von Historie oder Identität aufwerfen.

EIP-7702 lässt ein bestehendes EOA auf Contract-Code verweisen. Eine Wallet kann dem Konto dadurch codebasierte Fähigkeiten hinzufügen, ohne seine Adresse zu ändern. Der Vorschlag entfernt weder die bisherige Kontrolle durch den privaten Schlüssel noch aktualisiert er jedes EOA automatisch. Die Delegation wird erst in den Ethereum-Zustand geschrieben, nachdem das Konto eine gültige Autorisierung signiert und eingereicht hat.

Wie wird eine Autorisierung wirksam?

EIP-7702 führt den Transaktionstyp 0x04 ein. Eine solche Transaktion kann eine oder mehrere Autorisierungen enthalten. Jede davon zeigt, dass ein EOA der Delegation der Codeausführung an eine Zieladresse zustimmt.

Aus Sicht der Nutzenden besteht der Ablauf aus fünf Schritten:

1. Die Wallet wählt den vorgesehenen Delegate-Contract-Code und zeigt die Autorisierung an.
2. Das EOA signiert die Autorisierung und bestätigt Zielnetzwerk, Delegationsadresse und die aktuelle Transaktionssequenznummer des Kontos, den sogenannten Nonce.
3. Eine Typ-4-Transaktion reicht die Autorisierung beim Netzwerk ein. Absender kann das EOA selbst oder ein anderes Konto sein, das die Gas-Gebühr übernimmt.
4. Nach Prüfung von Signatur und Nonce schreiben die Netzwerk-Nodes eine Delegationsmarkierung auf das EOA, die auf den Zielcode verweist.
5. Ruft später ein anderes Konto oder ein Contract das EOA auf, verarbeitet der Code des Ziel-Contracts den Aufruf im Adress-, Guthaben- und Speicherkontext des EOA.

Mehrere Autorisierungsfelder begrenzen unterschiedliche Risiken:

Die Delegation überträgt keine Vermögenswerte an die Zieladresse. Der Zielcode läuft im Kontext des autorisierenden EOA, liest und verändert also dessen Speicher und verwendet dessen Adresse und Guthaben. Deshalb kann Delegate-Code weitreichende Kontrolle über das Konto erhalten.

Was ändert sich nach der Autorisierung?

Das Konto behält nach der Delegation dieselbe Adresse, sein vorhandenes Guthaben wird nicht automatisch übertragen und der private Schlüssel kann weiterhin Transaktionen signieren. Geändert wird das Codefeld des Kontos: Es speichert eine besondere Markierung, die auf den Code des Ziel-Contracts verweist. Aufrufe an das Konto werden anschließend gemäß dem von dieser Markierung referenzierten Code verarbeitet.

Die Delegation bleibt bestehen. Sie verschwindet nicht automatisch nach einer Transaktion, sondern bleibt aktiv, bis das Konto mit einer neuen gültigen Autorisierung auf anderen Code verweist oder die Delegation löscht. Nutzende dürfen daher nicht davon ausgehen, dass eine Autorisierung mit dem Abschluss eines bestimmten gebündelten Vorgangs endet.

Das Einrichten der Autorisierung und die Ausführung des anschließenden Aufrufs sind außerdem getrennte Phasen. Nach den Verarbeitungsregeln von EIP-7702 wird eine bereits verarbeitete Delegation nicht automatisch zurückgesetzt, wenn die spätere Ausführung der Typ-4-Transaktion fehlschlägt. Eine Wallet muss „Delegation wurde geschrieben“ und „beabsichtigte Aktion war erfolgreich“ getrennt anzeigen und prüfen.

Welche Kontofunktionen kann der Mechanismus unterstützen?

EIP-7702 stellt Wallets ein grundlegendes Werkzeug zur Verfügung. Häufige Entwürfe können mit Delegate-Code Folgendes ermöglichen:

• einen einzigen Signaturablauf für mehrere Vorgänge wie Freigabe, Tausch und Einzahlung;
• Einreichung und Gas-Zahlung durch ein anderes Konto oder einen Dienst;
• feingranulare Berechtigungen wie Sitzungsschlüssel, Nutzungslimits oder eingeschränkte Ziele;
• Authentifizierungsmethoden jenseits der Signatur eines einzelnen privaten Schlüssels;
• Wiederherstellungs-, Pausen- oder Ausgabenkontrollen;
• Kompatibilität mit Smart-Account-Infrastruktur auf Grundlage des Account-Abstraction-Standards ERC-4337.

EIP-7702 garantiert keine dieser Funktionen. Der Vorschlag legt fest, wie eine Delegation autorisiert und aufgezeichnet und der referenzierte Code ausgeführt wird. Delegate Contract und Wallet-Oberfläche bestimmen, welche Funktionen existieren, wie eine Aktion validiert wird und wie eine Wiederherstellung bei Problemen abläuft.

Gas-Sponsoring bedeutet nicht, dass Ethereum kein Gas mehr berechnet. Eine Typ-4-Transaktion erlaubt einem anderen Konto, als äußerer Transaktionsabsender aufzutreten, die Autorisierung des EOA einzuschließen und die Gas-Gebühr zu bezahlen. Ob ein Dienst die Gebühr übernimmt, wie die Kosten abgerechnet werden und wer spätere Aufrufe bezahlt, sind Produktentscheidungen der Wallet oder des Dienstes.

Wodurch unterscheidet sich der Mechanismus von einem Smart Account?

„Smart Account“ ist ein Oberbegriff für ein Kontoerlebnis, bei dem programmierbarer Code die Validierungs- und Ausführungsregeln bestimmt. EIP-7702 ist ein Mechanismus auf Protokollebene, der ein solches Erlebnis ermöglichen kann, ist aber nicht mit jedem Smart-Account-Entwurf gleichzusetzen.

ERC-4337 ist ein weiterer Account-Abstraction-Standard. Er organisiert Aktionen über ein UserOperation-Datenobjekt, das die Absicht der Nutzenden beschreibt, Bundler, die Vorgänge sammeln, und einen EntryPoint-Contract, der sie validiert und ausführt. Dafür muss die Konsensschicht von Ethereum nicht für jeden Kontoentwurf eine Transaktionsregel hinzufügen. EIP-7702 lässt ein EOA dagegen eine Code-Delegation direkt im Protokollzustand setzen. Beide Mechanismen können zusammenarbeiten: ERC-4337 legt fest, wie der Ablauf für Nutzervorgänge eine EIP-7702-Autorisierung einschließen kann.

EIP-7702 macht aus einem gewöhnlichen EOA auch nicht automatisch ein Konto, das ausschließlich durch eine echte Multisignatur-Regel kontrolliert wird. Selbst wenn der Delegate-Code mehrere Genehmigungen verlangt, kann der ursprüngliche private Schlüssel die Delegation ersetzen oder löschen und eine langfristige Regel umgehen, die nur durch den aktuellen Delegate erzwungen wird. Benötigt eine Anwendung ein Kontrollmodell, das ein einzelner ursprünglicher privater Schlüssel nicht außer Kraft setzen kann, darf sie dieses Modell nicht allein aus einer eingerichteten EIP-7702-Delegation ableiten.

Wie lässt sich die Delegation ersetzen oder widerrufen?

Das Konto kann eine neue Autorisierung signieren, die auf eine andere Zieladresse verweist. Zum Löschen der Delegation kann es die Nulladresse als Autorisierungsziel setzen. Die neue Autorisierung muss weiterhin Netzwerk-, Signatur- und Nonce-Prüfungen bestehen und über eine Typ-4-Transaktion auf die Blockchain geschrieben werden.

Das Löschen der Delegation entfernt den Codeverweis, aber nicht automatisch Daten, die der frühere Delegate-Code in den Kontospeicher geschrieben hat. Verwendet das Konto später anderen Code, kann dieser alte Daten lesen oder dieselbe Speicherposition anders interpretieren. Der Entwurf des Delegate Contracts muss Initialisierung, Upgrades und Speicherkompatibilität berücksichtigen. Vor einem Implementierungswechsel müssen Nutzende außerdem prüfen, ob ihre Wallet einen passenden Migrations- und Wiederherstellungsablauf bereitstellt.

Der Widerruf der Delegation ersetzt nicht den Schutz des privaten Schlüssels. Ist der Schlüssel kompromittiert, kann ein Angreifer weiterhin eine neue Autorisierung signieren, den Delegate ersetzen oder das Konto direkt kontrollieren. Delegate-Code kann Betriebsregeln ergänzen, doch der ursprüngliche Schlüssel bleibt ein entscheidender Kontrollnachweis.

Hauptrisiken und Prüfpunkte

Bösartiger oder fehlerhafter Delegate-Code

Delegate-Code läuft im Kontext des EOA und kann andere Contracts aufrufen, Vermögenswerte übertragen oder Speicher verändern. Bösartiger oder verwundbarer Code kann nahezu vollständige operative Kontrolle über das Konto erlangen. Eine Wallet sollte den Zielcode und seine Upgrade-Berechtigungen prüfen und Nutzende nicht zur Signatur für eine unbekannte Delegationsadresse auffordern.

Autorisierungs-Phishing

Eine EIP-7702-Autorisierung kann viele zukünftige Transaktionen betreffen und hat damit einen größeren Umfang als die Signatur einer einzelnen Übertragung. Zeigt eine Oberfläche nur „anmelden“ oder „Funktion aktivieren“, ohne Zielnetzwerk, Delegate-Code und Fortbestand klar darzustellen, können Nutzende die Autorisierung unterschätzen. Die offiziellen Ethereum-Hinweise empfehlen, dass Wallets Delegationsinteraktionen verwalten und Zielcode prüfen, statt gewöhnlichen Webseiten beliebige Autorisierungsanfragen zu ermöglichen.

Kettenübergreifende Wiederholung und Adressunterschiede

Das Feld chain_id beschränkt die Autorisierung auf ein Netzwerk. Der Wert 0 kann dieselbe Autorisierung auf mehreren Chains nutzbar machen, obwohl dieselbe Adresse nicht in jedem Netzwerk denselben Code enthalten muss. Auch bei identischem Adresstext können sich Code und Kontozustand unterscheiden. Eine Wallet muss Netzwerk, Zieladresse und den tatsächlich in diesem Netzwerk bereitgestellten Code gemeinsam prüfen.

Initialisierungs- und Speicherkonflikte

Neuer Delegate-Code muss möglicherweise zuerst Eigentümer, Berechtigungen oder andere Anfangsdaten speichern. Kann eine andere Partei die Initialisierung zuerst ausführen, kann das Konto falsch konfiguriert werden. Bei einem Delegationswechsel können Implementierungen, die dieselben Speicherpositionen wiederverwenden, außerdem Berechtigungs- oder Datenkonflikte erzeugen.

Frühere Anwendungsannahmen gelten nicht mehr

Manche Anwendungen haben „das Konto hat aktuell keinen Code“ als Beleg für ein gewöhnliches Nutzerkonto behandelt oder tx.origin genutzt, um den Ursprung eines Aufrufs abzuleiten. EIP-7702 lässt ein EOA delegierten Code ausführen. Diese Annahmen sind daher nicht mehr zuverlässig und können auch Wiedereintrittsrisiken schaffen. Anwendungen müssen Berechtigungen anhand des tatsächlichen Aufruf- und Autorisierungsmodells prüfen, statt sich auf frühere Typmerkmale eines Kontos zu verlassen.

Häufig gestellte Fragen

Ändert die Delegation die Wallet-Adresse?

Nein. Das EOA behält seine Adresse, und Guthaben sowie Historie bleiben dort. Hinzu kommt lediglich eine Code-Delegationsmarkierung.

Gilt die Delegation nur für eine Transaktion?

Nein. Nach dem Schreiben bleibt sie bestehen, bis eine neue Autorisierung sie ersetzt oder löscht. Das Scheitern einer beabsichtigten Aktion widerruft eine bereits verarbeitete Delegation nicht zwangsläufig.

Bleibt der private Schlüssel nach der Delegation gültig?

Ja. Der ursprüngliche private Schlüssel kann weiterhin Transaktionen signieren, die Delegation ersetzen oder löschen. Delegate-Code beseitigt nicht die Notwendigkeit, den Schlüssel zu schützen.

Liefert der Mechanismus automatisch Bündelung und Gas-Sponsoring?

Nein. Er stellt den grundlegenden Delegationsmechanismus bereit, der für die Umsetzung solcher Funktionen benötigt wird. Delegate-Code implementiert die Bündelung; Gas-Sponsoring erfordert zusätzlich einen externen Absender oder Dienst, der die Transaktion einreicht und die Gebühr bezahlt.

Kann ein Konto an jeden Contract delegieren?

Das Protokoll erlaubt einer Autorisierung, auf eine Codeadresse zu verweisen. Die technische Möglichkeit bedeutet jedoch nicht, dass der Code geeignet ist. Da der Zielcode im Kontext des Kontos läuft, sollten Nutzende eine vertrauenswürdige Wallet verwenden, um Zweck, Auditinformationen, Upgrade-Berechtigungen und Widerrufsmethode des Codes zu prüfen. Eine nicht identifizierbare Autorisierung sollte nicht signiert werden.

Verwandte Begriffe

Lies weiter über Ethereum, Smart Contracts und die Ethereum Virtual Machine, oder kehre zum Krypto-Glossar zurück. Dieser Eintrag wird erst dann aus dem A–Z-Glossar verlinkt, wenn alle sieben Sprachversionen veröffentlicht sind.

Quellen

• EIP-7702: Set Code for EOAs — Transaktionstyp, Autorisierungsfelder, delegierte Ausführung, Widerruf und Sicherheitsaspekte.
• Ethereum.org: Hinweise zu EIP-7702 — Wallet-Integration, Kontokontrolle, kettenübergreifende Autorisierung, Delegationsrisiken und Hinweise zur Nutzerinteraktion.
• Ethereum Foundation: Ankündigung von Pectra im Mainnet — Aktivierungsdatum im Mainnet und Kontext der Nutzerfunktionen von EIP-7702.
• ERC-4337: Account Abstraction mit alternativem Mempool — Unterstützung von EIP-7702-Autorisierungen durch ERC-4337.