Zum Inhalt springen
Financial Context Wiki

Ist eine Signatur zur Governance-Delegation sicher?

Erfahren Sie, wozu eine Signatur zur Governance-Delegation berechtigt, wie EIP-712-Domänentrennung, Nonces und Ablaufzeiten das Wiederholungsrisiko verringern und was vor dem Signieren zu prüfen ist.

Aktualisiert

Nur zu Bildungszwecken; keine Anlageberatung. Transaktionen und Signaturen für digitale Vermögenswerte können zu unwiederbringlichen Verlusten führen.

Direkte Antwort

Eine Signatur zur Governance-Delegation ist nur dann sicher, wenn die dekodierte Nachricht genau der beabsichtigten Delegation entspricht und der zuständige Vertrag einen ausreichenden Schutz vor Wiederholungsangriffen durchsetzt. Bei einem typischen Voting-Token-Modell ändert die Delegation, wer die Stimmkraft des Signierenden ausüben darf; sie überträgt weder das Token-Guthaben noch erteilt sie eine Genehmigung zum Ausgeben von Tokens. Maßgeblich dafür, was die Signatur tatsächlich bewirkt, ist jedoch der bereitgestellte Vertrag.

Eine Off-Chain-Signatur kann von einem Relayer eingereicht werden. Der Signierende zahlt daher möglicherweise kein Gas und autorisiert dennoch eine On-Chain-Zustandsänderung. Behandeln Sie die Signatur als ausführbare Anweisung, nicht als Anmeldung oder harmlose Aufforderung, ein Wallet zu verbinden.

Funktionsweise

Ein typischer delegateBySig-Ablauf besteht aus vier Schritten:

  1. Die Anwendung erstellt typisierte EIP-712-Daten mit einer Delegiertenadresse, einer Nonce und einer Ablaufzeit.
  2. Das Wallet signiert einen Digest, der an die typisierte Nachricht und eine EIP-712-Domäne gebunden ist.
  3. Jedes Konto kann die Signatur an den Token- oder Governance-Vertrag weiterleiten.
  4. Der Vertrag ermittelt oder validiert den Signierenden, prüft Nonce und Ablaufzeit und speichert den neuen Delegierten.

Die EIP-712-Domäne kann name, version, chainId und verifyingContract enthalten. Diese Felder trennen ansonsten identische Nachrichten nach Anwendung, Version, Netzwerk und Vertrag. EIP-712 selbst bietet ausdrücklich keinen Schutz vor Wiederholungsangriffen; der Vertrag muss eine Nonce verbrauchen oder jede Autorisierung auf andere Weise einmalig machen. Eine Ablaufzeit begrenzt das Zeitfenster nur, wenn der Vertrag sie tatsächlich prüft.

Prüfen Sie vor dem Signieren alle folgenden Angaben anhand einer offiziellen Governance-Oberfläche, der Dokumentation oder unabhängig verifizierter Vertragsdaten:

  • primaryType und die Feldnamen beschreiben eine Delegation, nicht eine Erlaubnis, Token-Übertragung, Order oder Autorisierung zur Kontoverwaltung.
  • verifyingContract ist der beabsichtigte Token- oder Governance-Vertrag auf der aktiven chainId.
  • delegatee ist die von Ihnen gewählte Vertreteradresse; prüfen Sie die vollständige Adresse und nicht nur einen Anzeigenamen.
  • nonce entspricht der aktuellen Vertrags-Nonce des Signierenden, und expiry ist für den vorgesehenen Ablauf kurz genug.
  • Das Wallet zeigt die vollständigen typisierten Daten an. Lehnen Sie Aufforderungen zum Blind Signing oder rohe Hashes ab, deren Bedeutung Sie nicht unabhängig nachvollziehen können.

Implementierungen unterscheiden sich. Der COMP-Vertrag von Compound hasht beispielsweise Delegiertenadresse, Nonce und Ablaufzeit, verlangt die Übereinstimmung der Nonce mit der gespeicherten Nonce des Signierenden, erhöht diese Nonce und lehnt eine abgelaufene Signatur ab. Auch die Votes-Schnittstelle von OpenZeppelin stellt delegateBySig, Nonce-Verarbeitung und Ablaufprüfungen bereit. Gehen Sie nicht davon aus, dass eine ähnlich benannte Funktion in einem anderen Vertrag denselben Schutz bietet.

Beispiel

Mira möchte 10.000 Stimmen an die Adresse 0xAB...1234 delegieren. Ihr Wallet zeigt primaryType: Delegation, den verifizierten Voting-Token-Vertrag, die aktive Chain-ID, delegatee: 0xAB...1234, die aktuelle Nonce und eine Ablaufzeit in 20 Minuten an. Nachdem sie die Adresse über eine zweite vertrauenswürdige Quelle geprüft hat, signiert sie. Ein Relayer reicht die Nachricht ein, und der Vertrag gibt das Delegationsereignis aus. Ihr Token-Guthaben verbleibt im Wallet, während der Vertreter nach den Regeln des Protokolls die zugehörige Stimmkraft erhält.

Ändern wir nun ein Detail: Die Seite fordert primaryType: Permit an und nennt einen Token-Spender, oder verifyingContract ist ein nicht zugehöriger Vertrag. Das ist nicht dieselbe Delegationsanweisung. Sie könnte stattdessen das Ausgeben von Tokens autorisieren, auch wenn die Schaltfläche auf der Seite „Delegieren“ heißt und der Signierende kein Gas zahlt. Mira sollte sie ablehnen.

Risiken und Schutzmaßnahmen

  • Falscher Delegierter: Address Poisoning, private Nachrichten und kopierte Anzeigenamen können delegatee durch eine vom Angreifer kontrollierte Adresse ersetzen. Prüfen Sie die vollständige Adresse anhand eines offiziellen Vorschlags oder Delegiertenprofils.
  • Falsche Aktion: Eine bösartige Oberfläche kann einen anderen EIP-712-Typ anfordern, etwa eine Erlaubnis. Lesen Sie primaryType, jedes Feld und den verifizierenden Vertrag; die Beschriftung der Schaltfläche bietet keinerlei Sicherheit.
  • Wiederholung: Schwache oder fehlende Nonce-Prüfungen können die Wiederverwendung einer Signatur ermöglichen. Eine Domäne ohne Bindung an die vorgesehene Chain oder den vorgesehenen Vertrag kann außerdem eine Nutzung im falschen Kontext zulassen. Prüfen Sie den tatsächlichen Validierungscode, denn EIP-712 allein schützt nicht vor Wiederholungsangriffen.
  • Langlebige Signatur: Eine ungenutzte signierte Nachricht kann ausführbar bleiben, bis sie abläuft oder ihre Nonce ungültig wird. Wählen Sie eine kurze Ablaufzeit, veröffentlichen Sie die Signatur nicht und nutzen Sie bei Bedarf nur das dokumentierte Invalidierungsverfahren des Protokolls.
  • Irreführende Wallet-Anzeige: Gekürzte Felder, eine unbekannte Domäne oder Blind Signing verhindern eine fundierte Zustimmung. Brechen Sie ab und prüfen Sie die Anfrage nach typisierten Daten mit einem Wallet oder Decoder, der die vollständige Nachricht anzeigt.
  • Unterschiede bei Vertragskonten: Smart-Contract-Wallets können Signaturen über ERC-1271 validieren, wobei die Gültigkeit vom Wallet-Zustand und von dessen Autorisierungsrichtlinie abhängen kann. Bestätigen Sie die Unterstützung durch Wallet und Governance-Vertrag, statt eine EOA-typische Wiederherstellung anzunehmen.
  • Folgen für die Governance: Eine Delegation kann Stimmkraft konzentrieren oder einem nicht vertrauenswürdigen Delegierten ermöglichen, gegen Ihre Interessen zu stimmen. Prüfen Sie Identität, Abstimmungshistorie und Interessenkonflikte des Delegierten sowie das Verfahren des Protokolls zur Neudelegation.

Überprüfen Sie die Transaktion nach der Einreichung auf der richtigen Chain: Kontrollieren Sie den Zielvertrag, die dekodierte Funktion, den wiederhergestellten oder im Ereignis gemeldeten Signierenden, den neuen Delegierten und die Nonce. Eine erfolgreiche Relayer-Transaktion beweist lediglich, dass der Vertrag den Aufruf akzeptiert hat; sie beweist nicht, dass die signierte Absicht sicher war.

Falls Sie signiert, aber noch keine Einreichung gesehen haben, geben Sie die Signatur nicht weiter und prüfen Sie den dokumentierten Weg des Protokolls zur Stornierung oder Nonce-Invalidierung. Wurde eine unerwünschte Delegation ausgeführt, delegieren Sie über den offiziellen Vertrag neu und prüfen Sie den neuen Zustand. Eine Delegation allein erzeugt normalerweise keine Token-Freigabe; verwechseln Sie eine Neudelegation daher nicht mit dem Widerruf von Freigaben. Falls Sie zusätzlich eine Erlaubnis signiert oder eine Seed-Phrase beziehungsweise einen privaten Schlüssel offengelegt haben, behandeln Sie dies als separaten Wallet-Vorfall mit höherem Schweregrad.

Häufige Irrtümer

  • „Kein Gas bedeutet keine Autorisierung.“ Der Relayer kann das Gas zahlen, während die Signatur die Autorisierung des Signierenden liefert.
  • „EIP-712 macht jede Signatur sicher.“ Der Standard vereinheitlicht das Hashing typisierter Daten und die Domänentrennung, enthält aber keinen Schutz vor Wiederholungsangriffen und kann nicht prüfen, ob der Benutzer die angezeigte Aktion beabsichtigt hat.
  • „Eine Delegation überträgt meine Tokens.“ Eine übliche Stimmdelegation verschiebt oder weist Stimmkraft zu, nicht das Eigentum an Tokens. Den tatsächlichen Effekt können jedoch nur der bereitgestellte Vertrag und die dekodierte Nachricht bestimmen.
  • „Ich kann eine Off-Chain-Signatur immer widerrufen.“ Es gibt keine universelle Transaktion zum Widerruf von Signaturen. Ablauf, Verbrauch oder Invalidierung einer Nonce und Neudelegation sind vertragsspezifische Mechanismen.
  • „Ein Wechsel des Delegierten löscht frühere Stimmen.“ Eine Neudelegation ändert die künftige oder aktuelle Stimmkraft nach den Regeln des Protokolls; bereits abgegebene Stimmen oder historische Snapshots werden dadurch möglicherweise nicht rückgängig gemacht.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...