Blockchain Developer interview questions

A distributed ledger is a shared record whose replicas are maintained by multiple network participants under common update rules.

• Each participating node can hold and verify its own copy instead of relying on one database server.
• A consensus protocol decides which valid updates and ordering the network accepts when nodes disagree.
• Replication improves fault tolerance, but it adds communication cost and does not make every distributed database a blockchain.
• A blockchain is one type of distributed ledger that usually groups updates into hash-linked blocks.

The header contains compact metadata used to identify and validate the block, while the body contains the transactions or other records it carries.

• A header normally references the previous block hash, linking the block to its parent.
• It also commits to the body through a transaction root such as a Merkle root, so a changed transaction produces a different commitment.
• Consensus fields such as a timestamp, height, validator data, difficulty, or nonce depend on the chain.
• Nodes process the body to verify transactions and recompute the commitments recorded in the header.

Each block commits to its parent hash, so changing an older block breaks the hash links from that point forward.

• Even a one-bit change produces a different cryptographic hash with overwhelming probability.
• The next block still points to the original hash, making the edited history fail validation immediately.
• An attacker would need to rebuild the changed block and every descendant, then overcome the network's consensus rules.
• Hashes make tampering detectable; consensus and economic cost make an alternative history difficult to have accepted.

A public blockchain is generally open for anyone to inspect and join, while a private blockchain restricts participation to approved identities.

• Public networks such as Ethereum use permissionless validation and economic incentives because validators may not know or trust one another.
• Private networks such as Hyperledger Fabric can control who reads data, submits transactions, or validates updates.
• Permissioned membership can provide higher throughput and privacy, but it concentrates control among the participating organizations.

An account model updates balances and state attached to addresses, while a UTXO model consumes existing outputs and creates new ones.

• Ethereum accounts have fields such as balance and nonce, which transactions modify in a shared global state.
• In Bitcoin, an output is spent in full, so a payment commonly creates one output for the recipient and another for change.
• UTXOs are easy to validate independently and can support parallel processing when they do not spend the same outputs.
• Accounts make balances and smart-contract state easier to express, but transactions can contend on the same state.

A full node validates the chain's rules itself, while a light node verifies limited evidence and obtains most data from full nodes.

• A full node downloads blocks and checks transactions, signatures, and consensus rules before accepting state.
• A light client usually keeps block headers and can verify inclusion with a Merkle proof instead of downloading every transaction.
• Light clients need far less storage and bandwidth, which suits phones and browser wallets.
• Their security depends on the protocol and available proofs, and relying on one RPC provider adds trust and privacy risks.

Nodes relay new transactions and blocks to connected peers, which produces gossip-style propagation across the network.

• A wallet usually submits a signed transaction to one node, and that node performs basic validation before forwarding it.
• Peers track items they have already seen so duplicate announcements do not trigger endless rebroadcasting.
• A newly produced block follows the same peer relay process, with each receiving node validating it before acceptance.
• Network latency means nodes may briefly see different transaction orders or competing chain tips.

A mempool is a node's local collection of valid unconfirmed transactions waiting for possible inclusion in a block.

• A node checks signatures, nonces or spendable outputs, and fee rules before admitting a transaction.
• Nodes can have different mempools because they receive transactions at different times and apply different size or fee policies.
• Block producers usually favor higher-fee transactions, though protocol and builder policies can change the ordering.
• Mempool admission does not guarantee confirmation because a transaction can expire, be dropped, conflict, or be replaced.

A transaction has one confirmation when it enters a block, and finality describes how confident an application can be that this result will not be reversed.

• Each additional block built on top adds another confirmation and makes a proof-of-work reorganization less likely.
• Proof-of-work finality is probabilistic, so applications wait for more confirmations when the transferred value or risk is higher.
• Many proof-of-stake chains finalize checkpoints through validator votes, after which reversal requires a severe protocol violation and penalties.

A node accepts a block only after independently validating its parent, consensus data, transactions, and resulting commitments.

• The parent reference must identify a known valid block, and header fields must satisfy the chain's consensus rules.
• The node checks transaction signatures, nonces or spent outputs, balances, and other protocol conditions.
• It executes valid transactions in order and recomputes transaction, receipt, or state roots recorded in the header.

Consensus lets distributed nodes agree on one valid transaction history even when some nodes fail or lie.

• Nodes need the same ordering because two individually valid transactions may try to spend the same funds.
• A Byzantine fault means a participant can behave arbitrarily, including sending conflicting messages to different peers.
• This is harder than a simple crash, where the node only stops responding and cannot actively mislead others.
• A consensus protocol defines the fault threshold under which safety and progress still hold, often in terms of voting power rather than node count.

Proof of work makes miners search for a block hash below the network's current target.

• A miner repeatedly changes a nonce or other header data and hashes the candidate block until one result meets the target.
• Finding that result is expensive, but every node can verify it with one hash calculation and validate the block's transactions.
• Nodes follow the valid branch with the most accumulated work, not simply the branch with the most blocks.
• The network adjusts difficulty so blocks arrive near the intended interval as total hash rate changes.

Proof of stake ties participation in consensus to locked capital that the protocol can reward or penalize.

• Validators lock the native asset instead of competing through continuous hash calculations.
• The protocol selects proposers and counts validator votes according to its stake and randomness rules.
• Honest proposals and votes earn rewards, while missed duties can lose rewards or incur inactivity penalties.
• Provably conflicting votes can destroy stake, making attacks carry a direct economic cost.

A validator participates in consensus, while a selected proposer publishes a block and other validators attest to their view of the chain.

• A solo Ethereum validator deposits 32 ETH and runs software that performs assigned consensus duties.
• For each slot, one selected proposer assembles and broadcasts a candidate block.
• Other validators publish attestations that vote for a chain head and checkpoint links, and the protocol aggregates their stake weight.
• Missing a duty loses potential rewards, while signing conflicting messages can lead to slashing.

A fork creates competing valid branches, and the protocol's fork-choice rule selects one as canonical.

• A temporary fork can occur when different blocks are published close together and reach nodes in different orders.
• Nodes validate each branch before applying fork choice, so an invalid block cannot win merely by extending a branch.
• Proof-of-work chains commonly prefer the valid branch with the most accumulated work, while proof-of-stake chains use validator votes and protocol-specific rules.
• Blocks outside the selected branch are noncanonical, and their transactions may be included again if they remain valid.

A reorganization replaces recent canonical blocks when another valid branch wins the fork-choice rule.

• The node rolls back state changes from the removed blocks and applies the blocks from the winning branch.
• A transaction in a removed block can become pending again, disappear, or be included later in a different position.
• Applications should track block hashes and wait for suitable confirmations or finality before treating a payment as irreversible.

Probabilistic finality makes reversal less likely over time, while economic finality makes reversal require a punishable loss of stake.

• In proof of work, each additional block adds work on top of a transaction, so replacing its branch becomes progressively less probable and more costly.
• In proof of stake, a checkpoint can become finalized after the required stake votes for it under the protocol's rules.
• Reverting an economically finalized checkpoint would require validators to violate accountable rules and risk losing substantial stake.

Majority consensus power can manipulate chain selection, but it does not grant control over other users' keys or valid protocol rules.

• The attacker can censor transactions or selected addresses by refusing to include their transactions in blocks.
• The attacker can reorder their own transactions and attempt a double spend by replacing a branch containing an earlier payment.
• The attacker cannot forge another user's signature, spend that user's coins, or make honest nodes accept an invalid state transition.

Slashing destroys part of a validator's stake when cryptographic evidence proves a forbidden consensus action.

• In Ethereum, slashable actions include proposing two blocks for one slot and making conflicting or surround votes.
• The signed messages provide evidence that other nodes can verify without trusting the reporter.
• Slashing is different from a small inactivity penalty, which can apply when a validator is offline rather than dishonest.
• Penalties grow when many validators are slashed together, discouraging operators from sharing one failure-prone setup.

Blockchains resist Sybil attacks by tying consensus influence to a scarce resource rather than the number of identities.

• Creating thousands of key pairs is nearly free, so signatures alone cannot prove that those keys belong to independent participants.
• Proof of work weights influence by contributed computation, which requires hardware and energy.
• Proof of stake weights influence by locked stake, so splitting the same funds across many validators does not create extra total voting power.
• Permissioned networks can instead restrict membership through verified organizations, certificates, or an access-control process.