Blockchain and Web3 fundamentals

A replicated log of transactions, batched into blocks, where each block commits to its predecessor by hash so that altering an old entry invalidates every entry after it. Many independent machines hold a copy, apply the transactions in the same order and therefore compute the same resulting state. The interesting part is not the hashing, which is ordinary, but that the participants agree on the order without any of them being in charge. Everything expensive about the technology — the latency, the cost per write, the constraints on what a program may do — is the price of removing that coordinator.

One thing: which ordered history is the real one. Not whether a transaction is valid, because validity is checked locally by rules every node already knows, and not what the state is, because the state follows deterministically from the order. Consensus exists because two honest nodes can see two conflicting blocks at the same height and must end up choosing the same one. Framing it this way is worth doing in an interview, because it explains why consensus changes affect throughput and finality but not what a contract can compute.

Proposing a block requires finding a hash below a target, which takes real work and therefore real electricity. Rewriting history means redoing that work for every block you want to replace, faster than the honest network extends the current chain — so the cost of a rewrite grows with how far back you reach. That is where the confirmation convention comes from: depth is a proxy for cost-to-undo. It also explains the standing criticism, which is that the security budget is an energy bill paid continuously whether or not anyone is attacking.

Capital at risk instead of energy spent. Validators lock a deposit, are selected to propose and attest to blocks, and lose part of the deposit for provable misbehaviour such as signing two conflicting blocks. The security argument shifts from "an attack costs more electricity than it earns" to "an attack costs you your stake". Two consequences follow that interviewers ask about: the protocol can define explicit finality, because a supermajority of stake can attest that a checkpoint is settled, and stake tends to concentrate in large operators, which is a live governance concern rather than a solved one.

Two valid blocks can be produced at the same height, and nodes temporarily disagree about which is canonical until the rule for choosing resolves it. The losing branch is discarded, along with every transaction that appeared only in it.

The branch that matters in that picture is the dotted one. A transaction that was included, that returned a successful receipt, and that your application already acted upon, is now simply not in the chain. It may be re-included later, at a different block, possibly with a different outcome if the state it depended on changed in the meantime.

The application-level consequence is that "I saw a receipt" is not a durable fact. Anything derived from chain events has to be reversible: store the block hash next to each derived record, verify on every new block that its parent is the hash you last recorded, and when it is not, rewind your derived data to the last agreeing block and reapply.

The reason this is worth rehearsing is that it is the single most common gap between candidates who have built a dApp and candidates who have read about one. The second group describes confirmations as a number to wait for; the first group has written the rewind path, because they have had a support ticket caused by not having one.

Execution, not settlement. A layer 2 processes transactions in its own environment and periodically posts data and a commitment back to the base chain, which remains the arbiter of what happened. Users get much lower fees because the expensive base-chain resource is amortised across many transactions. The trade-offs are the interesting part: withdrawals back to the base layer are not instant on designs that use a challenge period, most networks currently depend on a small number of privileged operators for ordering, and a contract deployed on one is not automatically deployed on another.

Because a bridge is custody wearing the clothes of a protocol. Locking an asset on one chain and issuing a representation of it on another means some mechanism — a contract, a multisig, a validator set — is authorised to mint on the destination chain when it believes a deposit happened. Compromise that authorisation and you can mint without depositing, which is unbounded. Several of the largest exploits by value have been bridges, and the pattern is consistent: the cryptography held and the trusted component did not. Treat any cross-chain design as a question about who may mint.