5 Beiträge getaggt mit „Account Abstraction“

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.