Blockchain Fundamentals Flashcards

In a Merkle tree used by Bitcoin, what happens to the transaction Merkle root if a single transaction in a block is altered after mining?

Answer: The root hash changes entirely, invalidating the block's proof-of-work

In a Merkle tree, each parent node is the hash of its two children. Altering any single transaction changes its leaf hash, which cascades up through every parent node all the way to the Merkle root. Because the Merkle root is embedded in the block header, the block header hash changes, destroying the proof-of-work nonce solution. The block becomes invalid and would be rejected by the network.

Which of the following best describes the 'nothing-at-stake' problem specific to naive Proof-of-Stake implementations?

Answer: Validators can vote on multiple competing chain forks simultaneously at negligible cost, undermining consensus

In naive PoS, signing/voting on blocks costs virtually nothing computationally (unlike PoW where hashing competing chains wastes real energy). A rational validator can therefore vote on every fork simultaneously, hoping to collect rewards regardless of which chain wins. This destroys the economic disincentive to support multiple forks. Modern PoS systems resolve this through slashing — penalizing validators who sign conflicting blocks by destroying a portion of their staked collateral.

A blockchain network has a target block time of 10 minutes and uses a difficulty adjustment algorithm that recalculates every 2016 blocks. If the last 2016 blocks were mined in exactly 14 days, what adjustment does the protocol make?

Answer: Difficulty decreases by approximately 0% because 14 days is exactly the target (2016 × 10 min ÷ 60 ÷ 24 = 14 days)

The target for 2016 blocks at 10 minutes each is exactly 2016 × 10 minutes = 20,160 minutes = 14 days. If the actual time was exactly 14 days, the actual time equals the target time, so the ratio is 1:1 and difficulty does not change (0% adjustment). This is a trick question — 14 days IS the target, so no adjustment is needed. Option B and C say the same thing but B correctly identifies WHY (14 days is the target).

In the context of blockchain light clients (SPV — Simplified Payment Verification), which attack vector does an SPV client remain vulnerable to that a full node is NOT?

Answer: Eclipse attacks combined with false Merkle proof responses from malicious peers

SPV clients do not download or validate the full blockchain; they only request Merkle proofs from peers to verify that a transaction is included in a block. If an attacker can eclipse an SPV node — surrounding it exclusively with dishonest peers — those peers can serve fabricated Merkle proofs for transactions that don't actually exist on the canonical chain. A full node independently validates every transaction and block, so it cannot be deceived by false proofs regardless of peer behavior. Both SPV and full nodes are equally exposed to 51% attacks on chain reorganization.

What is the primary cryptographic role of the 'nonce' field in a Bitcoin block header, and why is its 32-bit size considered a practical limitation for modern miners?

Answer: The nonce is iterated to find a header hash below the target difficulty; with ASICs exhausting all ~4.3 billion values in milliseconds, miners must also modify the coinbase's extraNonce to expand the search space

Miners repeatedly hash the block header with different nonce values, seeking a hash numerically below the current difficulty target. The 32-bit nonce provides only ~4.3 billion possible values. Modern ASICs can exhaust this entire space in under a second, finding no valid hash. To expand the search space without changing the block structure, miners increment an 'extraNonce' value embedded in the coinbase transaction, which changes the Merkle root in the header and effectively gives miners an astronomically larger nonce space to search.

In Ethereum's account-based model versus Bitcoin's UTXO model, which statement correctly identifies a security trade-off that favors the UTXO model?

Answer: UTXO transactions are inherently replay-protected across chain forks because each output can only be spent once and is tied to its specific chain state

In the UTXO model, each unspent output is a discrete coin that can only be consumed once. If a chain forks (e.g., ETH/ETC split in 2016), a UTXO transaction signed for one fork cannot trivially be replayed on the other fork because the specific UTXO it references may not exist or may already be spent on the sister chain. Ethereum's account-based model uses sequential nonces, and a transaction with a given nonce is valid on any fork where that account has the same nonce — making replay attacks across forks a real concern (which is why EIP-155 introduced chain-ID-bound signatures). Option C is partially true but is about MEV/ordering, not a fundamental account-model vulnerability.