Blockchain Fundamentals & Architecture Flashcards

In a UTXO-based blockchain, a transaction consuming three inputs of 0.4 BTC, 0.7 BTC, and 0.2 BTC while specifying two outputs of 0.9 BTC and 0.3 BTC results in which of the following?

Answer: A miner fee of 0.1 BTC is implicitly claimed by the block producer

In the UTXO model, all inputs must be fully consumed. The difference between total inputs (1.3 BTC) and total outputs (1.2 BTC) is 0.1 BTC, which is implicitly awarded to the miner as a transaction fee — there is no 'change' mechanism built into the protocol. Any change must be explicitly encoded as an output back to the sender.

Which property distinguishes a Directed Acyclic Graph (DAG) ledger architecture from a traditional blockchain in terms of consensus finality?

Answer: DAG ledgers typically offer probabilistic finality that improves as more subsequent transactions reference a given transaction

In DAG-based architectures (e.g., IOTA's Tangle), transactions achieve finality probabilistically: confidence increases as more subsequent transactions reference (directly or indirectly) the transaction in question. This contrasts with BFT-style blockchains that can achieve absolute finality but still differs from simple block-confirmation counting. DAGs do not eliminate double-spend risk — they address it through the weight of referencing transactions.

A blockchain network uses a Verifiable Random Function (VRF) to select block proposers. An attacker controlling 15% of staked tokens wishes to predict the next proposer in advance to mount a targeted DDoS attack. Under a correctly implemented VRF scheme, why does this attack fail?

Answer: The VRF proof can only be verified after the proposer reveals their secret key, so the winner is unknown until they publish their block

A VRF produces an output and a proof. The output (which determines selection) is computed using the proposer's private key and the epoch seed. No other node can compute the same output without that private key, so the winning proposer cannot be determined externally until they reveal their block (and implicitly their proof). This 'last-revealer advantage' protection means the identity of the next leader is only known when they publish, defeating pre-publication DDoS targeting.

In the context of blockchain Merkle trees, what specific vulnerability is introduced when a system fails to distinguish between leaf nodes and internal nodes during hash computation?

Answer: An attacker can forge a valid Merkle proof for a non-existent transaction by crafting an internal node value that matches a fabricated leaf hash

Without domain separation (e.g., prefixing leaf hashes with 0x00 and internal node hashes with 0x01), an attacker can take a valid internal node hash and present it as if it were a leaf node hash. This allows construction of a fraudulent Merkle proof that appears valid — the 'second preimage' attack on Merkle trees. Bitcoin's implementation uses double-SHA256 for all nodes but modern designs (e.g., RFC 6962 for Certificate Transparency) explicitly use domain separation to prevent this.

A Layer-1 blockchain processes 500 TPS with 10-second block times and a 2 MB block size limit. A proposed upgrade doubles the block size to 4 MB without changing any other parameters. Which network-level consequence is most architecturally significant?

Answer: Orphan/uncle block rates will increase because larger blocks take longer to propagate, raising the probability that two valid blocks are found before one is globally received

Larger blocks propagate more slowly across the peer-to-peer network. During that propagation window, another miner may find a competing valid block, leading to temporary forks (orphan or uncle blocks). Higher orphan rates disproportionately harm smaller miners (who have less hashrate to 'win' competing chains) and increase wasted proof-of-work, ultimately threatening chain security and centralization. This is the core architectural tension in the Bitcoin block size debate — it is not a simple free upgrade.

In a sharded blockchain where cross-shard transactions require a two-phase commit protocol, what is the primary threat introduced by the 'slow shard' problem?

Answer: A malicious or slow shard can hold cross-shard transactions in a pending state indefinitely, locking funds in the source shard without confirmation or rollback

In a two-phase commit across shards, the source shard locks (deducts) funds and waits for the destination shard to confirm receipt before finalizing. If the destination shard is slow, Byzantine, or partitioned, the transaction enters a permanently pending state — funds are locked on the source shard but unconfirmed on the destination. Without a robust timeout-and-rollback mechanism enforced by the coordination layer (e.g., beacon chain), this creates a liveness failure that can be exploited to freeze assets. Ethereum's cross-shard design specifically had to address this edge case.