Blockchain Fundamentals & Architecture Flashcards

In a Merkle Patricia Trie (as used in Ethereum), what is the primary advantage of the 'extension node' over a standard branch node when representing a long shared key prefix?

Answer: Extension nodes compress shared key segments into a single node, reducing trie depth and storage overhead

Extension nodes in a Merkle Patricia Trie act as path-compression shortcuts. When multiple keys share a long common prefix, an extension node encodes that entire shared nibble sequence in one node rather than requiring a chain of branch nodes, each with only one active child. This reduces trie depth, lowers storage costs, and speeds up traversal — a critical optimization given Ethereum's massive state trie.

A blockchain network uses a DAG (Directed Acyclic Graph) structure instead of a linear chain. Which specific consensus problem does a DAG architecture inherently make MORE difficult to solve compared to a linear blockchain?

Answer: Double-spend detection, because conflicting transaction ordering across DAG tips requires additional coordination protocols

In a linear blockchain, total ordering is straightforward — each block references exactly one parent, making double-spend detection unambiguous. In a DAG, multiple tips (unconfirmed vertices) can exist simultaneously and may reference different, potentially conflicting predecessors. Determining a canonical total ordering of transactions requires additional coordination mechanisms (e.g., a confirmation algorithm like IOTA's Tangle coordinator or Avalanche's metastability sampling) that go beyond what a linear chain needs.

In Bitcoin's UTXO model, a transaction spends three UTXOs worth 0.5 BTC, 0.3 BTC, and 0.7 BTC, creating two outputs of 0.6 BTC each. A miner includes this transaction. What happens to the remaining 0.3 BTC?

Answer: It is implicitly claimed by the miner as a transaction fee, requiring no explicit fee output

In Bitcoin's UTXO model, the fee is not an explicit output — it is the difference between total inputs and total outputs. Here: inputs = 0.5 + 0.3 + 0.7 = 1.5 BTC; outputs = 0.6 + 0.6 = 1.2 BTC; fee = 0.3 BTC. The miner who mines the block is entitled to collect this implicit remainder via the coinbase transaction. Unlike Ethereum, there is no 'gasPrice' field; the fee is simply unspent input value.

Which attack vector is specifically enabled by a blockchain that uses a predictable on-chain source of randomness (e.g., block hash or block timestamp) for a smart contract lottery?

Answer: Miner/validator extractable value (MEV) manipulation — a miner can withhold or selectively mine blocks whose hash yields a favorable lottery outcome

Using block hash or timestamp as randomness is vulnerable because the miner (or validator) who produces the block has advance knowledge of — or can influence — these values before broadcasting the block. A rational miner can simply discard blocks whose hash doesn't produce a favorable lottery result and re-mine, at the cost of the block reward. This is a classic MEV (Miner Extractable Value) scenario. The Finney attack is a double-spend technique unrelated to lottery randomness, and Eclipse/Replay attacks target different layers.

In the context of blockchain light clients (SPV — Simplified Payment Verification), which cryptographic property of Merkle trees allows a light client to verify a transaction's inclusion in a block WITHOUT downloading the full block?

Answer: A Merkle proof (authentication path) allows logarithmic-size proofs of inclusion by revealing only sibling hashes along the path from the leaf to the root

SPV clients exploit the Merkle proof (also called an authentication path or Merkle branch). To prove transaction T is in a block, the full node provides only the sibling hash at each level of the tree from T's leaf up to the root — O(log n) hashes for n transactions. The light client recomputes the root by hashing T with each sibling in sequence and checks it against the block header's Merkle root. This requires no knowledge of other transactions. Collision resistance is a prerequisite for security but is not the mechanism enabling the proof.

A proof-of-stake blockchain uses 'slashing' conditions. A validator is slashed for 'surround voting' — signing two attestations where one vote's source/target range strictly surrounds another's. What specific attack does this slashing condition primarily prevent?

Answer: Long-range attacks, where an attacker rewrites history by building an alternate chain from a distant checkpoint using old validator keys

Surround voting slashing specifically targets long-range (history-revision) attacks. If an attacker controls old validator keys (e.g., purchased after validators unstaked), they could attempt to build an alternate chain from far in the past. Surround voting would be required to 'straddle' honest checkpoints with fraudulent ones, finalizing the alternate chain. Slashing surround votes makes this cryptoeconomically prohibitive — validators lose their stake if their historical signatures are detected surrounding the honest chain's finalized checkpoints. Equivocation (double voting at the same height) is a separate slashing condition.