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.

flowchart TD
    A[Block 100] --> B[Block 101a seen first]
    A --> C[Block 101b]
    C --> D[Block 102b]
    B -.->|discarded| X[Transactions return to mempool]
    D --> E[Canonical chain continues]
    E --> F[App must undo effects of 101a]

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.

A program deployed at an address, whose code is fixed, whose storage persists, and which executes only when a transaction or another contract calls it. It cannot initiate anything by itself — there is no scheduler, so a "monthly payout" needs an external caller — and it cannot reach outside the chain. No HTTP requests, no clock beyond block timestamps, no filesystem, and no source of randomness that is both unpredictable and verifiable. Every one of those needs a party outside the chain to bring the information in, which is what an oracle is and why oracles are a trust boundary.

Because every node must reach the same result when it re-executes the transaction, possibly years later. An HTTP call would return different bodies to different nodes at different times, and consensus would be impossible. So the pattern inverts: a contract cannot pull, so something pushes. An oracle submits a transaction carrying the external value, the contract stores it, and the contract's users now depend on the oracle's honesty, liveness and update frequency. That dependency is a design decision to argue explicitly, not plumbing — most oracle-related failures are about staleness or a manipulable source rather than a broken signature.

The application binary interface is the agreed encoding for calling a contract: a function is identified by the first four bytes of the hash of its signature, and arguments follow in a defined layout. It matters because the chain stores bytecode, not names. Without the ABI, calldata is opaque bytes and a returned value is an untyped blob, which is why block explorers can decode transactions to verified contracts and show hexadecimal for everything else. It also means a call is dispatched by selector, so two different functions whose signatures hash to the same four bytes are a real, if rare, hazard.

A transaction is signed, costs a fee, is ordered by consensus and may change state. A call is a local simulation: a node executes the function against its current state and returns the result without publishing anything, so it is free, immediate and invisible to everyone else. Reads use calls; writes need transactions. The consequence people trip over is that a call can succeed while the equivalent transaction fails, because the state moved between the two — which is exactly what happens to a swap quoted by a call and executed a few seconds later.

Whenever something sits between them. msg.sender is the immediate caller, so if a user calls a router which calls your contract, you see the router.

// A user calls Router.execute, which calls Vault.deposit.
// Inside deposit, msg.sender is the Router address, not the user.
function deposit(uint256 amount) external {
    balances[msg.sender] += amount;   // credits the router
}

// tx.origin is the externally-owned account that signed the transaction,
// and using it for authorisation is a known vulnerability: any contract the
// user is tricked into calling can then act as them.

Two distinct mistakes come out of this. The first is accounting: credit the caller when you meant to credit the user, and every deposit routed through an aggregator lands in the aggregator's balance. The fix is an explicit onBehalfOf parameter with the router required to be trusted, or a permit-style signature from the user.

The second is authorisation. tx.origin looks like the answer, because it really is the signer — and it is precisely wrong, because it makes your contract vulnerable to any contract the user can be persuaded to interact with. That contract calls yours, tx.origin is still the user, and your check passes. Use msg.sender for authorisation and pass identity explicitly when there is a legitimate intermediary.

The delegatecall case is the third thing to know: under delegatecall, msg.sender is preserved from the outer call, which is what allows a proxy to forward a user's call without the implementation seeing the proxy as the caller.

require and a custom error for anything a caller can get wrong or any state precondition; assert for an invariant that should be impossible to violate, so that a failure signals a bug in your code rather than a bad input.

error InsufficientBalance(uint256 requested, uint256 available);

function withdraw(uint256 amount) external {
    uint256 available = balances[msg.sender];
    // Custom errors encode as a selector plus arguments, which is cheaper
    // than a string and gives the caller structured data to react to.
    if (amount > available) revert InsufficientBalance(amount, available);

    balances[msg.sender] = available - amount;
    totalDeposits -= amount;

    // An invariant, not an input check: if this is ever false the accounting
    // above is wrong, and no user input should be able to cause it.
    assert(totalDeposits <= address(this).balance);
}

Reading it in order: the revert path is a normal, expected outcome that the interface documents, and the caller should be able to decode which condition failed. The assert path is a claim about your own correctness, and the right response to seeing one fire in production is to stop the contract, not to retry.

The mechanical detail worth knowing is that all three undo every state change made in the call. There is no partial application of a transaction — a revert rolls back everything the transaction did, though the sender still pays for the gas consumed getting there. That is why a failed transaction has a receipt with a failure status and a nonzero gas cost, which surprises users who expect a failure to be free.

Since Solidity 0.8.0 arithmetic is checked by default and overflow reverts on its own, so the historical practice of wrapping every addition in a library is obsolete. An unchecked block opts back out, and is worth it only where you have proved the bound yourself.

They are the contract's output channel to the outside world. Emitting a log is far cheaper than storing the same data, and logs are indexed by topic so an off-chain consumer can filter them efficiently — but contract code cannot read past logs, which is exactly why they are cheap. That gives a clean rule: state is what the contract needs to make future decisions, and events are what applications, indexers and users need to know what happened. A contract storing a history array it never reads is paying permanent storage prices for something an event would have carried.

A token contract owns its own balances, so a third-party contract cannot move your tokens unless you first record an allowance for it, which takes a separate transaction. Two transactions to make one deposit is the visible cost.

step 1  user -> Token.approve(spender = Vault, amount = 1000)
step 2  user -> Vault.deposit(1000)
                 Vault -> Token.transferFrom(user, Vault, 1000)
                          checks and decrements the allowance

The failure modes all come from the allowance being persistent and separate from its use. An allowance left in place after a deposit stays exploitable if the spender is ever compromised or upgraded to something malicious, which is why "unlimited approval" is both the dominant convenience choice and the most commonly-abused one. Wallet phishing largely consists of getting a user to sign step 1 for a contract they have not read.

There are two mitigations to know by name. Signature-based approvals let the user sign an off-chain authorisation that the spender submits alongside its own call, collapsing the two transactions into one and, importantly, letting the authorisation carry an expiry. And revocation tooling exists because users accumulate live allowances they have forgotten, which is a real operational hygiene task rather than a theoretical risk.

The design lesson generalises past tokens: any pattern that separates granting permission from using it leaves a window, and the window's length is a parameter you should be choosing deliberately.

Gas meters the work a transaction does, so that computation, memory growth and state access are paid for in proportion to what they cost the network, and no transaction can loop forever. Under the fee market introduced by EIP-1559, each block has a protocol-set base fee per gas that is burned rather than paid to anyone, and the sender additionally offers a priority fee that goes to the block proposer. The practical reading is that the base fee is a congestion price you cannot negotiate, and the priority fee is the part that buys you position.

Four places, and knowing which is which is most of gas reasoning.

area       lifetime               cost profile            typical use
---------  ---------------------  ----------------------  ---------------------------
stack      one instruction span   cheapest                arithmetic operands
memory     one call               cheap, grows quadratically  temporary arrays, ABI buffers
calldata   one call, read-only    cheap to read           function arguments
storage    permanent              by far the most costly  balances, config, ownership

The lifetimes explain the prices. Stack and memory vanish when the call returns, so nobody has to keep them. Calldata arrives with the transaction and is already paid for by the sender, which is why marking a large external parameter calldata rather than memory avoids a pointless copy. Storage is the one every node retains indefinitely, so it is priced as a permanent liability rather than a computation.

Memory has a detail worth knowing: expansion is charged, and the charge grows faster than linearly as the memory footprint grows, so building one enormous array in memory is not free even though memory is described as cheap.

The habit this should produce is to ask, for every value a function handles, whether it needs to survive the call. If not, it does not belong in storage, and the most effective gas work is usually deleting a state variable rather than tuning one.

Because it is the only one that permanently enlarges the state every validating node must hold and be able to serve. Computation is transient and paid for once; a stored word has to be kept indefinitely by thousands of machines. Two refinements matter in interviews. Writing a slot that was previously empty costs more than overwriting one that already held a value, because it adds an entry rather than changing one. And the first access to a slot within a transaction is charged more than later accesses to the same slot, which is why reading a value once into a local variable and reusing it beats reading it repeatedly.

Execution halts, every state change made by the transaction is reverted, and the sender pays for all the gas consumed up to that point. So an out-of-gas failure is the worst of both outcomes: nothing happened and it was not free. This is why unbounded loops over a growing array are a design error rather than an inefficiency — the function works in testing and becomes permanently uncallable once the array crosses the threshold where it cannot finish inside a block's gas limit. The remedy is pagination, a pull pattern, or moving the aggregation off chain.

The gas limit is how much work you authorise the transaction to do; exceeding it reverts with all gas consumed, and setting it far too low guarantees that outcome. The fee cap is the most you are willing to pay per unit of that work, and setting it below the prevailing base fee simply means the transaction waits rather than fails. Two different failure modes, and candidates routinely blend them: too little gas burns money for nothing, too low a fee costs nothing and achieves nothing until the market moves.

You ask a node to simulate the transaction against current state and report the gas consumed. That works well for deterministic code and misleads in three situations. When state changes between estimation and execution, so a different branch runs — a first-time write instead of an update, or a path that touches an extra slot. When the code branches on the caller or on a balance that differs at execution. And when the transaction interacts with contracts whose behaviour depends on other transactions ordered ahead of it. Hence the convention of adding headroom to an estimate, and hence why headroom is not the same as safety.

It executes another contract's code in your contract's context: your storage, your balance, and the original msg.sender.

// Runs the library's bytecode, but every SLOAD and SSTORE hits THIS
// contract's storage. The target is effectively granted your state.
(bool ok, bytes memory out) = library.delegatecall(msg.data);
require(ok, "delegatecall failed");

That is the mechanism behind upgradeable proxies and behind shared library patterns, and it is the reason both need care. If the target address can be influenced by a caller, you have handed an attacker the ability to run arbitrary code against your storage, which includes overwriting your owner variable and moving your funds. So the target must be fixed at deployment or changeable only by an authority you would trust with the contract itself.

The second hazard is layout. Because storage belongs to the caller and slot assignment is decided by the callee's declarations, the two contracts must agree exactly about what lives in each slot. Reorder a variable in the implementation and it reads a different slot, silently, with no error to observe. This is what makes upgrade safety a schema-migration problem rather than a code-review problem.

Because gas consumption grows with the array and a transaction must fit in a block. A distribution function that iterates every holder works with fifty holders, is expensive with five thousand, and eventually cannot be executed at all — at which point the funds it was meant to move are stuck behind code that can never complete. The array's growth is usually driven by users, so an attacker can push you over the edge deliberately. Design for it by inverting the flow: let each recipient withdraw their own share, which bounds every transaction to one participant's work.

An external call transfers control, so the callee can call back into your contract before your current function has finished. If the state that authorises an action has not yet been updated, the re-entrant call reads a stale value and performs the action again. The classic form drains a vault by re-entering a withdrawal that zeroes the balance after sending funds. The modern forms arrive through token transfer hooks, NFT receipt callbacks and user-supplied router addresses, so a contract that never sends ether is not automatically safe.

Validation, then all of your own state changes, then anything that touches another address.

function withdraw() external {
    uint256 amount = balances[msg.sender];
    require(amount > 0, "nothing to withdraw");   // checks
    balances[msg.sender] = 0;                     // effects
    (bool ok, ) = msg.sender.call{value: amount}("");
    require(ok, "send failed");                   // interactions
}

Read it as an invariant rather than a recipe. The property being maintained is that at every point where control could leave this contract, the accounting is already consistent — the sum of balances matches the ether held. Move the assignment below the call and the invariant is false for the duration of the call, which is the entire vulnerability.

The ordering protects this function. It does not protect against re-entry through a different function that reads the same mapping, which is why a shared non-re-entrant flag is a sensible backstop and why applying it to only some functions of a contract is close to useless.

The variant to mention unprompted is read-only re-entrancy. A view function called during the window when your storage is mid-update returns a consistent-looking but wrong answer, and a third contract that trusts it — a lending market reading a price — is the one that loses money. Your contract is not exploited; its reader is.

Not in the way it was. Since Solidity 0.8.0, arithmetic on the built-in integer types reverts on overflow and underflow, so the old practice of routing every addition through a checked-arithmetic library is redundant. Two places remain. An unchecked block turns the checks off deliberately for gas, and inherits the full risk, so the bound must be proved by argument. And explicit casts between widths still truncate silently, so downcasting a value that does not fit produces a wrong number without reverting. Fixed-point arithmetic done with integers also rounds, and rounding in the protocol's favour or the user's is a decision, not an accident.

Because it is chosen, within limits, by whoever proposes the block, and because every value derivable on chain is visible to the transaction that uses it. Anything computed from the block hash, the timestamp or the difficulty can be predicted or influenced by a party who profits from the outcome, and a contract that mints a rare item based on such a value will be farmed. Randomness that resists this needs an external source with a commitment scheme — a value committed to before it is revealed — which is a verifiable-randomness service, and it is a dependency with cost and latency rather than a function call.

Whoever orders transactions in a block can insert, reorder or omit them for profit — front-running a large trade, sandwiching it on both sides, or racing a liquidation. It is a property of a public mempool plus discretionary ordering, so no contract can prevent it unilaterally. What a contract can do is limit the damage: accept a slippage bound or minimum output from the user so a sandwiched trade reverts instead of executing at a manipulated price, avoid designs where the first caller wins a large prize, and use commit-and-reveal where a user's intent must stay private until it is too late to act on. Naming the mitigation rather than just the phenomenon is the difference in an interview.

Rarely in the obvious owner-only function, and very often in the ones added later: an emergency withdrawal, a parameter setter, an initialiser, a function that was internal and became external during a refactor. They also hide in inheritance, where a modifier is applied to an overriding function and not to the base one that remains reachable, and in upgradeable contracts where a new implementation drops a modifier the old one had. The practical defence is an explicit inventory of every externally callable function with its required authorisation, reviewed as a table, because reading it function by function is how the gap survives review.

A contract that reads the instantaneous price from a single trading venue can be attacked by moving that venue's price. Borrowed capital, repaid within the same transaction, makes the move cheap: push the price, take a loan against inflated collateral or execute a mispriced trade, unwind. The vulnerability is not the loan, it is the choice of a manipulable, single-source, spot price as truth. Resistance comes from prices that are expensive to move for the duration you read them — a time-weighted average, an aggregate across independent venues, or a feed with multiple reporters — and from asking how deep the market being read actually is.

Because a low-level call reports failure by returning false, not by reverting, so ignoring the return value means execution continues as though it succeeded.

// Wrong: a failed send is invisible, and the accounting below runs anyway.
recipient.call{value: amount}("");
paidOut[recipient] += amount;

// Right: propagate the failure so the whole transaction reverts.
(bool ok, ) = recipient.call{value: amount}("");
require(ok, "send failed");
paidOut[recipient] += amount;

The first version marks a payout as made when no ether moved, and the discrepancy is only discoverable by reconciliation. It is the same class of bug as an ignored error return in any other language, made worse by the fact that the ledger involved is the one people care about.

There is a token-specific version of this. Some ERC-20 implementations return false instead of reverting on failure, and some do not return a value at all, which is why safe-transfer wrappers exist: they check the return data and treat an absent value as success only where that is the documented behaviour. Assuming every token reverts on failure is how an integration ends up crediting a deposit that never arrived.

The general rule to state is that on this platform every external interaction has three outcomes — succeeded, reverted, and returned a failure you must inspect — and code that handles two of them is incomplete.

An audit gives you expert adversarial review of a specific commit against a stated scope, and a report you can publish. It does not give you correctness. Findings are bounded by the time bought, the scope agreed and the specification supplied, so a contract that does exactly what its documentation says can still be economically broken by an interaction nobody modelled. Audits also go stale the moment you change code, which is why an upgradeable contract's audit covers the implementation reviewed and not the one currently deployed. Treat it as one control alongside tests, invariant fuzzing, monitoring and a staged rollout.

A private key is a large random number. The public key is computed from it by elliptic-curve multiplication on secp256k1, and the account address is derived from the public key by hashing and truncating. The derivation runs one way only, which has three consequences: an address can be generated offline with no registration anywhere, a lost key cannot be recovered by any authority, and a signature can be verified by recovering the signer's address from it without the signer publishing anything in advance. Custody is therefore the entire security model, and there is no password-reset flow to fall back on.

A seed phrase is a human-transcribable encoding of the entropy that generates a whole tree of keys. BIP-39 defines the wordlist and the mapping from words to a seed, and BIP-32 defines the hierarchical derivation of child keys from that seed, so one backup covers every account the wallet will ever create. The consequences to state are that the phrase is strictly more valuable than any single key, that a passphrase option exists which produces an entirely different tree from the same words, and that anyone reading the phrase — including a screenshot in a photo library — holds every account it generates.

A path selects one key from the tree defined by the seed, one level at a time.

m / 44' / 60' / 0'      / 0      / 0
|    |     |     |         |       |
|    |     |     account   change  address index
|    |     coin type: 60 is Ethereum
|    purpose: BIP-44 structured wallets
master key from the seed

The apostrophe marks a hardened step, which means the child cannot be derived from the parent's public key alone — that is what stops a leaked public key at one level exposing siblings.

The practical significance is the support question this generates constantly: a user restores a seed phrase into a different wallet, sees an empty account, and concludes their funds are gone. They are not. The second wallet derived a different path, so it is showing a different, genuinely empty address. Recovery means entering the path the original wallet used.

The same structure is why one seed can hold many chains and many accounts without extra backups, and why an application that asks users to "connect an account" should treat each address as independent rather than assuming one person means one address.

It keeps the private key in a device that never exports it, so malware on the connected computer cannot read the key and cannot sign without physical confirmation. What it does not protect against is you approving the wrong thing. If the calldata authorises an unlimited token allowance to an attacker, the device signs it correctly and the loss is complete. That is why on-device display of what is being signed matters so much, and why structured signing formats exist — the security boundary is the user's ability to understand the request, not the secrecy of the key.

It removes the single point of failure in signing: a threshold of keys must approve, so one lost or stolen key is neither fatal nor sufficient. That makes it the reasonable default for treasury funds and for contract administration. What it does not solve is correlated failure or social compromise. Signers on the same laptop, in the same office, or approving whatever the same team member asks them to approve, deliver the appearance of distributed control and none of the substance. The useful questions are whether signers are genuinely independent, whether they review what they sign, and how a lost signer is replaced.

Custodial means someone else holds the key and your balance with them is a database row, so transfers between their users need no chain transaction, account recovery exists, and you carry counterparty risk. Self-custodial means the user holds the key, every action is an on-chain transaction with a fee and a confirmation delay, and there is no recovery. The engineering difference is where correctness lives: a custodian runs a ledger and must reconcile it against chain state, while a self-custodial application signs nothing and must be robust to the user's wallet, network and fee choices.

It defines a way to sign structured data so a wallet can display what is being authorised instead of an opaque hash.

{
  "domain": { "name": "TokenVault", "chainId": 1, "verifyingContract": "0x..." },
  "primaryType": "Withdrawal",
  "message": { "asset": "USDC", "amount": "1000000", "deadline": 1893456000 }
}

Three parts do the work. The domain binds the signature to one contract on one chain, so it cannot be replayed against a different deployment. The type definition gives every field a name and a type, which is what allows a wallet to render it. And the message is the payload the contract will verify.

The security argument is about the human, not the cryptography. A user asked to sign a hash has no way to evaluate it, so the only rational answer is refusal — and since users do not refuse, phishing works. Rendering "approve unlimited spending to this address" is the mitigation.

The pattern this enables is gasless authorisation: the user signs an intent off chain, a relayer submits it and pays the fee, and the contract verifies the signature and enforces the deadline. Note the deadline field, because a signature with no expiry is a standing permission that outlives the user's intent.

Each account has a transaction count, and a transaction is only valid when its nonce equals that count exactly. So transactions from one account execute in nonce order regardless of the order they were submitted or the fees they pay, and a transaction sitting unconfirmed at a low fee blocks every later one from that account. The fix is a replacement at the same nonce with a meaningfully higher fee. A gap — nonce 42 submitted while 41 never was — leaves a valid but unexecutable transaction that nodes may eventually drop, which is why nonce allocation in a backend must be a single serialised authority with durable state.

The rigidity of an account whose only authorisation rule is one secp256k1 signature. Account abstraction moves the account itself into a contract, so validation becomes programmable: multiple signers, spending limits, session keys, social recovery, a third party paying the fee, or several actions batched into one user operation. The ERC-4337 design achieves this without a protocol change by routing user operations through a shared entry-point contract that bundlers submit. The cost is a more complex execution path and more moving parts to trust, which is a trade worth stating rather than presenting the approach as free.

A full node validates every block and holds the current state, so it can answer questions about now and re-execute anything from data it has. An archive node additionally retains historical state at every past block, which is what makes "what was this balance two years ago" answerable and what makes it far larger and more expensive to run. A light client verifies block headers and asks others for the data it needs, so it is cheap and depends on peers for correctness. The design consequence is that a historical state query fails against a pruned node while a query about the head succeeds, which looks like an intermittent bug.

It is each node's set of valid pending transactions, gossiped between peers, from which block proposers select. It is not a queue in any useful sense: there is no global ordering, no admission guarantee, no fairness, and each node's view differs. Transactions can be dropped when a node reclaims space, replaced by another with the same nonce and a higher fee, or held indefinitely if the fee is uncompetitive. Two consequences for applications: pending is not a state you can rely on, and everything in there is public, which is where front-running comes from.

The path has more steps than most candidates describe, and each one is a place to lose a transaction.

sequenceDiagram
    participant W as Wallet
    participant N as RPC node
    participant M as Mempool peers
    participant B as Block proposer
    participant A as Your backend
    W->>N: send raw signed transaction
    N->>M: gossip if valid
    B->>M: select by fee and nonce order
    B->>N: new block containing it
    A->>N: fetch receipt and check status

The gap worth pointing at is between the second and third arrows. The transaction has an identifier the moment the node accepts it, and that identifier is the thing applications treat as proof — but nothing has happened yet, and nothing may ever happen. Inclusion is the proposer's decision.

The last arrow carries the second lesson: a receipt exists for failed transactions too. Its status field distinguishes a transaction that executed successfully from one that reverted, and both consumed gas. Code that treats the presence of a receipt as success will book failures as completions.

Then there is the step the diagram cannot show, which is waiting. A receipt from the head of the chain can be discarded by a reorganisation, so the application decides a depth — a confirmation count, or the finalised block tag on chains that provide one — before it treats the effect as real.

They name three points on the chain, and choosing between them is a consistency decision.

tag         what it means                          what can still change
----------  -------------------------------------  ---------------------------
latest      the current head this node has seen    everything, and it may reorg
safe        unlikely to be reorganised             in principle, still could
finalized   settled by consensus                   nothing, short of catastrophe

Reading a balance at latest gives the freshest answer and the weakest guarantee, which is right for a display and wrong for anything you credit. Reading at finalized gives an answer that will not be withdrawn, at the cost of being some blocks behind the present.

The confusion to avoid is between finality and confirmation depth. On a chain with explicit finality, the tag is a protocol statement. On a chain without it, depth is a probabilistic argument about the cost of a rewrite, and the number of blocks you require is a risk judgement scaled to the value at stake.

The related detail is that a node lagging the head will answer latest differently from its peers. If a session reads from a pool of endpoints, one member being a block behind produces a read that contradicts a write the application just made.

Because scanning logs across a wide block range is expensive for the node, so providers cap the range, the number of results, or both. A backfill therefore has to be written as a pager rather than a query: a fixed block window per request, a durable cursor recording the last block processed, and logic to halve the window and retry when a busy range exceeds the result cap. Do it that way and the job is resumable after a failure and after a rate limit, which matters because a full history scan will hit both.

Good at low-latency notification of new heads and of logs matching a filter, without the request overhead of polling. Bad at durability. A dropped connection loses everything that happened while it was down, and the subscription does not replay, so a consumer built only on subscriptions has a silent gap after every network blip. The robust arrangement uses the subscription for latency and a polling reconciliation loop against a durable cursor for completeness, so the slow path repairs whatever the fast path missed.

Independence from a provider's limits, policies and pricing; the ability to answer queries a hosted plan restricts; and no third party observing which addresses your application cares about. What it costs is real operational work: fast storage that keeps growing, a client to upgrade before every network fork, monitoring for a node that is up but syncing behind the head, and an on-call rotation. The honest position for most teams is a hosted endpoint with a second provider and their own indexed database, moving to self-hosting when the request pattern or the privacy requirement makes it necessary.

An identifier derived from the bytes of the content, so anyone holding both can verify that the content is what the identifier names. That gives integrity independent of the source: fetching from an untrusted peer is safe because you check the result yourself. It also means the identifier is not a location, so the same file held by many parties has one name, and it means the content is immutable — change a byte and the identifier changes. What it does not guarantee is that anyone still holds the bytes. Verifiability and availability are separate properties, and only the first comes for free.

Pinning is telling a node to keep a piece of content rather than treating it as a discardable cache entry. It matters because most content-addressed networks are retrieval protocols, not durability guarantees: the content is available while somebody chooses to hold and serve it. If your pinning service lapses, the identifier stays valid forever and the data becomes unfetchable, which is a failure mode with no error message on the storage layer's side. Incentivised storage networks exist precisely to convert "somebody is being generous" into "somebody is paid until a date", which is a different assumption but still not an administered backup.

Because browsers do not speak these protocols natively, so applications fetch content through an HTTP gateway — and if that is one hosted gateway, you have reintroduced the single, rate-limited, blockable dependency the design was meant to remove. When it is slow your verifiable data is unavailable; when it is blocked, users conclude the asset is gone. The distinction worth being precise about is that content addressing makes the source replaceable rather than making delivery decentralised. Realising the benefit means several independent providers and a client that verifies the bytes it receives.

The rule is that state a contract must reason about goes on chain, and everything else goes where it is cheap.

data                              where                    why
--------------------------------  -----------------------  ----------------------------
balances, ownership, permissions  contract storage          the contract branches on it
what happened, for consumers      events                    logs are cheap, apps read them
large immutable files             content-addressed store   verifiable, too big for state
metadata that must not change      content identifier on chain  one slot proves the file
user profiles, search, history    your database             needs queries and mutation
personal data                     your database             erasure must be possible

The third and fourth rows are the pattern worth remembering: store the identifier on chain and the bytes off it, so the chain proves which file is authoritative without paying to hold it.

The last row is not a performance judgement. A right to erasure and a storage layer where deletion is not reliably achievable are in direct conflict, and encrypt-then-discard-the-key is a mitigation you should expect to defend rather than a settled answer.

You add a layer of indirection whose trust model you choose deliberately. A contract holding the current identifier gives you a mutable pointer with on-chain governance and an auditable history of changes. A naming layer within the storage network gives you a signed, updatable record. A database row is the cheapest and gives no guarantees to anyone but you. The point to make in an interview is that the pointer is now the thing that must be trustworthy: whoever can update it can change what users see, so the immutability of the content has not removed the trust question, only relocated it.

An indexer consumes events and state from the chain, transforms them into tables suited to the application's questions, and serves those. Every dApp needs one because a node is a poor query engine: it answers by identifier and by block, so "this user's transfers, filtered and paginated" is either many requests or impossible. An indexer converts a rate-limited external dependency into an internal store you can cache and scale. The requirement people underestimate is that it must handle reorganisations, which means recording the block hash with every derived row and being able to rewind.

Answer in terms of what problem the machinery is solving, then name the cost. Something like: many parties who do not trust each other need to agree on a single ordered history of transactions without appointing anyone to be in charge, so the system replicates the log everywhere, makes rewriting it expensive, and restricts programs to deterministic computation so every replica reaches the same state. Then say what that buys — verifiable, non-repudiable shared state — and what it costs, which is throughput, latency, and a permanent price per write. That framing shows judgement; the textbook definition shows recall.

A hierarchy, not a list of tricks. The strong answer says what gas is charging for, ranks storage writes far above computation, and works in order: remove the write entirely, then reduce the slots touched, then reduce the number of accesses, and only then consider byte-level techniques. It also names the cost of optimising, because assembly and packed layouts make a contract harder to audit and that trade is unfavourable on anything holding funds. A candidate reciting "use uint256, cache array length, use custom errors" without that ranking is repeating a blog post.

Describe the mechanism, not the drama, and be careful with the numbers. Say what the contract believed, which assumption turned out to be false, and what ordering or check would have prevented it — the interviewer is testing whether you can reason about a root cause, not whether you remember a headline figure. Where you are unsure of a detail, say so and describe the class instead. Confidently misstating how a well-documented incident worked is worse than not raising it, because in this field the interviewer usually knows the write-up better than you do.

Say so plainly and then be specific about what you have done: contracts written and tested locally, a testnet deployment, a fork of mainnet state used to reproduce an interaction, an indexer you built against a public contract. Those are real and they are checkable. What does not survive contact is implying production experience you do not have, because the follow-up questions are operational — how you handled a stuck nonce, what your upgrade process was, who held the keys — and the gap becomes obvious within two exchanges. Candidates are hired for judgement they can demonstrate.

Take it seriously, because the sceptic is often the hiring manager. Concede what is fair: most throughput is speculative, the user experience is difficult, and many deployed systems would be simpler and cheaper as a database. Then name the property that is genuinely hard to get elsewhere — verifiable shared state between parties who will not appoint a common operator — and give a case where that property is the requirement rather than a decoration. An engineer who can distinguish the technology from its marketing is more trustworthy on design decisions, and interviewers treat that as a signal.

This, or a close variant, is the question that separates candidates most reliably, because it is answered by method rather than recall.

function withdraw(uint256 amount) external {
    require(balances[msg.sender] >= amount);
    payable(msg.sender).call{value: amount}("");
    balances[msg.sender] -= amount;
}

A strong answer walks a fixed order. Authorisation: who may call this, and is msg.sender the right identity. State ordering: the balance is decremented after control has left, so a re-entrant call sees the old balance and drains the contract. Return values: the low-level call's result is discarded, so a failed send still decrements — or in this ordering, still returns as though it paid out. Arithmetic and bounds: the decrement is fine under checked arithmetic, but the require carries no message, which makes failures unreadable. External interactions: the recipient is arbitrary code, so gas and callbacks are its choice, not yours.

Then it proposes the fix and its invariant: move the decrement above the call, propagate the failure with a require on the result, add a non-re-entrant guard as a backstop, and state the property being preserved — accounting is consistent at every point where control can leave.

A weak answer identifies re-entrancy, names a guard modifier, and stops. It is not wrong, and it misses the discarded return value entirely, which is the second bug in three lines. What the interviewer is grading is whether you have a checklist you apply to unfamiliar code, because that is what reviewing a colleague's contract will require of you every week.