A block is the most basic building unit of a blockchain — you can picture it as one page in a public ledger. Each block mainly holds three things: a batch of transaction records packed into it, a timestamp recording when it was produced, and a fingerprint pointing to the previous block — namely the previous block's hash. Precisely because each block records the fingerprint of the one before it, blocks link one after another, head-to-tail, forming an ordered, interlocking chain — which is where the name blockchain comes from. Understanding the block is the first step to understanding how the whole blockchain works and why it's hard to tamper with.
Why package transactions into discrete blocks rather than recording them one by one? Two main reasons. First, efficiency: bundling a large batch of transactions over a period into one block, then confirming and broadcasting it to the whole network at once, is far more efficient than handling each transaction separately. Second, and more crucial, security: each block embeds the previous block's hash fingerprint, cryptographically linking all blocks into a chain that can't be easily unpicked. The moment someone tries to alter a transaction in an old block, that block's hash changes, so every later block's recorded previous-block fingerprint no longer matches, and the tampering is instantly caught by the whole network. This block design is the very foundation of the blockchain's tamper-resistance.
How are blocks produced, and how often? This is decided by each chain's Consensus Mechanism. Nodes on the network collect not-yet-recorded transactions, and a bookkeeper chosen by the consensus mechanism (a miner or validator) packs them into a new block, attaches the previous block's hash and a timestamp, then broadcasts it for the whole network to verify and append to the chain's end. Block times differ greatly across chains: Bitcoin produces a block roughly every ten minutes, while some chains take only seconds. For users, this explains a common phenomenon — why your transaction isn't completed instantly after you send it, but must wait to be packed into some block, and even wait a few more blocks of confirmation, before it's truly settled.
Understanding the block helps you grasp two practical things. First, what confirmations are: when your transaction is packed into a block, that's one confirmation; each additional block appended afterward adds another. The more confirmations, the lower the chance the transaction is reversed — which is why exchanges require waiting several block confirmations before crediting a large deposit. Second, block time shapes your experience: on a chain with slower block times, when the network is congested, your transaction may wait longer to be packed. So next time your wallet shows pending confirmation, you'll know it's waiting to be placed into the next block and accumulate enough confirmations, not stuck or broken.
Understand it with a concrete scenario. Suppose the blockchain is a public ledger everyone can see, and a block is each page of records in that ledger. Page 100 (a block) is filled with the transactions that happened over a period, such as A sends B two coins, C sends D half a coin, and so on. At the top of page 100, the bookkeeper first copies down the fingerprint (hash) of page 99. Then page 101 copies down page 100's fingerprint at its top, each page hooking onto the last.
Now suppose a bad actor wants to alter a transaction on page 50, changing A sends B into A sends the bad actor himself. Here's the problem: the moment he changes page 50's content, page 50's fingerprint changes; but page 51's top still copies the old page-50 fingerprint, the two no longer match, and the chain breaks. To make the lie hold, he must recompute and rewrite the fingerprints of every page after 50, and finish before the whole network keeps producing new pages — on a sufficiently decentralized chain, this is practically impossible. This is how the design of blocks hooking page onto page makes the ledger extremely hard to tamper with.
The block's design hides a core trade-off: block size and block time can't simultaneously maximize capacity, speed, and decentralization. Making blocks bigger and block times faster fits in more transactions and confirms faster, but raises the hardware bar for running a node, potentially shrinking the set of nodes that can participate and sacrificing decentralization; conversely, keeping blocks and block times conservative (like Bitcoin's ten-minute block) preserves the broadest decentralization and security, at the cost of low throughput, slow confirmation, and high fees when congested. How each chain sets its block parameters reflects where it chooses to stand on this triangle.