Naar inhoudBlockAssay

Blockchain en transacties

P01-L01 · P01 · P01-M01

Onderscheid een gebeurtenis in het register van een identiteitsclaim

ILLUSTRATIVE · needs_review

Vereisten:

Leerdoelen

  • Onderscheid een gebeurtenis in het register van een identiteitsclaim
  • Scheid indiening, opname en interpretatie.
  • Formuleer een registerclaim zonder een persoon te verzinnen.

EN-bronmaster · P01-L01 · geschatte duur 30 minuten · needs_review

Alleen lezen. Geen walletverbinding, echt geld, herstelzin, privésleutel, ondertekening of live transactie. De duur is een redactionele schatting; visuals zijn specificaties, geen uitgerolde componenten.

Waarom dit belangrijk is

Een scherm met ‘verzonden’ kan een applicatiehandeling beschrijven in plaats van een geaccepteerde registergebeurtenis. Onderzoek begint met de vraag die de beschikbare gegevens daadwerkelijk kunnen beantwoorden.

Uitleg

Een record heeft een beperkte reikwijdte

Een blockchain ordent records volgens de validatie- en consensusregels van het netwerk. Validatie controleert naleving; consensus bepaalt welke geldige geschiedenis het netwerk accepteert. Een transactie stelt wijzigingen voor; verspreiding is geen opname. Bitcoin registreert het uitgeven van nog niet uitgegeven transactieoutputs (UTXO), waarden uit eerdere transacties; Ethereum-transacties bevatten ondertekende instructies. Dat zijn verschillende boekhoudmodellen [BTC, TX]. Deze les gebruikt een bewust vereenvoudigd fictief register zonder het volledige formaat van een van beide netwerken na te bootsen.

Stel een beperktere vraag

‘Staat overdracht T in blok B van netwerk N?’ vereist een record met passende herkomst. ‘Heeft Alice Bob betaald voor goederen?’ voegt claims toe over adrescontrole, betalingsdoel en overeenkomst. Die volgen niet uit twee adressen. Een bekende naam naast een adres blijft een annotatie totdat de basis is vastgesteld.

Bewaar transactie-identifier, netwerk en context samen. Een hash zonder netwerk kan naar een irrelevante zoekopdracht leiden. Alleen hoogte identificeert mogelijk geen uniek blok bij een vertakking. Een scherm kan beide weglaten en alleen bewijzen wat een weergave toonde.

Scheid de fasen

Gebruik drie kolommen: ingediend, opgenomen en geïnterpreteerd. Acceptatie door een node betreft die node op dat moment. Opgeslagen opnamebewijs voegt registercontext toe. Een verklaring van het transactiedoel hoort in een afzonderlijk onderbouwde interpretatiekolom. Vul een ontbrekende fase niet stilzwijgend in omdat een latere weergave aannemelijk lijkt.

De vier bewijsstatussen gelden voor een specifieke claim. OBSERVED is direct zichtbaar in het verstrekte record. INFERRED is een afleiding met expliciete aannames. UNKNOWN betekent dat een feit niet beschikbaar is. INSUFFICIENT EVIDENCE beantwoordt een onderzochte claim die het materiaal niet vaststelt. In fictieve gegevens blijft OBSERVED beperkt tot de oefening, nooit een echte blockchain.

Schrijf een reproduceerbare zin

Gebruik: ‘In record R toont netwerk N gebeurtenis E in context C; identiteit en doel zijn niet vastgesteld.’ Anderen moeten R kunnen vinden en E inspecteren. Als R slechts een verzoek toont, schrijf dan ‘meldt indiening’ in plaats van ‘toont de gebeurtenis’. Precisie is nuttiger dan stellige taal.

Begrippen

  • Register: netwerkrecords en toestand onder validatieregels.
  • Hash: cryptografische vingerafdruk voor recordidentificatie; identificeert geen persoon.
  • Transactie: voorgestelde instructie of uitgaverecord.
  • Opname: aanwezigheid in een bepaald blok.
  • Toeschrijving: koppeling van een accountrol aan een entiteit.

Historisch voorbeeld

Conceptuele ILLUSTRATIVE kaarten, geen blockchainschermen. R1: SIM-NET, SIM-TX-A ingediend op T0. R2: dezelfde SIM-TX-A opgenomen op T1 in SIM-BLOCK-40, overdracht van 7 SIM-eenheden van ACCOUNT-A naar ACCOUNT-B. R3: ongeverifieerd label dat ACCOUNT-A ‘Alice’ noemt. T0/T1 zijn fictieve volgordemarkeringen.

Visuele specificaties

Transactietijdlijn: R1 op T0, R2 op T1; aparte baan voor label R3 zonder eigendomsverbinding. Bijschrift: fictieve fasen, geen menselijke toeschrijving. Alternatieve tekst: indiening gaat vooraf aan gemelde opname; naamlabel niet geverifieerd.

Wat het bewijs aantoont

De verstrekte kaarten onderscheiden een verzoek van een opgenomen verplaatsing.

Wat het bewijs niet aantoont

Een echte blockchain-gebeurtenis, economisch eigendom, intentie, levering of veiligheid van het activum.

Veelgemaakte fouten

  • ‘Verzonden’ behandelen als definitieve afwikkeling.
  • Een explorerlabel herhalen als geverifieerde persoon.
  • Een handelsverhaal schrijven op basis van alleen een overdracht.

Praktische oefening

Maak een bewijstabel met drie rijen: indiening, opname en menselijke identiteit. Beoordeel ‘Alice kocht goederen van Bob’. Noem twee ontbrekende feiten en herschrijf de zin.

Lever een korte tabel en onderbouwing uitsluitend op basis van het verstrekte materiaal. Voorgestelde verdeling: studie 12 min, controle/berekening 8 min, correctie/quiz 10 min.

Uitgewerkte correctie tonen

R1 ondersteunt indiening in de fictieve gegevens; R2 ondersteunt gemelde opname en verplaatsing van 7 eenheden. Geen kaart identificeert personen of een overeenkomst. R3 bewijst alleen het bestaan van het label. De aankoopclaim is INSUFFICIENT EVIDENCE; identiteit en doel zijn UNKNOWN. Begrensde zin: ‘R2 registreert 7 SIM-eenheden van ACCOUNT-A naar ACCOUNT-B in SIM-BLOCK-40; menselijke identiteit en aankoopdoel zijn niet vastgesteld.’

Rubriek: 1 punt voor precieze reikwijdte, herkomst van bron/oefengegevens, correcte redenering, expliciete grenzen en veilig offline werken (totaal 5). Verzonnen waarnemingen of onbewezen menselijke toeschrijving vereisen correctie ongeacht de score. Dit is leerfeedback, geen certificering.

Controlelijst

  • Vermeld netwerk en volledige recordlocator.
  • Benoem de daadwerkelijk getoonde fase.
  • Scheid adresrollen en personen.
  • Verbind beperkingen aan de conclusie.

Samenvatting

Een scherm met ‘verzonden’ kan een applicatiehandeling zijn in plaats van een geaccepteerde registergebeurtenis. Onderzoek begint met de vraag die de beschikbare gegevens kunnen beantwoorden. De kaarten onderscheiden verzoek en opgenomen verplaatsing. Ze bewijzen geen echte blockchain-gebeurtenis, eigendom, intentie, levering of activumveiligheid.

Samenvatting

  • Scheid indiening, opname en interpretatie.
  • Formuleer een registerclaim zonder een persoon te verzinnen.

Volgende les

P01-L02 na controle van oefening en vereisten.

Hulpmiddelen

NONE. De gezaghebbende catalogus vereist geen producttoegang voor deze les. Gebruik bevroren materiaal offline.

Bronnen en grenzen van claims

  • [BTC] Bitcoin-ontwikkelaarsgids — Blockchain — Geldige blokken, UTXO, werk en vertakkingen; geen historische authenticatie van de fictieve gegevens. Geverifieerd 2026-10-01.
  • [TX] Ethereum-transacties — Ondertekende instructies en uitvoering; opname staat los van verspreiding. Geverifieerd 2026-10-01.

Synthetische waarden zijn door de auteur gemaakte lesgegevens. Historische waarden gebruiken waar toepasselijk het gekoppelde dataset met de beperktere herkomst. Broncontrole is geen onafhankelijke redactionele goedkeuring.

Visuele specificaties

P01-L01-V01

SPECIFICATION_ONLY · ILLUSTRATIVE

Onderscheid een gebeurtenis in het register van een identiteitsclaim

Illustratieve lesgegevens; geen live weergave

Transactietijdlijn: R1 op T0, R2 op T1; aparte baan voor label R3 zonder eigendomsverbinding. Bijschrift: fictieve fasen, geen menselijke toeschrijving. Alternatieve tekst: indiening gaat vooraf aan gemelde opname; naamlabel niet geverifieerd.

Indiening gaat vooraf aan gemelde opname; naamlabel niet geverifieerd.

390px: gestapelde rijen met volledig tekstequivalent; rendering op 768px/desktop nog te controleren

RTL-proza; identifiers en getallen met eenheden blijven LTR; behoud feitelijke pijlrichtingen

FIX-P01-L01

Bronnen en grenzen van claims

BTC · PRIMARY_DOCUMENTATION

Bitcoin-ontwikkelaarsgids — Blockchain

Ondersteunde claim
Geldige blokken, UTXO, werk en vertakkingen; geen historische authenticatie van de fictieve gegevens.
Verificatiegrens
Primaire pagina onderzocht voor het genoemde mechanisme of toegeschreven verslag; authenticeert de oefengegevens niet.
Controledatum
2026-10-01
Primaire bron openen
https://developer.bitcoin.org/devguide/block_chain.html

TX · PRIMARY_DOCUMENTATION

Ethereum-transacties

Ondersteunde claim
Ondertekende instructies en uitvoering; opname staat los van verspreiding.
Verificatiegrens
Primaire pagina onderzocht voor het genoemde mechanisme of toegeschreven verslag; authenticeert de oefengegevens niet.
Controledatum
2026-10-01
Primaire bron openen
https://ethereum.org/en/developers/docs/transactions/

Herkomst van gegevens

id: FIX-P01-L01

dataStatus: ILLUSTRATIVE

source: Original teaching fixture embedded below; not externally observed

observedAt: null

timeBasis: SIM/T markers are fictional; no real timestamp or chain observation

scope: Invalid training labels; no usable wallet, key or signature

Toets je redenering

P01-L01-Q1 · Welke kaart ondersteunt opname?
P01-L01-Q2 · Wat is de identiteitsstatus van Alice?
P01-L01-Q3 · Wat ondersteunt R1 alleen?
P01-L01-Q4 · Hoe classificeer je de aankoopclaim?
P01-L01-Q5 · Welk verslag is reproduceerbaar?