Ethereum execution and finality

EN source master · P02-L02 · 30 minutes estimated · needs_review

Read-only study. No wallet connection, real money, seed phrase, private key, signature or live trade. Duration is an editorial estimate; visual assets are specifications, not deployed components.

Success and finality answer different questions. Mixing them can make a failed transaction look successful or an included transaction look more settled than the evidence supports.

Two axes, not one status ladder

A receipt describes execution. Ethereum execution runs on the Ethereum Virtual Machine (EVM), the environment that applies its execution rules. Consensus information describes whether its containing block belongs to a history with a particular settlement status. Ethereum proof of stake uses checkpoints and validator votes for finality; a validator is a protocol participant whose voting role is backed by staked ETH [POS]. A successful execution in a recent block need not yet be finalized.

Conversely, failed execution can be contained in finalized history. Finality does not rewrite its outcome. An included failure can still consume fees [GAS]. Do not summarize the two axes as one green ‘done’ badge.

Bind the receipt to the block

Keep transaction hash and block hash together. A finalized checkpoint later in height is not sufficient by itself unless the receipt block is established as its ancestor in the same chain. The fixture supplies that ancestry explicitly where needed; do not invent it in a real report.

A receipt status of zero supports failure at that execution context [RPC]. It does not identify the cause without further data. A missing error explanation remains UNKNOWN; do not diagnose an out-of-gas error simply because it is familiar.

Separate measurement and interpretation

The supplied status value is OBSERVED within the packet. Applying the stipulated ancestry to classify settlement is an INFERRED conclusion under that assumption. Current live state is not observed merely because the packet was read today.

Use an outcome matrix

Create rows for included success/unfinalized, included failure/finalized, and unavailable record. This prevents a single status vocabulary from hiding missing data. A finalized result still does not establish a token's legitimacy, a person's informed consent or the safety of another interaction.

Evidence-state classification

OBSERVED in the fixture: receipt statuses, supplied fee and stipulated checkpoint ancestry. INFERRED: A's failed execution lies in the stated finalized ancestry. UNKNOWN: B's finality and A's failure cause. INSUFFICIENT EVIDENCE: execution success alone establishes consensus finality or token safety.

• Execution status: success/failure of a transaction's execution.
• Finality: consensus settlement property of block history.
• Ancestry: block relationship in one chain.
• Receipt context: transaction plus containing block.

ILLUSTRATIVE. R-A: SIM-TX-A, BLOCK-100, status0, gas fee0.001 simulated ETH. R-B: SIM-TX-B, BLOCK-103, status1. Checkpoint BLOCK-102 is stipulated finalized and descends from BLOCK-100. No finality claim supplied for103.

Two-axis evidence panel: A failure/finalized-under-assumption; B success/finality unknown. Alt: finality does not change a failed execution into success.

The two-axis classifications under explicitly supplied ancestry.

Independent consensus validation, a failure diagnosis, safety or current network status.

• Finalized means succeeded.
• Status1 means finalized.
• Guessing ancestry from height alone.

Classify each transaction along both axes. Does A's fee disappear? Which missing record would resolve B's settlement context?

Submit a short evidence table and reasoning, using only the provided material. Suggested allocation: study 12 min, inspection/calculation 8 min, correction/quiz 10 min.

• Receipt outcome.
• Block hash.
• Consensus/ancestry support.
• Fee separately.
• Unknown failure causes remain unknown.

Success and finality answer different questions. Mixing them can make a failed transaction look successful or an included transaction look more settled than the evidence supports. The supplied material supports the two-axis classifications under explicitly supplied ancestry. It does not establish independent consensus validation, a failure diagnosis, safety or current network status.

• Separate execution outcome from consensus context.
• Explain a finalized failed execution.
• Read block ancestry assumptions.

P02-L03 after reviewing this exercise and its prerequisites.

NONE. The authoritative catalog requires no product access for this lesson. Use the frozen/offline material.

• [RPC] Ethereum JSON-RPC — Receipt status, block context and network-scoped API results. Checked 2026-10-01.
• [POS] Ethereum proof of stake — Consensus checkpoints and execution/consensus separation. Checked 2026-10-01.
• [GAS] Ethereum gas and fees — Gas used times effective price and included failure costs. Checked 2026-10-01.

Synthetic values are author-created exercise inputs. Historical values, if any, must use the linked dataset and its narrower provenance. Source inspection is not independent editorial acceptance.