Transaktionsverlauf

EN-Quellmaster · P09-L02 · 45 Minuten geschätzt · needs_review

Eine Transaktionsseite kann einen Transfer, seine Anweisung, eine dekodierte Zusammenfassung und eine Saldoänderung anzeigen. Dies können mehrere Ansichten eines Ereignisses sein. Das Addieren jeder Zeile überhöht die Aktivität; das Ignorieren des Ausführungsstatus kann fehlgeschlagene Versuche in erfolgreiche Transfers verwandeln.

Diese Lektion vermittelt ein Verlaufsledger, das Ereignisidentität, Erfolg, verschachtelte Aktivität und Gebühren trennt. Es bereitet die Finanzierungsanalyse vor, ohne jede Adressreferenz als Zahlung zu betrachten.

Die Verlaufsabdeckung definieren

Netzwerk, Zieladresse, zugehörige Tokenkonten, angefragtes Zeitfenster und Erhebungsmethode festhalten. Solana getSignaturesForAddress liefert Signaturen, die die angefragte Adresse in accountKeys referenzieren, mit neuesten Einträgen zuerst und Parametern zur Seitennavigation [S09-SIGNATURES]. Eine zurückgegebene Seite ist eine Entdeckungsliste, kein vollständiges Transferledger.

Eine referenzierte Adresse muss weder signieren noch empfangen. Anweisungen können Programme, Datenkonten und ausschließlich gelesenen Zustand referenzieren. Die Rolle im Datensatz prüfen, bevor Beteiligung als Handlung gezählt wird. Die Abfrage einer Eigentümeradresse kann zudem nicht jede Operation mit separaten Tokenkonten entdecken; die beabsichtigte Abdeckung prüfen, statt vollständigen Verlauf zu behaupten.

Signaturen über überlappende Seiten deduplizieren, unterschiedliche Anweisungen derselben Transaktion jedoch erhalten. Die Sortierung muss verfügbare Slot-/Blockreihenfolge und Evidenz zur Reihenfolge innerhalb eines Kontexts berücksichtigen. Die angezeigte Reihenfolge einer Oberfläche ist nicht automatisch die exakte Ausführungsreihenfolge.

Vor dem Zählen der Effekte das Ergebnis prüfen

Ausführungsmetadaten für entdeckte Datensätze abrufen. Solana getTransaction kann beim angefragten Commitment null zurückgeben; Zeit- oder Metadatenfelder können null sein [S09-TRANSACTION]. Einen fehlenden Abruf als ungeklärt behandeln, nicht als fehlgeschlagenes oder nicht existentes Ereignis.

Ein bestätigter/aufgenommener Datensatz kann dennoch eine fehlgeschlagene Operation enthalten. Erfolg getrennt von Finalität erfassen. Ein eingereichter Betrag beschreibt Absicht; ein erfolgreicher Saldoeffekt beschreibt Ausführung. Beim fehlgeschlagenen T2 der Fixture sind Token-Transfereffekte ausdrücklich null, während die bereitgestellte native Gebühr berechnet bleibt.

Vereinfachte Aussagen zur Rückabwicklung nicht auf jede Chain-Funktion verallgemeinern. Die Übung schließt Autorisierungsänderungen und andere Nicht-Transfermechanismen aus. Ihre Ergebnistabelle liefert die relevanten Effekte direkt. In realer Analyse tatsächliche Protokollregeln und Zustandsunterschiede prüfen.

Ereignisidentität von Anzeigezeilen trennen

Einen Ereignisschlüssel wählen: Netzwerk, Transaktionssignatur/Hash sowie gegebenenfalls Anweisungspfad oder Logindex. Eine Transferanweisung, ihre dekodierte Zusammenfassung und das passende Saldodelta können ein Ereignis bestätigen. Sie sind nicht drei getrennte Transfers.

Ein Saldodelta ist ein Nettoergebnis. Sendet ein Konto 10 und empfängt 4 in einem Zeitfenster, beträgt das Delta−6, während der Bruttoabfluss 10 ist. Das Delta löscht den Eingangstransfer nicht; das Summieren von Bruttobewegung und Nettodelta zählt doppelt.

Verschachtelte Aufrufe brauchen eigene Semantik. Geths callTracer beschreibt Aufrufrahmen mit konfigurierbarem Umfang [S09-TRACES]. Ein interner Aufruf ist Teil einer übergeordneten Transaktion, keine separat signierte Transaktion. Manche Rahmen tragen nativen Wert; andere Aufrufe tragen null und führen Code aus. Nicht jeden Aufruf als Zahlung zählen.

Aufrufe, Logs und Tokenbewegungen unterscheiden

Ein EVM-Receipt liefert Transaktionsverknüpfung, Status und Logs [S09-RECEIPT]. Ein Token-Ereignislog und ein Aufruf mit nativem Wert sind unterschiedliche Datensätze. Der Tokenvertrag, der ein Transfer-Log emittiert, ist nicht zwingend der wirtschaftliche Empfänger.

Auf Solana unterscheiden Ergebnismetadaten Anweisungen, innere Anweisungen, Gebühren und Salden [S09-STRUCTURES]. Eine innere Anweisung kann einen Mechanismus innerhalb einer übergeordneten Operation identifizieren. Eine Zusammenfassung derselben Anweisung sollte denselben Ereignisverweis verwenden.

Ein Vertragsaufruf mit Token-Transferlog kann eine wirtschaftliche Tokenbewegung plus eine Aufrufbeziehung darstellen, statt zwei Tokenbewegungen. Beide Beobachtungen in typisierten Tabellen erhalten und dann die zur Frage passende Zähleinheit wählen.

Gebühren getrennt halten

Gebühren verwenden den nativen Vermögenswert des Netzwerks und haben einen bestimmten Zahler. Sie sind keine Zieltoken-Transfers. Die Solana-Dokumentation beschreibt einen nativen Transaktionsgebührenmechanismus [S09-FEES]. Nicht annehmen, dass jede sichtbare Adresse die Gebühr zahlte oder jeder fehlgeschlagene Versuch kostenlos war.

Gebührensummen einmal je bereitgestelltem Transaktionsergebnis zählen, nicht einmal je Anweisung oder Zusammenfassungszeile. Rohe Gebühreneinheiten anhand der nativen Präzision umrechnen, falls der reale Datensatz sie bereitstellt. Diese Übung liefert normalisierte fiktive Gebühreneinheiten und keine Preisumrechnung.

Tokenbewegung und native Kosten separat abstimmen. Ein Tokendelta kann korrekt sein, während der native Saldo zusätzliche Miete, Einlagen oder unabhängige Effekte enthält. Die Fixture schließt diese Effekte ausdrücklich aus; reale Datensätze erfordern weitere Abstimmung.

Eine begrenzte Verlaufstabelle erstellen

Spalten für Ereignisverweis, Objektrolle, Ergebnis, Vermögenswert, Richtung, Bruttobetrag, Gebührenzahler und Unsicherheit verwenden. Eine separate Liste ungeklärter Datensätze führen. Fehlende Datensätze nicht löschen, nur damit die sichtbare Erfolgszahl vollständig erscheint.

Die Zahl erfolgreicher Token-Transfertransaktionen unterscheidet sich von der Zahl der Token-Transferereignisse. Eine Transaktion kann mehrere Ereignisse enthalten. Die berichtete Statistik benennen. Ein fehlgeschlagener Versuch kann zur Versuchszahl gehören und dennoch null zur erfolgreichen Bewegung beitragen.

Die abschließende Beschreibung muss Beobachtungsfenster und bereitgestellte Abdeckung nennen. Verlauf zeigt, was in verfügbaren Datensätzen geschah, nicht warum ein Akteur es wählte. Ein erfolgreicher Transfer belegt weder Zugehörigkeit noch ein Preissignal.

• Ausführungsergebnis: Erfolg/Fehlschlag der geprüften Operation.
• Ereignisverweis: Transaktion plus Anweisungs-/Logpfad.
• Aufrufrahmen: verschachtelte Ausführung innerhalb einer Transaktion.
• Bruttofluss: Summe gerichteter Bewegungen.
• Nettodelta: Endsaldo minus Anfangssaldo.
• Gebührenzahler: Konto, das die bereitgestellten nativen Kosten trägt.

ILLUSTRATIVE — FIX-P09-02. SIM-SOL-A / W / MINT-T. Vollständige Effekte nur für T1–T3, synthetisch geordnet S1,S2,S3. Native Gebühren sind normalisiert und werden von W bezahlt. Keine anderen Effekte im Zeitfenster. Anfänglicher Tokensaldo 100.

Separates SIM-EVM-A-Beispiel E1 ist erfolgreich mit oberstem W-E→ROUTER mit Wert0; verschachteltem ROUTER→C-E mit nativem Wert2 und einem Token-Transfer-Log für7 Einheiten von W-E an C-E. Die Fixture legt verschiedene Vermögenswerte/Effekte und vollständige Aufrufabdeckung fest. Für E1 wird kein Gebührenwert bereitgestellt.

OBSERVED in der Fixture: Die drei Ansichten von T1 beschreiben einen10-Token-Transfer; T2 schlägt fehl; T3 empfängt 4. E1 enthält einen Aufruf mit Nullwert, eine 2-native Bewegung und ein 7-Token-Log.

INFERRED: Erfolgreicher Zielabfluss 10, Zufluss 4, netto−6; Endsaldo 94. Native Gebühren von T1–T3 insgesamt 0.04.

UNKNOWN: Frühere Historie, menschliche Betreiber, E1-Gebühren und Motive.

INSUFFICIENT EVIDENCE: H2/H3 können keine20 zusätzlich übertragenen Token hinzufügen. Der Versuch von T2 kann nicht als erfolgreicher 20-Token-Abfluss zählen. Der verschachtelte Aufruf von E1 ist keine zweite unabhängig signierte Transaktion.

Zusammenfassungen und Deltas zu Transfers addieren; Aufnahme mit Erfolg gleichsetzen; jede Adressreferenz als Handlung behandeln; native Gebühren mit Tokenbeträgen vermischen; und nicht verfügbare Datensätze aus einer Abdeckungsbehauptung entfernen.

Ein dedupliziertes Tokenledger für T1–T3 erstellen. Brutto- und Nettofluss, Endsaldo und Gebühren berechnen. Den Aufruf und die Vermögenswertbewegungen von E1 klassifizieren, ohne eine Summe über unterschiedliche Vermögenswerte zu bilden.

• Entdeckung und Verlaufsabdeckung erfassen.
• Ausführungsergebnis getrennt von Finalität prüfen.
• Ereignisse durch Transaktion und Pfad kennzeichnen.
• Bruttofluss und Nettosaldo abstimmen.
• Gebühren einmal zählen und Zahler/Vermögenswert erhalten.
• Aufrufe, Logs und menschliche Zuordnung unterscheiden.

Verlaufsrekonstruktion ist Ereignisbilanzierung, kein Zeilenzählen. Erfolgreiche Bewegungen, fehlgeschlagene Versuche und Gebühren beantworten verschiedene Fragen.

Mehrere Ansichten können einen Transfer beschreiben. Verschachtelte Aufrufe sind keine separat signierten Transaktionen. Fehlende Datensätze bleiben ungeklärt statt abwesend.

Zeitachse T1–T3 mit H1/H2/H3 als einem Ereignis gebündelt, T2 fehlgeschlagen mit weiterhin bereitgestellter Gebühr, T3 eingehend4. Fluss10/4/netto−6/Endsaldo 94 und separates Gebührenpanel 0.04 zeigen. E1-Aufrufbaum von Token-/nativen Betragszeilen trennen.

Illustrative Ereignisbilanzierung; Zeilen und verschachtelte Aufrufe sind keine unabhängigen Transaktionen.

Deterministisches SVG/HTML oder Diagramme mit Einheiten, Evidenzverweisen und Textalternativen verwenden. Marineblau/Schwarz mit zurückhaltendem Cyan, elektrischem Blau und Violett; keine dekorativen oder erfundenen Explorer-Screenshots. Bei 390px Anmerkungen stapeln; bei Umsetzung der Assets 768px, Desktop und arabisches RTL prüfen. Kennungen LTR und sachliche Zeit-, Kanten- und Achsenrichtungen unverändert lassen. Nur das offiziell bereitgestellte BlockAssay-Zeichen verwenden. Beide visuellen Datensätze bleiben Spezifikationen.

WALLET_INTELLIGENCE entspricht der ausschließlich lesenden Prüfung öffentlicher Adressdatensätze, Beziehungen und Herkunft. Unterstütztes Netzwerk, genaue Kennungen, Felder und Abdeckung vor jeder Laufzeitintegration prüfen; hier wird keine Live-Fähigkeit eines Anbieters behauptet. Bei fehlenden Daten oder kostenpflichtigem Zugang die eingebettete Offline-Übung verwenden. Wallet-Verbindung, Zugangsdaten, privater Schlüssel, Signatur oder Live-Handel sind nicht erforderlich. Fehlende Daten bleiben unbekannt. Academy-Fortschritt, Creator-Status, Zahlungen und Empfehlungen ändern niemals die Radar-Evidenz.

• Solana getSignaturesForAddress — Signaturverlauf für referenzierte Adressen, Reihenfolge mit neuesten Einträgen zuerst und Seitennavigation. Geprüft am 2026-09-30.
• Solana getTransaction — Transaktionsabfrage, Commitment und Daten-/Zeitfelder, die null sein können. Geprüft am 2026-09-30.
• Solana-RPC-JSON-Strukturen — Ergebnismetadaten, Gebühr, Anweisungen und Salden als getrennte Ansichten. Geprüft am 2026-09-30.
• Solana-Gebühren — Mechanismus nativer Transaktionsgebühren; keine Tokenbewegung und kein universelles Kostenmodell. Geprüft am 2026-09-30.
• In Geth integrierte Tracer — Umfang der Aufrufrahmen-Traces und tracerspezifische Konfiguration. Geprüft am 2026-09-30.
• Ethereum Execution APIs eth_getTransactionReceipt — Receipt-Status, Transaktionsverknüpfung und Logs. Geprüft am 2026-09-30.

Alle Beispieldatensätze sind originale ILLUSTRATIVE Fixtures, keine historischen oder aktuellen Chain-Messungen. Die Dokumentation erklärt Mechanismen, keine erfundenen Beträge oder Bezeichnungen. Die synthetische Chronologie ist ausdrücklich begrenzt; observedAt=null ist beabsichtigt. OBSERVED bezeichnet in einer Übung einen bereitgestellten Fixture-Datensatz. Dokumentation und eingesetzte Dekodierung vor Veröffentlichung erneut prüfen. Anbieterbezeichnungen belegen keine Identität; Adresskontrolle und menschliche Zuordnung erfordern getrennte Evidenz.

P09-L03 nach der ausgearbeiteten Übung und der Fragenprüfung.