Module 2: How Blockchain Actually Works (At a High Level)

1. From Single Ledger to Shared Ledger

In Module 1, you learned to explain blockchain in plain English as a kind of shared digital ledger.

Now we go one layer deeper and answer:

• Who keeps this ledger?
• How do new transactions get added?
• Why can’t people just cheat and rewrite history?

Centralized vs. decentralized ledgers

• Centralized ledger (traditional)
• One main database (e.g., a bank’s server).
• The bank decides which transactions are valid.
• If the bank’s database is hacked or altered, the record can change.

• Decentralized ledger (blockchain)
• Many computers (called nodes) each keep a copy of the ledger.
• They use rules called a consensus mechanism to agree on which transactions are valid.
• No single party can unilaterally rewrite the ledger without others noticing.

Big picture of how a blockchain works

At a high level, most blockchains follow this pattern:

1. A user creates a transaction (e.g., sending a crypto token or updating a smart contract).
2. The transaction is broadcast to a peer‑to‑peer (P2P) network of nodes.
3. Nodes check if the transaction is valid according to the protocol rules.
4. Valid transactions are grouped into a block.
5. Nodes run a consensus mechanism (e.g., Proof of Work, Proof of Stake) to agree on which block to add next.
6. The chosen block is linked to the previous block using cryptographic hashes.
7. Every node updates its copy of the ledger.

The rest of this module unpacks those steps so you can explain them confidently to clients.

2. Peer‑to‑Peer Networks and Nodes

A peer‑to‑peer (P2P) network is a network where each computer (node) can communicate directly with others, rather than through a central server.

What is a node?

A node is any computer running the blockchain software and participating in the network. On many modern blockchains (e.g., Bitcoin, Ethereum, many Proof‑of‑Stake chains):

• Nodes keep a local copy of the blockchain.
• Nodes relay transactions and blocks to their peers.
• Some nodes also propose or validate new blocks (e.g., miners in Proof of Work, validators in Proof of Stake).

Visual description (mental picture)

Imagine a web of laptops and servers all around the world:

• Each device has an up‑to‑date copy of the ledger.
• When one device hears about a new transaction, it quickly tells its neighbors.
• Information spreads like ripples in a pond until almost every node has seen it.

Why P2P matters

• No single point of failure: If one node goes offline, the network still runs.
• Censorship resistance (especially on public chains): It’s much harder for one government or company to block all nodes.
• Data integrity: If a few nodes are compromised, the rest can reject invalid data.

This decentralized P2P structure is the foundation that consensus mechanisms build on.

3. Walkthrough: A Transaction’s Journey

Let’s follow a simple payment transaction on a public blockchain like Bitcoin or Ethereum (conceptually, not in all technical detail).

Scenario

Alice wants to send 1 token to Bob.

Step‑by‑step journey

1. Alice creates a transaction

• Using a wallet app, Alice enters Bob’s address and the amount.
• The wallet uses Alice’s private key to digitally sign the transaction.
• This signature proves the transaction came from Alice and hasn’t been tampered with.

1. Broadcast to the network

• The wallet sends the signed transaction to one node.
• That node checks it quickly (e.g., does Alice have enough balance?) and then forwards it to its peers.
• Within seconds, many nodes in the network have seen Alice’s transaction.

1. Validation by nodes

Each node independently checks, for example:

• Is the digital signature valid?
• Is Alice trying to spend the same funds twice (double‑spend)?
• Does the transaction follow the protocol rules (fees, format, etc.)?

1. Transaction enters the mempool

• Valid transactions are stored in a temporary area called the mempool (memory pool).
• Think of the mempool as a waiting room for transactions.

1. Block creation

• A miner (Proof of Work) or validator (Proof of Stake) selects a batch of transactions from the mempool.
• They build a candidate block containing:
• A list of transactions
• A reference (hash) to the previous block
• Other metadata required by the protocol

1. Consensus and block addition

• Through the consensus mechanism (PoW or PoS, explained in the next steps), one block is chosen as the next valid block.
• That block is appended to the chain.

1. Finalization/confirmations

• Once the block is accepted by the network, Alice’s payment appears in the ledger.
• As more blocks are added on top, the transaction becomes increasingly hard to reverse.

This journey is similar across many blockchains, even though the technical details (fees, timing, terminology) vary.

4. Proof of Work vs. Proof of Stake (Conceptual View)

The consensus mechanism is how nodes agree on the next valid block and protect the chain from attacks.

Today (early 2026), the two most discussed mechanisms in industry are:

• Proof of Work (PoW) – used by Bitcoin and some other chains.
• Proof of Stake (PoS) – used by Ethereum (since its 2022 merge) and many newer blockchains.

Proof of Work (PoW) – "security via computation"

• Who creates blocks?
• Miners compete to solve a difficult mathematical puzzle.
• How it works conceptually:

1. Miners take the candidate block’s data and repeatedly run it through a hash function with different random values (nonces).
2. They are trying to find a hash that meets the network’s difficulty target (e.g., starts with a certain number of zeros).
3. The first miner to find a valid hash broadcasts their block to the network.
4. Other nodes quickly verify that:

• The hash is correct.
• The transactions are valid.

1. If valid, nodes accept the block and extend the chain.

• Security intuition:
• Attacking the chain (e.g., rewriting history) would require enormous computing power and energy.

Proof of Stake (PoS) – "security via economic stake"

• Who creates blocks?
• Validators who have locked up ("staked") some of the blockchain’s native tokens.
• How it works conceptually (varies by protocol, but core idea is similar):

1. Validators deposit tokens as stake.
2. The protocol pseudo‑randomly selects a validator (or a small set) to propose the next block.
3. Other validators attest (vote) on whether the block is valid.
4. If the block is accepted, the proposer and honest validators receive rewards.
5. If a validator behaves maliciously (e.g., tries to double‑sign conflicting blocks), some of their stake can be slashed (destroyed).

• Security intuition:
• Attacking the chain would require owning and risking a large share of the total stake.

High‑level comparison (for client conversations)

• PoW
• Pros: Long track record (Bitcoin since 2009), very battle‑tested.
• Cons: High energy use; slower throughput in many PoW chains.

• PoS
• Pros: Much lower energy use; often higher throughput and more flexible designs.
• Cons: Newer; security assumptions depend on economic incentives and governance.

You do not need to explain the math to clients. Focus on the intuition: PoW secures the chain with computing power; PoS secures it with economic stake and penalties.

5. Thought Exercise: Choosing PoW or PoS for a Use Case

Imagine a client wants to launch a global payment network for small cross‑border transfers.

They ask: “Should we build it on a Proof of Work or Proof of Stake blockchain?”

Take 2–3 minutes and jot down answers to these questions:

1. Energy and sustainability

• How might the client’s brand be affected by using an energy‑intensive PoW chain vs. a more energy‑efficient PoS chain?

1. Security reputation

• Would the client value the long security track record of a major PoW chain (like Bitcoin), or the flexibility and programmability of a major PoS smart‑contract platform (like Ethereum today)?

1. Transaction speed and cost

• For frequent, low‑value transfers, what matters more: raw security, or lower fees and higher throughput?

1. Regulatory and ESG considerations (2020s context)

• Many institutional players now pay attention to ESG (Environmental, Social, Governance) metrics. How might that push them toward PoS‑based platforms?

After reflecting, summarize your recommendation in 2–3 sentences, as if you were emailing the client.

> Tip: There is no single "right" answer. The goal is to practice explaining trade‑offs in plain, business‑friendly language without getting lost in technical detail.

6. Immutability and Transparency: Why Tampering Is So Hard

Two of the most common client questions:

• “Can someone just change the data?”
• “How transparent is this really?”

Immutability ("hard to change")

Blockchains are often called immutable, but technically they are tamper‑resistant, not absolutely unchangeable.

Key ingredients:

1. Hashing and block linking

• Each block contains a hash of the previous block.
• If you change even one character in an earlier block, its hash changes.
• That breaks the link to all later blocks, making the tampering obvious.

1. Distributed copies

• Thousands of nodes (on major public chains) store the same history.
• An attacker would have to convince a majority of them to accept a modified version.

1. Consensus rules

• PoW: To rewrite history, an attacker needs to redo the PoW for the target block and all blocks after it, and outpace the honest miners.
• PoS: An attacker would need to control a large share of the stake and risk losing it through slashing.

Result:

• Changing confirmed transactions on a large, well‑secured public chain is economically and technically impractical.

Transparency

On public blockchains like Bitcoin and Ethereum:

• All confirmed transactions are publicly visible.
• Anyone can run a node or use a block explorer (e.g., Etherscan) to see:
• When a transaction happened
• Which addresses were involved
• How much value moved

Important nuance:

• Addresses are usually pseudonymous (not directly tied to a real‑world identity), but analysis techniques and regulations (e.g., KYC/AML requirements on exchanges) can often link activity to individuals or organizations.

When talking to clients, you can say:

> “Blockchains are designed so that once data is deeply embedded in the chain, changing it would be extremely expensive and obvious. And on public blockchains, anyone can independently verify the full history, which is why we call them transparent.”

7. Quick Check: Why Is the Chain Hard to Alter?

Test your understanding of immutability and transparency.

8. Public vs Private vs Permissioned Blockchains

In client conversations, confusion often arises around who can read and who can write data on different types of blockchains.

Public blockchains

• Who can read?
• Anyone (fully transparent ledger).
• Who can write/participate in consensus?
• Typically anyone who follows the protocol (e.g., runs a node, stakes tokens, or mines).
• Examples (as of 2026):
• Bitcoin (PoW), Ethereum (PoS), Solana, Polygon PoS, many others.
• Use cases:
• Public cryptocurrencies, DeFi, NFTs, global settlement layers.

Private blockchains

• Who can read?
• Only approved participants (e.g., within one company or a defined consortium).
• Who can write/participate in consensus?
• Also restricted to approved participants.
• Examples:
• Internal corporate ledgers, experimental systems built on frameworks like Hyperledger Fabric or Corda.
• Use cases:
• Internal audit trails, supply chain tracking inside a single organization, data sharing with strict confidentiality.

Permissioned blockchains (sometimes called permissioned networks or DLT platforms)

• Who can read?
• Varies: can be public‑read or restricted‑read.
• Who can write/participate in consensus?
• Restricted to a set of permissioned validators.
• Examples:
• Many enterprise and consortium networks (e.g., bank‑to‑bank settlement networks, trade finance platforms).
• Use cases:
• Multi‑institution collaboration where participants know each other but still want a shared, tamper‑resistant ledger.

How to explain this to clients

You can frame it as two separate questions:

1. Visibility: Who is allowed to see the data?

• Open (public) vs. restricted (private/consortium).

1. Control: Who is allowed to update the ledger and run consensus?

• Open participation vs. permissioned validators.

> In practice, many real‑world enterprise solutions today (2020s) use permissioned or consortium models, often built with enterprise frameworks, while still learning from the security and design patterns of public chains.

9. Classify These Scenarios: Public, Private, or Permissioned?

For each scenario, decide whether it best fits public, private, or permissioned blockchain. Write down your answers, then check with the suggested classification below.

1. Global NFT marketplace where anyone can mint, buy, or sell digital art.

• Likely classification: Public (needs openness, global reach, composability with other apps).

1. Internal audit log for a single bank’s compliance department, tracking who accessed which records.

• Likely classification: Private (only the bank’s internal teams need access; strong confidentiality).

1. Trade finance network where a group of banks, shipping companies, and insurers share documents and status updates on shipments.

• Likely classification: Permissioned/consortium (multiple known organizations; shared control, limited participants).

1. Central bank digital currency (CBDC) pilot where only regulated financial institutions can run validating nodes, but citizens can hold and use the currency.

• Likely classification: Permissioned validators with broader user access (a common design in current CBDC experiments).

Reflect: Which of these would you feel comfortable recommending a public chain for, and where would you argue for a permissioned or private approach due to regulation, privacy, or governance?

10. Key Term Review

Use these flashcards to reinforce the core concepts from this module.