ERC-6492 erklärt: Signaturen vor dem Smart-Wallet-Deployment prüfen
Warum ERC-6492 wichtig ist
Smart-Contract-Wallets müssen nicht zwangsläufig bereits auf der Blockchain existieren, wenn ihre Adresse angezeigt wird. Eine Adresse kann vorab berechnet werden, während der zugehörige Contract erst bei einer späteren Transaktion eingerichtet wird. Dieses Verfahren erleichtert die Nutzung programmierbarer Wallets, schafft aber ein Problem bei digitalen Signaturen: Eine Anwendung möchte die Identität der Wallet überprüfen, obwohl an ihrer Adresse noch kein Contract-Code liegt. ERC-6492 beschreibt eine standardisierte Lösung für genau diesen Fall. Der Standard erweitert die Signaturprüfung nach ERC-1271 und ermöglicht die Verifikation von Signaturen sogenannter counterfactual Wallets. Das ist technisch interessant, aber keine Aussage über die finanzielle Sicherheit einer Wallet.
Was bedeutet Counterfactual Deployment?
Counterfactual bedeutet hier, dass die zukünftige Contract-Adresse unter bestimmten Voraussetzungen bereits vor dem tatsächlichen Deployment berechnet werden kann. Bei CREATE2 hängt die Adresse unter anderem von der deployenden Factory, einem Salt und dem Hash des Initialisierungscodes ab. Dadurch kann eine Anwendung eine Wallet-Adresse verwenden, obwohl der Contract noch nicht auf der Blockchain gespeichert ist. Erst später wird der Code tatsächlich bereitgestellt. Das ist nicht dasselbe wie eine gewöhnliche EOA-Adresse, die aus einem privaten Schlüssel abgeleitet wird. Der Vorteil besteht darin, dass ein zusätzlicher Einrichtungsschritt zeitlich verschoben werden kann. Das Risiko besteht darin, dass Anwendungen den Zustand einer noch nicht existierenden Wallet falsch interpretieren.
Das Problem der Signaturprüfung
ERC-1271 definiert eine Funktion namens isValidSignature, die ein Smart Contract bereitstellt. Ein Verifizierer kann sie aufrufen, um festzustellen, ob der Contract einen bestimmten Hash und eine bestimmte Signatur anerkennt. Existiert der Contract jedoch noch nicht, kann die Funktion an der betreffenden Adresse nicht aufgerufen werden. Eine naive Anwendung könnte die Signatur deshalb ablehnen, obwohl die künftige Wallet sie nach ihren Regeln akzeptieren würde. Andere Anwendungen könnten fälschlich versuchen, die Signatur wie eine gewöhnliche EOA-Signatur zu prüfen. ERC-6492 führt eine zusätzliche Signaturhülle ein, die Informationen über die Vorbereitung oder Bereitstellung des Contracts mitliefert.
Was ERC-6492 standardisiert
Der Standard definiert ein Wrapper-Format für Signaturen von Contract-Wallets, die noch nicht bereitgestellt oder noch nicht zur Validierung bereit sind. Der Wrapper enthält eine Factory-Adresse beziehungsweise ein Vorbereitungsziel, die zugehörigen Aufrufdaten und die ursprüngliche ERC-1271-Signatur. Am Ende stehen spezielle Erkennungsbytes. Ein kompatibler Verifizierer erkennt dadurch, dass zunächst ein besonderer Prüfablauf nötig ist. Die Spezifikation schreibt keine einzelne Wallet-App, keine fixe Gebührenstruktur und keine Rendite vor. Sie beschreibt vielmehr, wie unterschiedliche Signaturarten zuverlässig auseinandergehalten und überprüft werden sollen. Die konkrete Sicherheit hängt weiterhin von der Factory, dem Wallet-Code und der Autorisierungslogik ab.
Die Magic Bytes verstehen
ERC-6492 verwendet als Erkennungsmerkmal einen 32 Byte langen Suffix aus wiederholten 6492-Mustern. Ein Verifizierer untersucht zunächst das Ende der Signatur. Findet er dieses Muster, behandelt er die Signatur als verpackte Contract-Signatur und nicht als gewöhnliche EOA-Signatur. Diese Reihenfolge ist wichtig: Die Signatur könnte sonst einem falschen Prüfverfahren zugeführt werden. Der Marker beweist allerdings nicht, dass die Signatur tatsächlich autorisiert ist. Er signalisiert nur, welches Verfahren zur Verifikation erforderlich sein könnte. Ein Betrüger kann Daten ebenfalls mit einem Marker versehen; entscheidend bleibt die nachfolgende tatsächliche Prüfung gegen die korrekte Wallet-Adresse und ihre Regeln.
Aufbau einer verpackten Signatur
Vereinfacht enthält die ERC-6492-Signatur drei Informationsblöcke: das Ziel für die Factory oder Vorbereitung, die erforderlichen Aufrufdaten und die eigentliche ERC-1271-Signatur. Anschliessend wird der Erkennungssuffix angehängt. Die Daten werden mit ABI-Kodierung in eine verarbeitbare Struktur gebracht. Bei einer noch nicht bereitgestellten Wallet können die Factory-Daten die vorübergehende Bereitstellung des Contracts während der Prüfung ermöglichen. Bei einer bereits vorhandenen, aber noch nicht bereiten Wallet können sie stattdessen einen vorbereitenden Schritt beschreiben. Für Endnutzer sind diese Bytes normalerweise nicht lesbar. Deshalb ist die verständliche Darstellung der beabsichtigten Aktion durch die Wallet-Oberfläche besonders wichtig.
Der korrekte Prüfablauf
Nach der Spezifikation prüft ein universeller Verifizierer zuerst, ob der ERC-6492-Suffix vorhanden ist. Falls ja, verarbeitet er die Wrapper-Daten und führt den vorgesehenen Factory- oder Vorbereitungsschritt aus, bevor er die ERC-1271-Validierung aufruft. Liegt kein solcher Wrapper vor, untersucht er, ob an der Adresse bereits Contract-Code existiert. Dann kann die gewöhnliche ERC-1271-Prüfung erfolgen. Erst wenn kein Contract-Code vorhanden ist und kein spezieller Wrapper vorliegt, kommt eine klassische EOA-Signaturprüfung in Betracht. Die Reihenfolge verhindert Verwechslungen. Sie ist keine optionale kosmetische Entscheidung, sondern Teil des technischen Sicherheitsmodells.
Werbung / Affiliate-Link: Relai ist eine Bitcoin-App. Bei Nutzung unseres Links oder Codes können wir eine Provision erhalten. Relai verkauft Bitcoin, nicht Ethereum oder andere Altcoins. Code: AUSWANDERNSCHWEIZ.
Warum die Reihenfolge entscheidend ist
Ein Contract kann ein eigenes Signaturformat verwenden, das zufällig auch wie eine gewöhnliche ECDSA-Signatur aussieht. Würde eine Anwendung sofort ecrecover verwenden, könnte sie die falsche Adresse rekonstruieren und die Signatur falsch zuordnen. Ausserdem müssen ERC-6492-Signaturen auch dann korrekt behandelt werden, wenn die Wallet zwischen Signaturerstellung und Verifikation inzwischen bereitgestellt wurde. Die Spezifikation verlangt deshalb, den speziellen Suffix vor den übrigen Prüfverfahren zu berücksichtigen. Anwendungen, die nur einzelne Fälle implementieren, können legitime Signaturen ablehnen oder problematische Grenzfälle übersehen. Für Entwickler sind systematische Tests mit bereits bereitgestellten und noch nicht bereitgestellten Konten unverzichtbar.
CREATE2 und die vorhersehbare Adresse
CREATE2 ermöglicht unter festgelegten Bedingungen die deterministische Berechnung einer Contract-Adresse. Der Hash des Initialisierungscodes und die Factory-Adresse sind dabei entscheidend. Ändert sich der Code, kann eine andere Adresse entstehen. Das hilft, eine signierte Autorisierung an eine erwartete Wallet-Implementierung zu binden. Trotzdem bedeutet eine vorhersehbare Adresse nicht, dass der spätere Contract sicher ist. Die Factory kann fehlerhaft sein, eine Wallet kann unzureichende Berechtigungsregeln enthalten und die spätere Verwaltung kann riskante Upgrade-Rechte vorsehen. Die Signaturprüfung und die Prüfung der Wallet-Architektur sind deshalb zwei unterschiedliche Aufgaben.
Beispiel einer Wallet vor dem ersten Transfer
Stell Dir vor, Du richtest eine Smart Wallet ein und erhältst sofort eine Ethereum-Adresse. Der Contract wurde noch nicht deployed, weil die erste kostenpflichtige Aktion erst später stattfinden soll. Du möchtest Dich aber schon heute bei einer Anwendung mit dieser Wallet anmelden. Die Anwendung fordert eine Signatur an. Ohne ERC-6492 kann sie die Signatur möglicherweise nicht gegen den noch fehlenden Wallet-Contract prüfen. Mit einem korrekt erzeugten Wrapper kann der Verifizierer die erforderliche Factory-Logik in einer simulierten Ausführung berücksichtigen und danach die eigentliche Contract-Signatur prüfen. Eine erfolgreiche Prüfung bestätigt die implementierte Autorisierung, nicht die Seriosität der Website.
Offchain-Prüfung mit eth_call
Die Spezifikation beschreibt eine Offchain-Validierung, bei der ein Ethereum-RPC-Aufruf die nötigen Schritte simuliert. Dabei kann ein Hilfscontract im Rahmen der Simulation die Wallet bereitstellen und anschliessend die Signaturprüfung ausführen. Ein eth_call ist keine gewöhnliche dauerhaft bestätigte Transaktion und verändert den Blockchain-Zustand nicht dauerhaft. Das heisst aber nicht, dass jeder RPC-Anbieter dieselben Ressourcen, Gasgrenzen oder Fehlerbehandlungen unterstützt. Die konkrete Implementierung muss Reverts, fehlerhafte Factory-Aufrufe und unerwartete Rückgabewerte korrekt behandeln. Anwendungen sollten ein gescheitertes Verfahren nicht stillschweigend als positive Signaturprüfung interpretieren.
Onchain-Prüfung und Seiteneffekte
Wird eine ERC-6492-Signatur innerhalb einer tatsächlichen Transaktion validiert, ist besondere Vorsicht nötig. Das vorübergehende Deployment oder ein Vorbereitungsschritt kann einen CALL erfordern, der grundsätzlich Seiteneffekte auslösen kann. Die Referenzimplementierung berücksichtigt diese Problematik und beschreibt Verfahren, um Seiteneffekte während einer reentrancy-sicheren Prüfung zurückzunehmen. Das ist technisch anspruchsvoller als eine reine statische Signaturprüfung. Ein Entwickler sollte daher nicht unbesehen ein vereinfachtes Beispiel kopieren. Für Anleger bedeutet dies, dass auch Infrastrukturcode ausserhalb des eigentlichen Wallet-Contracts sicherheitsrelevant sein kann.
Reentrancy und unerwartete Aufrufe
Reentrancy bezeichnet Situationen, in denen ein externer Aufruf erneut in eine noch laufende Ausführung eingreift. Wenn ein Verifizierer eine Factory oder einen fremden Contract aufruft, entsteht eine zusätzliche Angriffsfläche. Der ERC-6492-Standard diskutiert dieses Risiko ausdrücklich. Ob ein konkreter Validator sicher ist, hängt von der Implementierung und dem gewählten Ausführungsweg ab. Ein Audit muss daher nicht nur die Signaturprüfung, sondern auch den Umgang mit Factory-Aufrufen, Reverts und Zustandsänderungen betrachten. Ein korrektes Signaturformat allein verhindert keine Reentrancy-Schwachstelle.
Bereits bereitgestellte Wallets
Eine ERC-6492-Signatur kann erstellt worden sein, als die Wallet noch nicht existierte. Wenn sie später geprüft wird, kann der Contract inzwischen bereitgestellt sein. Der Verifizierer darf dann nicht blind auf einen historischen, angenommenen Wallet-Zustand vertrauen. Die Spezifikation berücksichtigt den aktuellen Contract und sieht einen Ablauf vor, der die bestehende Implementierung prüft und gegebenenfalls einen Vorbereitungsschritt versucht. Das ist wichtig, weil sich Eigentümer oder Autorisierungsregeln inzwischen geändert haben können. Eine frühere Signatur darf nicht automatisch alle späteren Änderungen übergehen. Die genaue Gültigkeit muss anhand der aktuellen Wallet-Logik beurteilt werden.
Unterschied zu ERC-1271
ERC-1271 beantwortet die Frage, ob ein bereits aufrufbarer Contract einen Hash und eine Signatur akzeptiert. ERC-6492 erweitert diese Prüfung auf den Fall, dass der Contract noch nicht bereitgestellt oder noch nicht zur Prüfung vorbereitet ist. ERC-6492 ersetzt ERC-1271 nicht; die eigentliche Autorisierung wird weiterhin über die Contract-Logik validiert. Das Zusammenspiel ist besonders für Smart Wallets interessant, deren Deployment aufgeschoben wird. Eine Anwendung, die nur ERC-1271 unterstützt, kann solche Signaturen nicht in allen Fällen korrekt behandeln. Umgekehrt muss ein ERC-6492-Verifizierer die gewöhnliche ERC-1271-Prüfung weiterhin unterstützen.
Unterschied zu ERC-4337
ERC-4337 ist eine Account-Abstraction-Architektur mit UserOperations und ergänzender Infrastruktur. ERC-6492 behandelt dagegen die Signaturprüfung vor einem möglichen Contract-Deployment. Beide Standards können in einem Smart-Wallet-Ökosystem zusammenkommen, lösen aber unterschiedliche Aufgaben. ERC-6492 stellt weder automatisch einen Bundler bereit noch garantiert es gesponserte Transaktionsgebühren. Auch soziale Wiederherstellung, Passkeys und Mehrfachfreigaben sind keine durch ERC-6492 selbst zugesicherten Funktionen. Prüfe die konkrete Wallet, statt aus einem Standardnamen auf sämtliche Eigenschaften zu schliessen.
Unterschied zu EIP-712
EIP-712 beschreibt das strukturierte Signieren typisierter Daten. ERC-6492 beschreibt, wie eine Signatur von einem noch nicht bereitgestellten Contract-Konto überprüft werden kann. Die Standards können kombiniert werden, indem ein korrekt berechneter Hash einer EIP-712-Nachricht innerhalb des ERC-6492-Prüfverfahrens validiert wird. Eine gut strukturierte Signaturanzeige hilft beim Verständnis, verhindert aber keine Phishing-Angriffe. Domain, Chain-ID, Vertragsadresse, Nonce und Gültigkeitsdauer müssen passend eingebunden sein. Eine formal gültige Signatur kann andernfalls in einem unerwarteten Kontext missbraucht werden.
Replay-Schutz über mehrere Netzwerke
Eine Signatur kann gefährlich werden, wenn sie in einem anderen Netzwerk oder zu einem anderen Zeitpunkt erneut akzeptiert wird. ERC-6492 weist auf zusätzliche Risiken bei deterministisch bereitgestellten Wallets hin. Unter bestimmten Bedingungen kann eine Signatur auf einem zweiten Netzwerk wieder gültig werden, obwohl die Berechtigungen auf dem ersten Netzwerk inzwischen geändert wurden. Gute Anwendungen verwenden daher eine eindeutige Bindung an Netzwerk und Anwendung, Nonces und Ablaufzeiten. Diese Schutzmechanismen sind nicht durch den Erkennungssuffix allein gewährleistet. Nutzer sollten besonders vorsichtig sein, wenn eine Wallet Signaturen ohne verständliche Netzwerkangabe anfordert.
Factory-Vertrauen und Deployment-Rechte
Der Wrapper enthält Informationen darüber, welche Factory oder welcher Vorbereitungsschritt zur Prüfung verwendet werden soll. Ein Verifizierer darf solche Angaben nicht unkritisch als vertrauenswürdig betrachten. Die Factory kann fehlerhaft sein, ungewöhnliche externe Aufrufe auslösen oder eine andere Implementierung bereitstellen als erwartet. Bei deterministischen Adressen spielt der tatsächliche Initialisierungscode eine wichtige Rolle. Ein Entwickler muss deshalb den Zusammenhang zwischen Adresse, Factory, Code und Berechtigungen prüfen. Für Nutzer ist die Vertrauenswürdigkeit der Wallet-Infrastruktur mindestens so wichtig wie das Vorhandensein einer erfolgreichen Signaturbestätigung.
Was eine erfolgreiche Prüfung nicht beweist
Eine erfolgreiche ERC-6492-Prüfung zeigt, dass die betreffende Signatur unter den geprüften Bedingungen akzeptiert wird. Sie bestätigt weder den wirtschaftlichen Wert eines Tokens noch die Sicherheit eines Handelsplatzes. Sie garantiert auch nicht, dass die Wallet später fehlerfrei deployed wird, dass keine Admin-Schlüssel kompromittiert sind oder dass der Nutzer die beabsichtigte Handlung vollständig verstanden hat. Bei DeFi-Anwendungen kommen Smart-Contract-Risiken, Liquiditätsrisiken, Gegenparteirisiken und starke Kursschwankungen hinzu. Eine Signatur ist ein technischer Autorisierungsnachweis, keine Anlageempfehlung.
Gebühren und Kosten richtig einordnen
Eine Offchain-Simulation mittels eth_call ist nicht gleichbedeutend mit einer dauerhaft ausgeführten Ethereum-Transaktion. Die spätere tatsächliche Bereitstellung einer Wallet kann jedoch Gas kosten. Die Höhe hängt vom Contract-Code, dem Netzwerk, der Auslastung und gegebenenfalls weiteren Dienstleistern ab. ERC-6492 schreibt keinen festen Gaspreis und keinen kostenlosen Deployment-Service vor. Wer eine Wallet nutzt, sollte zwischen Signaturprüfung, Einrichtung und tatsächlicher Vermögensübertragung unterscheiden. Gebührenangaben aus Werbematerialien gelten häufig nur unter bestimmten Bedingungen. Ohne konkrete Messung sind pauschale Kostenversprechen unzuverlässig.
Rechenbeispiel für eine spätere Bereitstellung
Nehmen wir als rein hypothetisches Beispiel an, ein Deployment benötige 250'000 Gas und der effektive Gaspreis betrage 8 Gwei. Die Multiplikation ergibt 2'000'000 Gwei, also 0,002 ETH. Bei einem nur für dieses Beispiel angenommenen Kurs von 2'000 CHF pro ETH entspräche dies 4 CHF. Diese Zahlen sind keine aktuellen Netzwerkgebühren, keine Schätzung für ein bestimmtes Wallet-Produkt und kein garantierter Preis. Sie verdeutlichen lediglich die Formel: Gasverbrauch mal Gaspreis, anschliessend umgerechnet zum angenommenen ETH-Kurs. Zusätzliche Operationen oder Gebühren können den Gesamtbetrag verändern.
Sicherheitscheck für Nutzer
Prüfe vor jeder Signatur die Domain der Anwendung und die angezeigte Wallet-Adresse. Achte auf Netzwerk, Frist, Nonce und den tatsächlichen Zweck der Anfrage. Wenn ein angeblicher Login weitreichende Tokenfreigaben verlangt, solltest Du die Aktion hinterfragen. Verwende möglichst Wallets mit transparenter Signaturanzeige und dokumentierter Sicherheitsarchitektur. Trenne grössere Bestände von experimentellen DeFi-Anwendungen. Bewahre Wiederherstellungsdaten offline und gib sie niemals auf einer Website ein. Die Nutzung von ERC-6492 schützt nicht vor manipulierten Benutzeroberflächen, Phishing oder kompromittierten Geräten.
Werbung / Affiliate-Link: Relai ist eine Bitcoin-App. Bei Nutzung unseres Links oder Codes können wir eine Provision erhalten. Relai verkauft Bitcoin, nicht Ethereum oder andere Altcoins. Code: AUSWANDERNSCHWEIZ.
Sicherheitscheck für Entwickler
Eine robuste Implementierung muss die Reihenfolge der Prüfverfahren beachten, den Erkennungssuffix korrekt erkennen und Wrapper-Daten sorgfältig dekodieren. Fehlerhafte Factory-Aufrufe, Reverts, fehlender Contract-Code und bereits bereitgestellte Wallets müssen ausdrücklich getestet werden. Prüfe auch Cross-Chain-Replay, wechselnde Eigentümer, Gasgrenzen und mögliche Reentrancy. Verlasse Dich nicht auf die blosse Existenz einer Library, sondern kontrolliere Version, Auditstand und die tatsächlich genutzten Funktionen. Ein erfolgreicher Unit-Test ersetzt keine Prüfung der wirtschaftlich relevanten Berechtigungen.
Bedeutung für Schweizer Anleger
ERC-6492 ist ein technischer Ethereum-Standard und begründet keine besondere steuerliche oder aufsichtsrechtliche Behandlung. Ob Token und Erträge in der Schweiz steuerlich relevant sind, hängt von den tatsächlichen Beständen und Vorgängen ab. Eine Wallet mit ERC-6492-Unterstützung ist nicht automatisch von der FINMA bewilligt oder beaufsichtigt. Für Deine Dokumentation solltest Du Transaktionen, Einstandswerte und Bestände nachvollziehbar erfassen. Bei komplexen DeFi-Vorgängen können zusätzliche Nachweise erforderlich sein. Die jeweils geltenden Informationen der zuständigen Behörden sind massgeblich.
FAQ: Ist die Wallet schon auf der Blockchain?
Nicht zwingend. Bei einem counterfactual Account kann die Adresse vor dem tatsächlichen Deployment bekannt sein. ERC-6492 erlaubt unter geeigneten Bedingungen die Signaturprüfung für diesen Zustand. Ob die Wallet später erfolgreich bereitgestellt wird, hängt von ihrer konkreten Infrastruktur ab.
FAQ: Kann ich dadurch ohne Gebühren handeln?
Nein. ERC-6492 standardisiert die Signaturprüfung und verspricht keine kostenlosen Transaktionen. Die spätere Bereitstellung oder Ausführung kann Netzwerkgebühren verursachen. Wer diese bezahlt, hängt vom Wallet-Produkt und möglichen Sponsoringmechanismen ab.
FAQ: Ist ERC-6492 ein eigener Coin?
Nein. ERC-6492 ist ein technischer Standard für die Validierung bestimmter Signaturen im Ethereum-Ökosystem. Es gibt dadurch keinen automatisch zugehörigen handelbaren Token. Vorsicht ist geboten, wenn jemand unter diesem Namen garantierte Gewinne oder einen offiziellen Tokenverkauf bewirbt.
FAQ: Ist ERC-6492 sicherer als ERC-1271?
Die Standards sind nicht als direkte Konkurrenz gedacht. ERC-6492 ergänzt ERC-1271 für Fälle vor dem Deployment oder vor der Bereitschaft einer Wallet. Die Sicherheit hängt von der korrekten Implementierung beider Mechanismen und von den Berechtigungsregeln der Wallet ab.
Fazit
ERC-6492 löst ein konkretes Problem programmierbarer Ethereum-Wallets: Eine Signatur kann überprüft werden, obwohl der zugehörige Smart Contract noch nicht auf der Blockchain bereitgestellt wurde. Das erleichtert bestimmte Login- und Interaktionsabläufe, erhöht aber auch die Anforderungen an die technische Verifikation. Besonders wichtig sind die richtige Prüfreihenfolge, vertrauenswürdige Factory-Aufrufe, Replay-Schutz und die aktuelle Wallet-Governance. Der Standard ist kein Schutzschild gegen Betrug, keine Garantie für sichere Smart Contracts und keine Anlageempfehlung. Kryptowährungen können stark schwanken und bis zum Totalverlust führen.
Kommentare