A minimal Python blockchain can be represented as an ordered list of blocks, with each block storing a hash-based reference to its predecessor. For Python learners, this model illustrates how linked records can be checked for inconsistencies; it does not establish network agreement, validate payments, or provide a production payment system.

What this simple Python blockchain demonstrates

This walkthrough uses “blockchain” narrowly to mean the particular data structure in the example: blocks arranged in order and connected through hash values. It is not a general account of blockchain architecture. The goal is to follow how a program can represent a record, calculate an identifier from selected fields, and refer from a new block to the preceding one.

A Python program can hold the blocks in a list and check whether their stored references match their neighbors. That can make certain accidental or uncoordinated edits apparent when a checker recalculates the hashes. It does not show that independent computers keep matching copies or agree on which version to accept. Those are properties of a specific network design, not consequences of using a list and hash function.

The example below is deliberately small and in-memory. It does not connect peers, define who may add records, or handle payment instructions. It is a learning aid for understanding representation and linkage, not a template for deployment or a claim that this program was tested, audited, or used in a transaction.

Represent a block and connect it to its predecessor

For this example, a block contains three pieces of information:

  • record: the sample content stored in the block;
  • timestamp: a value recorded when the example creates the block; and
  • previous_hash: the stored identifier for the preceding block.

The program also stores a hash calculated from the selected fields. A hash is a computed digest of input data. The precise inputs and representation are choices in this example; they are not a universal block format. The Python standard library’s hashlib module provides interfaces to named cryptographic hash algorithms that accept bytes and produce fixed-length digest values.

The first block has no earlier block to reference. The example therefore assigns it a defined starting value, such as the string "0", as its previous_hash. This is just a convenient initial condition for the toy chain. It is not a claim that all real networks use this convention.

For subsequent blocks, the program copies the preceding block’s stored hash into the new block’s previous_hash. That creates a chain of references. Ethereum, as one network-specific example, has blocks that cryptographically reference their parent blocks, forming an ordered chain of network state. This illustrates a protocol’s block structure; it does not mean the small Python model inherits Ethereum’s behavior or security properties. (source )

Build and inspect the chain in Python

The illustrative code shows one way to express the idea. The hash function encodes a dictionary containing the record, timestamp, and previous hash, then calculates a SHA-256 digest. The chain starts with a block whose predecessor reference is "0"; adding a record appends a block that refers to the current final block.

import hashlib
import json
import time


def hash_block(record, timestamp, previous_hash):
    """Calculate a digest from the fields selected for this example."""
    contents = {
        "record": record,
        "timestamp": timestamp,
        "previous_hash": previous_hash,
    }
    encoded = json.dumps(contents, sort_keys=True).encode("utf-8")
    return hashlib.sha256(encoded).hexdigest()


class Block:
    def __init__(self, record, previous_hash):
        self.record = record
        self.timestamp = time.time()
        self.previous_hash = previous_hash
        self.hash = hash_block(
            self.record, self.timestamp, self.previous_hash
        )


class SimpleChain:
    def __init__(self):
        self.blocks = [Block("Starting block", "0")]

    def add_record(self, record):
        previous = self.blocks[-1]
        self.blocks.append(Block(record, previous.hash))

    def links_match(self):
        for index in range(1, len(self.blocks)):
            current = self.blocks[index]
            earlier = self.blocks[index - 1]

            if current.previous_hash != earlier.hash:
                return False

            expected = hash_block(
                current.record,
                current.timestamp,
                current.previous_hash,
            )
            if current.hash != expected:
                return False

        return True

Read the code as a sequence of operations, not as a full blockchain protocol. Block gathers the example’s chosen fields and calculates the block’s stored hash. SimpleChain keeps blocks in a Python list. Its add_record method takes the hash from the final block and uses it as the predecessor reference for the next block. The links_match method walks through the list from the second block onward and checks that each reference points to the preceding block’s stored hash.

The same check recalculates each later block’s hash from its current fields and compares the result with the saved value. If the record or predecessor reference changes but the stored hash does not, that comparison can reveal the mismatch. If the earlier block changes, a later block can also fail the predecessor-reference check because it still points to the old hash.

These checks describe only the represented data. They do not establish that a record is true, that an authorized person supplied it, or that another computer has an identical copy. The timestamp is also just a value included in this example’s hash inputs; the code does not establish an authoritative time source.

A simple blockchain in Python can therefore be a useful exercise in building an object, computing an identifier, and linking records. The field selection, serialization, first-block convention, and validation method are all local teaching choices. A different example could represent the data differently without changing the narrow concept being demonstrated.

The links_match method can detect some inconsistencies by comparing stored values with freshly calculated ones. That capability is not the same as preventing changes. In this example, all blocks are kept in one editable list. Someone able to rewrite the list could change an earlier record, recalculate its hash, and update the references in later blocks. The program has no separate participant or shared decision process that establishes which rewritten version should count.

Bitcoin provides a protocol-specific contrast. Its original design uses hashes to link blocks and hash-based proof of work to order history; replacing accepted history requires renewed computational work. Bitcoin nodes also enforce transaction and block-validity rules, and proof of work does not make an invalid block valid. These mechanisms are not included in the Python example and should not be inferred from its use of hashes. (source )

Keep three questions separate when inspecting this model:

  • Do the links match? The program checks whether its selected fields, saved hashes, and predecessor references are internally consistent.
  • Is a proposed operation valid? The example has no transaction rules that determine whether a payment instruction is authorized or acceptable.
  • Which history do participants accept? The example has no process for independent participants to resolve competing records or agree on a shared state.

Only the first question is addressed, and only for the current in-memory representation. A matching result is not proof of distributed agreement, record authenticity, or payment correctness.

Why the example is not payment infrastructure

The code omits the systems needed to assess an actual payment network. It has no peer communication, consensus process, or transaction-validation rules. It does not manage keys, define recovery procedures, or provide monitoring. Adding a hash field cannot establish those missing functions.

A blockchain application stack can include nodes and smart contracts alongside client libraries, wallets, front-end interfaces, data indexing, storage, and other off-chain services. The sample implements none of those surrounding components. Even this broad list describes possible parts of an application stack, not a requirement that every system use every component. (source )

A production payment system would require a separate technical assessment of its network, transaction flow, confirmation expectations, capacity, fee behavior, application integration, dependencies, and operational requirements. The small program provides no evidence about those matters, and this article makes no claim about compliance, security, fees, or suitability for real funds.

Use this limitations checklist to keep the demonstration in bounds:

  • The blocks exist only in one program’s memory; the code does not exchange or reconcile them with network peers.
  • Hashes link the selected fields, and checks can expose mismatches; the model does not prevent an editor from rewriting and recalculating the chain.
  • No consensus rule chooses an accepted history.
  • No transaction policy checks payment instructions or determines who can submit them.
  • The program includes no key-management, recovery, monitoring, or deployment process.
  • Nothing in the example establishes that it is secure, compliant, or suitable for real payments.

The useful takeaway is limited: a simple Python blockchain can model blocks that refer to earlier blocks by hash and demonstrate how a checker can find certain inconsistencies. That is a data-structure lesson, not a demonstration of a decentralized payment network.

Sources and references