Bundler und UserOperations: Wie ERC-4337-Transaktionen funktionieren

Eine UserOperation ist das von ERC-4337 definierte signierte Absichtsobjekt: Sie erklärt, was ein Smart-Contract-Konto erledigt haben möchte und wie diese Aktion validiert und bezahlt werden soll. Anders als eine gewöhnliche Ethereum-Transaktion ist sie kein Objekt auf Protokollebene, das von einem Externally Owned Account signiert wird: Ihre Signatur prüft der Kontovertrag selbst, und sie muss ihr eigenes natives Gas nicht bezahlen. Ein Bundler ist der Off-Chain-Akteur, der UserOperations aus einem eigens dafür vorgesehenen alternativen Mempool sammelt, jede einzelne simuliert, die gültigen in eine einzige gewöhnliche Ethereum-Transaktion packt und den kanonischen EntryPoint-Vertrag aufruft — der jede Operation im Batch validiert, bevor er auch nur eine davon ausführt. Der Bundler streckt das echte Gas aus seinem eigenen EOA vor und wird on-chain vom sendenden Konto oder vom Paymaster dieses Kontos erstattet. Ein optionaler Paymaster-Vertrag kann sich während genau dieses Validierungsschritts bereit erklären, eine Operation zu übernehmen — dort werden Gebühren gesponsert oder in einem ERC-20-Token statt im nativen Gas-Token der Chain zahlbar.

Ein kurzer ERC-4337-Rückblick

ERC-4337 ist der Ethereum-Standard für Account Abstraction — eine Möglichkeit, Smart-Contract-Konten dieselbe erstklassige Fähigkeit zu geben, Aktionen zu initiieren und zu bezahlen, die Externally Owned Accounts (EOAs) schon immer hatten, ohne jegliche Änderung am Basisprotokoll. Anstatt die Konsensschicht zu modifizieren, führt ERC-4337 ein paralleles System höherstufiger Objekte und Off-Chain-Infrastruktur ein, das letztlich über gewöhnliche Ethereum-Transaktionen abgewickelt wird. Wenn Sie zuerst die Grundlagenversion möchten, behandelt unsere Erklärung zu was Account Abstraction ist die Motivation, was ERC-4337 ist kartiert den vollständigen Standard, und Smart Accounts im Vergleich zu EOAs stellt die beiden Kontotypen direkt gegenüber. Dieser Beitrag zoomt in die Mechanik: die Objekte, die durch das System wandern, und die Akteure, die sie verarbeiten. Beachten Sie, dass ERC-4337 ein EVM-Standard ist — er gilt für Ethereum und EVM-kompatible Chains, nicht für Nicht-EVM-Chains wie Solana oder TON.

Was eine UserOperation tatsächlich ist

Das zentrale Objekt in ERC-4337 ist die UserOperation. Sie sieht oberflächlich wie eine Transaktion aus, ist aber besser als signierte Absichtserklärung zu verstehen: "Hier ist, was mein Konto erledigt haben möchte, und hier sind die Parameter, um es zu validieren und dafür zu bezahlen." Sie ist ein Struct, das einem Vertrag als Calldata übergeben wird, kein natives Protokollobjekt — die Basisschicht hat noch nie von ihr gehört.

Eine UserOperation trägt im Kern:

• sender — das Smart-Contract-Konto, für das die Operation handelt.
• nonce — Replay-Schutz, den der EntryPoint als zweiteiligen Wert führt (ein Schlüssel plus eine Sequenz), sodass ein Konto mehrere unabhängige Nonce-Spuren betreiben kann statt einer einzigen strikten Warteschlange.
• callData — was das Konto ausführen soll, häufig ein Bündel mehrerer Aufrufe in einer Operation.
• Konto-Deployment-Daten — optional; deployt den Kontovertrag bei seiner allerersten Operation. So kann ein Smart Account an einer bekannten, deterministisch abgeleiteten Adresse mit Guthaben versehen werden, bevor er on-chain überhaupt existiert.
• Gas-Limits — getrennte Budgets für Validierung und Ausführung, plus ein preVerificationGas-Wert, der den Bundler für Calldata und Overhead entschädigt, die der EntryPoint nicht selbst abrechnen kann.
• Gebührenparameter — eine maximale Gebühr und eine maximale Prioritätsgebühr, analog zu EIP-1559.
• Paymaster-Daten — optional; welcher Vertrag die Operation sponsert und welchen Kontext er dafür braucht.
• Signatur — geprüft von der eigenen Validierungsfunktion des Kontos, nicht vom Protokoll.

Die genaue Kodierung hat sich über die EntryPoint-Versionen verändert — v0.7 trennt die Deployment- und Paymaster-Blobs in explizite Felder und packt mehrere Gas-Werte zusammen, während v0.6 einzelne Byte-Strings initCode und paymasterAndData verwendete — aber die konzeptionellen Inhalte sind dieselben. Wenn Sie integrieren, prüfen Sie, auf welche EntryPoint-Version Ihr Bundler zielt.

Der entscheidende Unterschied zu einer normalen Transaktion ist, wer und was sie signiert. Eine herkömmliche Ethereum-Transaktion muss vom privaten Schlüssel eines EOA mit einem festen ECDSA-Schema signiert werden, und dasselbe Konto zahlt das Gas. Eine UserOperation wird von der eigenen Smart-Contract-Kontologik des Absenders validiert — die jedes beliebige Signaturschema, jede Mehrschlüssel-Regel, jeden Session Key oder jede Autorisierungsrichtlinie umsetzen kann, die das Konto definiert — und sie muss überhaupt nicht selbst in nativem Gas bezahlen. Diese Flexibilität ist der ganze Sinn: Das Konto, nicht das Protokoll, entscheidet, wie eine gültige Aktion aussieht.

Der alternative Mempool, in dem sie leben

UserOperations gelangen nicht in den regulären Ethereum-Transaktions-Mempool, weil sie noch keine Transaktionen sind. Stattdessen werden sie an einen separaten alternativen Mempool (oft Alt-Mempool genannt) gesendet — ein Peer-to-Peer-Netzwerk, das ERC-4337-Objekten gewidmet ist. In der Praxis reicht eine Wallet oder eine dApp eine UserOperation ein, indem sie eth_sendUserOperation am RPC-Endpunkt eines Bundlers aufruft; dieser Bundler kann sie an den gemeinsamen Alt-Mempool weiterverbreiten oder in einem eigenen privaten Pool behalten. In beiden Fällen lauscht die Infrastruktur, die diese Objekte verarbeitet, hier statt am Mempool der Basisschicht. Diese Trennung hält den Account-Abstraction-Verkehr vom konsenskritischen Pfad fern, bis zu dem Moment, in dem er in eine echte Transaktion verpackt wird.

Die Rolle des Bundlers

Ein Bundler ist der Off-Chain-Akteur, der Absichten in On-Chain-Realität verwandelt. Seine Aufgabe hat vier Teile. Erstens sammelt er UserOperations aus dem alternativen Mempool. Zweitens simuliert und validiert er jede einzelne — er führt die Validierungslogik des Kontos in einem simulierten Kontext aus, um zu bestätigen, dass die Signatur gültig ist, die Nonce korrekt ist und das Konto oder sein Paymaster die Kosten decken kann. Drittens packt er eine oder mehrere gültige UserOperations in eine einzige gewöhnliche Ethereum-Transaktion. Viertens reicht er diese Transaktion aus seinem eigenen EOA beim Netzwerk ein, zahlt das Gas der Basisschicht im Voraus und erwartet eine On-Chain-Erstattung.

Simulation allein ist kein ausreichender Schutz, denn der Zustand kann sich zwischen Simulation und Aufnahme in einen Block ändern. Deshalb schränkt ERC-4337 auch ein, was Validierungscode tun darf: Während der Validierungsphase dürfen ein Konto oder ein Paymaster keine Block-Zeitstempel oder andere Umgebungswerte lesen, die es ihnen erlauben würden, sich on-chain anders zu verhalten als in der Simulation, und ihr Speicherzugriff ist weitgehend auf Slots beschränkt, die dem eigenen Konto zugeordnet sind. Von Verträgen, die im Namen vieler Nutzer handeln — insbesondere Factories und Paymaster —, wird erwartet, dass sie einen Stake hinterlegen, damit ein einzelner sich fehlverhaltender Vertrag nicht billig einen großen Teil des Mempools auf einen Schlag entwerten kann. Diese Regeln existieren aus einem einzigen Grund: die Simulation eines Bundlers zu einer verlässlichen Vorhersage dessen zu machen, was on-chain geschehen wird.

Weil der Bundler das Gas vorstreckt und Gebühren für die Aufnahme verdient, verhält er sich weitgehend wie ein spezialisierter Block-Builder für Account-Abstraction-Verkehr. Sein Simulations- und Validierungsschritt ist das, was ihn schützt: Er wird keine Operation bündeln, die ihn nicht erstatten würde.

Der EntryPoint-Vertrag

Alles läuft in einem einzigen, kanonischen Smart Contract namens EntryPoint zusammen. Er ist ein Singleton, pro Version an derselben Adresse über alle EVM-Chains hinweg deployt, und er verwahrt die Einlagen, aus denen Operationen bezahlt werden. Die Transaktion des Bundlers ist ein Aufruf des EntryPoint mit einem Array von UserOperations, und der EntryPoint durchläuft dann eine strikte zweiphasige Schleife.

In der Validierungsphase ruft er für jede Operation die Validierungsfunktion des Absenderkontos auf (und die des Paymasters, falls einer angegeben ist), um Signatur, Nonce und Zahlungsvereinbarung on-chain erneut zu prüfen, und er reserviert die maximal möglichen Kosten bei demjenigen, der zahlt. Erst nachdem alle Operationen im Batch validiert wurden, geht er zur Ausführungsphase über, in der er die Calldata jeder Operation an ihr Konto weiterleitet, um die Überweisung, den Swap oder eine andere Aktion tatsächlich durchzuführen, und anschließend die echten Kosten abrechnet und die nicht genutzte Reservierung zurückerstattet.

Diese Aufteilung ist wichtig: Validierung und Ausführung werden getrennt, damit die Zahlungsgarantien eines Batches feststehen, bevor irgendeine zustandsverändernde Arbeit läuft, und damit der EntryPoint das Gas über viele Operationen gleichzeitig präzise abrechnen kann. Sie bedeutet außerdem, dass das Scheitern einer Operation während der Ausführung die anderen im Batch nicht vergiften kann.

Wo der Paymaster hineinpasst

Ein Paymaster ist ein optionaler Vertrag, der sich bereit erklärt, für eine UserOperation im Namen des Kontos zu zahlen. Wenn eine UserOperation Paymaster-Daten enthält, fragt der EntryPoint während der Validierungsphase diesen Paymaster, ob er die Operation sponsern wird und zu welchen Bedingungen; der Paymaster gibt eine Entscheidung samt einem Kontext-Blob zurück. Nach der Ausführung ruft der EntryPoint den Paymaster in einem Post-Operation-Schritt mit dem tatsächlich verbrauchten Gas erneut auf — dort rechnet ein Paymaster, der in Token abrechnet, den exakten Betrag ab. Der Paymaster kann bedingungslos akzeptieren (echtes gasloses Sponsoring, bei dem eine App die Kosten trägt) oder er kann im Gegenzug für einen Wert akzeptieren — am nützlichsten, indem er den Nutzer in einem ERC-20-Token statt in nativem Gas belastet. Für einen tieferen Blick auf diese Komponente siehe was ein Paymaster ist. Der Paymaster ist der Angelpunkt im Ablauf, der "womit der Nutzer zahlt" von "worin das Netzwerk bezahlt wird" entkoppelt.

Wie Gas und Fehler behandelt werden

Gas ist in ERC-4337 geschichtet. Der Bundler zahlt echtes ETH für die äußere Transaktion; der EntryPoint misst das Validierungs- und Ausführungsgas jeder UserOperation gegen die von ihr deklarierten Limits; und wer in der Pflicht steht — das Konto oder sein Paymaster — muss beim EntryPoint genug hinterlegt haben, um die Rechnung zu decken, die am Ende des Batches beglichen wird. Eine Folge, die man kennen sollte: Eine ERC-4337-Operation kostet etwas mehr Gas als die entsprechende einfache Transaktion, weil Sie zusätzlich zur Aktion selbst auch die Validierung auf Vertragsebene und die Buchführung des EntryPoint bezahlen.

Fehler werden durch das Validierung-zuerst-Design eingedämmt. Wenn eine Operation während der On-Chain-Validierung fehlschlägt, würde der gesamte Batch revertieren; der Bundler verwirft sie deshalb und baut den Batch neu, statt das geschehen zu lassen — genau dafür ist seine Off-Chain-Simulation da. Wenn eine Operation die Validierung besteht, ihre Ausführung aber revertiert, werden die Ausführungseffekte zurückgerollt, während das bereits verbrauchte Gas dennoch abgerechnet und bezahlt wird, sodass ein Bundler für ehrliche Arbeit nicht unentschädigt bleibt. Diese Asymmetrie ist der Grund, warum Bundler so sorgfältig simulieren: Ihr Schutz vor Griefing besteht darin, nichts aufzunehmen, was sie nicht erstatten würde.

Der Lebenszyklus, der Reihe nach

1. Ihre Wallet baut eine UserOperation: sender, nonce, Calldata, Gas-Limits, Gebührenparameter, optionale Paymaster-Daten.
2. Ein Paymaster gibt, sofern einer genutzt wird, die Sponsoring-Bedingungen frei, bevor die Operation verbreitet wird.
3. Die Signierlogik Ihres Kontos signiert sie — was kein einzelner ECDSA-Schlüssel sein muss.
4. Die Wallet reicht sie beim RPC eines Bundlers ein, und sie gelangt in den alternativen Mempool.
5. Der Bundler simuliert und validiert sie unter den Opcode- und Speicherbeschränkungen des Standards.
6. Der Bundler packt sie mit anderen Operationen in eine Ethereum-Transaktion, die handleOps am EntryPoint aufruft, und zahlt das Gas der Basisschicht.
7. Der EntryPoint validiert jede Operation, führt deren Calldata aus, rechnet die Kosten gegen die Einlagen ab, erstattet den Überschuss zurück und entschädigt den Bundler.

Was das einem Wallet-Nutzer bringt

Die Maschinerie ist aufwendig, aber ihr Zweck ist alltäglich und nützlich: mehrere Aktionen in einer Bestätigung bündeln (zum Beispiel Approve und Swap zusammen), gesponserte oder in Token bezahlte Gebühren, andere Signaturschemata als ein einzelner secp256k1-Schlüssel, Ausgaberichtlinien und Session Keys sowie soziale oder gerätebasierte Wiederherstellung. Erwähnenswert ist, dass EIP-7702 es einem gewöhnlichen EOA erlaubt, vorübergehend mit Smart-Account-Code auszuführen, was den Abstand bei einigen dieser Funktionen verringert, ohne die oben beschriebene ERC-4337-Infrastruktur zu ersetzen.

Wie WATS dies nutzt

Auf EVM-Chains verlässt sich WATS auf genau ein Element dieses Ablaufs: den Paymaster-Slot. Wenn Sie eine Überweisung, einen Swap oder ein Stake in der WATS Hot Wallet durchführen, benennt die UserOperation, die Ihre Wallet baut, einen Paymaster, und dieser Paymaster ist es, der ermöglicht, dass die Gebühr in ATS statt im nativen Gas-Token der Chain berechnet wird — Sie müssen also nie auf jedem Netzwerk ein Staubguthaben an ETH, BNB oder POL halten, nur um überhaupt handlungsfähig zu sein. Sie müssen weder einen Bundler betreiben noch eine EntryPoint-Version wählen oder einen Bundler-RPC-Schlüssel besitzen; das ist Infrastruktur, und die Aufgabe der Wallet ist es, eine gültige UserOperation zu bauen und einzureichen.

Zwei Klarstellungen halten das ehrlich. Erstens ist die Zahlung in ATS kein Rabatt — das Netzwerk berechnet weiterhin seine normale Gebühr und der Paymaster begleicht sie; was sich ändert, ist also, welcher Token Ihr Guthaben verlässt, nicht die zugrunde liegenden Kosten. Zweitens ist ERC-4337 reines EVM, sodass auf Solana und TON eine gleichwertige Fee-Payer-Konstruktion die Rolle des Paymasters übernimmt statt des hier beschriebenen EntryPoint-Ablaufs. ATS ist ein LayerZero OFT, und genau das erlaubt es einem einzigen ATS-Guthaben, Gebühren auf Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana und TON zu decken; eingezogenes ATS wird verbrannt und führt das Angebot von 100.000.000 auf einen Boden von 30.000.000 herunter. WATS ist durchgängig vollständig nicht-verwahrend: Sie halten Ihre Schlüssel, und WATS hält niemals einen.

Wenn Sie diesen Ablauf als funktionierendes System statt als Spezifikation sehen möchten, ist der konkrete Schritt, eine Überweisung in der WATS Hot Wallet auf einer Chain zu versuchen, auf der Sie keinerlei nativen Gas-Token halten: Die UserOperation, der Bundler und der EntryPoint erledigen ihre Arbeit außer Sichtweite, und die Gebühr geht von Ihrem ATS-Guthaben ab. Wie das ATS-Gebührenmodell funktioniert erklärt die Mechanik von Anfang bis Ende.