Was ist Konto-Abstraktion (ERC-4337)?

Wenn du dich in den letzten Jahren auch nur ein bisschen im Ethereum-Umfeld bewegt hast, ist dir der Begriff „Account Abstraction" wahrscheinlich begegnet — meist in Verbindung mit dem Codenamen ERC-4337. Das klingt akademisch, doch die Idee dahinter ist sehr praktisch: Dein Ethereum-Wallet sollte sich wie ein kleines, anpassbares Stück Software verhalten, nicht wie ein einzelner privater Schlüssel mit einer „Friss oder stirb"-Schnittstelle.

In diesem Artikel erklären wir, was ERC-4337 tatsächlich verändert, die vier neuen Begriffe, die es einführt (UserOperation, EntryPoint, Bundler, Paymaster), was es in der Praxis ermöglicht und wie es sich zum multisig-Ansatz von SSP verhält. Vorkenntnisse zu Smart Contracts sind nicht nötig — nur Neugierde darauf, wie Krypto-Wallets unter der Haube funktionieren.

Das Problem, das ERC-4337 lösen wollte

Vor der Konto-Abstraktion war jedes Ethereum-Wallet ein sogenanntes externally-owned account — ein EOA. Ein EOA ist denkbar einfach: Ein privater Schlüssel kontrolliert eine Adresse, und jede Aktion dieser Adresse muss von genau diesem Schlüssel signiert werden.

Diese Einfachheit hat ihre scharfen Kanten:

• Keine Wiederherstellung. Schlüssel weg, Geld weg. Es gibt keinen „Passwort vergessen"-Link, keinen vertrauenswürdigen Kontakt, der für dich bürgen kann, kein zeitverzögertes Entsperren. Der Schlüssel ist das Konto.
• Kein Batching. Du willst einen Token freigeben und ihn dann tauschen? Das sind zwei separate Transaktionen, zwei separate Signaturen, zwei separate Gas-Zahlungen. Es gibt keine Möglichkeit zu sagen: „Mach das zusammen oder gar nicht."
• Kein natives multisig. Wolltest du mehrere Unterzeichner, musstest du einen Contract deployen (etwa Safe, früher Gnosis Safe) und dann ein EOA Transaktionen an diesen Contract senden lassen. Der Contract war multisig, aber das Konto, das mit der Außenwelt interagierte, war darunter immer noch ein EOA mit einem einzigen Schlüssel. Die User Experience war damit gegenüber einem regulären Wallet immer zweitklassig.
• Gas immer in ETH bezahlt, immer vom Absender. Keine dApp konnte dein Gas übernehmen. Kein Gas-Zahlen in USDC. Keine Ausnahmen.

Entwickler hatten sich jahrelang mit aufwendigen Contract-Mustern um diese Beschränkungen herumgemogelt. ERC-4337 lieferte ihnen endlich einen standardisierten Ausweg — und das, ohne dass Ethereums Basisprotokoll angepasst werden müsste.

Was ERC-4337 einführt

ERC-4337 ändert nicht, wie Ethereum selbst auf Protokollebene funktioniert — das ist der clevere Kniff. Stattdessen definiert es vier neue Rollen, die zusammen „Smart-Contract-Wallets als gleichberechtigte Bürger" vollständig im User Space simulieren. Wenn man diese vier Wörter einmal verinnerlicht hat, fügt sich der gesamte Standard nahtlos zusammen.

UserOperation. Das ist das neue Objekt einer „signierten Absicht", das die rohe Transaktion für ein AA-Wallet ersetzt. Während ein EOA eine mit seinem einzigen Schlüssel signierte Transaktion erzeugt, erzeugt ein AA-Wallet eine UserOperation — eine strukturierte Anfrage, die sagt: „Dieses Konto will X tun, hier ist die Autorisierung, hier ist, wie dafür bezahlt wird." Eine UserOperation könnte sagen: „Überweise 100 USDC an Alice, autorisiert durch Signaturen dieser beiden Geräte, und die dApp übernimmt das Gas."

EntryPoint-Contract. Ein einziger, kanonischer, auditierter Smart Contract, der auf Ethereum deployt ist. Er weiß, wie er UserOperations entgegennimmt, sie gegen die Regeln des AA-Wallets prüft, aus dem sie stammen, und die daraus folgenden Aktionen ausführt. Jedes AA-Wallet spricht mit demselben EntryPoint — genau das macht den Standard zu einem Standard.

Bundler. Ein Off-Chain-Akteur (man kann ihn sich als spezialisierten Relayer vorstellen), der UserOperations in einem öffentlichen Mempool entgegennimmt, mehrere davon zusammenfasst und das Paket als eine einzige Ethereum-Transaktion an den EntryPoint schickt. Der Bundler zahlt das eigentliche Gas an das Netzwerk und wird von den gebündelten UserOperations dafür entschädigt.

Paymaster. Ein optionaler Contract, der sich freiwillig melden kann, das Gas im Namen eines Nutzers zu übernehmen. Der Paymaster ist es, der „die dApp zahlt dein Gas" oder „Gas in USDC statt ETH bezahlen" möglich macht. Ohne Paymaster zahlt das AA-Wallet des Nutzers sein Gas selbst; mit einem springt der Paymaster ein.

Mehr Vokabular gibt es nicht. Alles andere ist Beiwerk.

Was Konto-Abstraktion in der Praxis ermöglicht

Die vier Bausteine oben klingen abstrakt, bis man sieht, was sie freischalten:

• Gas-Sponsoring. Eine dApp kann Gas für neue Nutzer übernehmen, sodass diese kein ETH besorgen müssen, bevor sie überhaupt etwas tun. Für das Onboarding ist das enorm — neue Nutzer können sich anmelden, ein NFT minten oder ihren ersten Trade platzieren, ohne vorher durch einen Fiat-zu-ETH-Einstieg zu müssen. Argent, Safe und ZeroDev unterstützen Sponsoring-Flows heute schon.
• Soziale Wiederherstellung. Du kannst dein Wallet so konfigurieren, dass eine ausreichende Anzahl von „Guardians" (Freunde, Familie, ein Hardware-Gerät im Tresor) den Schlüssel in deinem Namen rotieren kann, falls du deinen Hauptschlüssel verlierst. Die Recovery-Logik lebt in deinem Wallet-Contract — kein zentralisierter Verwahrer hält dein Geld, und gleichzeitig ist es nicht für immer weg, wenn ein einzelnes Gerät ausfällt.
• Session Keys. Eine dApp kann von deinem Wallet einen Schlüssel mit eingeschränkten Rechten anfordern, der auf eine Anwendung und einen bestimmten Satz von Aktionen begrenzt und nur ein paar Stunden gültig ist. Du signierst einmal mit deinem Hauptschlüssel, um die Session zu gewähren, und die dApp kann anschließend in ihrer Sandbox agieren, ohne dich bei jedem Klick um Bestätigung zu bitten. Spielestudios lieben dieses Muster.
• Gebatchte Aktionen. „Token freigeben UND tauschen" wird zu einer Signatur, einer UserOperation, einer Ausführung. Wenn ein Schritt fehlschlägt, wird das gesamte Paket zurückgerollt — keine halbfertigen Transaktionen mehr, die in einem inkonsistenten Zustand hängen bleiben.
• Eigene Signatur-Schemata. Du willst ein Wallet, das Passkeys, ein Hardware-Enclave oder ein 2-of-3-Schwellenverfahren nutzt? Die Verifikationslogik lebt im Wallet-Contract, also kannst du jede Kryptographie verwenden, die dir passt — nicht nur das für EOAs standardmäßige ECDSA auf secp256k1.

Wie sich das zum multisig-Modell von SSP verhält

SSP Wallet geht einen anderen Weg, um viele derselben Ziele zu erreichen. SSP setzt auf ein 2-of-2 BIP48 multisig — zwei unabhängige Schlüssel auf zwei unabhängigen Geräten, beide nötig, um irgendeine Transaktion zu signieren. ERC-4337 und BIP48-multisig sind unterschiedliche Mechanismen, die ein gemeinsames Problem angehen: Kein einzelnes Gerät darf ein Single Point of Failure sein.

Ein paar ehrliche Vergleiche:

• Was sie gemeinsam haben. Beide eliminieren den „ein Schlüssel, eine Chance"-Fehlermodus klassischer Single-Signature-Wallets. Verlierst du einen Faktor, kannst du mit dem anderen wiederherstellen. Wird ein Faktor kompromittiert (Malware auf einem Laptop, verlorenes Handy), kann ein Angreifer trotzdem nicht allein Gelder bewegen.
• Wo sie sich unterscheiden. BIP48 ist ein multisig-Standard mit Wurzeln in Bitcoin, der über die von SSP unterstützten Chains hinweg funktioniert — Bitcoin, Ethereum, Litecoin und einige weitere — und dabei die nativen multisig-Primitiven jeder Chain nutzt. ERC-4337 ist Ethereum-only und lebt auf der Smart-Contract-Ebene; deshalb kommt es mit Fähigkeiten, die BIP48 nativ nicht hat (Gas-Sponsoring, Session Keys), aber zum Preis von Ethereum-only-Reichweite und Contract-Execution-Overhead.
• Wo SSP heute steht. SSP ist um das BIP48-Modell herum gebaut. ERC-4337-Wallets und SSP-artiges multisig sind keine Feinde — sie sind ergänzende Werkzeuge — und prinzipiell könnte ein BIP48-multisig-Schlüssel als Signer innerhalb eines AA-Wallets dienen. Das ist derzeit nicht der Hauptweg von SSP, und wir sind lieber klar über das, was wir heute liefern, statt Integrationen zu versprechen, die wir nicht ausgeliefert haben.

Wenn du dich gefragt hast: „Soll ich ein AA-Wallet oder ein Hardware-multisig nutzen?" — die ehrliche Antwort ist, dass beide überlappende Probleme mit unterschiedlichen Trade-offs lösen, und die richtige Antwort davon abhängt, welche Chains dir wichtig sind.

Die ehrlichen Trade-offs

Konto-Abstraktion ist ein echter Fortschritt, aber sie ist nicht umsonst, und wer dir etwas anderes erzählt, will dir etwas verkaufen.

• Die Gas-Kosten sind höher. Jede UserOperation führt Contract-Code im EntryPoint und in deinem Wallet-Contract aus. Das ist strikt mehr Rechenarbeit als eine von einem EOA signierte Transaktion, also auch mehr Gas. Bundling amortisiert einen Teil davon, aber pro Aktion zahlst du in der Regel mehr als ein EOA es täte.
• Die Wiederherstellung ist nur so gut wie der Recovery-Contract. Soziale Wiederherstellung und Guardian-Schemata sind mächtige Funktionen — und gleichzeitig neue Angriffsoberfläche. Ein Bug in der Recovery-Logik oder ein zu klein bemessener Guardian-Satz kann genauso katastrophal sein wie der Verlust eines EOA-Schlüssels. Halte dich an auditierte Wallet-Implementierungen.
• Paymasters schaffen ein Vertrauensverhältnis. „Die dApp zahlt das Gas" klingt großartig, bedeutet aber, dass der Paymaster deine UserOperations sieht und sich prinzipiell weigern kann, bestimmte Transaktionen zu sponsern. Das ist ein anderes Vertrauensmodell als „du zahlst dein Gas selbst, niemand kann dich blockieren".
• Weniger im Großbetrieb erprobt. EOAs haben über mehr als ein Jahrzehnt Billionen an Werten gesichert. ERC-4337 ging im März 2023 live und reift noch. Für hochwertiges Cold Storage hat die konservative Antwort (Hardware-Wallet, multisig, auditierte Contracts) immer noch die längere Erfolgsbilanz.

Tiefer einsteigen

Für die SSP-Sicht darauf, wie Multi-Key-Sicherheit ohne Smart Contracts funktioniert, lies Was ist 2-of-2 multisig?.

Für die kanonische technische Spezifikation — inklusive der genauen UserOperation-Struktur, des EntryPoint-Interfaces und der Begründungen hinter jeder Designentscheidung — ist der EIP selbst die primäre Quelle: https://eips.ethereum.org/EIPS/eip-4337.