Blockchain Basics: Blocks, Hashes & Indexing a Chain

Block structure. A block holds a batch of transactions plus a header: the previous block's hash, a timestamp, and a Merkle root summarising its transactions. The block's own hash covers all of that, so each block 'commits' to the entire history behind it.

Merkle tree. Hash the transactions in pairs, then hash the hashes, until one root remains. To prove a transaction is in a block, you give the transaction plus about log2(n) sibling hashes, not the whole block. This is how light clients verify payments cheaply.

Consensus in one paragraph. Many independent nodes must agree on which block comes next. Proof-of-work makes proposing a block expensive; proof-of-stake makes cheating cost the proposer's deposit. Either way the chain can briefly fork, and the rule is 'follow the longest/heaviest chain', so recent blocks can be replaced.

Finality and reorgs. A transaction in the newest block may disappear in a reorg. Explorers show confirmations (blocks built on top) and treat data near the tip as provisional. A robust indexer stores the block hash with every row so it can detect a reorg and roll back to the common ancestor.

Why an explorer needs its own database. A node answers 'give me block N' or 'transaction by hash' quickly, but not 'all transactions for this address' or 'top token holders' - the chain stores data in order of arrival, not in the shape queries need. So an indexer reads blocks, decodes them, and writes them into SQL/search tables indexed by address, token and time.

Indexer design. Run your own nodes (do not depend on one provider); a pipeline reads new blocks, a decoder turns raw logs into events, and a loader writes to the database in order. Make each block's processing idempotent and track the last processed height so a crash resumes cleanly. Backfilling history runs in parallel by block range; the live tip runs in order.

Read path. Explorer traffic is read-heavy and spiky (a hyped token drops). Cache finalized blocks forever - they never change - and give the unconfirmed tip a short TTL. Search by hash, address and block number needs the right index on each.

What the chain is not. It is a poor general database: low throughput, high latency, expensive writes, public data. Design on the principle 'only put on chain what needs shared trust'.