Zum Inhalt springen
Financial Context Wiki

Warum müssen manche Token-Genehmigungen zuerst auf null gesetzt werden?

Manche ERC-20-Token lehnen den direkten Wechsel von einem Allowance-Wert ungleich null zu einem anderen ab. Erfahren Sie, wann Zero-first nötig ist, warum zwei Transaktionen nacheinander bestätigt werden müssen und welche Risiken bleiben.

Aktualisiert

Nur zu Bildungszwecken; keine Anlageberatung. Anlagen können zu Verlusten führen.

Direkte Antwort

Manche ERC-20-Implementierungen lehnen approve(spender, newAmount) ab, wenn sowohl die bestehende Allowance als auch newAmount ungleich null sind. Bei solchen Token reichen Sie zuerst approve(spender, 0) ein, warten auf die Bestätigung und reichen erst danach die neue Genehmigung ungleich null ein.

Diese Einschränkung ist nicht für jeden ERC-20-Token vorgeschrieben. ERC-20 definiert approve als Ersatz der aktuellen Allowance und empfiehlt Benutzeroberflächen, diese zuerst auf null zu setzen, um ein Wettrennen bei Genehmigungsänderungen abzumildern. Zugleich sollen Token-Verträge dies aus Kompatibilitätsgründen nicht erzwingen. Einige bereitgestellte Token tun es dennoch. Zero-first ist deshalb sowohl ein Kompatibilitätsverfahren als auch ein nützlicher Kontrollpunkt, aber keine Garantie, dass die alte Allowance vor Bestätigung der Nullsetzung nicht ausgegeben wird.

Warum müssen manche Token-Genehmigungen zuerst auf null gesetzt werden?
0 / 5
0 Artikel überprüft; 5 noch ungelöste Punkte

Der Abschluss dieser Überprüfung beweist nicht, dass ein Vermögenswert, eine Transaktion oder ein System sicher ist.

Funktionsweise

  1. Prüfen Sie Chain, Token-Vertrag, Eigentümer, Spender und beabsichtigten Betrag. Lesen Sie allowance(owner, spender) direkt aus dem Token-Vertrag, statt sich nur auf eine Wallet-Bezeichnung zu verlassen.
  2. Ist die Allowance bereits 0, reichen Sie die gewünschte Genehmigung einmal ein. Ist sie ungleich null, kann ein direkter Ersatz durch einen Wert ungleich null bei einer Standardimplementierung gelingen oder bei einem Zero-first-Token zurückgesetzt werden.
  3. Reichen Sie für den Zero-first-Ablauf approve(spender, 0) ein und warten Sie auf einen erfolgreichen Beleg. Lesen Sie anschließend dieselbe Eigentümer-Spender-Allowance erneut und bestätigen Sie den Wert 0.
  4. Prüfen Sie Token-Saldo, Spender und Zweck erneut. Reichen Sie erst dann approve(spender, newAmount) ein und betrachten Sie die neue Allowance erst nach Bestätigung als aktiv.
  5. Prüfen Sie die endgültige Allowance sowie zwischenzeitliche Transfer- und Approval-Ereignisse. Ein erfolgreicher Transaktionsbeleg weist die Ausführung nach; der aktuelle Vertragszustand zeigt die verbleibende Berechtigung.

OpenZeppelins SafeERC20.forceApprove bietet Verträgen einen Kompatibilitäts-Fallback: Die Funktion versucht den gewünschten Wert und bei einem Fehlschlag nacheinander 0 und den gewünschten Wert. Der Helfer ändert die eigene Allowance des aufrufenden Vertrags. Er korrigiert nicht automatisch die Genehmigung einer Benutzer-Wallet und ersetzt weder die Prüfung der Transaktionsreihenfolge noch die des Endzustands.

Beispiel

Ein Eigentümer hat einem Spender eine Allowance von 1000 Token erteilt und möchte sie auf 100 senken. Bei einem Zero-first-Token wird approve(spender, 100) zurückgesetzt, sodass die Onchain-Allowance 1000 bleibt. Ein zurückgesetzter Aufruf aktualisiert den Zustand nicht teilweise.

Stattdessen reicht der Eigentümer approve(spender, 0) ein. Vor dessen Bestätigung gibt der Spender 400 aus, sodass 600 verbleiben. Die danach bestätigte Nullsetzung ersetzt den Rest durch 0. Nach Prüfung des gesunkenen Token-Saldos kann der Eigentümer entscheiden, ob er die neuen 100 genehmigt. Falls ja, hat der Spender bereits 400 verwendet und kann später bis zu 100 zusätzlich einsetzen. Zero-first macht die zwischenzeitliche Ausgabe vor der neuen Genehmigung sichtbar, macht sie aber nicht rückgängig.

Risiken

  • Die alte Allowance kann genutzt werden, bis die Nullsetzung ausgeführt wird. Ein Spender kann einer ausstehenden Aufhebung oder Senkung zuvorkommen.
  • Werden Nullsetzung und Ersatz ohne Bestätigung der ersten Transaktion gesendet, entfällt der vorgesehene Kontrollpunkt und eine zwischenzeitliche Ausgabe kann verborgen bleiben.
  • Eine falsche Chain, Token-Adresse oder Spender-Adresse kann eine andere als die beabsichtigte Berechtigung erstellen oder aufheben. Token-Symbole sind keine eindeutigen Kennungen.
  • Der zweistufige Ablauf kostet zwei Transaktionen, wenn beide nötig sind; jede kann fehlschlagen, ersetzt werden oder ausstehend bleiben. Leiten Sie den Zustand nicht allein aus einer eingereichten Signatur ab.
  • Unbegrenzte Genehmigungen sowie aktualisierbare oder kompromittierte Spender können künftige Einzahlungen gefährden. Verwenden Sie den kleinsten praktikablen Betrag und prüfen Sie die restliche Allowance nach der Nutzung.
  • Vertragsintegrationen müssen nicht standardisierte Rückgabewerte und Genehmigungsverhalten bewusst behandeln. Ein Kompatibilitäts-Wrapper macht einen nicht vertrauenswürdigen Spender nicht sicher.

Häufige Irrtümer

  • Jeder ERC-20 verlangt Zero-first. Der Standard empfiehlt die clientseitige Reihenfolge, sagt aber, dass Token-Verträge sie nicht erzwingen sollten. Nur einige Implementierungen lehnen Änderungen von ungleich null zu ungleich null ab.
  • Zero-first beseitigt das Genehmigungswettrennen vollständig. Der Spender kann die alte Allowance weiterhin nutzen, bevor die Nullsetzung bestätigt ist.
  • Ein zurückgesetzter Ersatz hat die alte Allowance gelöscht. Ein Revert macht den versuchten Zustandswechsel rückgängig, sodass die vorherige Allowance normalerweise bestehen bleibt.
  • Zwei gemeinsam gesendete Transaktionen entsprechen dem Warten. Der Sicherheitskontrollpunkt entsteht durch Bestätigung und Prüfung des Nullzustands vor der Entscheidung über den Ersatz.
  • Das Trennen einer Website widerruft ihre Genehmigung. Wallet-Verbindungsstatus und Onchain-Allowance im Token-Vertrag sind getrennt.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...