Transactiehistorie

EN-bronmaster · P09-L02 · 45 minuten geschat · needs_review

Een transactiepagina kan een overdracht, de instructie, een gedecodeerde samenvatting en een saldoverandering tonen. Dit kunnen meerdere weergaven van één gebeurtenis zijn. Elke regel optellen blaast activiteit op; uitvoeringsstatus negeren kan mislukte pogingen tot geslaagde overdrachten maken.

Deze les leert een historieregister waarin gebeurtenisidentiteit, succes, geneste activiteit en kosten gescheiden blijven. Zij bereidt financieringsanalyse voor zonder te veronderstellen dat elke adresverwijzing een betaling betekent.

Definieer de dekking van de historie

Noteer netwerk, doeladres, gerelateerde tokenaccounts, gevraagd venster en verzamelmethode. Solana getSignaturesForAddress geeft handtekeningen terug die het gevraagde adres in accountKeys noemen, nieuwste eerst, met pagineringsparameters [S09-SIGNATURES]. Een teruggegeven pagina is een ontdekkingslijst, geen volledig overdrachtsregister.

Een genoemd adres hoeft geen ondertekenaar of ontvanger te zijn. Instructies kunnen naar programma’s, data-accounts en alleen-lezen toestand verwijzen. Inspecteer de recordrol voordat je betrokkenheid als actie telt. Een query op een eigenaaradres kan ook niet elke bewerking met afzonderlijke tokenaccounts ontdekken; inspecteer de beoogde dekking in plaats van volledige historie te verklaren.

Dedupliceer handtekeningen tussen overlappende pagina’s, maar behoud verschillende instructies binnen dezelfde transactie. Sortering moet rekening houden met beschikbare slot-/blokvolgorde en bewijs voor volgorde binnen een context. De weergavevolgorde van een interface is niet automatisch de exacte uitvoeringsvolgorde.

Verifieer het resultaat voordat je effecten telt

Haal uitvoeringsmetadata op voor ontdekte records. Solana getTransaction kan null teruggeven bij het gevraagde commitment en heeft tijd- of metadatavelden die null kunnen zijn [S09-TRANSACTION]. Behandel ontbrekende opvraging als onopgelost, niet als mislukte of niet-bestaande gebeurtenis.

Een bevestigd/opgenomen record kan nog een mislukte bewerking bevatten. Leg succes afzonderlijk van finaliteit vast. Een ingediend bedrag beschrijft intentie; een geslaagd saldo-effect beschrijft uitvoering. Voor de mislukte T2 in de fixture zijn tokenoverdrachtseffecten expliciet nul, terwijl de aangeleverde native kosten verschuldigd blijven.

Veralgemeniseer vereenvoudigde terugrolbeweringen niet naar elke ketenfunctie. De oefening sluit autorisatiewijzigingen en andere mechanismen zonder overdracht uit. Haar resultaattabel levert de relevante effecten rechtstreeks. Inspecteer bij werkelijke analyse protocolregels en toestandverschillen.

Scheid gebeurtenisidentiteit van weergaveregels

Kies een gebeurtenissleutel: netwerk, transactiehandtekening/hash en instructiepad of logindex, waar passend. Een overdrachtsinstructie, gedecodeerde samenvatting en bijpassende saldodifference kunnen één gebeurtenis bevestigen. Het zijn geen drie afzonderlijke overdrachten.

Een saldodifference is een nettoresultaat. Als een account 10 verstuurt en 4 ontvangt binnen één venster, is de verandering−6 terwijl de bruto-uitstroom 10 is. De verandering wist de inkomende overdracht niet uit; brutobeweging en nettoverandering optellen telt dubbel.

Geneste aanroepen hebben eigen semantiek nodig. Geths callTracer beschrijft call frames met configureerbare reikwijdte [S09-TRACES]. Een interne aanroep is onderdeel van een bovenliggende transactie, geen afzonderlijk ondertekende transactie. Sommige frames dragen native waarde; andere aanroepen dragen nul en voeren code uit. Tel niet elke aanroep als betaling.

Onderscheid aanroepen, logs en tokenbewegingen

Een EVM-ontvangstbewijs geeft transactiekoppeling, status en logs [S09-RECEIPT]. Een tokengebeurtenislog en een aanroep met native waarde zijn verschillende records. Het tokencontract dat een Transfer-log uitzendt is niet noodzakelijk de economische ontvanger.

Op Solana onderscheidt resultaatmetadata instructies, inner instructions, kosten en saldi [S09-STRUCTURES]. Een inner instruction kan een mechanisme binnen een bovenliggende bewerking identificeren. Een samenvatting van diezelfde instructie moet dezelfde gebeurtenisverwijzing gebruiken.

Een contractaanroep met een tokenoverdrachtslog kan één economische tokenbeweging plus een aanroeprelatie zijn, in plaats van twee tokenbewegingen. Bewaar beide waarnemingen in getypeerde tabellen en kies daarna de bij de vraag passende teleenheid.

Houd kosten apart

Kosten gebruiken het native activum van het netwerk en hebben een specifieke betaler. Het zijn geen overdrachten van de doeltoken. Solana-documentatie beschrijft een native transactiekostenmechanisme [S09-FEES]. Veronderstel niet dat elk zichtbaar adres de kosten betaalde of dat elke mislukte poging gratis was.

Tel kosten eenmaal per aangeleverd transactieresultaat, niet per instructie of samenvattingsregel. Converteer ruwe kosteneenheden met de native precisie als de werkelijke dataset die geeft. Deze oefening levert genormaliseerde fictieve kosteneenheden zonder prijsconversie.

Sluit tokenbeweging en native kosten afzonderlijk aan. Een tokenverandering kan correct zijn terwijl het native saldo extra rent, stortingen of niet-gerelateerde effecten bevat. De fixture sluit die effecten expliciet uit; werkelijke records vereisen aanvullende aansluiting.

Maak een begrensde historietabel

Gebruik kolommen voor gebeurtenisverwijzing, objectrol, resultaat, activum, richting, brutobedrag, kostenbetaler en onzekerheid. Houd een aparte lijst onopgeloste records bij. Verwijder ontbrekende records niet om de zichtbare succestelling volledig te laten lijken.

Het aantal geslaagde tokenoverdrachtstransacties verschilt van het aantal tokenoverdrachtsgebeurtenissen. Eén transactie kan meerdere gebeurtenissen hebben. Zeg welke statistiek je rapporteert. Een mislukte poging kan in een pogingentelling horen en toch nul bijdragen aan geslaagde beweging.

De eindbeschrijving moet waarnemingsvenster en aangeleverde dekking noemen. Historie leert wat in beschikbare records gebeurde, niet waarom een actor ervoor koos. Een geslaagde overdracht bewijst geen verbondenheid en is geen prijssignaal.

• Uitvoeringsresultaat: succes/mislukking van de onderzochte bewerking.
• Gebeurtenisverwijzing: transactie plus instructie-/logpad.
• Call frame: geneste uitvoering binnen een transactie.
• Brutostroom: som van bewegingen per richting.
• Nettoverandering: eind- minus beginsaldo.
• Kostenbetaler: account dat de aangeleverde native kosten draagt.

ILLUSTRATIVE — FIX-P09-02. SIM-SOL-A / W / MINT-T. Alleen volledige effecten voor T1–T3, synthetisch geordende S1,S2,S3. Native kosten zijn genormaliseerd en betaald door W. Geen andere venstereffecten. Begintokensaldo 100.

Afzonderlijk SIM-EVM-A-voorbeeld E1 slaagt met bovenste W-E→ROUTER value0; geneste ROUTER→C-E native value2 en één token Transfer-log voor7 eenheden van W-E naar C-E. De fixture stipuleert afzonderlijke activa/effecten en volledige aanroepdekking. Voor E1 wordt geen kostenwaarde aangeleverd.

OBSERVED in de fixture: De drie weergaven van T1 beschrijven één10-tokenoverdracht; T2 mislukt; T3 ontvangt 4. E1 bevat een aanroep met nulwaarde, een 2-native beweging en een 7-tokenlog.

INFERRED: Geslaagde doeluitstroom 10, instroom 4, netto−6; eind 94. Native kosten voor T1–T3 bedragen totaal 0.04.

UNKNOWN: Eerdere historie, menselijke beheerders, E1-kosten en motieven.

INSUFFICIENT EVIDENCE: H2/H3 kunnen geen20 extra overgedragen tokens toevoegen. De poging van T2 kan niet als geslaagde 20-tokenuitstroom tellen. De geneste aanroep van E1 is geen tweede onafhankelijk ondertekende transactie.

Samenvattingen en veranderingen bij overdrachten optellen; opname gelijkstellen aan succes; elke adresverwijzing als actie behandelen; native kosten met tokenbedragen mengen; en niet-beschikbare records uit een dekkingsclaim weglaten.

Maak een gededupliceerd tokenregister voor T1–T3. Bereken bruto- en nettostroom, eindsaldo en kosten. Classificeer de aanroep en activabewegingen van E1 zonder totaal over verschillende activa.

• Leg ontdekking en historiedekking vast.
• Verifieer uitvoeringsresultaat afzonderlijk van finaliteit.
• Identificeer gebeurtenissen met transactie en pad.
• Sluit brutostroom en nettosaldo aan.
• Tel kosten eenmaal en behoud betaler/activum.
• Houd aanroepen, logs en menselijke toeschrijving gescheiden.

Historiereconstructie is gebeurtenisboekhouding, geen regeltelling. Geslaagde bewegingen, mislukte pogingen en kosten beantwoorden verschillende vragen.

Meerdere weergaven kunnen één overdracht beschrijven. Geneste aanroepen zijn geen afzonderlijk ondertekende transacties. Ontbrekende records blijven onopgelost in plaats van afwezig.

Tijdlijn T1–T3 met H1/H2/H3 gebundeld als één gebeurtenis, T2 mislukt met kosten nog aangeleverd, T3 inkomend4. Toon stroom10/4/netto−6/eind 94 en apart kostenpaneel 0.04. Scheid de E1-aanroepboom van token-/native-bedragsrijen.

Illustratieve gebeurtenisboekhouding; rijen en geneste aanroepen zijn geen onafhankelijke transacties.

Gebruik deterministische SVG/HTML of grafieken met eenheden, bewijsverwijzingen en tekstalternatieven. Marineblauw/zwart met bescheiden cyaan, elektrisch blauw en violet; geen decoratieve of verzonnen explorer-screenshots. Stapel annotaties op 390px; controleer 768px, desktop en Arabisch RTL wanneer de assets zijn geïmplementeerd. Houd identificatoren LTR en de feitelijke richting van tijd/verbindingen/assen ongewijzigd. Gebruik alleen het officieel aangeleverde BlockAssay-merk. Beide visuele records blijven specificaties.

WALLET_INTELLIGENCE correspondeert met alleen-lezen inspectie van openbare adresrecords, relaties en herkomst. Controleer ondersteund netwerk, exacte identificatoren, velden en dekking vóór runtime-integratie; hier wordt geen live providercapaciteit geclaimd. Gebruik de ingebedde offline oefening als gegevens of betaalde toegang ontbreken. Geen walletverbinding, inloggegevens, private sleutel, handtekening of live handel is vereist. Ontbrekende gegevens blijven onbekend. Academy-voortgang, creatorstatus, betalingen en verwijzingen veranderen nooit Radar-bewijs.

• Solana getSignaturesForAddress — Handtekeninghistorie die naar een adres verwijst, volgorde met nieuwste eerst en paginering. Gecontroleerd op 2026-09-30.
• Solana getTransaction — Transactie opzoeken, commitment en gegevens-/tijdvelden die null kunnen zijn. Gecontroleerd op 2026-09-30.
• JSON-structuren van Solana RPC — Resultaatmetadata, kosten, instructies en saldi als afzonderlijke weergaven. Gecontroleerd op 2026-09-30.
• Solana-kosten — Mechanisme voor native transactiekosten; geen tokenbeweging of universeel kostenmodel. Gecontroleerd op 2026-09-30.
• Ingebouwde Geth-tracers — Reikwijdte van call-frame-traces en configuratie per tracer. Gecontroleerd op 2026-09-30.
• Ethereum Execution API’s eth_getTransactionReceipt — Status van ontvangstbewijs, transactiekoppeling en logs. Gecontroleerd op 2026-09-30.

Alle voorbeeldrecords zijn oorspronkelijke ILLUSTRATIVE fixtures, geen historische/live ketenmetingen. Documentatie verklaart mechanismen, niet verzonnen bedragen of labels. De synthetische chronologie is expliciet begrensd; observedAt=null is opzettelijk. OBSERVED in een oefening betekent een aangeleverd fixturerecord. Herbeoordeel documentatie en de geïmplementeerde decodering vóór publicatie. Providerlabels bewijzen geen identiteit; adrescontrole en menselijke toeschrijving vereisen afzonderlijk bewijs.

P09-L03 na de uitgewerkte oefening en bespreking van de vragen.