Blockchain e transazioni

Master sorgente EN · P01-L01 · durata stimata 30 minuti · needs_review

Studio in sola lettura. Nessuna connessione del wallet, fondi reali, frase seed, chiave privata, firma o transazione in tempo reale. La durata è una stima editoriale; i visual sono specifiche, non componenti distribuiti.

Una schermata con «inviato» può descrivere un’azione dell’applicazione anziché un evento accettato nel registro. L’indagine parte dalla domanda a cui i dati disponibili possono effettivamente rispondere.

Un record ha una portata limitata

Una blockchain ordina i record secondo le regole di validazione e consenso della rete. La validazione controlla il rispetto delle regole; il consenso determina quale storia valida la rete accetta. Una transazione propone modifiche; la diffusione in rete non è inclusione. Bitcoin registra la spesa di output di transazioni non ancora spesi (UTXO), valori creati da transazioni precedenti; le transazioni Ethereum contengono istruzioni firmate. Sono modelli contabili diversi [BTC, TX]. Questa lezione usa un registro fittizio deliberatamente semplificato senza riprodurre il formato completo di nessuna delle due reti.

Porre una domanda più circoscritta

«Il trasferimento T compare nel blocco B della rete N?» richiede un record con provenienza adeguata. «Alice ha pagato Bob per dei beni?» aggiunge affermazioni sul controllo degli indirizzi, lo scopo del pagamento e un accordo. Nessuna deriva solo da due indirizzi. Un nome familiare accanto a un indirizzo resta un’annotazione finché la sua base non è dimostrata.

Conservare insieme identificatore della transazione, rete e contesto. Un hash senza rete può condurre a una ricerca irrilevante. La sola altezza potrebbe non identificare un blocco univoco in una diramazione. Una schermata può ometterli entrambi e dimostrare soltanto che cosa mostrava una vista.

Separare le fasi

Usare tre colonne: inviato, incluso e interpretato. L’accettazione di una richiesta da parte di un nodo riguarda quel nodo in quel momento. Una prova archiviata di inclusione aggiunge contesto del registro. Spiegare lo scopo della transazione appartiene a una colonna interpretativa giustificata separatamente. Non colmare tacitamente una fase mancante perché una vista successiva sembra plausibile.

I quattro stati dell’evidenza si applicano a una specifica affermazione. OBSERVED significa direttamente visibile nel record fornito. INFERRED è una deduzione con assunzioni dichiarate. UNKNOWN indica un fatto non disponibile. INSUFFICIENT EVIDENCE risponde a un’affermazione valutata che il materiale non dimostra. Nei dati fittizi OBSERVED resta limitato all’esercizio, mai a una blockchain reale.

Formulare una frase riproducibile

Usare: «Nel record R, la rete N mostra l’evento E nel contesto C; identità e scopo non sono dimostrati». Altri devono poter trovare R ed esaminare E. Se R mostra solo una richiesta, sostituire «mostra l’evento» con «riporta l’invio». La precisione è più utile di un linguaggio sicuro di sé.

• Registro: record e stato della rete soggetti alle regole di validazione.
• Hash: impronta crittografica usata per identificare record; non identifica una persona.
• Transazione: istruzione proposta o record di spesa.
• Inclusione: presenza in un determinato blocco.
• Attribuzione: collegamento tra un ruolo di conto e un’entità.

Schede concettuali ILLUSTRATIVE, non schermate blockchain. R1: SIM-NET, SIM-TX-A inviata a T0. R2: la stessa SIM-TX-A inclusa a T1 in SIM-BLOCK-40, trasferimento di 7 unità SIM da ACCOUNT-A a ACCOUNT-B. R3: etichetta non verificata che chiama ACCOUNT-A «Alice». T0/T1 sono marcatori fittizi di sequenza.

Cronologia della transazione: R1 a T0, R2 a T1; traccia separata dell’etichetta R3 senza collegamento di proprietà. Didascalia: fasi fittizie, nessuna attribuzione umana. Testo alternativo: l’invio precede l’inclusione dichiarata; etichetta del nome non verificata.

Le schede fornite distinguono una richiesta da un movimento incluso.

Un evento reale su blockchain, proprietà economica, intento, consegna di beni o sicurezza dell’asset.

• Trattare «inviato» come regolamento definitivo.
• Ripetere un’etichetta di un explorer come persona verificata.
• Scrivere una storia commerciale basandosi soltanto su un trasferimento.

Creare una tabella dell’evidenza con tre righe: invio, inclusione e identità umana. Valutare «Alice ha comprato beni da Bob». Indicare due fatti mancanti e riscrivere la frase.

Consegnare una breve tabella e una motivazione basate soltanto sul materiale fornito. Ripartizione suggerita: studio 12 min, verifica/calcolo 8 min, correzione/quiz 10 min.

• Indicare rete e localizzatore completo del record.
• Identificare la fase effettivamente mostrata.
• Separare ruoli degli indirizzi e persone.
• Collegare i limiti alla conclusione.

Una schermata con «inviato» può descrivere un’azione dell’applicazione anziché un evento accettato nel registro. L’indagine parte dalla domanda a cui i dati disponibili possono rispondere. Le schede distinguono richiesta e movimento incluso. Non dimostrano un evento reale su blockchain, proprietà economica, intento, consegna di beni o sicurezza dell’asset.

• Separare invio, inclusione e interpretazione.
• Formulare un’affermazione sul registro senza inventare una persona.

P01-L02 dopo aver verificato esercizio e prerequisiti.

NONE. Il catalogo autorevole non richiede accesso al prodotto per questa lezione. Usare materiale congelato senza connessione di rete.

• [BTC] Guida per sviluppatori Bitcoin — Blockchain — Blocchi validi, UTXO, lavoro e diramazioni; nessuna autenticazione storica dei dati fittizi. Verificata 2026-10-01.
• [TX] Transazioni Ethereum — Istruzioni firmate ed esecuzione; inclusione distinta dalla diffusione in rete. Verificata 2026-10-01.

I valori sintetici sono dati didattici creati dall’autore. Dove applicabile, i valori storici devono usare il dataset collegato e la sua provenienza più circoscritta. La verifica delle fonti non è un’approvazione editoriale indipendente.