6 Beiträge getaggt mit „Account Abstraction“

Seit fünfzehn Jahren ist die Onboarding-Erfahrung im Kryptobereich unverzeihlich mangelhaft. Neue Benutzer laden eine Wallet herunter, werden mit zwölf zufälligen Wörtern bombardiert, die sie nicht verstehen, stellen fest, dass sie ETH benötigen, um überhaupt etwas zu tun (können aber kein ETH kaufen, ohne vorher ETH für Gas zu haben), und geben frustriert auf, bevor sie eine einzige Transaktion abgeschlossen haben. Die Branche nannte dies „Dezentralisierung“. Benutzer nannten es benutzerunfreundliches Design.

Die Account-Abstraktion – insbesondere ERC-4337 in Kombination mit dem Ethereum-Upgrade EIP-7702 im Mai 2025 – behebt endlich das, was niemals hätte kaputt sein dürfen. Über 40 Millionen Smart-Accounts wurden bereits über Ethereum und Layer-2-Netzwerke hinweg bereitgestellt, wobei fast 20 Millionen allein im Jahr 2024 erstellt wurden. Der Standard hat über 100 Millionen UserOperations ermöglicht, was einer Verzehnfachung gegenüber 2023 entspricht. Und da 87 % dieser Transaktionen durch Paymaster Gas-gesponsert sind, erleben wir das Ende des Paradoxons „Du brauchst ETH, um Ethereum zu nutzen“.

Dies ist keine schrittweise Verbesserung – es ist der Wendepunkt, an dem Krypto aufhört, Benutzer dafür zu bestrafen, dass sie keine Kryptographen sind.

Der Meilenstein von 40 Millionen Smart-Accounts: Was sich geändert hat​

Account-Abstraktion ist nicht neu – Entwickler diskutieren darüber seit den Anfängen von Ethereum. Was sich in den Jahren 2024-2025 änderte, waren die Bereitstellungsinfrastruktur, die Wallet-Unterstützung und die Layer-2-Skalierung, die Smart-Accounts wirtschaftlich rentabel machten.

ERC-4337, im März 2023 finalisiert, führte eine standardisierte Methode zur Implementierung von Smart-Contract-Wallets ein, ohne das Kernprotokoll von Ethereum zu ändern. Es funktioniert über UserOperations – Pseudo-Transaktionen, die von spezialisierten Knoten, sogenannten Bundlern, gebündelt und eingereicht werden. Dies ermöglicht Funktionen, die mit herkömmlichen Externally Owned Accounts (EOAs) unmöglich sind:

• Gaslose Transaktionen: Paymaster sponsern Gasgebühren und lösen so das ETH-Bootstrapping-Problem.
• Batch-Transaktionen: Bündelung mehrerer Operationen in einer, was Kosten und Klicks reduziert.
• Social Recovery: Wiederherstellung von Konten über vertrauenswürdige Kontakte anstelle von Seed-Phrasen.
• Session-Keys: Erteilung temporärer Berechtigungen für Apps, ohne Hauptschlüssel offenzulegen.
• Programmierbare Sicherheit: Benutzerdefinierte Validierungslogik, Ausgabenlimits, Betrugserkennung.

Der Meilenstein von 40 Millionen Bereitstellungen entspricht einem Wachstum von 700 % im Vergleich zum Vorjahr. Fast die Hälfte dieser Konten wurde im Jahr 2024 erstellt, mit einer Beschleunigung im Jahr 2025, als große Wallets und Layer-2-Lösungen die ERC-4337-Infrastruktur übernahmen.

Base, Polygon und Optimism führen die Akzeptanz an. Die Integration von Base in die Coinbase Wallet ermöglichte Millionen von Benutzern ein gasloses Onboarding. Das starke Gaming-Ökosystem von Polygon nutzt Smart-Accounts für In-Game-Ökonomien, ohne dass Spieler private Schlüssel verwalten müssen. Die Standardisierung des OP Stacks von Optimism half kleineren L2s, die Account-Abstraktion ohne benutzerdefinierte Implementierungen zu übernehmen.

Aber der eigentliche Katalysator war EIP-7702, das mit dem Pectra-Upgrade von Ethereum am 7. Mai 2025 aktiviert wurde.

EIP-7702: Wie man 300 Millionen bestehende Wallets upgraded​

ERC-4337 Smart-Accounts sind leistungsstark, aber es handelt sich um neue Konten. Wenn Sie Ethereum seit 2015 nutzen, liegen Ihre Vermögenswerte in einem EOA – einem einfachen Schlüssel-Wert-Paar, bei dem der private Schlüssel alles kontrolliert. Die Migration dieser Vermögenswerte auf einen Smart-Account erfordert Transaktionen, Gasgebühren und das Risiko von Fehlern. Für die meisten Benutzer war diese Hürde zu hoch.

EIP-7702 löste dies, indem es bestehenden EOAs ermöglichte, während Transaktionen vorübergehend Smart-Contract-Code auszuführen. Es führt einen neuen Transaktionstyp (0x04) ein, bei dem ein EOA ausführbaren Bytecode anhängen kann, ohne dauerhaft zu einem Vertrag zu werden.

So funktioniert es: Ein EOA-Inhaber signiert einen „Delegation Designator“ – eine Adresse, die ausführbaren Code enthält, den sein Konto vorübergehend übernimmt. Während dieser Transaktion erhält der EOA Smart-Contract-Fähigkeiten: Batch-Operationen, Gas-Sponsoring, benutzerdefinierte Validierungslogik. Nach Abschluss der Transaktion kehrt der EOA in seinen ursprünglichen Zustand zurück, aber die Infrastruktur erkennt ihn nun als Account-Abstraktion-kompatibel an.

Dies bedeutet, dass über 300 Millionen bestehende Ethereum-Adressen Smart-Account-Funktionen erhalten können, ohne Vermögenswerte zu migrieren oder neue Verträge bereitzustellen. Wallets wie MetaMask, Trust Wallet und Ambire können Benutzerkonten transparent upgraden und so Folgendes ermöglichen:

• Gasloses Onboarding: Apps sponsern Gas für neue Benutzer und beseitigen so das ETH-Paradoxon.
• Transaktions-Batching: Genehmigen und Tauschen von Token mit einem Klick statt zwei Transaktionen.
• Delegierung an alternative Schlüsselschemata: Verwendung von Face ID, Passkeys oder Hardware-Wallets als primäre Authentifizierung.

Große Wallets implementierten die EIP-7702-Unterstützung innerhalb weniger Wochen nach dem Pectra-Upgrade. Ambire und Trust Wallet rollten den Support sofort aus und machten die EOAs ihrer Benutzer ohne manuelle Migration bereit für die Account-Abstraktion. Dies war nicht nur ein Feature-Upgrade – es war die Nachrüstung der gesamten installierten Basis von Ethereum-Benutzern mit moderner UX.

Die Kombination aus ERC-4337 (neue Smart-Accounts) und EIP-7702 (aktualisierte bestehende Konten) ebnet den Weg zu über 200 Millionen Smart-Accounts bis Ende 2025, wie Branchenprognosen schätzen. Das ist kein Hype – es ist das natürliche Ergebnis der Beseitigung von Onboarding-Hürden, die sich Krypto ohne guten Grund selbst auferlegt hat.

100 Millionen UserOperations: Die wahre Kennzahl für die Adoption​

Smart-Account-Bereitstellungen sind eine Vanity-Metrik, wenn niemand sie nutzt. UserOperations – die transaktionsähnlichen Bündel, die ERC-4337 Smart Accounts einreichen – erzählen die wahre Geschichte.

Der ERC-4337-Standard hat über 100 Millionen UserOperations ermöglicht, gegenüber 8,3 Millionen im Jahr 2023. Das ist eine 12-fache Steigerung in nur einem Jahr, die primär durch Gaming, DeFi und gaslose Onboarding-Flows vorangetrieben wurde.

87 % dieser UserOperations wurden von Paymastern Gas-gesponsert – Smart Contracts, die Transaktionsgebühren im Namen der Nutzer bezahlen. Dies ist das Killer-Feature. Anstatt Nutzer zu zwingen, ETH zu erwerben, bevor sie mit Ihrer App interagieren, können Entwickler Gas sponsern und Nutzer sofort onboarden. Die Kosten? Ein paar Cent pro Transaktion. Der Vorteil? Die Beseitigung des größten Reibungspunkts beim Krypto-Onboarding.

Paymaster arbeiten in drei Modi:

1. Vollständiges Sponsoring: Die App zahlt alle Gas-Gebühren. Wird für Onboarding, Empfehlungen oder Werbekampagnen genutzt.
2. ERC-20-Zahlung: Nutzer zahlen Gas in USDC, DAI oder App-eigenen Token anstelle von ETH. Häufig im Gaming-Bereich, wo Spieler Token verdienen, aber kein ETH halten.
3. Bedingtes Sponsoring: Gas-Gebühren werden gesponsert, wenn bestimmte Bedingungen erfüllt sind (z. B. erste Transaktion, Transaktionswert überschreitet Schwellenwert, Nutzer wurde von einem bestehenden Mitglied geworben).

Die praktischen Auswirkungen: Ein neuer Nutzer kann die Anmeldung bis zur ersten Transaktion in weniger als 60 Sekunden abschließen, ohne eine zentrale Börse zu nutzen, ohne mehrere Wallets herunterzuladen und ohne Gas-Gebühren verstehen zu müssen. Er meldet sich mit E-Mail und Passwort (oder Social Auth) an, und die App sponsert seine ersten Transaktionen. Bis er Wallets und Keys verstehen muss, nutzt er die App bereits und erlebt ihren Mehrwert.

So funktionieren Web2-Apps. So hätte Krypto schon immer funktionieren sollen.

Gaslose Transaktionen: Das Ende des ETH-Bootstrapping-Problems​

Das Problem „man braucht ETH, um Ethereum zu nutzen“ war der peinlichste UX-Fehler von Krypto. Stellen Sie sich vor, Sie sagen den Nutzern einer neuen App: „Bevor Sie dies ausprobieren können, müssen Sie zu einem separaten Dienst gehen, Ihre Identität verifizieren, die Währung des Netzwerks kaufen und sie dann an diese App übertragen. Und wenn Ihnen diese Währung ausgeht, funktioniert keines Ihrer anderen Guthaben mehr.“

Paymaster haben diese Absurdität beendet. Entwickler können jetzt Nutzer onboarden, die null ETH haben, ihre ersten Transaktionen sponsern und sie sofort mit DeFi-, Gaming- oder Social-Apps interagieren lassen. Sobald die Nutzer vertrauter sind, können sie zur Selbstverwahrung (Self-Custody) und zur eigenständigen Verwaltung von Gas übergehen, aber die erste Erfahrung bestraft Neulinge nicht dafür, dass sie die Interna der Blockchain nicht verstehen.

Der Paymaster von Circle ist ein Paradebeispiel. Er ermöglicht es Anwendungen, Gas-Gebühren für Nutzer zu sponsern, die in USDC bezahlen. Ein Nutzer mit USDC in seinem Wallet kann auf Ethereum oder Layer 2s transagieren, ohne jemals ETH erwerben zu müssen. Der Paymaster konvertiert USDC im Hintergrund, um das Gas zu decken, unsichtbar für den Nutzer. Für Stablecoin-fokussierte Apps (Überweisungen, Zahlungen, Sparen) entfernt dies den mentalen Aufwand für die Verwaltung eines volatilen Gas-Tokens.

Die Paymaster-Infrastruktur von Base ermöglichte es Coinbase, Millionen von Nutzern ohne Krypto-Komplexität für DeFi zu gewinnen. Das Coinbase Wallet verwendet standardmäßig Base, sponsert erste Transaktionen und lässt Nutzer mit Apps wie Uniswap oder Aave interagieren, bevor sie verstehen, was Gas überhaupt ist. Bis die Nutzer ETH kaufen müssen, erleben sie bereits einen Mehrwert und haben einen Kontext dafür, warum das System so funktioniert, wie es funktioniert.

Gaming-Plattformen wie Immutable X und Treasure DAO nutzen Paymaster, um Transaktionen der Spieler zu subventionieren. In-Game-Aktionen – das Prägen von Gegenständen, der Handel auf Marktplätzen, das Einfordern von Belohnungen – geschehen sofort, ohne das Gameplay zu unterbrechen, um Gas-Transaktionen zu genehmigen. Spieler verdienen Token durch das Gameplay, die sie später für Gas verwenden oder handeln können, aber die anfängliche Erfahrung ist reibungslos.

Das Ergebnis: In den Jahren 2024–2025 wurden von Anwendungen gesponserte Gas-Gebühren in Höhe von zig Millionen Dollar verzeichnet. Das ist keine Wohltätigkeit – es sind Kundenakquisitionskosten (CAC). Apps haben entschieden, dass das Bezahlen von 0,02 bis 0,10 $ pro Transaktion für das Onboarding von Nutzern günstiger und effektiver ist, als Nutzer zu zwingen, zuerst durch zentrale Börsen zu navigieren.

Batch-Transaktionen: Ein Klick, mehrere Aktionen​

Einer der frustrierendsten Aspekte der traditionellen Ethereum-UX ist die Notwendigkeit, jede Aktion separat zu genehmigen. Möchten Sie USDC gegen ETH auf Uniswap tauschen? Das sind zwei Transaktionen: eine, um Uniswap zu erlauben, Ihr USDC auszugeben, und eine weitere, um den Tausch auszuführen. Jede Transaktion erfordert ein Wallet-Popup, eine Bestätigung der Gas-Gebühr und eine Blockbestätigungszeit. Für neue Nutzer fühlt sich dies an, als wäre die App kaputt. Für erfahrene Nutzer ist es einfach nur nervig.

ERC-4337 und EIP-7702 ermöglichen Transaktions-Batching, bei dem mehrere Operationen in einer einzigen UserOperation gebündelt werden. Derselbe Uniswap-Tausch wird zu einem Klick, einer Bestätigung, einer Gas-Gebühr. Das Smart Account führt intern Genehmigung und Tausch nacheinander aus, aber der Nutzer sieht nur eine einzige Transaktion.

Die Anwendungsfälle gehen weit über DeFi hinaus:

• NFT-Minting: USDC genehmigen, NFT prägen und auf dem Marktplatz listen in einer Transaktion
• Gaming: Belohnungen einfordern, Gegenstände verbessern und Token gleichzeitig staken
• DAO-Governance: Über mehrere Vorschläge in einer einzigen Transaktion abstimmen, anstatt für jeden Gas zu zahlen
• Social-Apps: Inhalte posten, Erstellern Trinkgeld geben und Konten folgen, ohne Bestätigungen pro Aktion

Dies ist nicht nur UX-Feinschliff – es verändert grundlegend, wie Nutzer mit On-Chain-Anwendungen interagieren. Komplexe, mehrstufige Abläufe, die sich zuvor klobig und teuer anfühlten, wirken jetzt sofort und kohärent. Der Unterschied zwischen „diese App ist kompliziert“ und „diese App funktioniert einfach“ hängt oft vom Batching ab.

Social Recovery : Das Ende der Angst vor der Seed - Phrase​

Fragen Sie einen beliebigen Nutzer , der nicht aus der Krypto - Welt stammt , was er bei der Eigenverwahrung ( Self - Custody ) am meisten fürchtet , und die Antwort lautet ausnahmslos : " Was passiert , wenn ich meine Seed - Phrase verliere ? " Seed - Phrasen sind in der Theorie sicher , in der Praxis jedoch katastrophal . Nutzer schreiben sie auf Papier ( geht leicht verloren oder wird beschädigt ) , speichern sie in Passwort - Managern ( Single Point of Failure ) oder sichern sie überhaupt nicht ( garantierter Verlust bei Geräteausfall ) .

Social Recovery stellt dieses Modell auf den Kopf . Anstatt einer 12 - Wort - Mnemonik als einziger Wiederherstellungsmethode ermöglichen Smart Accounts den Nutzern , vertrauenswürdige " Guardians " ( Wächter ) zu benennen – Freunde , Familie oder sogar Hardware - Geräte – , die gemeinsam den Zugriff wiederherstellen können , falls der Primärschlüssel verloren geht .

So funktioniert es : Ein Nutzer richtet seinen Smart Account ein und benennt drei Guardians ( jede beliebige Anzahl und jeder Schwellenwert ist möglich , z. B. 2 - von - 3 oder 3 - von - 5 ) . Jeder Guardian hält einen Wiederherstellungs - Shard – einen Teilschlüssel , der für sich allein keinen Zugriff auf das Konto ermöglicht . Wenn der Nutzer seinen Primärschlüssel verliert , kontaktiert er die Guardians und beantragt die Wiederherstellung . Sobald der Schwellenwert erreicht ist ( z. B. 2 von 3 Guardians stimmen zu ) , wird der Zugriff des Smart Accounts auf einen neuen , vom Nutzer kontrollierten Schlüssel übertragen .

Argent leistete 2019 Pionierarbeit für dieses Modell . Bis 2025 hat Argent Social Recovery für Hunderttausende von Nutzern ermöglicht , mit einer Erfolgsquote bei der Wiederherstellung von über 95 % für Nutzer , die ihre Geräte verloren haben . Der mentale Wandel ist bedeutend : Anstatt " Ich muss diese Seed - Phrase für immer schützen oder ich verliere alles " heißt es nun : " Ich muss die Beziehungen zu Menschen pflegen , denen ich vertraue – was ich ohnehin schon tue . "

Ambire Wallet wählte einen hybriden Ansatz , der E - Mail / Passwort - Authentifizierung mit optionaler Social Recovery für hochwertige Konten kombiniert . Nutzer , die Einfachheit bevorzugen , können sich auf die E - Mail - basierte Wiederherstellung verlassen ( mit verschlüsselten Key - Shards , die auf verschiedenen Servern gespeichert sind ) . Power - User können Social Recovery für zusätzliche Sicherheit darüberlegen .

Die Kritik : Social Recovery ist nicht rein " trustless " ( vertrauenslos ) – sie erfordert das Vertrauen in die Guardians , dass diese nicht kolludieren . Das ist fair . Aber für die meisten Nutzer ist es weitaus praktischer , drei Freunden zu vertrauen , als darauf zu vertrauen , dass sie selbst niemals ein Stück Papier verlieren . Die maximalistische Haltung von Krypto zur " reinen Eigenverwahrung " hat das Ökosystem für 99 % der Menschheit unbrauchbar gemacht . Social Recovery ist ein pragmatischer Kompromiss , der das Onboarding ermöglicht , ohne die Sicherheit in realistischen Bedrohungsszenarien zu opfern .

Session Keys : Delegierte Berechtigungen ohne Risiko​

Traditionelle EOAs ( Externally Owned Accounts ) funktionieren nach dem Alles - oder - Nichts - Prinzip : Wenn eine App Ihren privaten Schlüssel hat , kann sie Ihr gesamtes Wallet leeren . Dies schafft ein Dilemma für interaktive Anwendungen ( Spiele , soziale Apps , automatisierte Trading - Bots ) , die häufige Transaktionssignaturen ohne ständige Benutzerinteraktion benötigen .

Session Keys ( Sitzungsschlüssel ) lösen dies , indem sie Apps temporäre , begrenzte Berechtigungen erteilen . Ein Smart - Account - Besitzer kann einen Session Key erstellen , der für eine bestimmte Dauer ( z. B. 24 Stunden ) und nur für spezifische Aktionen ( z. B. Trading auf Uniswap , Minting von NFTs , Posten in einer sozialen App ) gültig ist . Die App hält den Session Key und kann Transaktionen innerhalb dieser Grenzen ausführen , hat aber keinen Zugriff auf das gesamte Guthaben des Kontos und kann keine unbefugten Aktionen durchführen .

Anwendungsfälle , die 2025 - 2026 explodieren :

• Gaming : Spieler gewähren Game - Clients Session Keys , was sofortige In - Game - Transaktionen ermöglicht ( Loot beanspruchen , Gegenstände handeln , Charaktere verbessern ) , ohne dass alle 30 Sekunden ein Wallet - Popup erscheint . Der Session Key ist auf spielbezogene Smart Contracts beschränkt und läuft nach Ende der Sitzung ab .

• Trading - Bots : DeFi - Nutzer erstellen Session Keys für automatisierte Handelsstrategien . Der Bot kann Trades ausführen , Portfolios umschichten und Renditen ( Yields ) beanspruchen , kann aber keine Gelder abheben oder mit Verträgen außerhalb der Whitelist interagieren .

• Soziale Apps : Dezentrale Alternativen zu Twitter / Reddit nutzen Session Keys , damit Nutzer posten , kommentieren und Trinkgelder ( Tips ) geben können , ohne jede Aktion einzeln genehmigen zu müssen . Der Session Key ist auf Interaktionen mit sozialen Verträgen beschränkt und hat ein Ausgabenlimit für Trinkgelder .

Das Sicherheitsmodell besteht aus zeitlich begrenzten und inhaltlich beschränkten Berechtigungen – genau so , wie OAuth für Web2 - Apps funktioniert . Anstatt einer App vollen Kontozugriff zu geben , gewähren Sie spezifische Berechtigungen für eine begrenzte Zeit . Wenn die App kompromittiert wird oder bösartig agiert , bleibt der schlimmste Schaden auf den Umfang und die Dauer des Session Keys begrenzt .

Dies ist die UX - Erwartung , die Nutzer aus dem Web2 mitbringen . Dass Krypto dies 15 Jahre lang nicht hatte , ist unentschuldbar , und Account Abstraction behebt dies endlich .

Base , Polygon , Optimism : Wo 40 Millionen Smart Accounts tatsächlich leben​

Die 40 Millionen Smart - Account - Implementierungen sind nicht gleichmäßig verteilt – sie konzentrieren sich auf Layer - 2 - Netzwerke , in denen die Gas - Gebühren niedrig genug sind , um Account Abstraction wirtschaftlich tragfähig zu machen .

Base führt die Adoption an und nutzt die Vertriebskanäle von Coinbase , um Privatnutzer in großem Maßstab an Bord zu holen . Das Coinbase Wallet setzt für neue Nutzer standardmäßig auf Base , wobei Smart Accounts transparent erstellt werden . Die meisten Nutzer merken nicht einmal , dass sie einen Smart Account verwenden – sie melden sich mit ihrer E - Mail an , beginnen mit Transaktionen und erleben ein gasloses ( gasless ) Onboarding , ohne die zugrunde liegende Technik zu verstehen . Das ist das Ziel . Krypto sollte nicht voraussetzen , dass Nutzer Merkle - Trees und elliptische Kurven verstehen , bevor sie eine App ausprobieren können .

Das Gaming - Ökosystem von Base profitiert massiv von Account Abstraction . Spiele , die auf Base aufbauen , nutzen Session Keys für ein reibungsloses Gameplay , bündeln Transaktionen ( Batch Transactions ) , um die Latenz bei In - Game - Aktionen zu verringern , und nutzen Paymaster , um das Onboarding der Spieler zu subventionieren . Das Ergebnis : Spieler ohne jegliche Krypto - Erfahrung können Web3 - Spiele spielen , ohne zu bemerken , dass sie sich auf einer Blockchain befinden .

Polygon hatte eine frühe Dynamik mit Gaming - und NFT - Plattformen , die ERC - 4337 adaptierten . Polygons niedrige Gebühren ( oft < $ 0,01 pro Transaktion ) machen von Paymastern gesponsertes Gas wirtschaftlich nachhaltig . Projekte wie Aavegotchi , Decentraland und The Sandbox nutzen Smart Accounts , um Hürden für Nutzer abzubauen , die mit virtuellen Welten interagieren möchten , anstatt Wallets zu verwalten .

Polygon ist zudem Partnerschaften mit großen Marken eingegangen ( Starbucks Odyssey , Reddit Collectible Avatars , Nike .SWOOSH ) , um Millionen von Nicht - Krypto - Nutzern einzubinden . Diese Nutzer sehen keine Wallets , Seed - Phrasen oder Gas - Gebühren – sie sehen spielerische Treueprogramme und digitale Sammlerstücke . Hinter den Kulissen nutzen sie Smart Accounts , die durch Account Abstraction ermöglicht werden .

Die Standardisierung des OP Stacks von Optimism hat Account Abstraction über verschiedene Rollups hinweg portierbar gemacht . Jede OP - Stack - Chain kann die ERC - 4337 - Infrastruktur von Optimism übernehmen , ohne dass eine benutzerdefinierte Implementierung erforderlich ist . Dies schuf einen Netzwerkeffekt : Entwickler bauen Apps mit Account - Abstraction - Funktionen einmal und stellen sie mit minimalen Änderungen auf Base , Optimism und anderen OP - Stack - Chains bereit .

Der Fokus von Optimism auf die Finanzierung öffentlicher Güter ( Public Goods Funding ) bot Wallet - Entwicklern zusätzliche Anreize , Account Abstraction zu implementieren . Runden der Retroactive Public Goods Funding ( RPGF ) belohnten explizit Projekte , die die Ethereum - UX verbesserten , wobei Account - Abstraction - Wallets erhebliche Zuweisungen erhielten .

Das Muster : Niedrige Gebühren + Vertriebskanäle + Entwickler - Tools = Adoption . Smart Accounts haben sich im Ethereum - Mainnet nicht durchgesetzt , da Gas - Gebühren von $ 5 - 50 das Paymaster - Sponsoring unerschwinglich teuer machen . Sie setzten sich auf L2s durch , wo die Kosten pro Transaktion auf Cent - Beträge sanken , was ein gasloses Onboarding wirtschaftlich rentabel machte .

Das 200 Millionen Smart Account Endgame​

Branchenprognosen schätzen bis Ende 2025 auf über 200 Millionen Smart Accounts, angetrieben durch die Einführung von ERC-4337 und die Nachrüstung bestehender EOAs durch EIP-7702. Das ist keine spekulative Träumerei – es ist das natürliche Ergebnis der Beseitigung künstlicher Reibungsverluste.

Der Weg zu 200 Millionen:

1. Einführung mobiler Wallets. Ambire Mobile, Trust Wallet und MetaMask Mobile unterstützen jetzt Account Abstraction und bringen Smart-Account-Funktionen zu Milliarden von Smartphone-Nutzern. Mobile ist der Ort, an dem die nächste Welle der Krypto-Adoption stattfindet, und die mobile UX verträgt kein Seed-Phrase-Management oder Gas-Bestätigungen pro Transaktion.

2. Gaming-Onboarding. Web3-Spiele sind der volumenstärkste Anwendungsfall für Account Abstraction. Free-to-Play-Spiele mit Play-to-Earn-Mechanik können Millionen von Spielern an Bord holen, erste Transaktionen sponsern und ein reibungsloses Gameplay ermöglichen. Wenn 10 – 20 große Spiele in den Jahren 2025 – 2026 Account Abstraction einführen, sind das 50 – 100 Millionen Nutzer.

3. Unternehmensanwendungen. Unternehmen wie Circle, Stripe und PayPal integrieren Blockchain-Zahlungen, werden ihre Kunden jedoch nicht mit Seed-Phrase-Management belasten. Account Abstraction ermöglicht es Unternehmens-Apps, Blockchain-basierte Dienste mit einer UX auf Web2-Niveau anzubieten.

4. Social Apps. Dezentrale soziale Plattformen (Farcaster, Lens, Friend.tech) benötigen ein reibungsloses Onboarding, um mit Twitter und Instagram zu konkurrieren. Niemand wird ein dezentrales Twitter nutzen, wenn jeder Post eine Wallet-Bestätigung erfordert. Session Keys und Paymaster machen dezentrale Social Apps praktikabel.

5. EIP-7702 Nachrüstung. Über 300 Millionen bestehende Ethereum-EOAs können Smart-Account-Funktionen ohne Migration erhalten. Wenn nur 20 – 30 % dieser Konten EIP-7702-Funktionen übernehmen, sind das 60 – 90 Millionen aktualisierte Konten.

Der Wendepunkt: wenn Smart Accounts zum Standard werden, nicht zur Ausnahme. Sobald große Wallets (MetaMask, Trust Wallet, Coinbase Wallet) standardmäßig Smart Accounts für neue Nutzer erstellen, verschiebt sich die installierte Basis schnell. EOAs werden zu Legacy-Infrastruktur, die aus Kompatibilitätsgründen beibehalten wird, aber nicht mehr die primäre Nutzererfahrung darstellt.

Warum BlockEden.xyz-Builder sich darum kümmern sollten​

Wenn Sie auf Ethereum oder Layer 2 bauen, ist Account Abstraction keine optionale Infrastruktur – sie ist die Grundvoraussetzung für eine wettbewerbsfähige UX. Nutzer erwarten gasloses Onboarding, Batch-Transaktionen und Social Recovery, denn so funktionieren Web2-Apps und so sollten moderne Krypto-Apps funktionieren.

Für Entwickler bedeutet die Implementierung von Account Abstraction:

Wahl der richtigen Infrastruktur: Nutzen Sie ERC-4337 Bundler und Paymaster-Dienste (Alchemy, Pimlico, Stackup, Biconomy), anstatt alles von Grund auf neu zu bauen. Das Protokoll ist standardisiert, die Tools sind ausgereift, und das Rad neu zu erfinden, verschwendet Zeit.

Onboarding-Flows entwerfen, die Komplexität verbergen: Zeigen Sie den Nutzern bei der Anmeldung keine Seed-Phrases. Fragen Sie nicht nach der Bestätigung von Gasgebühren, bevor sie den Mehrwert erlebt haben. Sponsern Sie erste Transaktionen, nutzen Sie Session Keys für wiederholte Interaktionen und führen Sie fortgeschrittene Funktionen schrittweise ein.

Social Recovery unterstützen: Bieten Sie E-Mail-basierte Wiederherstellung für Gelegenheitsnutzer, Social Recovery für diejenigen, die es wünschen, und Seed-Phrase-Backup für Power-User, die volle Kontrolle verlangen. Verschiedene Nutzer haben unterschiedliche Bedrohungsmodelle – Ihre Wallet sollte allen gerecht werden.

Account Abstraction ist die Infrastruktur, die Ihre App für die nächsten Milliarden Nutzer zugänglich macht. Wenn Ihr Onboarding-Flow immer noch erfordert, dass Nutzer ETH kaufen, bevor sie Ihr Produkt ausprobieren können, konkurrieren Sie mit gefesselten Händen.

Für Entwickler, die Anwendungen mit Account Abstraction erstellen, bietet BlockEden.xyz die RPC-Infrastruktur zur Unterstützung von Smart Accounts in großem Maßstab. Unabhängig davon, ob Sie ERC-4337 UserOperations implementieren, Paymaster-Dienste integrieren oder auf Base, Polygon oder Optimism bereitstellen, bewältigen unsere APIs die Durchsatz- und Zuverlässigkeitsanforderungen einer produktiven Account Abstraction. Erkunden Sie unseren API-Marktplatz, um die nächste Generation der Krypto-UX aufzubauen.

Quellen​

• ERC-4337 Dokumentation
• Was ist ERC-4337? | Alchemy
• EIP-7702 Implementierungshandbuch | QuickNode
• Ethereum Pectra Upgrade Übersicht | Alchemy
• Pectra Upgrade & EIP-7702 verleihen EOAs Smart-Wallet-Superkräfte | Circle
• Was sind Paymaster? (ERC-4337) | Alchemy
• Gaslose Transaktionen mit Paymaster | Base Dokumentation
• Was ist Account Abstraction? | Ambire Blog
• Warum Account Abstraction das größte Problem von Krypto lösen wird | Medium

AllScale.io ist eine legitime, Risikokapital-finanzierte Stablecoin-Zahlungsplattform – kein Token-Projekt –, die sich an Freelancer und kleine Unternehmen in Schwellenländern richtet. Gegründet im Februar 2025 und unterstützt durch 6,5 Mio. $ von renommierten Krypto-VCs wie YZi Labs, Draper Dragon und KuCoin Ventures, zeigt das Unternehmen positive Signale: ein öffentlich bekanntes (doxxed) Team mit nachweisbarer Erfahrung bei Kraken, Capital One und Block sowie institutionelle Unterstützung durch den Cyberport-Inkubator in Hongkong. Das Fehlen öffentlicher Sicherheitsaudits und das extrem junge Alter der Plattform (weniger als ein Jahr) rechtfertigen jedoch eine sorgfältige Due Diligence vor einem größeren Engagement.

Was AllScale tut und welches Problem es löst​

AllScale positioniert sich als die „weltweit erste Self-Custody Stablecoin-Neobank“, die speziell für die über 600 Millionen globalen Kleinstunternehmen entwickelt wurde – Freelancer, Content-Ersteller, KMUs und Remote-Auftragnehmer –, die mit traditionellen grenzüberschreitenden Zahlungen zu kämpfen haben. Das Kernproblem: Internationale Freelancer stehen vor Barrieren bei Bankkonten, hohen Überweisungsgebühren, Verlusten durch Währungsumrechnung und Abrechnungsverzögerungen, die oft 5 Werktage überschreiten.

Die Plattform ermöglicht es Unternehmen, Rechnungen zu erstellen, Zahlungen in USDT oder USDC zu erhalten – unabhängig davon, wie Kunden bezahlen (Kreditkarte, Überweisung oder Krypto) – und über eine Non-Custodial-Wallet sofort auf Gelder zuzugreifen. Zu den wichtigsten Produkten gehören AllScale Invoice (live seit September 2025), AllScale Pay (Social Commerce via Telegram, WhatsApp, Line) und AllScale Payroll (grenzüberschreitende Zahlungen für Auftragnehmer). Das Unternehmen betont das Konzept der „unsichtbaren Krypto“ – Kunden merken möglicherweise nicht einmal, dass sie Blockchain-Infrastrukturen nutzen, während Händler Stablecoins erhalten.

Aktueller Entwicklungsstand: Die Plattform befindet sich in der öffentlichen Beta-Phase mit einem funktionierenden Produkt im BNB Chain Mainnet. Benutzer können über dashboard.allscale.io auf das Dashboard zugreifen, wobei möglicherweise eine Warteliste gilt.

Technische Architektur basiert auf BNB Chain und Account Abstraction​

AllScale baut auf bestehender Blockchain-Infrastruktur auf, anstatt eine eigene Chain zu betreiben. Der primäre Technologie-Stack umfasst:

Der Passkey-basierte Ansatz eliminiert die berüchtigten UX-Hürden der Seed-Phrasen-Verwaltung und senkt die Barriere für die Massenadaption. Die Multi-Chain Paymaster-Sponsoring-Architektur wickelt die Transaktionskosten im Hintergrund ab.

Was fehlt: AllScale unterhält keine öffentlichen GitHub-Repositories – die Infrastruktur ist proprietär und quellgeschlossen. Es wurden keine Smart-Contract-Adressen veröffentlicht, es sind keine öffentlichen APIs oder SDKs verfügbar, und die technische Dokumentation unter docs.allscale.io konzentriert sich eher auf Benutzerhandbücher als auf Architekturspezifikationen. Diese Undurchsichtigkeit verhindert eine unabhängige technische Überprüfung ihrer Behauptungen.

Kein nativer Token – die Plattform nutzt USDT und USDC​

AllScale hat keinen eigenen Kryptowährungs-Token. Dies ist ein entscheidender Unterschied zu vielen Web3-Projekten: Es gibt kein ICO, IDO, Token-Verkauf oder spekulativen Vermögenswert. Das Unternehmen operiert als traditionelle Delaware C-Corp, die Eigenkapitalfinanzierung aufnimmt.

Die Plattform nutzt Stablecoins von Drittanbietern – primär USDT und USDC – als Zahlungsmittel. Benutzer erhalten Zahlungen in Stablecoins, mit automatischer Umrechnung von Fiat- oder Kartenzahlungen. Die Integration mit der BNB Chain bietet zudem Zugang zu USD1 (dem mit Binance assoziierten Stablecoin).

Einnahmemodell (geschätzt, nicht öffentlich bekanntgegeben):

• Transaktionsgebühren bei der Rechnungs- und Zahlungsabwicklung
• Spreads bei der Währungsumrechnung von Fiat-zu-Stablecoin-Börsen
• B2B-Lohnbuchhaltungsdienste (Payroll Management)
• Gebühren für On/Off-Ramp-Integrationen

Das Fehlen eines Tokens eliminiert bestimmte Risiken (spekulative Volatilität, Manipulation der Tokenomics, regulatorische Bedenken hinsichtlich Wertpapieren), bedeutet aber auch, dass es für Investoren über die Beteiligung am Eigenkapital hinaus kein tokenbasiertes Exposure gibt.

Vier öffentlich bekannte Gründer mit nachweisbarem Hintergrund​

Das Team von AllScale zeigt eine starke Transparenz – alle Gründer sind öffentlich identifiziert und verfügen über nachprüfbare berufliche Werdegänge:

Shawn Pang (CEO & Mitgründer): Informatik und Wirtschaft an der Western University. Ehemaliger Produktmanager für Zahlungsbetrug bei Capital One; erster PM in Kanada bei TikTok; Mitbegründer von HashMatrix, einer Growth-Marketing-Agentur für KI-Produkte.

Ruoyang „Leo“ Wang (COO & Mitgründer): Computer-Engineering an der University of Toronto. Hintergrund bei PingCAP (verteilte Datenbanken), IBM, AMD und Scotiabank. Frühere Startup-Erfahrung mit CP Clickme.

Jun Li & Khalil Lin (Mitgründer): Weitere Mitgründer mit Rechts- und Compliance-Expertise, Berichten zufolge mit OKX-Hintergrund. LinkedIn-Profile verfügbar.

Avrilyn Li (Founding Product Manager): KI-zu-Web3-Unternehmerin der Ivey Business School, die das Payroll-Produkt leitet.

Das Team beansprucht kollektive Erfahrung von Binance, OKX, Kraken, Block (Square), Amazon, Dell und HP. Die Gesamtteamgröße beträgt etwa 7–11 Mitarbeiter.

Finanzierung und Investoren​

Zu den namhaften beteiligten Investoren gehören KuCoin Ventures, Oak Grove Ventures, BlockBooster, Aptos, GSR Ventures und V3V Ventures. Angel-Investoren sind unter anderem Gracy Chen und Jedi Lu. Das Unternehmen ist Mitglied des Hong Kong Cyberport Incubation Program, einem staatlich geförderten Technologie-Accelerator.

Erhebliches Sicherheitsrisiko: keine öffentlichen Audits oder Bug-Bounty-Programm​

Dies ist das bedeutendste Warnsignal (Red Flag) in der Untersuchung. Obwohl Nutzergelder über Smart-Contract-Wallets verwaltet werden:

• Keine öffentlichen Smart-Contract-Audits von anerkannten Firmen (CertiK, Hacken, Trail of Bits, OpenZeppelin, SlowMist)
• Nicht gelistet auf CertiK Skynet oder ähnlichen Sicherheitsdatenbanken
• Kein Bug-Bounty-Programm auf Immunefi, HackerOne oder Bugcrowd
• Keine Versicherungs- oder Deckungsmechanismen offengelegt
• Keine Richtlinie zur Offenlegung von Sicherheitslücken öffentlich sichtbar

AllScale beansprucht Sicherheitsmerkmale wie eine Self-Custody-Architektur, automatisierte KYC / KYB / KYT-Compliance, die Integration von Hardware-Sicherheitsmodulen (HSM) für Passkeys und 2FA-Unterstützung. Das Self-Custody-Modell reduziert das Gegenparteirisiko der Plattform — falls AllScale kompromittiert würde, wären die Gelder der Nutzer in ihren eigenen Wallets theoretisch sicherer als bei einem verwahrenden Dienst (Custodial Service).

Positiv zu vermerken: Es wurden bisher keine Sicherheitsvorfälle, Hacks oder Exploits für AllScale gemeldet. Angesichts des geringen Alters der Plattform könnte das Fehlen von Vorfällen jedoch eher auf eine begrenzte Bekanntheit als auf eine robuste Sicherheit hindeuten.

Wettbewerbslandschaft und Marktpositionierung​

AllScale konkurriert im sich schnell entwickelnden Bereich der Stablecoin-Zahlungen:

Differenzierungsfaktoren von AllScale:

• Self-Custody-Modell (Nutzer kontrollieren ihre Gelder)
• Passkey-Authentifizierung, die die UX-Hürde der Seed-Phrase eliminiert
• Keine Gas-Gebühren durch Account Abstraction
• Fokus auf Schwellenländer (Afrika, Lateinamerika, Südostasien)
• Ausrichtung auf KMU („Last-Mile“) im Gegensatz zum Fokus auf Großunternehmen

Nachteile: Extrem junges Unternehmen, kleines Team, begrenzter Track Record, Wettbewerb gegen finanzstarke etablierte Anbieter mit bestehenden Vertriebskanälen.

Die Community-Präsenz befindet sich in einem frühen Stadium und ist B2B-orientiert​

AllScale unterhält die üblichen Web3-Social-Media-Kanäle:

• X (Twitter): @allscaleio (aktiv seit April 2025)
• Telegram: AllScaleHQ Community-Gruppe
• Discord: Aktiver Server mit sichtbarer Community-ID
• LinkedIn: AllScale Inc Unternehmensseite
• Newsletter: „The Stablecoin Scoop“ auf Substack

Die Community befindet sich in der Anfangsphase, wobei das Engagement primär über AMA-Sessions, X Spaces und Partnerschaftsankündigungen erfolgt. AllScale war Gastgeber des Scale Stablecoin Summit in Hongkong (Juni 2025) zusammen mit der HashKey Group und der Amber Group.

Es gelten keine traditionellen DeFi-Metriken: AllScale ist eine Zahlungsplattform, kein DeFi-Protokoll, daher sind TVL-Metriken (Total Value Locked) nicht anwendbar. Die Plattform ist nicht auf DeFiLlama oder Dune Analytics gelistet. Nutzerzahlen und Bindungsraten werden von Investoren erwähnt, aber nicht öffentlich offengelegt.

Zu den nennenswerten Partnerschaften gehören die BNB Chain (offizieller Ökosystempartner), Skill Afrika (afrikanische Freelancer-Communities), Ethscriptions (L1-Permanenz) und Asseto (RWA-Tokenisierung für Renditeprodukte).

Risikobewertung zeigt ein frühphasiges Unternehmen mit moderatem Risiko​

Positive Signale für Legitimität​

• Öffentlich bekanntes (doxxed) Team mit verifizierbarem beruflichem Hintergrund
• Seriöse Krypto-VCs (YZi Labs, Draper Dragon, Amber Group, KuCoin Ventures)
• Institutionelle Unterstützung durch Hong Kong Cyberport
• Delaware C-Corp Rechtsstruktur
• Funktionierendes Produkt live im BNB Chain Mainnet
• Keine Betrugsvorwürfe, BBB-Beschwerden oder Warnungen aus der Community gefunden
• Keine Bedenken hinsichtlich anonymer Teammitglieder
• Keine unrealistischen Renditeversprechen oder Tokenspekulationen
• Compliance-orientierte Positionierung (GENIUS Act, Hong Kong Stablecoin Ordinance)

Bereiche, die zur Vorsicht mahnen​

• Extreme Neuheit: Gegründet im Februar 2025, weniger als ein Jahr alt
• Keine öffentlichen Sicherheits-Audits trotz Verwaltung von Geldern
• Kein Bug-Bounty-Programm
• Keine unabhängigen Nutzerbewertungen oder Community-Feedback verfügbar
• Closed-Source-Infrastruktur — Behauptungen können nicht unabhängig überprüft werden
• Berichterstattung in der Presse primär durch Pressemitteilungen, kein unabhängiger Journalismus
• Zentralisierungsrisiken: Vom Unternehmen betriebene Plattform, Abhängigkeit von der BNB Chain
• Kleines Team (~ 7-11 Personen), das einen ehrgeizigen globalen Umfang bewältigt

Nicht gefunden (potenzielle Warnsignale durch Abwesenheit)​

• Keine öffentlich bekannt gegebenen Nutzermetriken
• Keine Umsatzzahlen
• Kein formeller Beirat
• Keine spezifischen regulatorischen Lizenzen (der Hongkong-Rahmen ist noch nicht in Kraft)

Aktuelle Entwicklungen und Roadmap​

Aktuelle Meilensteine (2025):

• 8. Dezember: 5 Mio. $ Seed-Runde angekündigt (unter der Leitung von YZi Labs)
• November: AllScale Pay live auf der BNB Chain ; Partnerschaft mit Skill Afrika
• Oktober: Partnerschaft mit Ethscriptions für L1-Permanenz
• September: Produkteinführung von AllScale Invoice
• August: BNB Chain Integration mit USD1-Unterstützung
• Juni: Scale Stablecoin Summit Hongkong ; 1,5 Mio. $ Pre-Seed-Finanzierung

Bevorstehend:

• Q1 2026: Marktexpansion in Lateinamerika
• Zukunft: DeFi-Renditeoptionen , erweiterte Cross-Chain-Funktionen , B2B-Unternehmenslösungen

Fazit​

AllScale.io erweist sich als ein legitimes Startup in der Frühphase und nicht als ein betrügerisches Projekt , unterstützt von glaubwürdigen Investoren und einem transparenten , verifizierbaren Team . Das Projekt adressiert ein reales Marktproblem – Reibungsverluste bei grenzüberschreitenden Zahlungen für Freelancer in Schwellenländern – mit einem durchdachten technischen Ansatz , der Account Abstraction und Stablecoins nutzt .

Jedoch erfordern zwei bedeutende Lücken Aufmerksamkeit vor einem nennenswerten Engagement : das vollständige Fehlen öffentlicher Sicherheitsaudits und die Closed-Source-Infrastruktur , die eine unabhängige Verifizierung verhindert . Für eine Plattform , die Nutzergelder verwaltet , sind diese Versäumnisse wesentliche Bedenken , unabhängig von den Qualifikationen des Teams .

Gesamtrisikobewertung : Moderat . Das Unternehmen zeigt starke Legitimitätssignale , birgt jedoch inhärente Risiken der Frühphase . Potenzielle Nutzer sollten mit kleinen Beträgen beginnen , bis Sicherheitsaudits veröffentlicht werden . Potenzielle Partner sollten direkten Zugang zu technischen Spezifikationen und Audit-Berichten anfordern . Das Projekt ist es wert , beobachtet zu werden , während es reift , insbesondere im Hinblick auf Ankündigungen von Sicherheitsaudits im ersten Quartal 2026 .

Stellen Sie sich eine Welt vor, in der Benutzer nahtlos mit Ihrer dApp interagieren können, ohne native Token (SUI) besitzen zu müssen. Dies ist kein ferner Traum mehr. Mit Suis Gas Station (auch bekannt als Paymaster) können Entwickler die Gasgebühren im Namen ihrer Benutzer übernehmen, wodurch eine der größten Hürden für Neueinsteiger in Web3 vollständig beseitigt und ein wirklich reibungsloses On-Chain-Erlebnis ermöglicht wird.

Dieser Artikel bietet einen vollständigen Leitfaden zur Umstellung Ihrer dApp auf Gas-los. Wir werden tief in die Kernkonzepte des Sui Paymasters, seine Architektur, Implementierungsmuster und Best Practices eintauchen.

1. Hintergrund und Kernkonzepte: Was ist eine gesponserte Transaktion?​

In der Welt der Blockchain erfordert jede Transaktion eine Netzwerkgebühr oder „Gas“. Für Benutzer, die an die nahtlosen Erfahrungen von Web2 gewöhnt sind, stellt dies eine erhebliche kognitive und operative Hürde dar. Sui begegnet dieser Herausforderung auf Protokollebene mit gesponserten Transaktionen.

Die Kernidee ist einfach: einer Partei (dem Sponsor) zu erlauben, die SUI-Gasgebühren für die Transaktion einer anderen Partei (des Benutzers) zu bezahlen. Auf diese Weise können Benutzer, selbst wenn sie kein SUI in ihrer Wallet haben, dennoch erfolgreich On-Chain-Aktionen initiieren.

Paymaster ≈ Tankstelle​

Im Sui-Ökosystem wird die Logik für das Sponsern von Transaktionen typischerweise von einem Off-Chain- oder On-Chain-Dienst namens Gas Station oder Paymaster gehandhabt. Zu seinen Hauptaufgaben gehören:

1. Bewertung der Transaktion: Er empfängt die gas-losen Transaktionsdaten eines Benutzers (GasLessTransactionData).
2. Bereitstellung von Gas: Er sperrt und weist die notwendige Gasgebühr für die Transaktion zu. Dies wird normalerweise über einen Gas-Pool verwaltet, der aus vielen SUI-Coin-Objekten besteht.
3. Erzeugung einer Sponsor-Signatur: Nach Genehmigung des Sponsorings signiert die Gas Station die Transaktion mit ihrem privaten Schlüssel (SponsorSig), wodurch ihre Bereitschaft zur Zahlung der Gebühr bestätigt wird.
4. Rückgabe der signierten Transaktion: Er sendet die TransactionData zurück, die nun die Gasdaten und die Signatur des Sponsors enthält, um die endgültige Signatur des Benutzers abzuwarten.

Kurz gesagt, eine Gas Station fungiert als Tankservice für die Benutzer Ihrer dApp und stellt sicher, dass ihre „Fahrzeuge“ (Transaktionen) reibungslos im Sui-Netzwerk fahren können.

2. Hochrangige Architektur und Interaktionsfluss​

Eine typische gas-lose Transaktion erfordert die Koordination zwischen dem Benutzer, dem dApp-Frontend, der Gas Station und einem Sui Full Node. Die Interaktionssequenz ist wie folgt:

Ablaufbeschreibung:

1. Der Benutzer führt eine Aktion in der dApp-Benutzeroberfläche aus, die ein Transaktionsdatenpaket ohne Gasinformationen erstellt.
2. Die dApp sendet diese Daten an ihre zugewiesene Gas Station, um ein Sponsoring anzufordern.
3. Die Gas Station überprüft die Gültigkeit der Anfrage (z. B. ob der Benutzer für ein Sponsoring berechtigt ist), füllt die Transaktion dann mit einem Gas Coin und ihrer Signatur auf und gibt die halbfertige Transaktion an die dApp zurück.
4. Der Benutzer sieht die vollständigen Transaktionsdetails in seiner Wallet (z. B. „Ein NFT kaufen“) und gibt die endgültige Signatur. Dies ist ein entscheidender Schritt, der sicherstellt, dass der Benutzer die Zustimmung und Kontrolle über seine Aktionen behält.
5. Die dApp sendet die vollständige Transaktion, die sowohl die Signaturen des Benutzers als auch des Sponsors enthält, an einen Sui Full Node.
6. Nachdem die Transaktion On-Chain abgeschlossen ist, kann die Gas Station dies durch Abhören von On-Chain-Ereignissen oder -Belegen bestätigen und dann das dApp-Backend über einen Webhook benachrichtigen, um den Geschäftsprozess abzuschließen.

3. Drei Kern-Interaktionsmodelle​

Sie können die folgenden drei Interaktionsmodelle einzeln oder in Kombination verwenden, um Ihren Geschäftsanforderungen gerecht zu werden.

Modell 1: Benutzer-initiiert → Sponsor-genehmigt (Am häufigsten)​

Dies ist das Standardmodell, das für die überwiegende Mehrheit der In-dApp-Interaktionen geeignet ist.

1. Benutzer erstellt GasLessTransactionData: Der Benutzer führt eine Aktion innerhalb der dApp aus.
2. Sponsor fügt GasData hinzu und signiert: Das dApp-Backend sendet die Transaktion an die Gas Station, die sie genehmigt, einen Gas Coin anhängt und ihre Signatur hinzufügt.
3. Benutzer überprüft und gibt endgültige Signatur: Der Benutzer bestätigt die endgültigen Transaktionsdetails in seiner Wallet und signiert sie. Die dApp übermittelt sie dann an das Netzwerk.

Dieses Modell bietet eine hervorragende Balance zwischen Sicherheit und Benutzererfahrung.

Modell 2: Sponsor-initiierte Airdrops/Anreize​

Dieses Modell ist perfekt für Airdrops, Benutzeranreize oder die Verteilung von Vermögenswerten in Batches.

1. Sponsor füllt TransactionData vorab aus + signiert: Der Sponsor (typischerweise das Projektteam) konstruiert den Großteil der Transaktion vorab (z. B. das Airdroppen eines NFT an eine bestimmte Adresse) und fügt seine Sponsoring-Signatur hinzu.
2. Die zweite Signatur des Benutzers macht sie wirksam: Der Benutzer muss diese „vorab genehmigte“ Transaktion nur einmal signieren, damit sie ausgeführt wird.

Dies schafft ein extrem reibungsloses Benutzererlebnis. Mit nur einem Klick zur Bestätigung können Benutzer Belohnungen beanspruchen oder Aufgaben erledigen, was die Konversionsraten von Marketingkampagnen drastisch erhöht.

Modell 3: Wildcard GasData (Kreditlinienmodell)​

Dies ist ein flexibleres und berechtigungsbasiertes Modell.

1. Sponsor überträgt ein GasData-Objekt: Der Sponsor erstellt zunächst ein oder mehrere Gas-Coin-Objekte mit einem bestimmten Budget und überträgt das Eigentum direkt an den Benutzer.
2. Benutzer gibt innerhalb des Budgets frei aus: Der Benutzer kann diese Gas Coins dann frei verwenden, um beliebige Transaktionen zu bezahlen, die er innerhalb der Budgetgrenzen und des Gültigkeitszeitraums initiiert.
3. Gas Coin wird zurückgegeben: Sobald der Gas Coin aufgebraucht oder abgelaufen ist, kann das Gas-Coin-Objekt so konzipiert werden, dass es automatisch zerstört oder an den Sponsor zurückgegeben wird.

Dieses Modell entspricht der Vergabe einer „Gasgebühren-Kreditkarte“ mit begrenzter Laufzeit und begrenztem Budget an den Benutzer, geeignet für Szenarien, die ein hohes Maß an Benutzerautonomie erfordern, wie z. B. das Anbieten eines Free-to-Play-Erlebnisses während einer Spielsaison.

4. Typische Anwendungsszenarien​

Die Stärke des Sui Paymasters liegt nicht nur in der Lösung des Gasgebührenproblems, sondern auch in seiner Fähigkeit, sich tief in die Geschäftslogik zu integrieren, um neue Möglichkeiten zu schaffen.

Szenario 1: Paywalls​

Viele Content-Plattformen oder dApp-Dienste erfordern, dass Benutzer bestimmte Kriterien erfüllen (z. B. ein VIP-NFT besitzen, ein bestimmtes Mitgliedschaftsniveau erreichen), um auf Funktionen zugreifen zu können. Der Paymaster kann diese Logik perfekt implementieren.

• Ablauf: Ein Benutzer fordert eine Aktion an → das dApp-Backend überprüft die Qualifikationen des Benutzers (z. B. NFT-Besitz) → wenn berechtigt, ruft es den Paymaster auf, um die Gasgebühr zu sponsern; wenn nicht, lehnt es die Signaturanfrage einfach ab.
• Vorteil: Dieses Modell ist von Natur aus resistent gegen Bots und Missbrauch. Da die Sponsoring-Entscheidung im Backend getroffen wird, können böswillige Benutzer die Qualifikationsprüfung nicht umgehen, um Gasgelder abzuschöpfen.

Szenario 2: Ein-Klick-Kaufabwicklung​

In E-Commerce- oder In-Game-Kaufszenarien ist die Vereinfachung des Zahlungsprozesses entscheidend.

• Ablauf: Der Benutzer klickt auf einer Checkout-Seite auf „Jetzt kaufen“. Die dApp erstellt eine Transaktion, die die Geschäftslogik (z. B. transfer_nft_to_user) enthält. Der Benutzer muss nur signieren, um die Geschäftstransaktion in seiner Wallet zu genehmigen, ohne sich um Gas kümmern zu müssen. Die Gasgebühr wird vom Sponsor der dApp übernommen.
• Vorteil: Sie können Geschäftsparameter wie eine order_id direkt in den ProgrammableTransactionBlock kodieren, was eine präzise On-Chain-Zuordnung für Backend-Bestellungen ermöglicht.

Szenario 3: Datenzuordnung​

Eine genaue Datenverfolgung ist grundlegend für die Geschäftsoptimierung.

• Ablauf: Beim Erstellen der Transaktion schreiben Sie einen eindeutigen Bezeichner (wie einen order_hash) in die Parameter der Transaktion oder in ein Ereignis, das bei der Ausführung ausgegeben wird.
• Vorteil: Wenn die Gas Station den On-Chain-Beleg für eine erfolgreiche Transaktion erhält, kann sie diesen order_hash leicht extrahieren, indem sie die Ereignis- oder Transaktionsdaten parst. Dies ermöglicht eine präzise Zuordnung zwischen On-Chain-Statusänderungen und spezifischen Backend-Bestellungen oder Benutzeraktionen.

5. Code-Grundgerüst (Basierend auf dem Rust SDK)​

Hier ist ein vereinfachtes Code-Snippet, das die Kerninteraktionsschritte demonstriert.

// Assume tx_builder, sponsor, and wallet have been initialized

// Step 1: On the user or dApp side, construct a gas-less transaction
let gasless_transaction_data = tx_builder.build_gasless_transaction_data(false)?;

// Step 2: On the Sponsor (Gas Station) side, receive the gasless_transaction_data,
// fill it with a Gas Coin, and return the transaction data with the Sponsor's signature.
// The sponsor_transaction_block function handles gas allocation and signing internally.
let sponsored_transaction = sponsor.sponsor_transaction_block(gasless_transaction_data, user_address, gas_budget)?;

// Step 3: The dApp sends the sponsored_transaction back to the user,
// who signs and executes it with their wallet.
let response = wallet.sign_and_execute_transaction_block(&sponsored_transaction)?;

Für eine vollständige Implementierung verweisen wir auf das Gas Station Tutorial in der offiziellen Sui-Dokumentation, das sofort einsatzbereite Codebeispiele bietet.

6. Risiken und Schutz​

Obwohl leistungsstark, erfordert der Einsatz einer Gas Station in einer Produktionsumgebung eine sorgfältige Abwägung der folgenden Risiken:

• Äquivokation (Double-Spending): Ein böswilliger Benutzer könnte versuchen, denselben Gas Coin für mehrere Transaktionen parallel zu verwenden, was dazu führen würde, dass der Gas Coin vom Sui-Netzwerk gesperrt wird. Dies kann effektiv gemildert werden, indem jedem Benutzer oder jeder Transaktion ein eindeutiger Gas Coin zugewiesen, eine Blacklist geführt und Signaturanfragen ratenbegrenzt werden.
• Gas-Pool-Management: In Szenarien mit hoher Parallelität kann ein einzelner Gas Coin mit hohem Wert zu einem Leistungsengpass werden. Der Gas Station-Dienst muss in der Lage sein, große SUI-Coins automatisch in viele kleinere Gas Coins aufzuteilen und diese nach Gebrauch effizient zurückzugewinnen. Professionelle Gas Station-Anbieter wie Shinami bieten ausgereifte, verwaltete Lösungen hierfür an.
• Autorisierung und Ratenbegrenzung: Sie müssen strenge Autorisierungs- und Ratenbegrenzungsrichtlinien festlegen. Verwalten Sie beispielsweise Sponsoring-Limits und -Häufigkeiten basierend auf Benutzer-IP, Wallet-Adresse oder API-Tokens, um zu verhindern, dass der Dienst von böswilligen Akteuren geleert wird.

7. Ökosystem-Tools​

Das Sui-Ökosystem bietet bereits eine Vielzahl von Tools, um die Entwicklung und Bereitstellung von Paymastern zu vereinfachen:

• Offizielle SDKs (Rust/TypeScript): Enthalten High-Level-APIs wie sponsor_transaction_block(), was die Integrationskomplexität erheblich reduziert.
• Shinami Gas Station: Bietet einen All-in-One-Managed-Service, einschließlich automatischer Gas-Coin-Aufteilung/-Rückgewinnung, detaillierter Metriküberwachung und Webhook-Benachrichtigungen, sodass sich Entwickler auf die Geschäftslogik konzentrieren können.
• Enoki / Mysten Demos: Die Community und Mysten Labs stellen auch Open-Source-Paymaster-Implementierungen bereit, die als Referenz für den Aufbau Ihres eigenen Dienstes verwendet werden können.

8. Implementierungs-Checkliste​

Bereit, Ihre dApp in die gas-lose Ära zu bringen? Gehen Sie diese Checkliste durch, bevor Sie beginnen:

• Planen Sie Ihren Finanzierungsfluss: Definieren Sie die Finanzierungsquelle, das Budget und die Nachschubstrategie des Sponsors. Richten Sie Überwachung und Warnmeldungen für Schlüsselmetriken (z. B. Gas-Pool-Guthaben, Verbrauchsrate) ein.
• Reservieren Sie Attributionsfelder: Achten Sie bei der Gestaltung Ihrer Transaktionsparameter darauf, Felder für Geschäftsbezeichner wie order_id oder user_id zu reservieren.
• Implementieren Sie Anti-Missbrauchsrichtlinien: Sie müssen strenge Autorisierungs-, Ratenbegrenzungs- und Protokollierungsmechanismen implementieren, bevor Sie live gehen.
• Proben auf dem Testnet: Egal, ob Sie Ihren eigenen Dienst aufbauen oder eine Drittanbieter-Gas Station integrieren, führen Sie immer zuerst gründliche Parallelitäts- und Stresstests auf einem Testnet oder Devnet durch.
• Kontinuierlich optimieren: Verfolgen Sie nach dem Start kontinuierlich die Transaktionserfolgsraten, Fehlerursachen und Gaskosten. Passen Sie Ihr Budget und Ihre Strategien basierend auf den Daten an.

Fazit​

Der Sui Paymaster (Gas Station) ist mehr als nur ein Tool zur Deckung der Gasgebühren von Benutzern. Es ist ein leistungsstarkes Paradigma, das ein „Zero SUI On-Chain“-Benutzererlebnis elegant mit dem geschäftlichen Bedürfnis nach „On-Chain-Attribution auf Bestellebene“ innerhalb einer einzigen, atomaren Transaktion kombiniert. Es ebnet Web2-Benutzern den Weg in Web3 und bietet Entwicklern eine beispiellose Flexibilität für die Geschäftsanpassung.

Mit einem zunehmend ausgereiften Ökosystem von Tools und den derzeit niedrigen Gaskosten im Sui-Netzwerk war es noch nie eine bessere Zeit, die Zahlungs- und Interaktionsflüsse Ihrer dApp in die gas-lose Ära zu bringen.

Wie man Wallet-Reibung reduziert, den Benutzerfluss aufrechterhält und das Potenzial prognostiziert

Was wäre, wenn Ihre Web3-App den gleichen nahtlosen Anmeldevorgang hätte wie ein moderner Web2-Dienst? Das ist das Kernversprechen von zkLogin auf der Sui-Blockchain. Es funktioniert wie OAuth für Sui und ermöglicht es Benutzern, sich mit vertrauten Konten von Google, Apple, X und weiteren anzumelden. Ein Zero-Knowledge-Proof verknüpft dann diese Web2-Identität sicher mit einer On-Chain-Sui-Adresse – keine Wallet-Pop-ups, keine Seed-Phrasen, kein Benutzerabgang.

Die Auswirkungen sind real und unmittelbar. Mit Hunderttausenden von bereits aktiven zkLogin-Konten berichten Fallstudien von massiven Zuwächsen bei der Benutzerkonversion, die nach der Beseitigung traditioneller Wallet-Barrieren von mageren 17 % auf gesunde 42 % anstieg. Lassen Sie uns aufschlüsseln, wie es funktioniert und was es für Ihr Projekt tun kann.

Warum Wallets die Erstkonversion töten​

Sie haben eine bahnbrechende dApp entwickelt, aber Ihr Benutzerakquisitions-Funnel leckt. Der Schuldige ist fast immer derselbe: der "Connect Wallet"-Button. Das standardmäßige Web3-Onboarding ist ein Labyrinth aus Erweiterungsinstallationen, Seed-Phrasen-Warnungen und Krypto-Jargon-Quizzen.

Es ist eine massive Barriere für Neulinge. UX-Forscher beobachteten einen erstaunlichen 87 %igen Rückgang in dem Moment, in dem eine Wallet-Aufforderung erschien. In einem aufschlussreichen Experiment führte die einfache Umleitung dieser Aufforderung auf eine spätere Phase des Checkout-Prozesses dazu, dass die Abschlussrate auf 94 % stieg. Selbst für krypto-interessierte Benutzer ist die Hauptangst: „Ich könnte meine Gelder verlieren, wenn ich auf den falschen Button klicke.“ Das Entfernen dieses einen, einschüchternden Schritts ist der Schlüssel zur Erschließung exponentiellen Wachstums.

Wie zkLogin funktioniert (einfach erklärt)​

zkLogin umgeht das Wallet-Problem elegant, indem es Technologien verwendet, denen jeder Internetnutzer bereits vertraut. Die Magie geschieht hinter den Kulissen in wenigen schnellen Schritten:

1. Ephemeres Schlüsselpaar: Wenn ein Benutzer sich anmelden möchte, wird ein temporäres, sitzungsbezogenes Schlüsselpaar lokal in seinem Browser generiert. Stellen Sie es sich wie einen temporären Passkey vor, der nur für diese Sitzung gültig ist.
2. OAuth-Prozess: Der Benutzer meldet sich mit seinem Google-, Apple- oder einem anderen Social-Konto an. Ihre App bettet geschickt einen eindeutigen Wert (Nonce) in diese Anmeldeanfrage ein.
3. ZKP-Dienst: Nach einer erfolgreichen Anmeldung generiert ein ZKP (Zero-Knowledge Proof)-Dienst einen kryptografischen Beweis. Dieser Beweis bestätigt: „Dieses OAuth-Token autorisiert den Besitzer des temporären Passkeys,“ ohne jemals die persönliche Identität des Benutzers On-Chain preiszugeben.
4. Adresse ableiten: Das JWT (JSON Web Token) des Benutzers vom OAuth-Anbieter wird mit einem eindeutigen Salt kombiniert, um seine permanente Sui-Adresse deterministisch zu generieren. Der Salt wird privat gehalten, entweder Client-seitig oder in einem sicheren Backend.
5. Transaktion übermitteln: Ihre App signiert Transaktionen mit dem temporären Schlüssel und fügt den ZK-Proof bei. Sui-Validatoren überprüfen den Proof On-Chain und bestätigen die Legitimität der Transaktion, ohne dass der Benutzer jemals eine traditionelle Wallet benötigt.

Schritt-für-Schritt-Integrationsanleitung​

Bereit zur Implementierung? Hier ist eine Kurzanleitung mit dem TypeScript SDK. Die Prinzipien sind für Rust oder Python identisch.

1. SDK installieren​

Das @mysten/sui-Paket enthält alle zklogin-Helfer, die Sie benötigen.

pnpm add @mysten/sui

2. Schlüssel und Nonce generieren​

Erstellen Sie zunächst ein ephemeres Schlüsselpaar und eine Nonce, die an die aktuelle Epoche im Sui-Netzwerk gebunden ist.

const keypair = new Ed25519Keypair();
const { epoch } = await suiClient.getLatestSuiSystemState();
const nonce = generateNonce(keypair.getPublicKey(), Number(epoch) + 2, generateRandomness());

3. Weiterleitung zu OAuth​

Erstellen Sie die entsprechende OAuth-Anmelde-URL für den von Ihnen verwendeten Anbieter (z. B. Google, Facebook, Apple) und leiten Sie den Benutzer weiter.

4. JWT dekodieren & Benutzer-Salt abrufen​

Nachdem sich der Benutzer angemeldet und zurückgeleitet wurde, rufen Sie das id_token aus der URL ab. Verwenden Sie es, um den benutzerspezifischen Salt von Ihrem Backend abzurufen, und leiten Sie dann seine Sui-Adresse ab.

const jwt = new URLSearchParams(window.location.search).get('id_token')!;
const salt = await fetch('/api/salt?jwt=' + jwt).then(r => r.text());
const address = jwtToAddress(jwt, salt);

5. ZK-Proof anfordern​

Senden Sie das JWT an einen Prover-Dienst, um den ZK-Proof zu erhalten. Für die Entwicklung können Sie den öffentlichen Prover von Mysten verwenden. In der Produktion sollten Sie Ihren eigenen hosten oder einen Dienst wie Enoki nutzen.

const proof = await fetch('/api/prove', {
  method:'POST',
  body: JSON.stringify({ jwt, ... })
}).then(r => r.json());

6. Signieren & Senden​

Erstellen Sie nun Ihre Transaktion, legen Sie den Absender auf die zkLogin-Adresse des Benutzers fest und führen Sie sie aus. Das SDK übernimmt das automatische Anhängen der zkLoginInputs (des Proofs). ✨

const tx = new TransactionBlock();
tx.moveCall({ target:'0x2::example::touch_grass' }); // Beliebiger Move-Aufruf
tx.setSender(address);
tx.setGasBudget(5_000_000);

await suiClient.signAndExecuteTransactionBlock({
  transactionBlock: tx,
  zkLoginInputs: proof // Die Magie geschieht hier
});

7. Sitzung beibehalten​

Für eine reibungslosere Benutzererfahrung verschlüsseln und speichern Sie das Schlüsselpaar und den Salt in IndexedDB oder im lokalen Speicher. Denken Sie daran, diese alle paar Epochen zu rotieren, um die Sicherheit zu erhöhen.

KPI-Prognosevorlage​

Der Unterschied, den zkLogin macht, ist nicht nur qualitativ, sondern auch quantifizierbar. Vergleichen Sie einen typischen Onboarding-Funnel mit einem zkLogin-gestützten:

👉 Was das bedeutet: Für eine Kampagne, die 10.000 einzelne Besucher anzieht, ist das der Unterschied zwischen 300 On-Chain-Aktionen am ersten Tag und über 2.500.

Best Practices & Fallstricke​

Um ein noch nahtloseres Erlebnis zu schaffen, beachten Sie diese Profi-Tipps:

• Gesponserte Transaktionen nutzen: Bezahlen Sie die ersten Transaktionsgebühren Ihrer Benutzer. Dies beseitigt jegliche Reibung und sorgt für einen unglaublichen "Aha"-Moment.
• Salts sorgfältig behandeln: Das Ändern des Salts eines Benutzers generiert eine neue Adresse. Tun Sie dies nur, wenn Sie einen zuverlässigen Wiederherstellungspfad für sie kontrollieren.
• Sui-Adresse offenlegen: Zeigen Sie den Benutzern nach der Anmeldung ihre On-Chain-Adresse. Dies ermöglicht fortgeschrittenen Benutzern, diese später bei Bedarf in eine traditionelle Wallet zu importieren.
• Refresh-Loops verhindern: Cachen Sie das JWT und das ephemere Schlüsselpaar, bis sie ablaufen, um zu vermeiden, dass der Benutzer wiederholt zur Anmeldung aufgefordert wird.
• Prover-Latenz überwachen: Behalten Sie die Roundtrip-Zeit der Proof-Generierung im Auge. Wenn sie 2 Sekunden überschreitet, sollten Sie die Bereitstellung eines regionalen Provers in Betracht ziehen, um die Geschwindigkeit zu gewährleisten.

Wo BlockEden.xyz Mehrwert schafft​

Während zkLogin den benutzerseitigen Ablauf perfektioniert, bringt die Skalierung neue Backend-Herausforderungen mit sich. Hier kommt BlockEden.xyz ins Spiel.

• API-Schicht: Unsere hochdurchsatzstarken, geo-gerouteten RPC-Knoten stellen sicher, dass Ihre zkLogin-Transaktionen mit minimaler Latenz verarbeitet werden, unabhängig vom Standort des Benutzers.
• Observability: Erhalten Sie sofort einsatzbereite Dashboards, um wichtige Metriken wie Proof-Latenz, Erfolgs-/Fehlerraten und die Gesundheit Ihres Konversions-Funnels zu verfolgen.
• Compliance: Für Apps, die in Fiat-Währungen überbrücken, bietet unser optionales KYC-Modul einen konformen On-Ramp direkt von der verifizierten Identität des Benutzers.

Bereit zum Start?​

Die Ära der klobigen, einschüchternden Wallet-Abläufe ist vorbei. Starten Sie eine zkLogin-Sandbox, schließen Sie BlockEdens Full-Node-Endpunkt an und beobachten Sie, wie Ihre Anmeldekurve nach oben zeigt – während Ihre Benutzer das Wort „Wallet“ nie hören müssen. 😉

Seit Jahren wird die Krypto-Welt durch ein kritisches Usability-Problem behindert: die Wallet. Traditionelle Wallets, bekannt als Externally Owned Accounts (EOAs), sind unerbittlich. Eine einzige verlorene Seed-Phrase bedeutet, dass Ihre Gelder für immer verloren sind. Jede Aktion erfordert eine Signatur, und Gasgebühren müssen im nativen Token der Kette bezahlt werden. Dieses klobige, risikoreiche Erlebnis ist ein großes Hindernis für die Massenadoption.

Hier kommt die Account Abstraction (AA) ins Spiel, ein Paradigmenwechsel, der die Art und Weise, wie wir mit der Blockchain interagieren, neu definieren wird. Im Kern verwandelt AA das Konto eines Benutzers in einen programmierbaren Smart Contract, der Funktionen wie soziale Wiederherstellung, Ein-Klick-Transaktionen und flexible Gaszahlungen ermöglicht.

Der Weg in diese intelligentere Zukunft entfaltet sich entlang dreier unterschiedlicher Pfade: der kampferprobte ERC-4337, die effiziente Native AA und der mit Spannung erwartete EIP-7702. Lassen Sie uns aufschlüsseln, was jeder Ansatz für Entwickler und Benutzer bedeutet.

💡 Pfad 1: Der Pionier — ERC-4337​

ERC-4337 war der Durchbruch, der die Account Abstraction auf Ethereum und EVM-Ketten ohne das Kernprotokoll zu ändern, brachte. Stellen Sie es sich vor wie das Hinzufügen einer intelligenten Schicht über dem bestehenden System.

Es führt einen neuen Transaktionsfluss ein, der Folgendes umfasst:

• UserOperations: Ein neues Objekt, das die Absicht eines Benutzers darstellt (z. B. „100 USDC gegen ETH tauschen“).
• Bundlers: Off-Chain-Akteure, die UserOperations aufnehmen, bündeln und an das Netzwerk übermitteln.
• EntryPoint: Ein globaler Smart Contract, der die gebündelten Operationen validiert und ausführt.

Die Vorteile:

• Universelle Kompatibilität: Es kann auf jeder EVM-Kette eingesetzt werden.
• Flexibilität: Ermöglicht umfangreiche Funktionen wie Session Keys für Spiele, Multi-Signatur-Sicherheit und Gas-Sponsoring über Paymaster.

Der Kompromiss:

• Komplexität & Kosten: Es führt einen erheblichen Infrastruktur-Overhead ein (Betrieb von Bundlern) und hat die höchsten Gasgebühren der drei Ansätze, da jede Operation die zusätzliche EntryPoint-Logik durchläuft. Aus diesem Grund hat sich seine Akzeptanz hauptsächlich auf gasfreundlichen L2s wie Base und und Polygon entwickelt.

ERC-4337 ebnete den Weg, damit andere AA-Lösungen folgen konnten. Es bewies die Nachfrage und legte den Grundstein für ein intuitiveres Web3-Erlebnis.

🚀 Pfad 2: Das integrierte Ideal — Native Account Abstraction​

Wenn ERC-4337 ein Add-on ist, baut Native AA intelligente Funktionen direkt in das Fundament der Blockchain ein. Ketten wie zkSync Era und Starknet wurden von Grund auf mit AA als Kernprinzip konzipiert. In diesen Netzwerken ist jedes Konto ein Smart Contract.

Die Vorteile:

• Effizienz: Durch die Integration der AA-Logik in das Protokoll werden zusätzliche Schichten entfernt, was zu deutlich niedrigeren Gasgebühren im Vergleich zu ERC-4337 führt.
• Einfachheit für Entwickler: Entwickler müssen keine Bundler oder einen separaten Mempool verwalten. Der Transaktionsfluss fühlt sich viel mehr wie ein Standardfluss an.

Der Kompromiss:

• Ökosystem-Fragmentierung: Native AA ist ketten-spezifisch. Ein Konto auf zkSync unterscheidet sich von einem Konto auf Starknet, und keines von beiden ist nativ zum Ethereum-Mainnet. Dies schafft eine fragmentierte Erfahrung für Benutzer und Entwickler, die über mehrere Ketten hinweg arbeiten.

Native AA zeigt uns das „Endspiel“ für Effizienz, aber seine Akzeptanz ist an das Wachstum seiner Host-Ökosysteme gebunden.

🌉 Pfad 3: Die pragmatische Brücke — EIP-7702​

EIP-7702, das in das Ethereum-Upgrade „Pectra“ von 2025 aufgenommen werden soll, ist ein Game-Changer, der darauf abzielt, AA-Funktionen den Massen bestehender EOA-Benutzer zugänglich zu machen. Es verfolgt einen hybriden Ansatz: Es ermöglicht einem EOA, seine Autorität vorübergehend an einen Smart Contract zu delegieren für eine einzelne Transaktion.

Stellen Sie es sich so vor, als würden Sie Ihrem EOA vorübergehend Superkräfte verleihen. Sie müssen Ihre Gelder nicht migrieren oder Ihre Adresse ändern. Ihre Wallet kann einfach eine Autorisierung zu einer Transaktion hinzufügen, wodurch sie gebündelte Operationen durchführen kann (z. B. Genehmigen + Tauschen mit einem Klick) oder ihre Gasgebühren gesponsert werden.

Die Vorteile:

• Abwärtskompatibilität: Es funktioniert mit den Milliarden von Dollar, die durch bestehende EOAs gesichert sind. Keine Migration erforderlich.
• Geringe Komplexität: Es verwendet den Standard-Transaktionspool, wodurch die Notwendigkeit von Bundlern entfällt und die Infrastruktur drastisch vereinfacht wird.
• Katalysator für die Massenadoption: Indem intelligente Funktionen jedem Ethereum-Benutzer über Nacht zugänglich gemacht werden, könnte die Einführung besserer UX-Muster schnell beschleunigt werden.

Der Kompromiss:

• Keine „volle“ AA: EIP-7702 löst das Schlüsselmanagement für das EOA selbst nicht. Wenn Sie Ihren privaten Schlüssel verlieren, haben Sie immer noch Pech. Es geht mehr darum, die Transaktionsfähigkeiten zu verbessern, als die Kontosicherheit grundlegend zu überarbeiten.

Kopf-an-Kopf: Ein klarer Vergleich​

Die Zukunft ist konvergent und benutzerzentriert​

Diese drei Pfade schließen sich nicht gegenseitig aus; sie konvergieren zu einer Zukunft, in der die Wallet kein Reibungspunkt mehr ist.

1. Soziale Wiederherstellung wird Standard 🛡️: Die Ära der „verlorenen Schlüssel, verlorenen Gelder“ geht zu Ende. AA ermöglicht eine wächterbasierte Wiederherstellung, wodurch die Selbstverwahrung so sicher und nachsichtig wird wie ein traditionelles Bankkonto.
2. Gaming UX neu gedacht 🎮: Session Keys ermöglichen nahtloses Gameplay ohne ständige „Transaktion genehmigen“-Pop-ups, wodurch sich Web3-Gaming endlich wie Web2-Gaming anfühlt.
3. Wallets als programmierbare Plattformen: Wallets werden modular. Benutzer könnten ein „DeFi-Modul“ für automatisiertes Yield Farming oder ein „Sicherheitsmodul“ hinzufügen, das eine 2FA für große Überweisungen erfordert.

Für Entwickler und Infrastrukturanbieter wie Blockeden.xyz ist diese Entwicklung unglaublich spannend. Die Komplexität von Bundlern, Paymastern und verschiedenen AA-Standards schafft eine enorme Chance, robuste, zuverlässige und abstrahierte Infrastruktur bereitzustellen. Ziel ist ein einheitliches Erlebnis, bei dem ein Entwickler AA-Funktionen einfach integrieren kann und die Wallet intelligent ERC-4337, Native AA oder EIP-7702 im Hintergrund verwendet, je nachdem, was die Kette unterstützt.

Die Wallet erhält endlich das Upgrade, das sie verdient. Der Übergang von statischen EOAs zu dynamischen, programmierbaren Smart Accounts ist nicht nur eine Verbesserung – es ist die Revolution, die Web3 für die nächsten Milliarden Benutzer zugänglich und sicher machen wird.

Hallo und willkommen zurück in unserem Blockchain-Blog! Heute tauchen wir in einen spannenden neuen Vorschlag namens ERC-4337 ein, der Account Abstraction in Ethereum einführt, ohne Änderungen am Konsensschicht-Protokoll zu erfordern. Stattdessen stützt sich dieser Vorschlag auf eine höhere Infrastrukturschicht, um seine Ziele zu erreichen. Lassen Sie uns erkunden, was ERC-4337 zu bieten hat und wie es die Einschränkungen des aktuellen Ethereum-Ökosystems angeht.

Was ist ERC-4337?​

ERC-4337 ist ein Vorschlag, der Account Abstraction in Ethereum durch die Verwendung eines separaten Mempools und eines neuen Typs von Pseudo-Transaktionsobjekten, genannt UserOperation, einführt. Benutzer senden UserOperation-Objekte in den alternativen Mempool, wo eine spezielle Klasse von Akteuren, sogenannte Bundler, diese zu einer Transaktion bündeln, die einen handleOps-Aufruf an einen dedizierten Smart Contract tätigt. Diese Transaktionen werden dann in einen Block aufgenommen.

Der Vorschlag verfolgt mehrere Ziele:

1. Benutzern ermöglichen, Smart-Contract-Wallets mit beliebiger Verifizierungslogik als ihre primären Konten zu verwenden.
2. Die Notwendigkeit für Benutzer, Externally Owned Accounts (EOAs) zu besitzen, vollständig beseitigen.
3. Dezentralisierung gewährleisten, indem jeder Bundler am Prozess der Aufnahme von Account-Abstracted User Operations teilnehmen kann.
4. Ermöglichen, dass alle Aktivitäten über einen öffentlichen Mempool stattfinden, wodurch die Notwendigkeit entfällt, dass Benutzer direkte Kommunikationsadressen bestimmter Akteure kennen.
5. Vertrauensannahmen gegenüber Bundlern vermeiden.
6. Keine Ethereum-Konsensänderungen erfordern, um eine schnellere Akzeptanz zu ermöglichen.
7. Andere Anwendungsfälle unterstützen, wie datenschutzfreundliche Anwendungen, atomare Multi-Operationen, das Bezahlen von Transaktionsgebühren mit ERC-20-Tokens und von Entwicklern gesponserte Transaktionen.

Abwärtskompatibilität​

Da ERC-4337 die Konsensschicht nicht ändert, gibt es keine direkten Abwärtskompatibilitätsprobleme für Ethereum. Allerdings sind Konten vor ERC-4337 nicht ohne Weiteres mit dem neuen System kompatibel, da ihnen die erforderliche validateUserOp-Funktion fehlt. Dies kann behoben werden, indem ein ERC-4337-kompatibles Konto erstellt wird, das die Verifizierungslogik als Wrapper neu implementiert und es als vertrauenswürdigen Op-Submitter des ursprünglichen Kontos festlegt.

Referenzimplementierung​

Für diejenigen, die tiefer in die technischen Details von ERC-4337 eintauchen möchten, ist eine Referenzimplementierung unter https://github.com/eth-infinitism/account-abstraction/tree/main/contracts verfügbar.

Sicherheitsaspekte​

Der Entry Point Contract für ERC-4337 muss umfassend geprüft und formal verifiziert werden, da er als zentraler Vertrauenspunkt für das gesamte System dient. Obwohl dieser Ansatz den Prüf- und formalen Verifizierungsaufwand für einzelne Konten reduziert, konzentriert er das Sicherheitsrisiko im Entry Point Contract, der robust verifiziert werden muss.

Die Verifizierung sollte zwei primäre Behauptungen abdecken:

1. Sicherheit gegen willkürliche Übernahme: Der Entry Point ruft ein Konto nur generisch auf, wenn validateUserOp für dieses spezifische Konto erfolgreich war.
2. Sicherheit gegen Gebührenentzug: Wenn der Entry Point validateUserOp aufruft und dies erfolgreich ist, muss er auch den generischen Aufruf mit calldata gleich op.calldata tätigen.

Fazit​

ERC-4337 ist ein spannender Vorschlag, der darauf abzielt, Account Abstraction in Ethereum einzuführen, ohne Änderungen am Konsensschicht-Protokoll zu erfordern. Durch die Nutzung einer höheren Infrastrukturschicht eröffnet es neue Möglichkeiten für Dezentralisierung, Flexibilität und verschiedene Anwendungsfälle. Obwohl Sicherheitsaspekte zu berücksichtigen sind, hat dieser Vorschlag das Potenzial, das Ethereum-Ökosystem und die Benutzererfahrung erheblich zu verbessern.