Esecuzione e finalità Ethereum

Master sorgente EN · P02-L02 · 30 minuti stimati · needs_review

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

Successo e finalità rispondono a domande diverse. Mescolarli può far sembrare riuscita una transazione fallita o più consolidata una transazione inclusa di quanto l'evidenza sostenga.

Due assi, non una sola scala di stati

Una ricevuta descrive l'esecuzione. L'esecuzione Ethereum avviene nella Ethereum Virtual Machine (EVM), l'ambiente che applica le sue regole di esecuzione. Le informazioni sul consenso descrivono se il blocco che la contiene appartiene a una storia con un particolare stato di regolamento. Il proof of stake Ethereum usa checkpoint e voti dei validatori per la finalità; un validatore è un partecipante al protocollo il cui ruolo di voto è sostenuto da ETH in staking [POS]. Un'esecuzione riuscita in un blocco recente potrebbe non essere ancora finalizzata.

Al contrario, un'esecuzione fallita può essere contenuta in una storia finalizzata. La finalità non ne riscrive l'esito. Un fallimento incluso può comunque consumare commissioni [GAS]. Non riassumere i due assi in un unico badge verde «completato».

Vincolare la ricevuta al blocco

Conservare insieme hash della transazione e hash del blocco. Un checkpoint finalizzato a un'altezza successiva non basta da solo, a meno che il blocco della ricevuta sia stabilito come suo antenato nella stessa blockchain. I dati dell'esercizio forniscono esplicitamente quell'ascendenza dove serve; non inventarla in un resoconto reale.

Uno stato della ricevuta pari a zero sostiene il fallimento in quel contesto di esecuzione [RPC]. Non identifica la causa senza ulteriori dati. Una spiegazione mancante dell'errore resta UNKNOWN; non diagnosticare un esaurimento del gas soltanto perché è familiare.

Separare misura e interpretazione

Il valore dello stato fornito è OBSERVED nel pacchetto. Applicare l'ascendenza stipulata per classificare il regolamento è una conclusione INFERRED secondo tale assunzione. Lo stato attuale in tempo reale non è osservato soltanto perché il pacchetto è stato letto oggi.

Usare una matrice degli esiti

Creare righe per successo incluso/non finalizzato, fallimento incluso/finalizzato e record indisponibile. Questo impedisce a un unico vocabolario di stati di nascondere dati mancanti. Un risultato finalizzato non dimostra comunque legittimità di un token, consenso informato di una persona o sicurezza di un'altra interazione.

Classificazione degli stati dell'evidenza

OBSERVED nei dati dell'esercizio: stati delle ricevute, commissione fornita e ascendenza stipulata del checkpoint. INFERRED: l'esecuzione fallita di A si trova nell'ascendenza finalizzata dichiarata. UNKNOWN: finalità di B e causa del fallimento di A. INSUFFICIENT EVIDENCE: il solo successo dell'esecuzione dimostra finalità del consenso o sicurezza del token.

• Stato dell'esecuzione: successo/fallimento dell'esecuzione di una transazione.
• Finalità: proprietà di regolamento del consenso relativa alla storia dei blocchi.
• Ascendenza: relazione tra blocchi in una blockchain.
• Contesto della ricevuta: transazione e blocco che la contiene.

ILLUSTRATIVE. R-A: SIM-TX-A, BLOCK-100, status0, commissione gas0.001 ETH simulati. R-B: SIM-TX-B, BLOCK-103, status1. Il checkpoint BLOCK-102 è stipulato finalizzato e discende da BLOCK-100. Nessuna affermazione di finalità fornita per103.

Pannello dell'evidenza a due assi: A fallimento/finalizzato secondo assunzione; B successo/finalità sconosciuta. Testo alternativo: la finalità non trasforma un'esecuzione fallita in un successo.

Le classificazioni a due assi secondo l'ascendenza esplicitamente fornita.

Validazione indipendente del consenso, diagnosi del fallimento, sicurezza o stato attuale della rete.

• Supporre che finalizzato significhi riuscito.
• Supporre che status1 significhi finalizzato.
• Indovinare l'ascendenza dalla sola altezza.

Classificare ogni transazione lungo entrambi gli assi. La commissione di A scompare? Quale record mancante risolverebbe il contesto del regolamento di B?

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

• Esito della ricevuta.
• Hash del blocco.
• Sostegno del consenso/ascendenza.
• Commissione separata.
• Le cause sconosciute di fallimento restano sconosciute.

Successo e finalità rispondono a domande diverse. Mescolarli può far sembrare riuscita una transazione fallita o più consolidata una transazione inclusa di quanto l'evidenza sostenga. Il materiale fornito sostiene le classificazioni a due assi secondo l'ascendenza esplicitamente fornita. Non dimostra validazione indipendente del consenso, diagnosi del fallimento, sicurezza o stato attuale della rete.

• Separare esito dell'esecuzione e contesto del consenso.
• Spiegare un'esecuzione fallita finalizzata.
• Leggere le assunzioni sull'ascendenza dei blocchi.

P02-L03 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.

• [RPC] JSON-RPC Ethereum — Stato della ricevuta, contesto del blocco e risultati API specifici della rete. Verificata 2026-10-01.
• [POS] Proof of stake Ethereum — Checkpoint del consenso e separazione esecuzione/consenso. Verificata 2026-10-01.
• [GAS] Gas e commissioni Ethereum — Gas utilizzato moltiplicato per prezzo effettivo e costi dei fallimenti inclusi. 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.