Warum steht auf meiner Brieftasche „Transaktion fehlgeschlagen“, obwohl ich trotzdem eine Benzingebühr bezahlt habe?

Fehlgeschlagene Transaktionen in Blockchain-Netzwerken verstehen

1. Eine als „fehlgeschlagen“ gekennzeichnete Transaktion bedeutet, dass die Ethereum Virtual Machine (EVM) oder eine entsprechende Ausführungsumgebung den Vorgang abgelehnt hat, bevor die beabsichtigte Logik abgeschlossen wurde. Diese Ablehnung erfolgt während der Ausführungsphase, nicht vor der Einreichung.

2. Gasgebühren werden für jeden Rechenschritt verbraucht, einschließlich Validierungsprüfungen, Speicherzugriff und Opcode-Ausführung. Selbst wenn ein Vertrag rückgängig gemacht wird oder der Treibstoff ausgeht, sind die durchgeführten Schritte unumkehrbar und nicht erstattungsfähig.

3. Das Netzwerk unterscheidet nicht zwischen „erfolgreicher Absicht“ und „ausgeführter Arbeit“. Miner oder Validatoren werden für die Verarbeitungszeit und die verbrauchten Ressourcen entschädigt, unabhängig davon, ob die endgültige Zustandsänderung stattgefunden hat.

4. Zu den häufigsten Ursachen gehören unzureichendes Gleichgewicht, falsche Funktionsparameter, fehlgeschlagene require()- oder revert()-Anweisungen in Smart Contracts und Ganzzahlüberläufe, die explizite Rücksetzungen auslösen.

5. Benutzer interpretieren den Fehler oft fälschlicherweise als einen Fehler auf Netzwerkebene, obwohl er in Wirklichkeit ein bewusstes Vertragsverhalten widerspiegelt, das darauf abzielt, die Integrität zu wahren und ungültige Zustandsübergänge zu verhindern.

Gasgebührenmechanismen in EVM-kompatiblen Ketten

1. Der Gaspreis wird pro Einheit berechnet und mit der Gesamtzahl der verbrauchten Einheiten multipliziert. Die Gebühr wird vom Konto des Absenders bei der Übermittlung der Transaktion abgebucht, nicht bei Erfolg.

2. Das gesamte Gas, das bis zum Zeitpunkt des Ausfalls verbraucht wurde, wird dauerhaft verbraucht. Es erfolgt keine teilweise Rückerstattung, es sei denn, eine bestimmte Wiederherstellung mit Begründungszeichenfolge wird ausgelöst und das Gas verbleibt nach der Wiederherstellungsanweisung.

3. Wenn einer Transaktion das Gas ausgeht, werden 100 % des angegebenen Gaslimits verbraucht. Wenn es explizit zurückgesetzt wird (z. B. über revert() oder require(false)), wird ungenutztes Gas zurückerstattet – die Grundkosten für den Aufruf der Funktion und die Ausführung früherer Opcodes sind jedoch weiterhin nicht erstattungsfähig.

4. Transaktionssimulationstools wie Tenderly oder Blocknative können vor der Veröffentlichung eine Vorschau des Gasverbrauchs und möglicher Rückfälle anzeigen, können jedoch aufgrund der dynamischen Bedingungen in der Kette keine identischen Ergebnisse garantieren.

5. Wallet-Schnittstellen zeigen selten den genauen Grund für die Wiederherstellung an, es sei denn, der Knoten unterstützt die eth_call-Ablaufverfolgung oder die Transaktion wurde lokal mit vollständiger Debug-Ausgabe simuliert.

Smart Contract Revert-Verhalten und seine Auswirkungen

1. Die Anweisungen „revert()“, „require()“ und „assurance()“ von Solidity stoppen die Ausführung und machen Zustandsänderungen rückgängig, eliminieren jedoch nicht den Gasverbrauch für Vorgänge, die vor dem Zurücksetzen ausgeführt wurden.

2. Ein Zurücksetzen mit einer benutzerdefinierten Fehlermeldung (eingeführt in Solidity 0.8.4+) verursacht immer noch Gaskosten für die Kodierung und Ausgabe dieser Nachricht – oft kommen 100–300 Gaseinheiten über die Basisausführung hinaus hinzu.

3. Verträge, die vor dem Hardfork in Istanbul bereitgestellt wurden, können sich unter den Bedingungen der Rückstellung aufgrund von Änderungen bei der Berechnung der Gasrückerstattungen nach der Rückstellung anders verhalten.

4. Bibliotheken von Drittanbietern wie SafeERC20 oder ReentrancyGuard von OpenZeppelin führen zusätzliche Prüfungen ein, die den Gas-Overhead erhöhen und die Oberfläche für frühe Rückfälle vergrößern.

5. Externe Aufrufe nicht vertrauenswürdiger Verträge erhöhen das Risiko: Selbst wenn Ihre Transaktionslogik solide ist, wird die Wiederherstellung eines aufgerufenen Vertrags zurückkommen und dazu führen, dass Ihre gesamte Transaktion mit verbrauchtem Gas fehlschlägt.

Einschränkungen der Wallet-Schnittstelle und Fehlinterpretation durch Benutzer

1. Die meisten Verbraucher-Wallets verlassen sich auf eth_getTransactionReceipt, um den Erfolgsstatus zu bestimmen, und interpretieren den Status == 0x0 als „fehlgeschlagen“, ohne die zugrunde liegenden Wiederherstellungsdaten offenzulegen.

2. Der Ausdruck „Transaktion fehlgeschlagen“ ist eine UI-Abstraktion – er weist nicht auf eine Netzwerküberlastung, einen RPC-Fehler oder einen Wallet-Fehler hin, es sei denn, er wird von spezifischen Fehlercodes wie „unzureichende Mittel“ oder „einmal zu niedrig“ begleitet.

3. Einige Wallets unterdrücken EVM-Fehler auf niedriger Ebene, um eine Überlastung der Benutzer zu vermeiden, und ersetzen technische Meldungen wie „Ausführung rückgängig gemacht: ERC-20-Überweisungsbetrag übersteigt den Kontostand“ durch generische Bezeichnungen.

4. Transaktions-Hashes bleiben auch nach einem Fehler gültig und in Explorern sichtbar, sodass Benutzer Trace-Protokolle, Speicherlesevorgänge und Stack-Traces überprüfen können – dies erfordert jedoch technische Vertrautheit und externe Tools.

5. Hardware-Wallet-Integrationen führen manchmal zu Latenz oder Signaturinkongruenzen, die zu stillen Fehlern vor der Ausführung führen, die nicht von On-Chain-Reverts in Wallet-Benutzeroberflächen zu unterscheiden sind.

Häufig gestellte Fragen

F: Kann ich meine Benzingebühr zurückerhalten, wenn eine Transaktion fehlschlägt? Benzin wird nie vollständig erstattet. Es wird nur ungenutztes Gas nach einem expliziten revert() oder require() zurückgegeben. Die Grundausführungskosten und die vor der Rückerstattung aufgewendeten Gase bleiben abgezogen.

F: Warum zeigt MetaMask „Fehlgeschlagen“ an, Etherscan jedoch „Erfolgreich“? Diese Diskrepanz ist normalerweise auf Caching-Verzögerungen oder nicht übereinstimmende RPC-Endpunkte zurückzuführen. Etherscan zeigt die kanonische Quittung an; MetaMask spiegelt möglicherweise eine veraltete oder verzweigte Ansicht wider, bis die Bestätigungstiefe zunimmt.

F: Hat eine fehlgeschlagene Transaktion Auswirkungen auf mein Wallet-Nonce? Ja. Jede signierte Transaktion erhöht die Nonce des Absenders, unabhängig davon, ob sie erfolgreich war oder zurückgesetzt wurde. Nachfolgende Transaktionen müssen die nächste sequenzielle Nonce verwenden, um akzeptiert zu werden.

F: Wie finde ich den genauen Grund für die Rückgängigmachung meiner Transaktion heraus? Verwenden Sie einen Block-Explorer mit Trace-Funktionalität (z. B. Tenderly, Blockscout) oder spielen Sie die Transaktion mit hardhat-node oder cast send von Foundry mit dem Flag --debug ab, um interne Aufrufe zu überprüfen und Zeichenfolgen zurückzusetzen.