CryptoRoad.it

Ratgeber Ratgeber Sicherheit

EIP-7702: Ethereum-Wallet delegieren und Risiken prüfen

•

EIP-7702 ermöglicht einem Ethereum-Konto, das durch einen privaten Schlüssel kontrolliert wird, die Ausführung an einen Vertrag zu delegieren. Dadurch können gebündelte Aktionen, gesponserte Gasgebühren und flexiblere Berechtigungen möglich werden. Die Sicherheitsentscheidung ist jedoch weitreichend: Sie genehmigen nicht nur die Ausgabe eines Tokens, sondern wählen Code, der im Kontext Ihres Kontos ausgeführt wird.

Die Delegation endet nicht automatisch nach einer einzelnen Transaktion. Sie kann bestehen bleiben, bis sie korrekt ersetzt oder entfernt wird. Akzeptieren Sie deshalb keine Signatur allein wegen kostenloser Gasgebühren, eines Airdrops oder einer bequemen Aktivierung. Dieser Leitfaden erklärt die Unterschiede zwischen Berechtigungen und sinnvolle Prüfungen, ohne eine universelle Wiederherstellungsanleitung zu versprechen.

EIP-7702: Konto, Schlüssel und delegierter Code

Ein extern kontrolliertes Konto, kurz EOA, wird traditionell mit einem privaten Schlüssel gesteuert. Der Mechanismus erlaubt einen Verweis auf einen Vertrag, dessen Code im Kontext dieses Kontos läuft. Die Adresse bleibt erhalten, und der ursprüngliche Schlüssel spielt weiterhin eine zentrale Rolle. Es entsteht nicht automatisch eine neue Wallet mit höherer Sicherheit.

Geändert wird das Verhalten des Kontos. Eine sorgfältig entwickelte Implementierung kann nützliche Funktionen hinzufügen. Deren Qualität hängt jedoch vom gewählten Code und seinen Prüfungen ab. Delegation ist nur die Grundlage. Ausgabenlimits, Sitzungsschlüssel und Wiederherstellung sind Funktionen einer Implementierung, keine pauschalen Garantien des Protokolls.

Unser Leitfaden zu Krypto-Wallets erklärt den Unterschied zwischen Schlüsselkontrolle und Verwahrung durch einen Anbieter. Eine einfachere Oberfläche ersetzt nicht die Frage, wer signieren kann und welche Handlung eine Freigabe erlaubt.

Welche Vorteile sind im Alltag möglich?

Durch Bündelung können mehrere Aktionen in einer Ausführung zusammengefasst werden. Eine Anwendung könnte beispielsweise eine Token-Freigabe und einen anschließenden Tausch in einem weniger fragmentierten Ablauf organisieren. Entscheidend bleibt, ob die Implementierung das erwartete Verhalten tatsächlich sicher abbildet. Gemeinsam ausgeführte Aktionen sind nicht automatisch wirtschaftlich sinnvoll oder ungefährlich.

Bei gesponserten Transaktionen übernimmt eine andere Partei die Kosten. Das kann den vorherigen Kauf von ETH vermeiden, macht Gas aber nicht kostenlos. Jemand bezahlt es. Ein Dienst kann diese Ausgaben über Gebühren, Vertragsbedingungen oder einen anderen Vermögenswert zurückholen. Betrachten Sie den Gesamtpreis und nicht nur die Bezeichnung „gasless“.

Oberhalb des delegierten Codes können Wallets eingeschränkte Berechtigungen aufbauen. Ein Sitzungsschlüssel könnte nur für eine Anwendung oder bis zu einer bestimmten Ausgabengrenze gelten. Diese Regeln müssen technisch durchgesetzt werden. Die Beschreibung auf einer Website genügt nicht: Welcher Code kontrolliert die Grenze, und wer kann seine Konfiguration verändern?

Delegation ist keine gewöhnliche Token-Freigabe

Eine ERC-20-Freigabe erlaubt einem Spender, einen bestimmten Betrag eines bestimmten Tokens auszugeben. Permit und Permit2 verwenden andere Autorisierungswege, deren Befugnisse durch die jeweiligen Verträge definiert werden. Eine Delegation verändert dagegen den Code, der im Kontokontext ausgeführt wird. Das sind unterschiedliche Sicherheitsebenen, auch wenn alle Oberflächen eine Signatur verlangen.

VorgangPrüfgegenstandWichtige Frage
Token-FreigabeSpender und BetragWer kann diesen Token ausgeben?
Permit oder Permit2Signatur und vertragsabhängige RechteWelche Werte und Grenzen gelten?
DelegationDem Konto zugeordneter CodeWelche Implementierung steuert die Ausführung?

Der Leitfaden zu Permit2 und dem Widerruf von Signaturen hilft bei dieser Trennung. Eine widerrufene Token-Freigabe entfernt nicht automatisch die Delegation. Umgekehrt löscht deren Entfernung nicht sämtliche Token-Freigaben. Eine Prüfung muss das konkrete Recht identifizieren, statt alle Signaturen gleich zu behandeln.

Die Delegation bleibt bestehen

Die endgültige Spezifikation sieht eine dauerhafte Delegation vor. Wer sie als Erlaubnis nur für den aktuellen Klick versteht, unterschätzt die Folgen. Eine Signatur kann eine Änderung autorisieren, die innerhalb einer Transaktion verarbeitet wird. Die gewählte Implementierung kann danach weiterhin mit dem Konto verbunden sein.

Das Verarbeiten einer Autorisierung und der Erfolg der nachfolgenden Aktion sind getrennte Schritte. Eine fehlgeschlagene Ausführung hebt eine bereits verarbeitete Delegation nicht zwangsläufig auf. Leiten Sie den vollständigen Kontostand daher nicht allein aus einer Meldung „failed“ ab. Prüfen Sie die Angaben der Wallet und der Blockchain zum Konto selbst.

Ein Beispiel: Eine Website verspricht einen gesponserten Tausch, der Tausch scheitert und die Seite wird geschlossen. Es ist nicht sicher anzunehmen, dass sämtliche Änderungen rückgängig gemacht wurden. Zur Nachprüfung gehört eine möglicherweise installierte Delegation, nicht nur der Token-Bestand oder der Beleg des Tauschs.

Vertragsadresse, Netzwerk und Nonce

Eine Autorisierung enthält Angaben zur Implementierung, zum Netzwerkbezug und zur Nonce des Kontos. Diese Informationen sind wesentlich. Ein Vertrag kann auf einer Kette geprüft sein, auf einer anderen aber fehlen, anders aussehen oder ungeprüft sein. Eine Adresse, die einer offiziellen Adresse ähnelt, reicht als Nachweis nicht aus.

Das Protokoll erlaubt auch eine Chain-ID von null, die die Autorisierung nicht an eine einzige Kette bindet. Trotzdem funktioniert nicht jede Signatur überall: Nonce-Bedingungen und Unterstützung durch das Netzwerk bleiben relevant. Eine Wallet sollte diesen Geltungsbereich verständlich zeigen, statt ihn in einer allgemeinen Signaturanfrage zu verstecken.

Nutzer sollten keine Signaturcodierung von Hand rekonstruieren müssen. Verwenden Sie dokumentierte und unterstützte Implementierungen, prüfen Sie das Netzwerk und lehnen Sie beliebige Delegationsadressen ab, die eine Anwendung vorgibt. Die offizielle Wallet-Dokumentation ist wichtiger als ein Werbefenster der verbundenen Website.

Das größte Risiko ist nicht vertrauenswürdiger Code

Im Kontokontext ausgeführter Code kann deutlich mehr bewirken als eine reine Kontostandsabfrage. Eine bösartige oder fehlerhafte Implementierung kann Vermögenswerte und Berechtigungen gefährden. Verifizierter Quellcode auf einem Explorer hilft bei der Identifikation, ist jedoch nicht mit einer unabhängigen Sicherheitsprüfung gleichzusetzen.

Fragen Sie nach unabhängigen Prüfungen, aktualisierbaren Bestandteilen und der Kontrolle über Änderungen. Ein Audit betrifft eine bestimmte Version und einen definierten Umfang. Es garantiert nicht jede zukünftige Konfiguration. Auch eine bekannte Wallet sollte erklären, welche Implementierung verwendet wird und welcher Ablauf bei Problemen vorgesehen ist.

Signieren Sie keine beliebige Delegation zur angeblichen Wallet-Verifizierung, für eine Belohnung oder zur Behebung einer behaupteten Störung. Angreifer können eine weitreichende Kontoänderung als Routine darstellen. Wenn die Oberfläche Website-Zugang und Kontokontrolle nicht sauber trennt, ist Abbrechen sicherer als experimentelles Freigeben.

Entfernung bedeutet keinen vollständigen Neustart

Eine neue Autorisierung zur Nulladresse kann den Delegationscode entfernen. Nutzen Sie vertrauenswürdige, kompatible Werkzeuge und überprüfen Sie anschließend den Zustand auf dem richtigen Netzwerk. Folgen Sie keinen privaten Anweisungen unbekannter Personen und importieren Sie keine Seed-Wörter in einen vermeintlichen Bereinigungsdienst.

Die Entfernung löscht nicht automatisch den Kontospeicher, bestehende Token-Freigaben oder sämtliche Rechte anderer Anwendungen. Diese Ebenen können zusätzliche Prüfungen erfordern. Ist der private Schlüssel kompromittiert, wird er durch das Entfernen der Delegation nicht wieder geheim. Ein Angreifer kann weiterhin über den gestohlenen Schlüssel verfügen.

Auch bereits signierte, noch nicht verwendete Autorisierungen verdienen Aufmerksamkeit. Eine Website zu trennen vernichtet keine schon übermittelten Signaturen. Das richtige Vorgehen hängt von den Wallet-Werkzeugen und dem Kontozustand ab. Bei erheblichen Beträgen oder einem laufenden Vorfall ist qualifizierte Unterstützung sinnvoller als eine Reihe unverstandener Aktionen.

Hardware-Wallets brauchen echte Unterstützung

Ein Hardware-Gerät schützt die Aufbewahrung des Schlüssels, macht aber eine vom Nutzer genehmigte Signatur nicht automatisch harmlos. Wenn das Display den Autorisierungstyp nicht erklärt oder unverständliche Daten zeigt, kann die praktische Sicherheit leiden. Prüfen Sie sowohl Herstellerangaben als auch die Unterstützung durch die verwendete Software.

Unser Hardware-Wallet-Leitfaden erläutert diese Grenze. Den Schlüssel vom Computer zu trennen ist hilfreich. Trotzdem müssen Sie verstehen, was Sie bestätigen. Umgehen Sie fehlende Unterstützung nicht durch deaktivierte Warnungen oder Konfigurationen einer unbekannten Website.

Eine neue Funktion kontrolliert ausprobieren

Ein erfolgreicher Test beweist nur, dass eine bestimmte Aktion unter bestimmten Bedingungen funktioniert hat. Er beweist nicht, dass alle Berechtigungen eng begrenzt sind oder spätere Änderungen ungefährlich bleiben. Notieren Sie deshalb Netzwerk, Implementierung und das von der Wallet beschriebene Ergebnis. Prüfen Sie, ob weitere Aktionen einen veränderten Signaturablauf verwenden.

Trennen Sie außerdem Anzeige und tatsächliche Durchsetzung. Ein Feld mit einem Tageslimit ist nur dann eine Sicherheitsgrenze, wenn der relevante Code es korrekt kontrolliert. Eine abgeschaltete Oberfläche kann bereits eingeräumte Rechte nicht automatisch beseitigen. Ebenso ist eine Sitzung im Browser etwas anderes als eine Sitzungserlaubnis, die im Kontosystem gespeichert oder durch eine Signatur begründet wurde.

Bei einer unklaren Anfrage ist nicht entscheidend, ob der angezeigte Betrag klein ist. Eine Änderung am ausführenden Code kann ein größeres Risiko erzeugen als der unmittelbar sichtbare Transfer. Lesen Sie die Beschreibung des Autorisierungstyps, vergleichen Sie sie mit der offiziellen Dokumentation und brechen Sie ab, wenn beide nicht zusammenpassen. Ein Test mit wenig Geld ersetzt diese Prüfung nicht.

Dokumentieren Sie für eine spätere Prüfung nur die notwendigen öffentlichen Angaben. Netzwerk, Kontoadresse und verwendete Implementierung helfen, einen Vorgang einzuordnen. Seed-Wörter oder private Schlüssel gehören nicht in ein Support-Ticket, einen Screenshot oder eine Online-Notiz. Auch vermeintlich hilfreiche Personen dürfen diese Daten nicht erhalten.

Wenn Sie ein Problem melden, beschreiben Sie getrennt die Signaturanfrage, den Status der Transaktion und den beobachteten Kontozustand. So wird nicht versehentlich der fehlgeschlagene Tausch mit einer entfernten Delegation gleichgesetzt. Prüfen Sie den offiziellen Supportkanal unabhängig von privaten Nachrichten. Ein technischer Fachbegriff oder ein bekanntes Profilbild beweist weder Zuständigkeit noch Vertrauenswürdigkeit.

Bleibt der Zweck einer Signatur unklar, ist eine spätere Entscheidung besser als eine sofortige Freigabe unter Zeitdruck.

Checkliste vor der Aktivierung

  • Dokumentiert die Wallet Unterstützung für das richtige Netzwerk?
  • Ist die Implementierung von der Wallet geprüft statt beliebig vorgegeben?
  • Wer bezahlt Gas und welche zusätzlichen Kosten bleiben?
  • Wer setzt Limits durch und wer kann sie ändern?
  • Kennen Sie unterstützte Werkzeuge für Prüfung und Entfernung?
  • Sind Delegation, Token-Freigaben und ausstehende Signaturen getrennt betrachtet?

EIP-7702 kann ein bestehendes Konto flexibler machen. Sinnvoll ist nicht, jede neue Funktion zu aktivieren, sondern den autorisierten Code und seine Grenzen zu verstehen. Eine bessere Bedienung hilft nur dann, wenn sie keine Sicherheitsentscheidung verbirgt, die weiter reicht als die ursprünglich beabsichtigte Handlung.

Primärquellen, geprüft am 30. September 2026: EIP-7702-Spezifikation; Ethereum-Erklärung zu Pectra und Delegation; Ethereum-Dokumentation. Dies ist eine Risikoerklärung, keine universelle Wiederherstellungsanleitung oder Finanzempfehlung.