Blockchain Fundamentals Flashcards

In the context of blockchain finality, what distinguishes 'probabilistic finality' from 'absolute finality,' and which consensus mechanism achieves absolute finality?

Answer: Probabilistic finality means a transaction becomes irreversible only after enough confirmations accumulate, reducing reversal probability over time; BFT-based systems like Tendermint achieve absolute finality because a block is final once validators sign it.

In Nakamoto-style PoW chains (Bitcoin, early Ethereum), finality is probabilistic — each additional block exponentially reduces the chance of a reorg, but never reaches zero mathematically. BFT-derived systems like Tendermint/Cosmos achieve absolute (or 'instant') finality because a supermajority (≥2/3) of validators must sign a block before it is committed; once committed, no fork can override it without violating the safety guarantee.

A blockchain developer notices that two smart contracts call each other in a cycle during the same transaction. Which low-level EVM mechanism is specifically responsible for the reentrancy vulnerability this can cause, and what is the most gas-efficient mitigation pattern?

Answer: The CALL opcode forwards residual gas to the recipient by default, allowing the callee to re-enter the caller before state updates complete; the Checks-Effects-Interactions pattern mitigates this without extra gas overhead.

CALL (and CALLCODE) forward remaining gas to the target address. If the target is a malicious contract, it can call back into the sender before the sender's state (e.g., balance deduction) is updated — classic reentrancy. The Checks-Effects-Interactions (CEI) pattern requires completing all state changes BEFORE making external calls, eliminating the re-entry window with zero extra gas. Reentrancy guards (mutexes) also work but consume an extra SSTORE/SLOAD, making CEI more gas-efficient.

Bitcoin uses a UTXO model while Ethereum uses an account/balance model. Which of the following is a concrete, non-obvious technical consequence of Bitcoin's UTXO model that does NOT apply to Ethereum's account model?

Answer: Bitcoin transactions can be validated in parallel because each UTXO is an independent input with no shared mutable state between unrelated transactions in the same block.

Because each UTXO is a discrete, self-contained coin that can only be spent once, transactions spending different UTXOs have no state dependency on each other. This means full nodes can validate multiple transactions in parallel within a block — a property that gives UTXO chains structural advantages for sharding and parallel processing. Ethereum's account model requires sequential or carefully coordinated execution because two transactions touching the same account nonce or balance are order-dependent.

In a Merkle Patricia Trie (MPT) as used in Ethereum's state trie, what is the purpose of 'extension nodes,' and how do they differ from 'branch nodes' in terms of storage efficiency?

Answer: Extension nodes compact a shared hex-prefix path segment into a single node, reducing the number of nodes needed for long shared key prefixes; branch nodes fan out into up to 16 children and are needed only where the key path diverges.

Ethereum's MPT has four node types: blank, leaf, extension, and branch. An extension node encodes a shared nibble-prefix that multiple keys have in common, collapsing what would otherwise be a long chain of single-child branch nodes into one compact node. A branch node has up to 16 slots (one per hex nibble) and is required whenever two or more keys diverge at that position. Extension nodes are a key optimization: without them, a trie with keys sharing a 20-nibble prefix would require 20 branch nodes instead of one extension node.

A Layer-2 optimistic rollup submits a batch to Ethereum mainnet. A verifier detects fraud and submits a fraud proof during the challenge window. Which of the following accurately describes what happens at the smart contract level during a successful fraud proof on an Optimistic Rollup?

Answer: The fraud proof contract re-executes only the disputed transaction(s) on-chain using the pre-state and input data committed in the batch, verifies the output diverges from the claimed state root, then reverts to the last valid state root and slashes the sequencer's bond.

In an optimistic rollup (e.g., Optimism pre-Bedrock, Arbitrum Classic), fraud proofs work by re-executing the specific disputed state transition on-chain. The verifier submits the pre-state (committed in the batch calldata) and the disputed transaction inputs. The fraud proof contract executes only that step in the EVM, compares the resulting state root against what the sequencer claimed, and if they differ, the sequencer's bond is slashed and the contract reverts to the last valid committed state root. Only the disputed step is re-executed — not the entire batch — making the proof feasible on-chain.

The Lightning Network uses Hash Time-Locked Contracts (HTLCs) for multi-hop payments. If a routing node in the middle of a payment path goes offline after receiving the incoming HTLC but before forwarding the outgoing HTLC, what is the precise on-chain resolution mechanism that protects the sender?

Answer: The HTLC includes a timelock (CLTV) that, if the preimage is not revealed within the expiry window, allows the sender's channel partner to reclaim the locked funds via a timeout transaction on-chain, cascading back to the original sender.

HTLCs use two spending conditions: (1) the recipient reveals the preimage to claim funds, or (2) the timelock (CLTV — CheckLockTimeVerify) expires and the payer reclaims funds. Each hop in a multi-hop path has staggered timelocks (decreasing toward the destination) to ensure that if a node goes offline, the upstream node's timelock expires first, allowing them to reclaim their locked HTLC on-chain before the downstream timelock expires. This prevents the offline node from holding funds indefinitely. No third-party arbitrator exists — it is enforced entirely by Bitcoin Script.