ERC-1271 erklärt: Smart-Contract-Signaturen, Wallets und Sicherheitsrisiken
Eine Ethereum-Adresse kann einer Person mit privatem Schlüssel gehören oder einem Smart Contract. Für die zweite Gruppe reicht die übliche Prüfung einer ECDSA-Signatur nicht aus. ERC-1271 schafft eine standardisierte Schnittstelle, mit der Anwendungen einen Smart Contract selbst fragen können, ob eine bestimmte Signatur für ihn gültig ist. Das klingt nach einem technischen Detail, betrifft aber Multisignatur-Wallets, DAOs, Smart Accounts, Handelsaufträge und sichere Anmeldeverfahren.
Dieser Leitfaden erklärt die Funktionsweise, die Grenzen der Norm und typische Sicherheitsfehler. Du lernst, warum ein gültiges Prüfergebnis nicht automatisch eine sichere Zahlung bedeutet, wie sich ERC-1271 von ERC-2612 und EIP-712 unterscheidet und worauf Du bei der Nutzung einer Contract Wallet achten solltest. Alle Zahlenbeispiele sind ausdrücklich illustrativ; Gebühren, Preise und Tokenrenditen sind keine Prognosen.
Was ist ERC-1271?
ERC-1271, auch als EIP-1271 bezeichnet, ist ein Ethereum-Standard zur Signaturvalidierung durch Smart Contracts. Die zentrale Funktion heisst isValidSignature(bytes32 hash, bytes signature). Eine aufrufende Anwendung übergibt einen 32-Byte-Hash und die zu prüfenden Signaturdaten. Akzeptiert der Contract diese nach seinen eigenen Regeln, antwortet er mit dem vier Byte langen Erkennungswert 0x1626ba7e. Ein anderer Rückgabewert oder ein fehlgeschlagener Aufruf bedeutet, dass die Anwendung die Signatur nicht als gültig behandeln darf.
Der Standard definiert also die Frage und das Format der Antwort, nicht die internen Entscheidungsregeln. Ein Wallet-Contract kann eine einzelne Eigentümerunterschrift verlangen, zwei von drei autorisierten Signaturen prüfen oder eine zuvor genehmigte Nachricht erkennen. Diese Flexibilität ist der Kernnutzen, zugleich aber eine Sicherheitsverantwortung der jeweiligen Implementierung.
Warum normale Ethereum-Signaturen nicht ausreichen
Bei einem klassischen Externally Owned Account, kurz EOA, erzeugt ein privater Schlüssel eine kryptografische Signatur. Eine Anwendung kann daraus unter den richtigen Voraussetzungen den Unterzeichner ableiten und mit einer erwarteten Adresse vergleichen. Bei einem Smart Contract existiert hingegen nicht automatisch ein zugehöriger privater Schlüssel. Der Contract ist ausführbarer Code mit eigenem Zustand, nicht ein gewöhnlicher Signaturschlüssel.
Eine Multisignatur-Wallet kann mehrere Menschen und Regeln bündeln. Wenn eine Anwendung ausschliesslich eine klassische EOA-Signatur erwartet, könnte sie einen solchen Account ausschliessen, obwohl dieser nach seinen internen Regeln korrekt autorisiert wurde. ERC-1271 erlaubt der Anwendung, die Prüfung an den Contract zu delegieren, der die Autorisierung tatsächlich verwaltet.
So funktioniert isValidSignature Schritt für Schritt
Zuerst legt die Anwendung fest, welche konkrete Handlung autorisiert werden soll, beispielsweise eine Order mit Asset, Menge, Empfänger, Frist und Netzwerk. Daraus berechnet sie nach einem definierten Schema einen Hash. Anschliessend erhält sie Signaturdaten, die der Contract verstehen kann. Die Anwendung ruft isValidSignature mit Hash und Signatur auf. Der Contract überprüft seine Regeln und gibt im Erfolgsfall 0x1626ba7e zurück.
Wichtig ist, dass die aufrufende Anwendung das Ergebnis exakt mit diesem Erkennungswert vergleicht. Ein einfaches «der Aufruf hat nicht geworfen» ist kein Beweis für eine gültige Signatur. Die Norm verlangt ausserdem, dass die Validierungsfunktion keinen Zustand verändert. Externe Aufrufe sind erlaubt, sodass die tatsächliche Prüfung dennoch von weiteren Contracts oder Zuständen abhängen kann.
Praxisbeispiel: Zwei von drei Personen genehmigen eine Order
Angenommen, eine gemeinsame Wallet verwaltet Vermögenswerte einer Organisation. Drei Mitglieder sind berechtigt, eine Order freizugeben; die Wallet-Regel verlangt mindestens zwei gültige Zustimmungen. Eine Anwendung erstellt eine Order über 1,5 ETH und berechnet ihren eindeutigen Hash. Zwei Mitglieder genehmigen exakt diese Nachricht. Die Wallet prüft die vorgelegten Signaturen gegen die aktuelle Eigentümerliste und den Schwellenwert. Nur wenn die Bedingungen erfüllt sind, bestätigt sie die Signaturvalidität.
Die Zahl 1,5 ETH dient ausschliesslich als Rechenbeispiel und sagt nichts über den Marktwert aus. Würde die Wallet-Regel auf drei notwendige Zustimmungen geändert, könnte dieselbe Kombination von zwei Unterschriften bei einer erneuten Prüfung ungültig werden. Ob und wann eine frühere Genehmigung weiterhin gilt, hängt von Contract-Logik, Zustand und Anwendung ab.
Werbung: Bitcoin mit Relai kaufen
Werbung / Affiliate-Link: Relai ist eine Bitcoin-App. Bei Nutzung unseres Links oder Codes können wir eine Provision erhalten. Relai verkauft nicht die hier besprochenen Smart-Contract-Token. Code: AUSWANDERNSCHWEIZ.
ERC-1271 und EIP-712: Zwei verschiedene Aufgaben
EIP-712 beschreibt, wie typisierte strukturierte Daten einheitlich gehasht und signiert werden. Das kann einer Wallet helfen, verständliche Felder wie Betrag, Zieladresse und Gültigkeitsdauer anzuzeigen. ERC-1271 beschreibt dagegen, wie ein Smart Contract eine Signatur für einen gegebenen Hash beurteilt. Beide Standards können zusammenwirken: Die Anwendung bildet mit EIP-712 einen nachvollziehbaren Hash und fragt danach die Contract Wallet mittels ERC-1271 nach ihrer Autorisierung.
EIP-712 allein enthält keine vollständige Replay-Sicherung. Auch ERC-1271 fügt nicht automatisch eine Nonce, eine Frist oder eine Beschränkung auf eine bestimmte Anwendung hinzu. Solche Regeln müssen in der jeweiligen Nachricht, dem ausführenden Contract und gegebenenfalls in der Wallet-Logik sinnvoll implementiert und überprüft werden.
Was bedeutet Domain Separation?
Eine Signatur sollte möglichst klar an ihren Einsatzzweck gebunden sein. Ein EIP-712-Domain-Separator kann unter anderem den Namen und die Version einer Anwendung, die Chain-ID und die Adresse des verifizierenden Contracts berücksichtigen. So lassen sich unbeabsichtigte Wiederverwendungen in anderen Kontexten erschweren. Eine Anwendung muss aber selbst korrekt festlegen, welche Daten sie einbezieht und wie sie Signaturen später verwendet.
Beispielsweise darf die Zustimmung zu einer Order für Contract A nicht stillschweigend eine Order für Contract B freigeben. Fehlt die eindeutige Bindung, können Angreifer unter Umständen gültige Signaturdaten in einem anderen Zusammenhang wiederverwenden. Deshalb ist es gefährlich, nur den Rückgabewert von isValidSignature zu prüfen und den Aufbau des ursprünglich signierten Hashes zu ignorieren.
ERC-1271 gegenüber ERC-2612 Permit
ERC-2612 erweitert bestimmte ERC-20-Token um eine signaturbasierte Freigabe von Token-Allowances. Die Permit-Nachricht enthält unter anderem Eigentümer, Spender, Wert, Nonce und Deadline. ERC-1271 ist demgegenüber eine allgemeine Schnittstelle für Signaturen von Contract Accounts. Es ist kein eigener Token-Freigabemechanismus und erlaubt nicht automatisch, Token zu übertragen.
Ob ein konkreter Permit-Ablauf mit einer Contract Wallet funktioniert, hängt von der Implementierung des Tokens und der beteiligten Anwendung ab. Du solltest nicht davon ausgehen, dass jede ERC-2612-Funktion automatisch ERC-1271-Signaturen unterstützt. Prüfe die dokumentierte Kompatibilität und die tatsächlichen Contract-Funktionen statt allein auf ein Standardsiegel zu vertrauen.
Multisig-Wallets, DAOs und Smart Accounts
Multisignatur-Wallets sind ein naheliegender Einsatzfall. Ein Contract kann mehrere Schlüssel, eine Schwelle und zusätzliche Berechtigungen verwalten. Eine DAO kann signierte Anweisungen anhand ihrer Governance-Regeln bewerten. Smart Accounts können unter Umständen unterschiedliche Signaturverfahren oder zeitlich begrenzte Berechtigungen verwenden. ERC-1271 vereinheitlicht die Schnittstelle zur Aussenwelt, ohne diese Konzepte selbst vorzuschreiben.
Das ist auch für dezentrale Handelsplattformen und signierte Offchain-Orders relevant. Eine Order kann ausserhalb der Blockchain erstellt werden, während ihre Ausführung später durch einen Smart Contract erfolgt. Der ausführende Contract muss jedoch erneut prüfen, ob die Autorisierung zum Zeitpunkt der Ausführung noch gültig ist und ob alle weiteren Bedingungen der Order erfüllt sind.
Wie teuer ist die Signaturprüfung?
Die reine Prüfung kann ausserhalb einer Transaktion als lesender Contract-Aufruf erfolgen. Das bedeutet nicht, dass jede Verwendung kostenlos ist. Wird die Validierung innerhalb einer Onchain-Transaktion ausgeführt, verbraucht sie Gas. Die Kosten hängen von der Anzahl und Art der kryptografischen Prüfungen, externen Aufrufen, Speicherzugriffen und dem aktuellen Gaspreis ab.
Ein rein illustratives Beispiel: Eine Transaktion verbraucht insgesamt 120'000 Gas bei 15 Gwei effektivem Gaspreis. Das ergibt 1'800'000 Gwei oder 0,0018 ETH. Diese Rechnung ist kein Benchmark für ERC-1271, denn sie umfasst sämtliche Operationen der angenommenen Transaktion. Bei einem anderen Gasverbrauch oder Gaspreis verändert sich der Betrag entsprechend.
Signaturgültigkeit kann sich mit der Zeit verändern
Ein wesentlicher Unterschied zu einer isolierten EOA-Signatur ist die mögliche Zustandsabhängigkeit. Ein Contract kann Eigentümer wechseln, einen Signaturschlüssel sperren, eine Genehmigung widerrufen oder eine Frist prüfen. Dieselbe Signatur kann daher zu unterschiedlichen Zeitpunkten verschieden beurteilt werden. Eine frühere positive Antwort ist nicht zwangsläufig ein dauerhafter Nachweis.
Für Anwendungen folgt daraus eine praktische Regel: Die Validierung muss an dem Punkt erfolgen, an dem die Autorisierung tatsächlich gebraucht wird. Ein früheres Prüfergebnis aus einem Cache kann veraltet sein. Besonders bei Offchain-Orders, langfristigen Genehmigungen und zeitkritischen Ausführungen ist eine klare Regelung für Zustandsänderungen und Widerrufe nötig.
Replay-Angriffe und doppelte Ausführung verhindern
Ein Replay-Angriff entsteht, wenn eine gültige Autorisierung erneut eingesetzt wird, obwohl sie nur einmal oder nur in einem bestimmten Kontext gelten sollte. Die Signaturvalidierung allein verhindert das nicht. Ein ausführender Contract kann beispielsweise eine eindeutige Nonce speichern, eine Order als verbraucht markieren, eine Deadline erzwingen und die signierte Domain eindeutig festlegen.
Angenommen, eine Order erlaubt eine Auszahlung von 0,2 ETH. Wird dieselbe Signatur dreimal akzeptiert, könnten bei fehlerhafter Ausführungslogik insgesamt 0,6 ETH abfliessen. Die Rechnung 3 × 0,2 = 0,6 ETH illustriert das Risiko. Eine korrekte Einmalverwendung oder eine passende Begrenzung muss die zweite und dritte Ausführung verhindern. ERC-1271 allein liefert diese Schutzmassnahme nicht.
Phishing: Eine gültige Signatur kann trotzdem gefährlich sein
Eine technisch gültige Signatur beweist nur, dass die implementierten Autorisierungsregeln erfüllt sind. Sie beweist nicht, dass die Person die wirtschaftlichen Folgen verstanden hat. Betrüger können täuschende Webseiten einsetzen, die eine harmlos wirkende Nachricht präsentieren, tatsächlich aber eine weitreichende Order, Freigabe oder andere Handlung autorisieren lassen.
Prüfe deshalb Domain, Netzwerk, Contract-Adresse, Empfänger, Asset, Betrag, Nonce, Frist und alle verfügbaren Felder. Unverständliche hexadezimale Daten oder unbeschränkte Berechtigungen sind Warnzeichen. Auch bei Multisig-Systemen müssen die beteiligten Personen unabhängig kontrollieren, was sie genehmigen. Zwei Unterschriften auf derselben betrügerischen Nachricht machen die Handlung nicht sicher.
Technische Implementierungsrisiken
Eine fehlerhafte Contract-Implementierung kann Signaturen unberechtigt akzeptieren oder legitime Signaturen zurückweisen. Kritisch sind unter anderem falsche Hash-Berechnung, fehlende Domain-Bindung, unzureichende Rollenprüfung, veraltete Eigentümerlisten, unerwartete externe Contract-Aufrufe und fehlerhafte Verarbeitung unterschiedlicher Signaturformate.
Auch Upgrades verdienen Aufmerksamkeit. Bei einer veränderbaren Wallet-Implementierung kann sich die Prüfungslogik nach einem Upgrade ändern. Nutzer sollten deshalb nicht nur fragen, ob ein Contract ERC-1271 unterstützt, sondern wer den Contract verändern darf, welche Sicherheitsprüfungen existieren und welche Governance-Regeln Änderungen kontrollieren.
Werbung: Bitcoin mit Relai kaufen
Werbung / Affiliate-Link: Relai ist eine Bitcoin-App. Bei Nutzung unseres Links oder Codes können wir eine Provision erhalten. Der Code AUSWANDERNSCHWEIZ ist zum Kopieren angegeben; ein Bonus oder Rabatt wird nicht zugesichert.
ERC-1271 in einer Anwendung prüfen: Praktische Checkliste
Wenn Du eine Anwendung beurteilst, prüfe zuerst, ob die angebliche Wallet-Adresse tatsächlich ein Contract ist und ob der Contract die passende Schnittstelle implementiert. Verifiziere die Adresse über vertrauenswürdige Quellen und einen Blockchain-Explorer. Untersuche anschliessend, welche Daten signiert werden und wie der Hash entsteht. Bei EIP-712 sollten Domain, Chain-ID, Contract-Adresse und alle relevanten Felder nachvollziehbar sein.
Danach ist zu prüfen, ob die Anwendung die Rückgabe von isValidSignature exakt gegen 0x1626ba7e vergleicht. Eine sichere Anwendung muss darüber hinaus die wirtschaftliche Handlung begrenzen, Replay-Schutz anwenden und Signaturen bei Bedarf zum Ausführungszeitpunkt erneut validieren. Für erhebliche Vermögenswerte sind unabhängige Codeprüfungen und ein begrenzter Test mit kleinen Beträgen sinnvoll.
Welche Rolle spielt die Dezentralisierung?
Ein ERC-1271-kompatibler Contract ist nicht automatisch dezentral. Ein einziger Administrator kann die Signaturregeln kontrollieren; alternativ können mehrere unabhängige Eigentümer mit einer Schwelle zustimmen. Auch Upgrades, Guardian-Systeme, Pausenfunktionen und externe Validierungsdienste beeinflussen das Vertrauen. Der Standard macht hierzu keine Mindestvorgaben.
Bei einem Projektvergleich solltest Du deshalb die tatsächliche Kontrolle über Schlüssel, Upgrades und Notfallmechanismen untersuchen. Eine Wallet mit drei Unterzeichnern ist nicht wirklich unabhängig, wenn alle Schlüssel bei derselben Person oder demselben Dienstleister liegen. Technische Multisig-Strukturen ersetzen keine organisatorische Trennung.
Risiken für Anleger und Organisationen
Smart-Contract-Signaturen betreffen die Verwaltung digitaler Vermögenswerte, nicht deren Wertentwicklung. Selbst eine fehlerfrei implementierte Wallet schützt nicht vor Kurseinbrüchen, Totalverlust, fehlerhaften Investments, unsicheren Bridges, kompromittierten Gegenparteien oder rechtlichen Unsicherheiten. Auch das Risiko, dass eine berechtigte Mehrheit eine wirtschaftlich schlechte Entscheidung trifft, bleibt bestehen.
Organisationen sollten Freigaberegeln dokumentieren, Verantwortlichkeiten trennen, Berechtigungen regelmässig überprüfen und einen nachvollziehbaren Prozess für Schlüsselverlust und Personalwechsel einrichten. Bei komplexen Konstruktionen kann fachliche Beratung zu IT-Sicherheit, Recht, Steuern und Governance notwendig sein.
FAQ: Häufige Fragen zu ERC-1271
Kann jeder Smart Contract ERC-1271 nutzen? Grundsätzlich kann ein Contract die definierte Schnittstelle implementieren. Ob sie sicher und korrekt arbeitet, hängt von der jeweiligen Implementierung ab.
Ist ERC-1271 eine Kryptowährung? Nein. Es ist ein technischer Schnittstellenstandard und besitzt keinen eigenen ERC-1271-Coin.
Brauche ich für jede Prüfung eine Blockchain-Transaktion? Nein. Lesende Prüfungen können ohne eigene Onchain-Transaktion erfolgen. Wird die Prüfung Teil einer Transaktion, entstehen Gas-Kosten für die Ausführung.
Sind ERC-1271-Signaturen immer Multisig? Nein. Ein Contract kann eine einzelne Signatur, mehrere Signaturen oder andere autorisierte Prüfverfahren akzeptieren.
Kann eine einmal gültige Signatur später ungültig sein? Ja. Wenn die Contract-Regeln zustands- oder zeitabhängig sind, kann sich das Ergebnis ändern.
Verhindert ERC-1271 Phishing und Replay-Angriffe? Nein. Dafür sind verständliche Signaturinhalte, sichere Wallet-Bedienung, Nonces, Fristen, Domain-Bindung und korrekte Ausführungslogik notwendig.
Fazit: Was Du aus ERC-1271 mitnehmen solltest
ERC-1271 ist ein wichtiges Bindeglied zwischen Smart-Contract-Wallets und Anwendungen, die signierte Nachrichten prüfen müssen. Sein Nutzen liegt in einer einheitlichen Schnittstelle: Ein Contract kann selbst entscheiden, welche Signatur nach seinen Regeln gültig ist. Die Norm schreibt jedoch weder Multisig noch Replay-Schutz, Tokenfreigaben oder sichere Geschäftslogik vor.
Wer Contract Wallets nutzt oder entwickelt, sollte deshalb zwei Ebenen getrennt prüfen: Ist die Signatur nach den Wallet-Regeln gültig, und ist die dadurch autorisierte Handlung im konkreten Kontext tatsächlich gewollt und sicher? Erst die Kombination aus korrekter Implementierung, eindeutigen Nachrichtendaten und umsichtigem Umgang mit Berechtigungen reduziert die Risiken.
Weiterführende Artikel auf Auswandern Schweiz
Quellen und weiterführende Literatur
Hinweis: Dieser Artikel dient der allgemeinen Information und ist keine individuelle Anlage-, Steuer- oder Rechtsberatung. Die technischen Standards beschreiben Schnittstellen; konkrete Projekte können davon abweichende Sicherheits- und Betriebsrisiken aufweisen.
Kommentare