Account Abstraction jenseits von Ethereum

Account Abstraction wird oft als eine Ethereum-Geschichte eingeführt — als ein Weg, eine Wallet mit einem einzigen Schlüssel mithilfe von ERC-4337 in ein programmierbares smart account zu verwandeln. Doch die Idee endet nicht bei Ethereum L1. Sie verbreitet sich auf zwei sehr unterschiedlichen Wegen: nach außen über die EVM-Chains, die sich Ethereums Ausführungsmodell teilen, und nativ in Chains hinein, die von Tag eins an mit fest im Protokoll verankerter Account Abstraction entworfen wurden. Dieser Artikel kartiert diese breitere Landschaft, erklärt, wie sich native Account Abstraction von dem auf Ethereum aufgesetzten ERC-4337-Standard unterscheidet, und achtet besonders auf eine Grenze: wo das allgemeine Ökosystem endet und wo das beginnt, was SSP tatsächlich unterstützt.

Dies ist der letzte Artikel unserer Account-Abstraction-Serie. Falls die Kernkonzepte neu für Sie sind, beginnen Sie mit Account Abstraction von Grund auf und vergleichen Sie anschließend die beiden Kontomodelle in EOA vs. smart account: Die Unterschiede, die zählen. Hier setzen wir voraus, dass Sie ungefähr wissen, was ein smart account ist, und weiten den Blick auf den Rest der Kryptowelt.

Derselbe Standard, überall wo die EVM läuft

Der erste Weg, auf dem sich Account Abstraction ausbreitet, ist der einfachste: Sie reist mit der EVM mit. ERC-4337 ist keine Änderung des Basisprotokolls. Es ist ein Standard auf Vertragsebene, aufgebaut auf einem EntryPoint-Vertrag, UserOperation-Objekten, Bundlern und optionalen Paymastern — und nichts davon erfordert Konsens-Änderungen. Diese Entwurfsentscheidung hat eine machtvolle Folge. Jede Chain, die die Ethereum Virtual Machine ausführt, kann denselben EntryPoint, dieselbe Bundler-Infrastruktur und dieselben smart-account-Verträge beherbergen.

Genau deshalb unterstützen die großen EVM-L2s und Sidechains ERC-4337 auf dieselbe Weise wie Ethereum:

• Polygon führt die EVM aus, also werden derselbe smart-account-Vertrag und derselbe EntryPoint ohne Änderung bereitgestellt.
• Base ist ein EVM-L2, auf dem ERC-4337-Account-Abstraction genauso funktioniert wie auf L1.
• BNB Smart Chain ist EVM-kompatibel und beherbergt denselben Standard.
• Avalanche C-Chain führt die EVM aus und unterstützt dieselbe Account Abstraction auf Vertragsebene.

Weil der Standard portabel ist, überträgt sich die smart-account-Logik einer für Ethereum geschriebenen Wallet im Wesentlichen unverändert auf diese Chains. Genau diese Portabilität ist es, die es SSP erlaubt, seinen Entwurf auf jeder von ihm unterstützten EVM-Chain laufen zu lassen — derselbe 2-of-2-Vertrag verhält sich identisch, ob er auf Ethereum, Polygon, Base, BNB Smart Chain oder Avalanche bereitgestellt wird. Für die praktische, chain-spezifische Sicht auf die Nutzung von SSP in diesen Netzwerken siehe SSP auf Polygon, Base und anderen EVM-Chains nutzen.

Native Account Abstraction: wenn sie das Protokoll ist, nicht eine Schicht

Der zweite Weg, auf dem sich Account Abstraction ausbreitet, ist grundlegend anders. Manche Chains haben nicht auf einen Opt-in-Standard gewartet — sie haben Account Abstraction direkt ins Protokoll eingebaut, sodass es überhaupt keine Unterscheidung zwischen „EOA und smart account" gibt. Jedes Konto ist standardmäßig ein smart account.

Starknet: jedes Konto ist ein Vertrag

Starknet hat Account Abstraction von Tag eins an. Auf Starknet gibt es keine extern besessenen Konten im Ethereum-Sinne; jedes Konto ist ein Vertragskonto, geschrieben in der Sprache Cairo. Weil das Kontoverhalten auf Protokollebene durch Vertragscode definiert ist, sind Signaturschemata, Validierungsregeln, multisig und Gebührenlogik Eigenschaften des Kontos selbst und keine nachträglich angefügten Funktionen.

Der Kontrast zu Ethereum ist aufschlussreich. Auf Ethereum ist das Standardkonto eine EOA mit einer fest verdrahteten ECDSA-Prüfung, und ERC-4337 existiert, um programmierbare Konten obendrauf zu schichten, ohne einen Hard Fork. Auf Starknet gibt es nichts zu schichten — das programmierbare Konto ist die Grundlinie. Es gibt keinen separaten EntryPoint-Standard zu übernehmen, denn Account Abstraction ist nicht optional. Die Starknet-Dokumentation unter docs.starknet.io beschreibt dieses Kontomodell im Detail.

zkSync Era: native AA mit eingebauten Paymastern

zkSync Era verfolgt einen ähnlichen protokollnativen Ansatz. Account Abstraction ist Teil des Protokolls statt eines Aufsatzes, und das System enthält eingebaute Paymaster-Unterstützung auf Protokollebene. Auf Ethereum ist ein Paymaster ein durch den ERC-4337-Standard definierter und über den EntryPoint geleiteter Vertrag; auf zkSync Era ist die Paymaster-Funktionalität ein erstklassiges Merkmal der Chain selbst, sodass das Sponsern von Gebühren oder das Bezahlen von gas in einem anderen Token Teil der Art ist, wie das Netzwerk funktionieren soll. Die zkSync-Dokumentation behandelt seine native Account Abstraction und sein Paymaster-Modell.

Native AA vs. ERC-4337: der Kernunterschied

Es lohnt sich, die Unterscheidung klar zu benennen, denn sie ist der konzeptionelle Kern dieses Artikels:

• ERC-4337 ist ein Opt-in-Standard, der auf ein unverändertes Protokoll aufgesetzt wird. Ethereums Basisschicht versteht nativ weiterhin nur EOAs und ihre einzige ECDSA-Signatur. Smart accounts existieren, weil sich Entwickler auf ein gemeinsames Set von on-chain- und off-chain-Komponenten geeinigt haben — den EntryPoint, den alternativen Mempool, die Bundler —, die Account Abstraction auf Protokollebene ohne Konsens-Änderung simulieren. Es ist gerade deshalb brillant, weil es keinen Hard Fork erforderte, und aus demselben Grund auf jede EVM-Chain portabel.
• Native Account Abstraction ist ins Protokoll eingebaut. Auf Starknet und zkSync Era behandelt die Chain selbst jedes Konto als programmierbar. Es gibt kein Opt-in, keinen separaten zu übernehmenden Standard und keine Unterscheidung zwischen einem „normalen" und einem smarten Konto — das smart account ist das Konto.

Beide liefern dem Endnutzer dieselben Vorteile: mehrere Unterzeichner, benutzerdefinierte Validierung, Wiederherstellungslogik und flexibles gas. Sie kommen lediglich aus entgegengesetzten Richtungen — die eine als sorgfältig konstruierte Schicht, die andere als grundlegende Protokollentscheidung. Wenn Sie die formale Spezifikation des geschichteten Ansatzes möchten, ist EIP-4337 die kanonische Referenz.

Wo SSP hineinpasst — und wo nicht

Dies ist die Grenze, bei der Genauigkeit gefragt ist. SSP ist eine selbstverwahrende Wallet, aufgebaut um ein 2-of-2-multisig: ein Schlüssel in der SSP-Wallet-Browser-Erweiterung, der zweite in der SSP-Key-Mobil-App, wobei kein Gerät allein Gelder bewegen kann. Auf EVM-Chains setzt SSP dies als ERC-4337 smart account um, dessen Validierungslogik eine einzige Schnorr-aggregierte Signatur prüft, die aus beiden Schlüsseln gebildet wird. SSPs smart contracts wurden 2025 von Halborn auditiert.

Weil ERC-4337 über die gesamte EVM hinweg portabel ist, überträgt sich SSPs Ansatz auf die von ihm unterstützten EVM-Chains: Ethereum, Polygon, Base, BNB Smart Chain und Avalanche C-Chain. Derselbe 2-of-2-smart-account-Vertrag läuft auf allen.

Starknet und zkSync Era erscheinen in diesem Artikel als Teil des breiteren Ökosystems — Beispiele für Chains, bei denen Account Abstraction nativ im Protokoll steckt. Sie sind nicht Teil von SSPs unterstütztem Chain-Set. SSP bringt ERC-4337-Account-Abstraction auf die oben aufgeführten EVM-Chains; es läuft nicht auf Starknet, zkSync Era oder anderen Nicht-EVM-Chains. Wenn Sie anderswo in der Kryptowelt über native AA lesen, behandeln Sie das als Kontext dafür, wie verbreitet das smart-account-Modell geworden ist, nicht als Aussage darüber, wo SSP arbeitet.

Warum das wichtig ist

Tritt man einen Schritt zurück, ist das Muster klar: Das smart-account-Erlebnis wird in weiten Teilen der Kryptowelt zum Standard, nicht zu einer Nischenfunktion für Power-User.

• Auf der EVM bringt ERC-4337 programmierbare Konten ohne Hard Fork zu Ethereum und jeder kompatiblen Chain, was es einer Wallet wie SSP ermöglicht, auf Polygon, Base, BNB Smart Chain und Avalanche dieselbe 2-of-2-Sicherheit anzubieten wie auf Ethereum.
• Auf nativ abstrahierten Chains stellt sich die Frage „ist das eine EOA oder ein smart account?" schlicht nicht, weil es nur eine Art von Konto gibt und dieses programmierbar ist.

Für einen Selbstverwahrungs-Nutzer ist die Erkenntnis, dass das starre Einzelschlüsselmodell nicht mehr die einzige Option ist und zunehmend auch nicht die Standardoption. Ob Account Abstraction als geschichteter Standard oder als natives Protokollmerkmal kommt — das Ziel ist dasselbe: Konten, die Sie programmieren können, mit Sicherheitsregeln — wie SSPs Zwei-Geräte-multisig —, die ein einzelner privater Schlüssel allein niemals durchsetzen könnte. Um zu wiederholen, wie sich dieses Modell mit dem ursprünglichen Ethereum-Konto vergleicht, siehe EOA vs. smart account: Die Unterschiede, die zählen, und für den Standard für sich genommen Was ist Account Abstraction (ERC-4337)?.