How Blocks Are Built and Chained
Users broadcast transactions to the network. All nodes receive pending transactions and place them in a pool waiting to be included in the next block.
A node (miner or validator) selects transactions from the pool and bundles them into a new block, along with a timestamp and the hash of the previous block.
The node solving PoW (or selected by PoS) announces the new block. Other nodes verify the block's validity (transactions valid? hash correct? nonce works?) and add it to their chain.
All nodes update their copy of the ledger to include the new block. The block's hash is embedded in the next block to be created — extending the chain.
If anyone modifies a past block, its hash changes. This breaks all subsequent blocks' "previous hash" references — every node can immediately detect the inconsistency by comparing hashes.
Block Structure
| Field | Contents | Purpose |
|---|---|---|
| Previous Block Hash | SHA-256 hash of the prior block | Creates the cryptographic chain — links this block to all previous history |
| Timestamp | Time the block was created | Records when transactions occurred |
| Transaction Data | List of all transactions in this block | The actual record: who sent what to whom |
| Nonce | Number varied during mining (PoW) | The solution to the Proof of Work puzzle — proves computational effort was expended |
| Block Hash | SHA-256 of this block's entire contents | This block's unique fingerprint; embedded in the next block as "Previous Block Hash" |
Why Tampering with History Fails
Step 1: Attacker modifies Block 800
The attacker alters a transaction in Block 800 (e.g., changes "Alice pays Bob 1 BTC" to "Alice pays Attacker 1 BTC").
Block 800's hash is now different — its contents changed.
Step 2: Block 801 is now invalid
Block 801 contains the old hash of Block 800 as its "previous block hash." But Block 800's hash just changed. Block 801's "previous hash" field is wrong — it no longer matches the actual Block 800 hash.
Step 3: Cascade failure through all subsequent blocks
Block 801's hash must also be recomputed (its contents changed). This breaks Block 802. And Block 803. All the way to the current block (Block 1000+). The attacker must recompute every subsequent block.
Step 4: The race they cannot win
While the attacker is recomputing blocks 800–1000, the legitimate network has continued adding new blocks. The attacker's chain is now behind the legitimate chain. In PoW, the longest chain wins — the attacker's tampered chain is rejected.
Proof of Work vs. Proof of Stake
| Property | Proof of Work (PoW) | Proof of Stake (PoS) |
|---|---|---|
| How validators are selected | First to solve the computational puzzle (find a valid nonce) | Random selection weighted by amount staked |
| Cost to participate | Computing hardware + electricity (expensive) | Cryptocurrency stake (economic capital) |
| Attack cost | Must control >50% of network hash rate (massive hardware/electricity) | Must control >50% of staked cryptocurrency (massive economic stake — which would lose value if you attacked) |
| Energy efficiency | Very high energy consumption — by design (computational difficulty) | Much more energy-efficient — no competitive computation |
| Examples | Bitcoin | Ethereum (post-2022), Cardano |
Blockchain Applications
Cryptocurrency
Digital currency transactions recorded on a decentralized ledger. No bank or government controls the ledger. Bitcoin was the first — all participants can verify the complete transaction history back to the genesis block.
Supply Chain Tracking
Each step in a product's journey (manufacturer → distributor → retailer → customer) is recorded on a blockchain by each participant. The chain of custody is publicly auditable and tamper-evident — counterfeits and diversion are detectable.
Digital Identity
Credentials (degrees, licenses, certifications) stored on a blockchain and cryptographically tied to the holder's identity. Owner controls their own credentials — no central database to breach or corrupt. Third parties can verify credentials without contacting the issuing institution.
Smart Contracts
Self-executing code deployed to the blockchain. Terms are written in code; conditions trigger automatic execution. No intermediary needed — the network enforces the contract. Transparent and auditable by all participants.
Voting Systems
Votes recorded as blockchain transactions. Publicly auditable — any observer can verify the count. Tamper-evident — changing a vote would require breaking the chain. Voter identity kept private through cryptographic techniques while vote integrity is public.
Healthcare Records
Patient records shared across providers on a blockchain. No single provider owns the data. Patients control access. Audit trail of every access is tamper-evident. Eliminates data silos while maintaining integrity and controlled access.