Warum eine Smart Account ein anderes Denkmodell ist
Wer schon einmal eine Adresse kopiert, sie in einem Block-Explorer überprüft und versucht hat zu entschlüsseln, was eine Transaktion getan hat, der geht stillschweigend davon aus, dass ein Schlüssel ein Konto kontrolliert. Smart-Contract-Wallets brechen diese Annahme. Die Adresse, die du in Etherscan oder einem ähnlichen Explorer siehst, ist kein Schlüssel. Sie ist ein Vertrag. Der Vertrag besitzt Vermögenswerte, erzwingt Regeln und entscheidet, welche Anweisungen er akzeptiert. Der Nutzer, genauer gesagt die Menge der Schlüssel oder Sessions, die aktuell handeln dürfen, sendet Anweisungen über eine separate Pipeline an diesen Vertrag.
Deshalb wirkt eine einzelne On-Chain-Aktion in einem Block-Explorer oft unübersichtlich. Was wie eine Transaktion aussieht, besteht intern aus mehreren Schichten: die signierte Absicht des Nutzers, ein Relayer, der sie einreicht, ein EntryPoint-Vertrag, der sie validiert, optionale Paymaster-Logik, die Gas bezahlt, und die callData, die die eigentliche Aktion innerhalb der Smart Account ausführt. Die Form auf der Chain wirkt zunächst ungewohnt, und genau auf diese Ungewohnheit setzen Angreifer.
Transaktion versus UserOperation: der zentrale Unterschied
Eine gewöhnliche Ethereum-Transaktion hat sechs lesbare Felder: from, to, value, data, gas limit und signature. Eine UserOperation, definiert im ERC-4337-Standard, ergänzt Felder für delegierte und gesponserte Ausführung. Für das Lesen am wichtigsten sind: sender, also die Adresse der Smart Account; nonce, die pro Konto gilt und nicht wie eine EOA-Nonce an den globalen Transaktionszähler gebunden ist; initCode, das das Konto bei erster Nutzung bereitstellt; callData, also das, was die Smart Account bei Freigabe ausführt; und signature, die eine ECDSA-Signatur, eine aggregierte BLS-Signatur eines Bundlers oder ein von der Account selbst definierter Validator-Hook sein kann.
Dazu kommt ein Gas-Bezahl-Overlay, das normale Transaktionen nicht haben. paymasterAndData verweist auf einen Paymaster-Vertrag, der den Bundler erstattet. Der Paymaster darf deine UserOperation prüfen, bevor er zustimmt, sie zu sponsern, und in manchen Implementierungen kann er den postOp-Schritt verändern, der nach Abschluss deines Calls läuft. Dieser post-op-Callback ist eine echte Angriffsfläche: Ein bösartiger Paymaster kann die Rückgabedaten deines Calls lesen und sie auf Weisen nutzen, die du nicht autorisiert hast. Behandle Paymaster wie jeden anderen Vertragspartner, denn genau das sind sie im strengen Sinne.
Eine UserOperation zu lesen bedeutet daher, mindestens vier Dinge zu prüfen: dass sender auf einen Vertrag zeigt, den du tatsächlich besitzt oder erwartest, dass callData Adressen anspricht, die du autorisiert hast (eine Session oder eine vom Guardian genehmigte Whitelist), dass die Gas-Parameter nicht absurd hoch sind und dass der Paymaster einer ist, dem du vertraust, sich korrekt zu verhalten.
Der EntryPoint-Vertrag: Geteiltes Infrastrukturrisiko
Jedes ERC-4337-Smart-Account im Ethereum-Mainnet teilt sich zum Zeitpunkt der Erstellung eine einzige EntryPoint-Adresse. Der Standard erlaubt ausdrücklich mehrere EntryPoint-Versionen, in der Praxis trägt jedoch eine kanonische Bereitstellung den Großteil der Aktivität. Diese Zentralisierung ist eine bewusste Designentscheidung: Ein gemeinsamer EntryPoint ermöglicht es Bundlern, Paymastern und Account-Implementierungen, ohne paarweise Integrationen zusammenzuarbeiten. Sie konzentriert aber auch das Risiko.
Wenn der EntryPoint aktualisiert, durch eine Governance-Abstimmung übernommen wird oder eine Schwachstelle enthält, ist jedes Smart-Account, das darüber läuft, gleichzeitig betroffen. Das ist keine Hypothese. Ende 2023 wurde ein Vorfall im Zusammenhang mit einer EntryPoint-bezogenen Bibliothek bei einem Audit durch einen Prüfer offengelegt und über alle Integrationen hinweg gepatcht. Im großen Stil ging nichts verloren, doch die Lehre blieb: Geteilte Infrastruktur ist ein einzelner Fehlerpunkt, und die Sicherheit deines Accounts ist nur so stark wie die schwächste Komponente in diesem Stack.
Beim Lesen von On-Chain-Daten sollte daher kurz geprüft werden, ob der EntryPoint, über den dein Account läuft, die Version ist, die du erwartest. Mainnet und die meisten L2s veröffentlichen kanonische EntryPoint-Adressen, und Tools wie Etherscan kennzeichnen die auditierten Bereitstellungen. Wenn du siehst, dass eine UserOperation an einen nicht-kanonischen EntryPoint gesendet wird, behandle das als deutliches Warnsignal: Es könnte sich um einen Phishing-Relayer oder einen Fork handeln, der Signaturen abfangen soll.
Session Keys: Eingegrenzte, zeitlich begrenzte Untervollmachten
Sessions sind das Feature, das sich am meisten zu verstehen lohnt, denn sie werden auch am häufigsten missbraucht. Ein Session Key ist ein zweiter Signer, den du einer bestimmten App für ein definiertes Zeitfenster mit einem definierten Satz an Berechtigungen gewährst. In der Praxis sieht das so aus, dass eine dApp für die nächste Stunde die Erlaubnis anfordert, auf Uniswap in deinem Namen zu handeln, bis zu einem Ausgabenlimit und gegen eine Allowlist von Token-Verträgen.
On-Chain lebt eine Session als State innerhalb deines Smart-Accounts. Die relevanten Felder, in der Reihenfolge, in der sie im Storage tendenziell erscheinen, sind: eine autorisierte Session-Key-Adresse; ein Ablaufzeitpunkt oder Blocknummer; ein Ausgabenlimit pro Zeitraum (oft täglich oder pro Epoche); eine Target-Allowlist oder Selector-Allowlist; und ein Policy-Hook, der zusätzliche Regeln anwenden kann. Implementierungen variieren. Safe Modules, Zodiac Heads, Biconomy Sessions und Kernel Session Validators kodieren dies jeweils etwas anders, und das genaue Slot-Layout ist wichtig, wenn du den Storage direkt liest.
Die Erkenntnis ist, dass Sessions zwar begrenzt, aber nicht standardmäßig sicher sind. Eine Session, die auf Uniswaps Router beschränkt ist, ist nur so gut wie Uniswaps Router. Eine Session, die eine Allowlist von Selektoren gewährt, kann dennoch gefährliche Selektoren treffen, wenn die App weiß, welche sie aufrufen muss. Und Sessions, die kein zeitlich zurückgesetztes Ausgabenlimit erzwingen, können mit der Zeit Gelder abziehen, sobald der Nutzer nicht mehr aufmerksam ist.
Zwei praktische Gewohnheiten helfen. Erstens: Lies den exakten Storage-Slot oder die dekodierte Ansicht, die die Wallet-UI anzeigt, bevor du die Session-Genehmigung signierst, und behandle sie als Quelle der Wahrheit, nicht als Marketingtext der dApp. Zweitens: Bevorzuge Sessions mit sowohl einem Pro-Zeitraum-Limit als auch einem Pro-Aufruf-Limit, damit ein einzelner durchgehender Aufruf kein sinnvolles Maximum überschreiten kann.
Eine einzelne UserOperation im Detail lesen
Stell dir vor, du siehst in deiner Wallet einen Hash 0xabc... und willst wissen, was er tatsächlich getan hat. Öffne die Transaktion in einem Block-Explorer und klicke dich zur EntryPoint-Transaktion durch, deren callData mit handleOps beginnt. Der Reiter für interne Transaktionen erzählt die eigentliche Geschichte.
Schritt 1: validateUserOp
Der EntryPoint ruft zunächst die Funktion validateUserOp deines Accounts auf. Hier wird die Signatur geprüft, Nonces werden gegen Replay-Schutz validiert und alle Session-Policies werden erzwungen. Eine fehlgeschlagene Validierung macht das gesamte Bundle rückgängig, daher ist ein erfolgreicher Durchlauf ein Beleg dafür, dass mindestens ein gültiger Signer die Operation genehmigt hat.
Schritt 2: execute
Wenn die Validierung erfolgreich ist, ruft der EntryPoint die Funktion execute deines Accounts mit der von dir angegebenen callData auf. Dies ist die für den Nutzer sichtbare Aktion: ein Swap, eine Überweisung, eine Contract-Interaktion. Das Lesen der callData dieses internen Aufrufs liefert dir das eigentliche Ziel, den Wert und den Function-Selector, den der Nutzer wollte.
Schritt 3: postOp
Nach der Ausführung läuft postOp des Paymasters, das zum Beispiel für die Abrechnung von Gas-Schulden, die Rückerstattung ungenutzten Gases oder die Bezahlung des Bundlers verwendet wird. Jede State-Änderung hier wurde durch deine Paymaster-Wahl autorisiert, nicht direkt durch dich. Alles Auffällige, das hier passiert, etwa zusätzliche Token-Transfers oder neue Approvals, ist ein Zeichen, genauer hinzusehen.
Wenn du diese drei Ebenen zusammensetzt, erfährst du, wer was autorisiert hat, was gelaufen ist und welche Nebeneffekte im Nachhinein aufgetreten sind. Die meisten Phishing-Muster werden auf dieser Ebene sichtbar, sobald du weißt, worauf du achten musst.
Paymaster und Bundler: Sichtbarkeit und Vertrauen
Ein Bundler ist die Partei, die deine UserOperation entgegennimmt, mit anderen bündelt und die eigentliche On-Chain-Transaktion an den EntryPoint sendet. Da der Bundler EntryPoint.handleOps aufruft, zahlt die Adresse des Bundlers das Gas auf Chain-Ebene. Du als Smart-Account-Besitzer brauchst nie ETH für Gas, wenn ein Paymaster bereit ist zu sponsern. Das ist bequem, und es ist zugleich eine Vertrauensbeziehung.
Die Verpflichtung eines Paymasters ist on-chain auf zwei Arten kodiert: der Stake, den er beim EntryPoint hinterlegt hat und der bei Fehlverhalten gemäß den Regeln des Standards slashed werden kann, und die Policy seiner Funktion validatePaymasterUserOp, die entscheidet, ob er sponsert. Slashing existiert, ist aber ein grobes Auffangnetz, keine feinkörnige Garantie. Ein Paymaster kann die Operationen, die er sieht, weiterhin beobachten, zensieren oder front-runnen.
Front-Running ist das am wenigsten diskutierte Risiko. Ein Paymaster, der deinen Swap sieht, bevor er ausgeführt wird, kann den Trade auf seine eigene Adresse kopieren, im selben Block ausführen und den Preisvorteil, den du erwartet hast, abschöpfen. Das ist nicht theoretisch; es ist die gleiche Dynamik wie Miner-Extractable Value, verpackt für die Welt der Account-Abstraktion. Gegenmaßnahmen existieren (private Mempools, Commit-Reveal-Schemata, Signed-Intent-Layer), aber sie erfordern aktive Nutzung. Standardmäßige öffentliche Bundler und Paymaster bieten keinen solchen Schutz.
Auch hier hilft das Lesen von On-Chain-Daten. Wenn du siehst, dass deine Operationen immer in derselben Slot-Nummer oder direkt nach einer bestimmten Adresse landen, beobachtet dich dieser Bundler oder Paymaster genau. Der Wechsel zu einem privaten Mempool oder die Nutzung von Paymastern, die sich explizit zu Non-Front-Running-Policies verpflichten und eine überprüfbare Bilanz vorweisen können, ist eine echte Sicherheitssteigerung.
Sitzungen und Berechtigungen on-chain widerrufen
Der häufigste Fehler, den Nutzer von Smart Accounts machen, ist, eine Sitzung so zu behandeln, als ob es reiche, sie in der Benutzeroberfläche der dApp zu widerrufen. In der Regel ist das nicht genug. Die Benutzeroberfläche der dApp vergisst möglicherweise schlicht die Sitzung, während die On-Chain-Berechtigung bis zum Ablauf aktiv bleibt. Bis der Smart-Account-Vertrag einen Inaktivitäts-Timeout erzwingt oder bis du aktiv widerrufst, kann der Sitzungsschlüssel weiterhin Operationen signieren, die der EntryPoint akzeptiert.
Ein echter Widerruf hat drei praktische Formen. Die erste besteht darin, die Revoke-Funktion des Smart Accounts aufzurufen, falls vorhanden, mit der Kennung des Sitzungsschlüssels. Die zweite besteht darin, den Hauptsigner des Kontos zu rotieren, wodurch jede Sitzung ungültig wird, deren Berechtigung an den Signer gebunden war. Die dritte besteht darin, die Sitzung natürlich auslaufen zu lassen, was nur funktioniert, wenn du von Anfang an ein kurzes Zeitfenster festgelegt hast.
Einen On-Chain-Widerruf zu lesen bedeutet, zwei Dinge zu prüfen: den Speicher-Slot der Sitzung, der den widerrufenen oder abgelaufenen Zustand widerspiegeln sollte, und die Nonce-Sequenz des Kontos, die für den widerrufenen Schlüssel nicht weiter fortschreiten sollte. Wenn du einen Sitzungsschlüssel siehst, der nach einem vermeintlichen Widerruf weiterhin Operationen signiert, ist das der Moment, innezuhalten und nachzugehen. Es könnte eine veraltete Benutzeroberfläche sein oder eine Sitzung, die nie ordentlich begrenzt wurde und nun ausgenutzt wird.
Wie du Smart-Account-Aktivitäten auf smarte Weise verfolgst
Smart-Account-Aktivitäten sind schnelllebig, und die On-Chain-Spur ergibt erst Sinn, wenn du die darunterliegenden Schichten verstehst. Zu verfolgen, wer deine Operationen weiterleitet, welche Paymasters sie sponsern und welche Sitzungen noch aktiv sind, ist ein aussichtsloses Spiel, wenn du es manuell machst. Zippfeed liefert Wallet- und Protokoll-Schlagzeilen mit Stimmungsbewertung (bullish, neutral oder bearish) sowie einer Wichtigkeitsbewertung, damit du die Muster hinter dem Rauschen erkennst, bevor du das nächste Mal signierst.
