Skip to main content

What Is Blockchain?

Learning Objectives​

By the end of this lesson, you will be able to:

  • Define a blockchain as a technical system, not just a buzzword.
  • Identify the core components of a blockchain (blocks, state, consensus, network).
  • Explain the problems blockchain solves relative to traditional databases.
  • Connect blockchain concepts to real‑world systems practiced in the Flow Initiative.

Introduction​

Blockchain is often presented as magic money machine. In reality, it is a very specific engineering pattern for building shared, append‑only ledgers across many machines and people [web:140][web:157].

For Flow Initiative trainees, the goal is not to “believe in crypto” but to understand blockchain as a distributed systems primitive. You will eventually apply this to:

  • decentralized ledgers,
  • incentive‑driven infrastructure, and
  • public‑goods applications that redistribute control and value.

This lesson grounds “blockchain” in concrete components and assumptions, not marketing narratives.

A Minimal Definition​

A blockchain is a public, distributed, append‑only database where:

  • Data is grouped into blocks.
  • Each block cryptographically refers to its previous block.
  • A consensus mechanism decides which blocks are valid and accepted by the network [web:140][web:160].

Unlike a centralized database:

  • There is no single owner.
  • Anyone can verify the state by running their own node.
  • Once data is accepted, it is hard to change without coordinated effort.

Why “Blockchain” Exists​

Blockchains solve several related problems:

  • Trust minimization — you do not need to rely fully on a single party.
  • Censorship resistance — it is hard for any one player to block or erase data.
  • State transparency — everyone can see the same history of changes.
  • Programmable incentives — you can design reward and penalty rules for participants [web:154][web:157].

From an engineer’s perspective, what matters is:

  • what guarantees the system actually offers,
  • what assumptions it makes about the environment, and
  • what trade‑offs you accept by choosing it.

Core Components​

1. Blocks​

A block is a data structure that usually contains:

  • A list of transactions or state updates.
  • A reference (hash) to the previous block.
  • Metadata such as timestamp, fees, and validator info.

When blocks are chained together, you get a history of the ledger’s state.

2. State​

The state is the current representation of all balances, contracts, and rules defined on the chain.

Different blockchains organize state differently:

  • Account‑based (e.g., Ethereum),
  • UTXO‑based (e.g., Bitcoin).

Regardless of model, the state evolves deterministically from block to block.

3. Consensus​

Consensus is the process by which nodes agree on which blocks are valid. Without consensus, every node would maintain its own incompatible view of the state.

Common consensus families:

  • Proof‑of‑Work (PoW) — nodes prove computational work to propose blocks.
  • Proof‑of‑Stake (PoS) — nodes “stake” value as collateral to participate in validation [web:140][web:157].

Different consensus mechanisms make different assumptions about:

  • cost of attack,
  • liveness vs. safety, and
  • performance under network partitions.

4. Network​

A blockchain is a peer‑to‑peer network of nodes:

  • Some nodes propose blocks.
  • Some nodes validate and relay them.
  • Some nodes execute transactions and store state.

The network layer is responsible for:

  • message propagation,
  • fork handling, and
  • re‑synchronization after failures.

5. Cryptography​

Blockchains rely on standard cryptographic tools:

  • Cryptographic hashes — to link blocks and detect tampering.
  • Public‑key cryptography — to authenticate participants and sign messages.
  • Digital signatures — to prove origin and integrity of data [web:157][web:160].

These tools are not invented for blockchain; they are composed into a new pattern for trust‑minimized coordination.

How Blockchain Differs from a Regular Database​

Traditional Database​

  • Usually owned by one organization.
  • State is updated by a small, trusted set of administrators.
  • Replication is controlled by a single entity.
  • Failure modes are relatively simple: disk, network, operator.

Blockchain​

  • Ideally, no central owner.
  • State is updated by many participants under shared rules.
  • Replication is decentralized and competitive.
  • Failure modes involve Byzantine behavior, incentives, and forks.

From an engineer’s viewpoint, this means:

  • your code must reason about partial knowledge and competing histories.
  • your system must be resilient to misaligned or malicious actors.

Practical Examples Trainees Will Encounter​

As you move deeper into the Flow Initiative blockchain track, you will see variants of:

  • L1 blockchains — base‑layer ledgers with consensus and state, such as Ethereum‑style chains.
  • L2 networks — systems that scale and bundle transactions without sacrificing the security of the base layer.
  • Smart contracts — code stored on the chain that defines rules and state transitions [web:141][web:149].

Even at the beginner level, it helps to see these patterns:

  • A payment system where transactions must be ordered and irreversible.
  • A registry where identity or credentials are stored transparently.
  • A token economy where value accrues to participants based on agreed‑on rules.

Why This Matters for Flow Engineers​

Flow trainees work on African‑centric infrastructure, where:

  • single‑points of failure are dangerous,
  • trust in institutions can be low or contested, and
  • cost‑effective, open systems are often needed.

Blockchain is one pattern for:

  • building trust‑minimized payments and incentives,
  • creating shared, auditable data across organizations, and
  • enabling public‑goods infrastructure whose rules are encoded and transparent rather than hidden in closed systems [web:154][web:163].

Your job is not to treat blockchain as a universal solution. It is to understand when and why it fits a problem.

Key Takeaways​

  • A blockchain is a distributed, append‑only ledger with cryptographic links across blocks.
  • Consensus is the engine that makes this ledger coherent across many nodes.
  • State is the outcome of all accepted blocks.
  • The network and cryptography layers enforce the rules and detect attacks.

These are the pieces you will dissect in later lessons.

Practical Exercise​

Exercise 1: Sketch a Simple Blockchain​

On paper or in a text editor, sketch a tiny blockchain with 3 blocks:

  • Block 0 (genesis): contains an initial state.
  • Block 1: contains 2 transactions.
  • Block 2: contains 1 transaction and a nonce.

For each block, write:

  • a hash (e.g., 0x...),
  • a reference to the previous block hash, and
  • a short description of the state change.

This is a minimal mental model of how blocks fit together.

Exercise 2: Relate to Real‑World Systems​

Think of one real‑world system that reminds you of a blockchain (e.g., a shared ledger, a consensus‑driven process, a tamper‑resistant log). Write:

  • What it does.
  • How it is similar to a blockchain.
  • How it is different.

Self‑Assessment​

Rate yourself from 1 to 5:

  • I can explain what a blockchain is in one sentence.
  • I can list the main components (blocks, state, consensus, network).
  • I can explain how it differs from a traditional database.
  • I can see why this pattern might matter for public‑goods infrastructure.

Action item: write a 3‑sentence note in your Flow lab repo describing how a blockchain is like a “shared, append‑only log” with rules.

Next Steps​

  • Read 02-key-terms-and-models.md next to build precise language for blockchain work.
  • Use this conceptual model when you later encounter Ethereum‑style chains, L2s, or token‑based systems in the Flow curriculum.
  • Treat blockchain as a distributed systems primitive, not a miracle technology.

Video​

This lesson equips Flow Initiative trainees with a grounded, engineering‑style understanding of blockchain as a distributed, append‑only ledger driven by consensus and cryptography, preparing them for deeper work in the beginner, intermediate, and advanced tracks.