Account Abstraction von Grund auf

Wenn Sie jemals eine selbstverwaltete Wallet auf Ethereum genutzt haben, haben Sie ein extern besessenes Konto — eine EOA — verwendet, ob Sie es wussten oder nicht. Das Gespräch über Account Abstraction beginnt damit zu verstehen, was eine EOA ist, warum ihr Design alles einschränkt, was Sie on-chain tun können, und wie ERC-4337 Account Abstraction diese Einschränkungen umgeht, ohne das Basisprotokoll anzutasten. Dieser Artikel ist der Einstiegspunkt in eine Serie, die Sie von den ursprünglichen Einschränkungen bis dahin führt, wie SSP Account Abstraction nutzt, um sein 2-von-2-multisig auf EVM-Chains zu betreiben.

Dies ist das grundlegende, konzeptionelle Stück. Für eine fokussierte Darstellung des ERC-4337-Standards selbst lesen Sie Was ist Account Abstraction (ERC-4337)? ergänzend zu diesem Artikel; hier bauen wir die Intuition dafür auf, warum der Standard existiert.

Das Konto, das Ethereum Ihnen gab

Ethereum hat zwei Arten von Konten. Vertragskonten werden durch Code regiert. EOAs — die gewöhnlichen Wallets, die die meisten Menschen nutzen — werden durch einen einzigen privaten Schlüssel regiert. Wer diesen Schlüssel besitzt, kann jede Transaktion aus dem Konto autorisieren, und das Protokoll validiert genau eine Sache: dass die Transaktion eine gültige ECDSA-Signatur über die secp256k1-Kurve trägt, erzeugt durch den Schlüssel, der die Adresse kontrolliert.

Diese eine Regel ist elegant, und sie ist zugleich der Ursprung jeder unten besprochenen Einschränkung. Die Gültigkeit einer Transaktion ist im Protokoll fest verdrahtet. Sie, der Kontoinhaber, dürfen nicht entscheiden, was „gültig“ bedeutet. Das Protokoll entscheidet, und es kann nur ein Signaturschema eines einzigen Schlüssels prüfen.

Was dieses Design grundlegend einbaut

Vier Einschränkungen folgen direkt aus dem Ein-Schlüssel-eine-Signatur-Modell:

• Ein Schlüssel ist ein einzelner Ausfallpunkt. Verlieren Sie den Schlüssel, sind die Gelder weg. Geben Sie ihn preis, hat ein Angreifer alles. Es gibt keinen zweiten Faktor auf Protokollebene, keinen Mitunterzeichner, keine Richtlinie, die den Diebstahl hätte blockieren können.
• Keine eigene Validierungslogik. Eine EOA kann nicht sagen „verlange zwei Signaturen“, noch „erlaube diese kleine Zahlung automatisch, aber verlange zusätzliche Freigabe oberhalb einer Schwelle“, noch „lass diesen Schlüssel nur werktags ausgeben“. Das Konto hat keine Logik. Es hat eine Signaturprüfung.
• Der Absender muss ETH für gas halten. Jede EOA-Transaktion bezahlt ihr eigenes gas in ETH. Ein neuer Nutzer, der nur einen ERC-20-Token, aber kein ETH besitzt, kann diesen Token nicht bewegen, weil er die Gebühr nicht bezahlen kann. Gebührenzahler und Transaktionsabsender sind gezwungen, dasselbe Konto zu sein.
• Die Seed-Phrase-UX kennt keine Gnade. Da der Schlüssel das Konto ist, bedeutet der Einstieg, eine Seed-Phrase aufzuschreiben und sie für immer zu schützen. Es gibt keinen Wiederherstellungsweg, der nicht diese Phrase einbezieht, und ein einziger Fehler ist von Dauer.

Das sind keine Bugs. Es sind die Folgen davon, dass die Validierung im Protokoll statt im Konto wohnt.

Die Kernidee: das Konto programmierbar machen

Account Abstraction ist die Idee, diese Validierungslogik aus dem Protokoll herauszunehmen und in das Konto selbst zu verlegen. Statt dass das Netzwerk fest kodiert „eine Transaktion ist gültig, wenn sie eine korrekte ECDSA-Signatur hat“, entscheidet ein smart account — ein Vertrag, der Ihre Gelder hält — selbst, was als gültige Transaktion zählt.

Sobald das Konto ein programmierbarer Vertrag ist, lösen sich die vier Einschränkungen in Designentscheidungen auf:

• Es kann zwei Signaturen statt einer verlangen, was genau der Weg ist, auf dem multisig ohne native Protokollunterstützung möglich wird.
• Es kann Wiederherstellungsregeln umsetzen, sodass ein verlorener Schlüssel nicht länger das Ende der Geschichte ist.
• Es kann jemand anderen das gas bezahlen lassen und so den Gebührenzahler vom Absender trennen.
• Es kann mehrere Aktionen — etwa Freigeben und Tauschen — in einer einzigen atomaren Operation bündeln.

Das Konto hört auf, ein passives Schlüsselpaar zu sein, und wird zu programmierbarer Logik, die Sie kontrollieren.

Wie ERC-4337 dies ohne Hard Fork liefert

Das Schwierige ist, dass eine Änderung daran, wie Ethereum Transaktionen validiert, normalerweise eine Änderung des Basisprotokolls bedeutet — ein langsames, umstrittenes, netzwerkweites Upgrade. ERC-4337 umgeht das vollständig. Es führt Account Abstraction als Schicht über dem bestehenden Netzwerk ein, ohne dass Konsensänderungen nötig sind.

Der Mechanismus ruht auf einigen Bausteinen:

• UserOperations. Statt eine normale Transaktion zu senden, drückt ein smart account die Absicht als UserOperation aus — ein strukturiertes Objekt, das beschreibt, was das Konto tun möchte und wie es validiert werden soll.
• Ein alternativer mempool. UserOperations leben in ihrem eigenen mempool, getrennt von gewöhnlichen Transaktionen.
• Bundlers. Ein bundler sammelt UserOperations aus diesem mempool, packt sie zusammen und reicht sie als tatsächliche Transaktion bei der Chain ein, wobei er das gas der Basisschicht bezahlt.
• Der EntryPoint-Vertrag. Ein einziger, geprüfter EntryPoint-Vertrag ist der On-Chain-Engpass. Er ruft jeden smart account auf, um dessen eigene Validierungslogik auszuführen, und führt die Operation dann aus, wenn die Validierung besteht.
• Paymasters. Ein optionaler paymaster-Vertrag kann zustimmen, das gas für eine UserOperation zu übernehmen, was gaslose und Bezahlung-per-Token-Abläufe möglich macht.

Zusammengenommen lässt dies jeden Vertrag als vollständig programmierbares Konto auftreten, validiert nach seinen eigenen Regeln, während das zugrunde liegende Ethereum-Protokoll genau so bleibt, wie es war. Der Standard ist in EIP-4337 spezifiziert, und Ethereums eigene Account-Abstraction-Roadmap verfolgt, wohin sich das breitere Vorhaben bewegt.

Warum das für Nutzer der Selbstverwahrung wichtig ist

Für jemanden, der seine eigenen Schlüssel hält, ist Account Abstraction kein abstraktes Protokolldetail — es ändert, was eine Wallet sicher tun kann:

• Multisig ohne native Unterstützung. Ein smart account kann mehr als eine Signatur verlangen, sodass eine Wallet fordern kann, dass zwei unabhängige Geräte jede Überweisung freigeben. Das ist der Baustein, auf den SSP sich stützt, näher erläutert in EVM Multisig auf die Account-Abstraction-Art.
• Wiederherstellungsoptionen. Programmierbare Validierung öffnet die Tür zu Wiederherstellungsabläufen, die nicht auf eine einzige fragile Seed-Phrase zusammenfallen.
• Gas-Sponsoring. Paymasters bedeuten, dass die Gebühr vom Absender entkoppelt werden kann, was die schlimmste Einstiegsreibung glättet.
• Bündelung. Mehrere Schritte können als eine Operation abgewickelt werden, was sowohl Klicks als auch das Risiko reduziert, auf halbem Weg zu scheitern.

Der praktische Unterschied zwischen einer Einschlüssel-EOA und einem programmierbaren smart account ist groß genug, um eine eigene Behandlung zu verdienen — siehe EOA versus smart account: die Unterschiede, die zählen.

Wo SSP hineinpasst

SSP ist eine selbstverwaltete Wallet, die um 2-von-2-multisig herum gebaut ist. Ein Schlüssel lebt in der SSP-Wallet-Browsererweiterung; der zweite lebt in der SSP-Key-Mobil-App. Jede Transaktion wird in der Erweiterung erstellt und auf dem Telefon mitunterzeichnet, sodass kein Gerät allein Gelder bewegen kann.

Auf EVM-Chains liefert SSP dieses 2-von-2 mithilfe von ERC-4337. Die Wallet ist ein ERC-4337-smart-account, dessen Validierungslogik beide Schlüssel verlangt, und die zwei Teilsignaturen verbinden sich — im MuSig2-Stil über secp256k1 — zu einer einzigen Schnorr-aggregierten Signatur, die der Vertrag on-chain verifiziert. Die smart contracts von SSP wurden 2025 von Halborn geprüft. Das vollständige Design ist Gegenstand von SSP-Account-Abstraction-Architektur.

Mit anderen Worten: die oben beschriebene abstrakte Fähigkeit — ein Konto, das seine eigene Mehrfachsignatur-Regel durchsetzt — ist genau das, was SSP auf Ethereum, Polygon, Base und den übrigen unterstützten EVM-Chains in eine funktionierende Wallet verwandelt.

Der Rest dieser Serie

Dieses Stück hat das Problem und die Kernidee aufgestellt. Die Serie baut von hier aus weiter:

1. Account Abstraction von Grund auf — dieser Artikel: warum EOAs einschränkend sind und was Account Abstraction bedeutet.
2. EOA versus smart account: die Unterschiede, die zählen — ein direkter Vergleich der beiden Kontomodelle.
3. SSP-Account-Abstraction-Architektur — wie SSP ERC-4337 in eine 2-von-2-Wallet verdrahtet.
4. Gas-Sponsoring und Paymasters erklärt — wie Paymasters entkoppeln, wer zahlt, von wer sendet.
5. Account Abstraction auf Nicht-Ethereum-Chains — wie dieselbe Idee über Ethereum hinaus reist.

Beginnen Sie mit der ERC-4337-Erläuterung, wenn Sie den Standard isoliert wollen, und kommen Sie dann für das größere Bild hierher zurück. Von dort an hört das Konto auf, eine Einschränkung zu sein, und beginnt, etwas zu sein, um das herum Sie programmieren können.