Blockchain Fundamentals Flashcards

In a Merkle Patricia Trie used by Ethereum, what is the primary advantage of using a 'extension node' over storing the full path in every leaf node?

Answer: It reduces storage overhead by compressing shared path prefixes into a single node

Extension nodes in a Merkle Patricia Trie compress sequences of nibbles (half-bytes) that are shared across multiple branches into a single node, avoiding redundant storage of common prefixes. This is critical for Ethereum's state trie efficiency, where many addresses share common prefix nibbles. The other options describe unrelated mechanisms — ECDSA signing happens at the transaction layer, and state roots are per-block, not coexisting.

A blockchain network uses a BFT-based consensus mechanism with 100 validators. An attacker controls 32 validators. Which statement accurately describes the network's security posture?

Answer: The attacker can halt the network but cannot create double-spends

Classical BFT (e.g., PBFT, Tendermint) tolerates up to ⌊(n-1)/3⌋ faulty nodes — for n=100, that's 33. With 32 malicious validators (below the 1/3 threshold), safety (no conflicting finalized blocks) and liveness (the network keeps producing blocks) are both guaranteed. The attacker cannot cause safety failures or halt the network. However, if they had exactly 34+ validators, they could break liveness. At 32, neither safety nor liveness is compromised — the attacker can do neither of the harmful actions listed in other options.

Which of the following best explains why a 51% attack on a Proof-of-Work chain allows double-spending but does NOT allow an attacker to steal funds from arbitrary wallets?

Answer: Transaction validity (including signature verification) is enforced by all nodes independently of mining power

A 51% attacker controls block ordering and can reorg the chain to reverse their own confirmed transactions (double-spend), but they cannot forge signatures or create transactions spending others' funds. Every full node independently validates ECDSA (or Schnorr) signatures before relaying or accepting transactions. A block containing an invalid signature would be rejected by the network regardless of the miner's hash power. Mining power only controls which valid transactions are included and in what order — it does not override cryptographic rules enforced at the node level.

In the Lightning Network, what is the purpose of the Hash Time-Locked Contract (HTLC) 'timelock' component, specifically in a multi-hop payment routing scenario?

Answer: It ensures that each intermediate node has sufficient time to claim its funds on-chain if an upstream node becomes unresponsive

In multi-hop Lightning routing (A→B→C→D), each hop uses an HTLC with a decreasing timelock (e.g., D's HTLC expires in 40 blocks, C's in 80, B's in 120). This staggering ensures that if D reveals the preimage to C, C has enough time to claim funds from B on-chain before B's HTLC expires — and so on up the route. Without this, a malicious or offline intermediate node could cause an upstream node to lose funds. The timelock is about on-chain fallback safety during channel failures, not exchange rates or replay protection.

A developer deploys an upgradeable smart contract using the Transparent Proxy Pattern. After a year, the team discovers the implementation contract has a critical reentrancy vulnerability. Which scenario correctly describes the LIMIT of upgradeability in this context?

Answer: A storage collision between the proxy and implementation contract can cause the upgrade to silently corrupt state

In the Transparent Proxy Pattern, the proxy stores its own admin and implementation addresses at specific storage slots. If the new implementation contract's state variables are laid out differently from the original (storage layout mismatch), variable reads/writes in the new implementation can read from slots used by the proxy's own internal variables — silently corrupting state. This is the critical 'storage collision' risk. Option A is wrong: storage is NOT automatically migrated; the proxy's storage persists as-is, and the new implementation must be compatible. Options C and D describe mechanisms that don't work this way.

When Ethereum transitioned from Proof-of-Work to Proof-of-Stake via 'The Merge', which of the following correctly describes what was NOT changed at the execution layer?

Answer: The EVM opcode set and gas mechanics for smart contract execution

The Merge replaced the consensus mechanism (PoW mining → PoS validators) but deliberately left the execution layer — including the EVM, its opcode set, gas pricing, and smart contract semantics — entirely unchanged. This was by design to ensure existing contracts and tooling continued to work without modification. ETH issuance changed significantly (miners stopped receiving block rewards), block proposer selection moved from hash-based mining to validator selection by the beacon chain, and transaction ordering moved from miners to validators — but the EVM itself was untouched.