Blockchain Basics: How Decentralized Ledgers Work

1. From Traditional Ledgers to Blockchains

In earlier modules you saw why we care about decentralized systems. Here we focus on how blockchains actually work.

1.1 Traditional ledgers

A ledger is just a record of who owns what and which transactions happened.

• Paper ledger / bank database: One central authority (a bank, a company, a government) controls the ledger.
• You must trust that authority to:
• Record transactions correctly
• Not secretly change past records
• Stay online and secure

1.2 The blockchain idea (high level)

A blockchain is a special kind of distributed ledger where:

• Many computers (called nodes) keep identical copies of the ledger.
• Transactions are grouped into blocks.
• Each block is cryptographically linked to the previous one.
• Everyone can verify the history, instead of trusting a single authority.

Think of it as a shared Google Sheet that:

• Everyone can view (and often propose edits),
• Is locked so you cannot edit old rows, only add new ones,
• Has built‑in math proofs (hashes) that reveal any tampering.

We will unpack the technical pieces behind this idea so you can see why it works.

2. What Exactly Is a Blockchain?

2.1 Core definition

A blockchain is:

> A distributed, append-only ledger made of ordered blocks of transactions, where each block contains a cryptographic hash of the previous block.

Key properties:

• Distributed: Many nodes have a copy.
• Append-only: You can add new data, but not delete/overwrite old data (in normal operation).
• Ordered blocks: Transactions are batched into blocks, arranged in a chain.
• Cryptographic linkage: Each block points securely to the previous one.

2.2 Basic components

At a minimum, a blockchain system has:

• Transactions – individual actions (e.g., Alice sends 1 BTC to Bob).
• Blocks – containers that hold many transactions plus metadata.
• Nodes – computers running the blockchain software.
• Network protocol – rules for how nodes talk, share blocks, and agree on the state.
• Consensus mechanism – how nodes agree on which blocks are valid and in what order (e.g., Proof of Work, Proof of Stake).

In this module we focus on the ledger structure (blocks, hashes, immutability). Consensus is covered more deeply in typical follow‑up modules on consensus and security.

3. Inside a Transaction and a Block

3.1 What does a transaction look like?

Concrete example (Bitcoin-style transaction, simplified):

• Inputs: Where the coins are coming from (previous outputs).
• Outputs: Where the coins are going to (new owners' addresses).
• Amount: How much value is moved.
• Digital signature: Cryptographic proof that the owner of the private key authorized this transaction.

In Ethereum-style systems, a transaction might also include:

• To: Address of a smart contract or user.
• Data: Instructions for a smart contract (e.g., call function `transfer()`).
• Gas limit / gas price: How much computation you are willing to pay for.

3.2 What does a block contain?

A typical block has (simplified):

• Block header (metadata):
• `previousblockhash` – hash of the last block in the chain
• `merkle_root` – combined hash of all transactions in this block
• `timestamp` – when the block was created (approximate)
• `nonce` and/or other consensus-related fields
• Block body:
• A list/array of transactions

3.3 Visual mental model

Imagine a file folder:

• The front page (header) says:
• "This folder follows folder with ID: `previousblockhash`"
• "Inside, the documents combine to ID: `merkle_root`"
• Inside the folder are all the signed transaction documents.

Every new folder references the ID of the previous one, forming a chain of folders.

4. Hashing: The Glue That Links Blocks

4.1 What is a cryptographic hash?

A cryptographic hash function (like SHA-256 or Keccak-256) takes any input data and outputs a fixed-length "fingerprint" (hash).

Properties (for secure hash functions):

• Deterministic: Same input → same output.
• Preimage resistance: Given a hash, it's infeasible to find an input that produces it.
• Second preimage resistance: Given one input, it's infeasible to find a different input with the same hash.
• Collision resistance: It's infeasible to find any two different inputs with the same hash.
• Avalanche effect: Tiny change in input → completely different output.

4.2 How hashes link blocks

Each block header includes `previousblockhash`. This value is:

• The hash of the entire previous block header (and indirectly, its transactions).

So:

• If you change anything in an old block (even 1 bit),
• Its hash changes,
• Which breaks the `previousblockhash` in the next block,
• Which breaks the link in all later blocks.

This chain of hashes makes the ledger tamper-evident: Any alteration of history is immediately detectable by honest nodes.

5. Try Hashing a Block Header (Conceptual Demo)

You don't need to be a programmer to follow this. The idea is to see how a small change in data completely changes the hash.

Run this Python code (e.g., in a notebook or online Python environment):

6. Thought Exercise: Why Is the Chain Hard to Rewrite?

Reflect on these questions (write down your answers briefly):

1. Suppose an attacker wants to change a transaction in block #100 in a long chain of 5,000 blocks.

• What happens to the hash of block #100?
• What happens to the `previousblockhash` stored in block #101?
• How many blocks would the attacker need to re‑hash (and re‑validate) to make the chain look consistent?

1. In a public blockchain using Proof of Work (like Bitcoin), re‑hashing many blocks means redoing a huge amount of computation.

• Why does this make rewriting history economically and computationally expensive?

1. In a Proof of Stake system (like Ethereum since its 2022 merge to PoS), changing history would require controlling a large share of staked tokens.

• Why does this create a strong economic disincentive to attack the chain?

After you think it through, summarize in one sentence:

> What makes a blockchain ledger practically immutable?

(Hint: It is a combination of hash-linked structure + consensus mechanism + economic costs.)

7. Immutability and Transparency in Practice

7.1 Immutability (with nuance)

We often say blockchains are immutable, but more precisely they are:

• Append-only and tamper-evident.

In practice, on major public chains (Bitcoin, Ethereum):

• Rewriting deep history is so expensive and risky that it is treated as practically impossible.
• Very recent blocks can sometimes be reorganized ("reorgs"), but protocols are designed to make deep reorgs extremely unlikely.

7.2 Transparency

On public blockchains:

• Anyone can run a node or use a block explorer (e.g., Etherscan, Blockchain.com) to see:
• All transactions and blocks
• Current balances of addresses (pseudonymous, not real names)
• This creates auditability: independent parties can verify:
• Total supply
• That no coins were created from nothing (beyond what the protocol allows)
• That smart contracts executed as coded

7.3 Why this enables "trustless" transactions

"Trustless" does not mean "no trust at all". It means:

• You do not have to trust any single central intermediary.
• You do rely on:
• Open-source protocol rules
• Cryptography
• Economic incentives
• A large, diverse set of nodes

You can independently verify:

• That a transaction is valid
• That it is included in a block
• That the block is part of the canonical chain

This is the core reason blockchains support peer-to-peer digital money and assets without a central operator.

8. Public vs Private Blockchains

As of early 2026, both public and private/permissioned blockchains are widely used, but for different purposes.

8.1 Public blockchains

Examples:

• Bitcoin, Ethereum, many Layer‑1 and Layer‑2 networks.

Characteristics:

• Open participation: Anyone can run a node, submit transactions, and (often) help validate blocks.
• High transparency: Ledger is publicly visible.
• Strong decentralization (varies by network): Many independent validators/miners.
• Native tokens: E.g., BTC, ETH, used for fees and incentives.

Typical use cases:

• Cryptocurrencies and digital cash
• Public DeFi (decentralized finance)
• NFTs and digital collectibles
• Public smart contracts (e.g., DAOs, open protocols)

8.2 Private / permissioned blockchains

Examples (frameworks):

• Hyperledger Fabric, R3 Corda, Quorum/ConsenSys Quorum.

Characteristics:

• Restricted participation: Only approved entities can run nodes and validate.
• Access control: Data may be visible only to certain members.
• Governance by a consortium or single organization.
• Often use different consensus (e.g., Practical Byzantine Fault Tolerance variants) optimized for speed and throughput.

Typical use cases:

• Inter-bank settlement within a consortium
• Supply chain tracking among known companies
• Enterprise record-keeping where auditability matters but full public transparency is not acceptable

8.3 Hybrid approaches

Real-world systems increasingly use hybrid models:

• A private chain for sensitive business data
• Periodic checkpoints or proofs anchored to a public chain (like Ethereum or Bitcoin) for public verifiability.

When you evaluate a blockchain project, always ask:

> Who is allowed to read, write, and validate data, and what are the trade‑offs in decentralization, privacy, and performance?

9. Quick Check: Public vs Private

Answer this question to test your understanding of public vs private blockchains.

10. Map Use Cases to Blockchain Types

For each scenario below, decide whether a public or private blockchain (or a hybrid) is more appropriate, and explain why in 1–2 sentences.

1. Global digital currency used by anyone with internet access.
2. Internal supply chain tracking among 10 large companies that already have legal contracts with each other.
3. Decentralized lending protocol where users around the world can lend and borrow crypto assets without a bank.
4. University credential verification where employers can check degrees but students’ detailed records must stay private.

After you decide:

• Compare your reasoning to these hints:
• Does the scenario require open participation and censorship resistance? → likely public.
• Are all participants known organizations with legal agreements? → likely private/permissioned.
• Is there a need for public verifiability plus data privacy? → likely hybrid.

11. Review Key Terms

Flip these cards (mentally or using your study tool) to reinforce core concepts.