Tegenpartijen

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

Een wallet kan een router aanroepen, tokens naar een bewaaradres sturen en een ongevraagde overdracht ontvangen. Een graaf kan alle drie als tegenpartijen tonen, hoewel het verschillende relaties zijn. Hen partners of verbonden partijen noemen verzint een betekenis die het register niet levert.

Deze les maakt een getypeerde tegenpartijtabel en apart register van providerlabels. Je onderscheidt technische interacties, geslaagde bewegingen en ongeverifieerde entiteitsclaims.

Definieer een tegenpartij per gebeurtenistype

Bij directe waardeoverdracht zijn gedecodeerde bron en bestemming de bewegingseindpunten. Bij een contractaanroep is het aangeroepen adres een uitvoeringseindpunt. Bij een tokenlog hebben het uitzendende contract en de from/to-velden verschillende rollen. Specificeer welke relatie je meet.

Een tegenpartijlijst zonder regel is niet reproduceerbaar vergelijkbaar. “Unieke overdrachtsontvangers” verschilt van “alle aangeroepen contracten”. Eén transactie kan beide categorieën bevatten. Combineer ze niet tot één telling als aantal zakelijke relaties.

Activa-identiteit en netwerk blijven nodig. Een TOKEN-A-overdracht en TOKEN-B-overdracht zijn afzonderlijke hoeveelheden, ook bij dezelfde ontvanger. Een nulwaardeaanroep kan uitvoeringsinteractie bewijzen zonder native betaling te bewijzen.

Lees geneste uitvoering zorgvuldig

Geth callTracer vertegenwoordigt call frames en kan worden ingesteld om alleen de bovenste aanroep te bevatten [S09-TRACES]. Een onvolledige traceconfiguratie kan geneste interacties weglaten. Leg vast of je bron de relevante diepte dekt in plaats van aan te nemen dat de bovenste ontvanger het enige uitvoeringseindpunt is.

Een router kan activiteit via andere contracten delegeren of routeren. Het door de gebruiker aangeroepen account hoeft niet het account te zijn dat een uiteindelijke tokenbeweging ontvangt. Een interactiegraaf moet beide verbindingen met verschillende typen behouden in plaats van ze als duplicaten of gelijkwaardige economische relaties te behandelen.

Ethereum-ontvangstbewijslogs bevatten transactiekoppeling en gebeurtenisinformatie [S09-RECEIPT]. Decoderen vereist de juiste uitzender en semantiek. Een contract dat een token Transfer-gebeurtenis uitzendt is daardoor niet koper, ontvanger of verbonden partij van elk daarin genoemd adres.

Onderscheid betrokkenheid van vrijwillige relatie

Op Solana vindt een handtekeningzoekopdracht transacties die een adres in accountKeys noemen [S09-SIGNATURES]. Verwijzing alleen betekent niet dat het adres de transactie autoriseerde. Inspecteer ondertekenaars, instructies en effecten voordat je een actieve rol toewijst.

Een inkomende overdracht kan ongevraagd zijn. Ontvangst alleen bewijst geen toestemming, lidmaatschap of partnerschap. Zelfs herhaalde directe interactie kan passen bij gewoon gebruik van een openbare service in plaats van verbondenheid.

Een overdracht via een contract kan een gedelegeerde of applicatiebeleid betrekken. Concludeer niet dat de zichtbare houder elke beweging persoonlijk ondertekende. Resultaatmetadata scheidt accountrollen en uitvoeringsweergaven [S09-STRUCTURES]; menselijke intentie vereist aanvullend bewijs.

Bewaar labels als bronbeweringen

Een providerlabel moet uitgever, exact adres/netwerk, vastleggings-/bijwerkcontext, bewoording, basis en verificatiestatus hebben. Meld ontbrekende velden. “Exchange-X” naast een adres is geen onafhankelijk vastgestelde entiteitsidentiteit.

Twee interfaces met dezelfde onderliggende labelfeed geven geen twee onafhankelijke bevestigingen. Labelovereenstemming kan onderzoek motiveren terwijl haar afhankelijkheid expliciet blijft. Bewaar beide labels en het conflict als bronnen tegenspreken.

Een werkelijk geverifieerd servicestortingsmechanisme zou nog niet de economische gebruiker van het account identificeren of bewijzen dat een overdracht een verkoop was. Technische verbondenheid, servicebewaring en persoonlijke identiteit zijn afzonderlijke vragen.

Tel de bedoelde eenheid

Gebruik unieke geslaagde gebeurtenissleutels voor bewegingstellingen. Gebruik unieke eindpuntadressen voor ontvangerstellingen binnen opgegeven activum/venster. Herhaald sturen naar één adres telt als meerdere gebeurtenissen maar één unieke ontvanger.

Sluit mislukte pogingen uit van geslaagde stroomtotalen en behoud ze in een pogingentabel. Wis ze niet uit het onderzoek. Bewaar niet-beschikbare resultaten als onopgelost; succes noch mislukking mag uit een mooie interfaceregel worden afgeleid.

Onderscheid inkomende en uitgaande verbindingen in richtingrapporten. Ontvangen van een contract is niet gelijk aan het aanroepen. Een heen-en-terugbeweging bewijst geen eigendom of terugbetalingsdoel zonder mechanismebewijs.

Benoem wat de claim zou versterken

Vraag voor een technische rol gedecodeerde bewerkingen, correcte code/application binary interface (ABI), tracedekking en samenhangende saldi. Vraag voor provideridentiteit de labelbasis en onafhankelijke bevestiging. Specificeer voor verbondenheid welk organisatorisch of geauthenticeerd bewijs nodig zou zijn.

Zoek niet naar persoonlijke identiteit enkel omdat een openbaar adres interessant is. Houd de vraag evenredig aan het leerdoel. Deze oefening bevat geen echte mensen of bruikbare adressen en vereist geen toeschrijvingsonderzoek buiten aangeleverde records.

Een begrensde bevinding zoals “W maakte twee geslaagde TOKEN-A-zendingen naar X; X is door één gedeelde feed als Exchange-X gelabeld, hier ongeverifieerd” is informatief. Zij impliceert geen verkoop, partnerschap of gemeenschappelijke eigenaar.

Bewaar causale en financiële grenzen

Interactie bewijst geen verbondenheid. Een grote overdracht naar een gelabelde service bewijst geen markttransactie. Een grafiek die daarna beweegt bewijst niet dat de overdracht dat veroorzaakte. Zulke latere conclusies vereisen apart bewijs en volgen niet uit een tegenpartijtelling.

Het doel van de les is nauwkeurige relatievocabulaire. Meer verbindingen zijn niet noodzakelijk sterker bewijs van een menselijke relatie. Soms tonen meerdere regels slechts meer interne mechanismen voor één openbare transactie.

• Uitvoeringseindpunt: adres dat tijdens uitvoering wordt aangeroepen.
• Bewegingseindpunt: bron of bestemming van een gedecodeerde activaoverdracht.
• Uitzender: contract dat een gebeurtenislog produceert.
• Unieke ontvanger: afzonderlijke bestemming volgens een verklaarde regel.
• Providerbewering: gepubliceerd label dat beoordeling van reikwijdte/herkomst wacht.
• Verbondenheid: organisatorische relatie die onafhankelijk bewijs nodig heeft.

ILLUSTRATIVE — FIX-P09-04. SIM-EVM-A, W, synthetisch geordende T1–T4. TOKEN-A-bedragen genormaliseerd. Alle genoemde resultaten zijn aangeleverd, niet gemeten.

Er zijn geen verkooprecords, organisatorische verbondenheid of bewijs van menselijke controle aangeleverd. Labels hebben synthetische vastlegging T5; er bestaat geen echte tijdstempel.

OBSERVED in de fixture: W roept ROUTER aan; geneste POOL-interactie en twee TOKEN-A-zendingen naar X zijn aangeleverd. L1/L2 delen een labelbron; L3 conflicteert.

INFERRED: Geslaagd uitgaand TOKEN-A-totaal 15, met één unieke geslaagde ontvanger X binnen dit venster/deze regel. C6 voegt pogingontvanger Y toe, geen geslaagde stroom.

UNKNOWN: Entiteit achter X, toestemming voor ontvangst bij C5, motieven en economische eigenaars.

INSUFFICIENT EVIDENCE: ROUTER-/POOL-interacties bewijzen geen verbondenheid. L1/L2 zijn geen onafhankelijk identiteitsbewijs; L3 lost het conflict niet op. Ontvangst door X bewijst geen verkoop.

Uitzender als ontvanger tellen; routeraanroepen als partnerschappen behandelen; geneste en directe eindpunten zonder typen samenvoegen; gekopieerde labels als onafhankelijke bevestiging overnemen; en ongevraagde ontvangst als vrijwillig lidmaatschap interpreteren.

Maak een getypeerde relatietabel en statistiek van geslaagde TOKEN-A-uitstroom. Scheid entiteitslabelbeweringen van registerrecords. Herschrijf “W verkocht15 aan zijn Exchange-X-partner en ontving een partnerbetaling”.

• Definieer relatie- en telregels.
• Scheid aanroeper, genest eindpunt, uitzender en ontvanger.
• Verifieer resultaat en tracedekking.
• Leg labels met bronafhankelijkheden vast.
• Bewaar mogelijkheden van ongevraagd/onbekende intentie.
• Vermijd conclusies over verbondenheid, verkoop en identiteit zonder bewijs.

Tegenpartijanalyse beschrijft specifieke interacties. Technische deelname en gelabelde entiteiten bewijzen niet automatisch economische of organisatorische relaties.

Interactie is geen verbondenheid. Herhaalde ontvangers verschillen van herhaalde gebeurtenissen. Providerlabels zijn beweringen met herkomst en conflicten.

Gebruik verschillende verbindingsstijlen voor aanroepen en overdrachten met record-ID’s; TOKEN-A-uitzender apart. Markeer C6 mislukt, C5-toestemming onbekend. Toon X-labels in bronregister met gedeelde-feedhaak voor L1/L2 en L3-conflict, geen identiteitsbadge.

Illustratieve tegenpartijtypen; interactie bewijst geen verbondenheid.

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.

• 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.
• Solana getSignaturesForAddress — Handtekeninghistorie die naar een adres verwijst, volgorde met nieuwste eerst en paginering. Gecontroleerd op 2026-09-30.
• JSON-structuren van Solana RPC — Resultaatmetadata, kosten, instructies en saldi als afzonderlijke weergaven. 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-L05 na de uitgewerkte oefening en bespreking van de vragen.