Wie lese ich eine Transaktion in einem Block-Explorer wie Etherscan? (Die Details verstehen)

Grundlegendes zu Transaktionen

1. Jede Transaktion auf Ethereum erscheint als eindeutige Kennung, die als Transaktions-Hash bezeichnet wird – eine 64-stellige Hexadezimalzeichenfolge, die mit „0x“ beginnt. Dieser Hash dient als unveränderlicher Fingerabdruck der in der Kette durchgeführten Aktion.

2. Die Blocknummer gibt an, welcher Block die Transaktion enthält. Blöcke sind sequentielle Dateneinheiten und jede trägt einen Zeitstempel, einen Schwierigkeitsgrad und Metriken zum Gasverbrauch, die die Netzwerkbedingungen zum Zeitpunkt der Ausführung widerspiegeln.

3. Der Status wird entweder als „Erfolgreich“ oder „Fehlgeschlagen“ angezeigt. Eine fehlgeschlagene Transaktion verbraucht immer noch Gas und erscheint in der Kette, verändert aber nicht den Zustand von Smart Contracts oder Guthaben.

4. Das Feld „Von“ zeigt die initiierende Adresse an – immer ein externes Konto (External Owned Account, EOA), es sei denn, die Auslösung erfolgt durch einen Vertrag über Delegatecall oder ähnliche Mechanismen.

5. Das Feld „An“ kann eine Vertragsadresse, eine andere EOA oder „Vertragserstellung“ anzeigen, wenn die Transaktion einen neuen Bytecode in die Kette eingefügt hat.

Entschlüsselung von Gas und Gebühren

1. Der Gaspreis wird in Gwei angegeben und spiegelt wider, wie viel der Absender pro Gaseinheit zu zahlen bereit war. Es beeinflusst direkt die Transaktionspriorität in Miner/Validator-Mempools.

2. Der Gasverbrauch stellt die tatsächlich während der Ausführung verbrauchten Rechenressourcen dar – nicht den Grenzwert. Die Diskrepanz zwischen dem Gaslimit und dem Gasverbrauch offenbart Optimierungsmöglichkeiten oder unerwartete Rückschläge.

3. Transaktionsgebühr = verbrauchtes Gas × Gaspreis – dieser Wert wird vom Guthaben des Absenders abgezogen und im Rahmen von Konsensanreizen an Validatoren verteilt.

4. Die Grundgebühr pro Gas erscheint in Post-London-Upgrade-Transaktionen und wird verbrannt, wodurch ETH dauerhaft aus dem Verkehr gezogen wird, anstatt Bergleute zu belohnen.

5. Die Prioritätsgebühr (oder Trinkgeld) ist optional und geht vollständig an die Validatoren, um einen Anreiz für eine schnellere Aufnahme zu schaffen, insbesondere bei Überlastung.

Analysieren von Eingabedaten und Funktionsaufrufen

1. Eingabedaten sind hexadezimal kodiert und ohne ABI-Dekodierung oft nicht lesbar. Wenn eine Transaktion mit einem Smart Contract interagiert, stellen die ersten vier Bytes den Funktionsselektor dar, der aus dem Keccak-256-Hash der Funktionssignatur abgeleitet wird.

2. Etherscan versucht eine automatische ABI-Erkennung für verifizierte Verträge und zeigt für Menschen lesbare Funktionsnamen wie „transfer(address,uint256)“ neben dekodierten Parametern an.

3. Bei nicht verifizierten Verträgen bleiben die Eingabedaten roh – Analysten verlassen sich auf Tools wie ABIDecoder oder manuelles Reverse Engineering unter Verwendung bekannter Standards wie ERC-20 oder ERC-721.

4. Interne Transaktionen – keine echten Blockchain-Ereignisse, sondern simulierte Spuren – offenbaren Wertübertragungen von Vertrag zu Vertrag, die in Feldern der obersten Ebene unsichtbar sind. Diese erscheinen auf der Registerkarte „Interne Txns“.

5. Das Vorhandensein von „0x“, gefolgt von Bytes ungleich Null in den Eingabedaten, signalisiert fast immer eine Vertragsinteraktion und nicht eine einfache ETH-Übertragung .

Überprüfung von Token-Übertragungen und Ereignissen

1. Token-Bewegungen werden als von Smart Contracts ausgegebene Ereignisse protokolliert, nicht als native Blockchain-Operationen. Etherscan analysiert diese Protokolle, um den Abschnitt „Übertragene Token“ zu füllen.

2. Jede Token-Übertragung umfasst Von, An, Wert und Token-Vertragsadresse – was eine präzise Verfolgung über Wallets und Protokolle hinweg ermöglicht.

3. ERC-20-Übertragungen lösen Transfer(Adresse indiziert von, Adresse indiziert zu, uint256-Wert)-Ereignisse aus, während ERC-721 Transfer(Adresse indiziert von, Adresse indiziert zu, uint256 indiziert tokenId) ausgibt.

4. Ereignisprotokolle werden im Beleg gespeichert, nicht in der Transaktion selbst – das heißt, sie sind erst nach Bestätigung zugänglich .

5. Ungewöhnliche Muster – wie etwa Nullwertübertragungen an unbekannte Adressen oder wiederholte Genehmigungen verdächtiger Verträge – weisen häufig auf Phishing oder böswilliges Token-Verhalten hin.

Häufig gestellte Fragen

F: Warum wird bei einer Transaktion „Warnung! Bei der Vertragsausführung ist ein Fehler aufgetreten“ angezeigt, aber immer noch „Erfolgreich“? A: Dies tritt auf, wenn ein Vertrag intern einen Fehler auslöst, ihn aber mit Try/Catch abfängt oder bedingt zurücksetzt, ohne den gesamten Aufruf anzuhalten – der Status der obersten Ebene spiegelt den externen Erfolg wider, selbst wenn die interne Logik fehlschlägt.

F: Kann ich private Schlüsselinformationen aus einer Transaktion auf Etherscan sehen? A: Nein. Private Schlüssel erscheinen niemals in der Kette. Nur öffentliche Schlüssel und daraus abgeleitete Signaturen sind sichtbar und können nicht rückgängig gemacht werden, um Geheimnisse wiederherzustellen.

F: Was bedeutet „Nonce zu niedrig“ bei einer ausstehenden Transaktion? A: Das bedeutet, dass die Transaktion eine Nonce verwendet, die niedriger ist als die Nonce des aktuellen Kontos, was darauf hinweist, dass es sich um ein Duplikat oder einen veralteten Versuch handelt – Knoten lehnen sie komplett ab.

F: Woher weiß ich, ob ein Vertrag auf Etherscan verifiziert wurde? A: Bei verifizierten Verträgen wird neben der Vertragsadresse ein grünes Abzeichen „Verifiziert“ angezeigt und es werden Registerkarten für „Code“, „Vertrag lesen“ und „Vertrag schreiben“ angezeigt. Bei nicht verifizierten Verträgen wird nur Bytecode angezeigt.