Account Abstraction (ERC-4337) in Produktion: Was sie ermöglicht und was nicht

ERC-4337 ist Infrastruktur für programmierbare Accounts, kein fertiges Versprechen für gaslose Transaktionen, Recovery, Passkeys, Session Keys, niedrigere Gebühren oder Sicherheit. Es definiert einen UserOperation-Ablauf mit Smart Account, Bundler, EntryPoint und optionalem Paymaster. Produkteigenschaften entstehen aus der gewählten Account-Implementierung und den Diensten.

Wavect hat an Produkten für Account Abstraction gearbeitet, darunter die veröffentlichte AA-Fallstudie und MetaMask-Snap-Arbeit. Diese Projekte prägen die Checkliste, beweisen aber nicht, dass ein Stack zu jeder Wallet passt.

Was ist ERC-4337?

ERC-4337 führt UserOperations über eine zusätzliche Infrastrukturschicht ein, ohne den Ethereum-Konsens zu ändern. Der Nutzer sendet eine UserOperation an einen Bundler. Dieser validiert und bündelt Operationen in einer Transaktion zum EntryPoint. Der Smart Account prüft die Autorisierung und führt Aufrufe aus. Ein optionaler Paymaster kann Gebühren nach seiner Policy übernehmen. Die Spezifikation definiert Replay-Bindung, Validierung, Deposits, Stakes, Simulation und Ausführung (ERC-4337-Spezifikation).

Das Signaturfeld wird von der Smart-Account-Implementierung interpretiert. Diese Flexibilität kann verschiedene Autorisierungsverfahren unterstützen, aber ERC-4337 allein erzeugt keine Passkeys, Guardians, Recovery, Ausgabenlimits oder Session Keys.

Was kann ein konkreter Smart-Account-Stack ermöglichen?

• Gesponserte Gebühren. Ein Paymaster kann Netzwerkgebühren zahlen, wenn seine Validierung die Operation akzeptiert. Der Sponsor braucht dennoch Policy, Deposits, Budgets, Missbrauchsschutz und Abstimmung.
• Alternative Gebühreneinziehung. Sponsoring kann mit Offchain-Abrechnung oder Token-Settlement kombiniert werden, abhängig von Implementierung, Preis, Liquidität und Regulierung.
• Mehrere Aufrufe. Ein Account kann gemäß seinem Code mehrere Calls ausführen. Ob dafür eine Nutzerfreigabe genügt und Gas gespart wird, hängt von Implementierung und Last ab.
• Eigene Autorisierung. Der Account kann unterstützte Signaturverfahren, Passkeys, Multisig, Guardians, Rollen oder eingeschränkte Delegierte prüfen.
• Recovery und Rotation. Die Wallet kann Schlüsselrotation oder Recovery definieren. Deren Sicherheit folgt Faktoren, Fristen, Abbruchpfad und Governance.
• Deployment bei erster Nutzung. Eine Factory kann den kontrafaktischen Account bei Verarbeitung der UserOperation erstellen.

Was garantiert ERC-4337 nicht?

• Gaslosen Betrieb. Jemand bezahlt die Netzwerkgebühren, und fehlgeschlagene oder revertierte Operationen können Kosten erzeugen.
• Niedrigere Gas-Kosten. Validierung, EntryPoint, Paymaster, Factory und Account-Ausführung bringen zusätzliche Arbeit. Batching kann Teile amortisieren, muss aber gemessen werden.
• Sichere Recovery. Recovery kann Schlüsselverlustrisiko senken und zugleich Guardian-, Identitäts-, Verzögerungs-, Zwangs- und Social-Engineering-Risiken erhöhen.
• Dezentralisierung oder Verfügbarkeit von Bundlern. Prüfe kompatible Betreiber, Policies, EntryPoint-Unterstützung, Failover, Zensur und Service-Level.
• Chain-übergreifende Identität. Adressen, Deployments, Deposits, Provider, Zustand und Funktionen können je Chain abweichen.
• Verständliche Einwilligung. Mehrere Calls und delegierte Rechte brauchen weiterhin korrekte Simulation und klare Autorisierung.

Welche Angriffsflächen brauchen explizite Tests?

Wie sollte ein Paymaster gestaltet sein?

Definiere Berechtigte, erlaubte Calls, Maximalkosten, Zeit- und Replay-Bindung, Budgets, Rate Limits, Preisbildung, Autorisierung und Accounting. Unterstelle feindliche Eingaben. Ein Paymaster hält ein Deposit für Gebühren und, falls sein Validierungsverhalten es verlangt, einen Stake. Er kann auch bei einem Revert zahlen.

Die ERC-4337-Dokumentation beschreibt Risiken wie Deposit-Abfluss, hohe Kosten, revertierte Calls, Timeouts und Races sowie deterministische Validierung und Bundler-Simulation (Paymaster-Sicherheitsleitfaden). Behandle Offchain-Signer und APIs als Teil der Sicherheitsgrenze.

Wie unterscheiden sich EOAs und ERC-4337 Smart Accounts?

Eine Externally Owned Account hat eine feste Protokollautorisierung über ihren Schlüssel. Ein Smart Account kann reichhaltigere Validierung und Ausführung ergänzen, bringt aber Code-, Konfigurations-, Service- und Governance-Risiken mit. Keine Option ist grundsätzlich richtig für Verbraucher, Betreiber oder Vielnutzer.

Vergleiche konkrete Optionen bei Onboarding, unterstützten Wallets, Recovery, Autorisierung, Transaktionssimulation, Gas, Latenz, Verfügbarkeit, Upgrades, Audits, Integrationen, Support und Exit. Unterstelle weder, dass eine EOA keinen Recovery-Pfad hat, noch dass ein Smart Account immer einen besitzt.

"Account Abstraction schafft eine programmierbare Sicherheitsgrenze. Ihre Sicherheit hängt vom Programm, den Authorities, Diensten und dem tatsächlich ausgelieferten Recovery-Pfad ab."

Was ist EIP-7702?

EIP-7702 ist eine Protokollfunktion, mit der eine EOA einen Delegationsindikator auf Code setzen kann. Die Delegation bleibt bestehen, bis sie geändert oder gelöscht wird, und gilt nicht nur für eine Transaktion. Sie kann Batching, Sponsoring und eingeschränkte Unterschlüssel unterstützen, bringt aber Initialisierungs-, Storage-, Delegations-, Relayer- und Kompatibilitätsrisiken mit.

Der EIP definiert das Autorisierungstupel und die persistente Code-Delegation. Er dokumentiert Sicherheitsaspekte wie Initialisierungs-Front-Running, Storage-Verwaltung, Griefing gesponserter Relayer und Interaktionen mit tx.origin (EIP-7702). ERC-4337 definiert außerdem, wie delegierte EIP-7702-Accounts UserOperations senden. Die Ansätze können sich ergänzen.

Kannst du einen eigenen Bundler betreiben?

Ja, wenn die Implementierung die relevanten EntryPoint- und Mempool-Regeln unterstützt. Eigenbetrieb umfasst Node-Abhängigkeiten, Simulation, Gebührenschätzung, Mempool-Policy, Reputation, Monitoring, Updates, DoS-Schutz, Schlüsselbetrieb und Bereitschaft. Ein Hosted Provider bringt Gegenpartei-, Kompatibilitäts-, Verfügbarkeits-, Policy-, Datenschutz- und Exit-Risiken.

Entscheide anhand gemessener Anforderungen. Teste mindestens einen Fallback, wenn das Produkt Kontinuität verspricht, und prüfe, ob Failover Operationsstatus, Idempotenz, Gebühren und Nutzerkommunikation erhält.

Brauchst du einen eigenen Account Contract?

Nicht standardmäßig. Prüfe gewartete Implementierungen anhand von Signaturverfahren, Modulen, Recovery, Upgrades, Standards, Chains, EntryPoint-Version, Audit-Historie, Incident Response, Integrationssupport und Governance. Die Behauptung, benannte Implementierungen deckten 90 Prozent realer Anforderungen ab, ist nicht belegbar.

Baue eigenen Code nur, wenn eine dokumentierte Anforderung unerfüllt bleibt und der Nutzen Design, Tests, unabhängiges Audit, Monitoring, Upgrades und Migration rechtfertigt. Wiederverwendung ersetzt keine Prüfung von Konfiguration und Modulen.

Welche Evidenz sollte den Produktionsstart freigeben?

1. Fixiere unterstützte Versionen von Account, EntryPoint, Factory, Modul, Paymaster, Bundler, Chain und Client.
2. Dokumentiere Eigentümer für Autorisierung, Recovery, Upgrades, Pause, Deposits, Sponsoring und Notfälle.
3. Teste Replay-, Initialisierungs-, Signatur-, Nonce-, Modul-, Delegierten-, Paymaster-, Simulations-, Fehler- und Upgrade-Pfade.
4. Miss Gas und Latenz für repräsentative erfolgreiche, revertierte, gesponserte, gebündelte und Recovery-Operationen.
5. Führe eine unabhängige Prüfung der Risikogrenze einschließlich Konfiguration und Integrationen durch.
6. Übe Bundler- und Provider-Ausfall, Deposit-Erschöpfung, Schlüsselkompromittierung, Rollback und Nutzersupport.
7. Überwache akzeptierte Ergebnisse, Ablehnungsgründe, Sponsoringkosten, Bundler-Zustand, Account-Versionen und privilegierte Änderungen.

Wenn eine Operation zwischen Wallet, Bundler, Paymaster und EntryPoint scheitert, füge das exakte Artefakt in unseren kostenlosen ERC-4337 UserOperation Debugger ein. Er trennt gepackte Felder und AA-Fehlercodes lokal ohne weiteren RPC-Aufruf. Unser Blockchain-Engineering-Service kann helfen, aus dem Bedrohungsmodell Implementierung und Evidenz zu machen.