Imagine a concert ticket that Alice can transfer to Bob. The difficult question is not how to send Bob a picture of the ticket. It is how everyone agrees that Alice no longer controls it, Bob now does, and Alice cannot transfer the same right to Carol.
A blockchain is one way to coordinate this shared state across participants. Understanding that problem is more useful than memorizing cryptocurrency names.
This guide explains the building blocks, connects them to a current enterprise trend—tokenization—and provides a small Python lab with 28 automated tests, a UML model and a BPMN process. You need no wallet, cryptocurrency, API key or paid service.
1. Why blockchain matters in 2026
For Homann Software’s Learning Hub, the relevant angle is practical software engineering: state, authorization, integration and verification. Our editorial choice for the leading beginner topic is tokenization, because it connects blockchain concepts to a concrete business question: which rights can software record and transfer?
This choice is not a claim that tokenization leads every market metric. Three current developments make it a useful learning path:
| Development | Current evidence | What a beginner should learn |
|---|---|---|
| Tokenized financial infrastructure | The Eurosystem launched Pontes on 21 September 2026 to connect tokenized wholesale asset transactions with settlement in central bank money. | Asset records and payment settlement are distinct parts of a system. |
| Scaling and usability | Ethereum’s roadmap includes capacity, transaction-cost and user-experience improvements; its scaling documentation describes rollups. | Networks have different execution, cost and trust assumptions. |
| Security engineering | Ethereum’s security roadmap covers work on resilience and post-quantum security. | Security is maintained through evolving protocols and operations. |
Pontes is a wholesale financial-market initiative. It does not mean every company needs a public blockchain, and it is distinct from a retail digital euro. The launch offers a concrete signal of institutional engineering activity rather than a prediction about token prices. See the ECB launch announcement and the Pontes overview.
Ethereum’s roadmap is explicitly subject to change. Treat planned upgrades as plans; do not infer that a named upgrade is live from its target quarter. Its scaling documentation and security roadmap explain the broader directions. Research checked on 9 November 2026.
2. The building blocks, in plain English
A ledger is a record of events or balances. A distributed ledger has copies maintained across multiple computers. A blockchain structures its history as linked blocks. Different networks make different choices about participation, ordering and finality; “blockchain” is a family of designs.
| Term | Meaning | Ticket example |
|---|---|---|
| State | The current result of accepted operations | Bob owns ticket-001. |
| Transaction | A request to change state | Alice requests a transfer to Bob. |
| Block | An ordered container of transactions and associated data | A batch containing that request. |
| Hash | A fixed-length digest computed from data | A fingerprint of a block’s contents. |
| Node | A computer running network software | A participant checking the history. |
| Consensus | Rules for agreeing on the accepted history | Which valid transfer is ordered first? |
| Smart contract | Code and state executed under a blockchain’s rules | Transfer only if the sender controls the ticket. |
Hashes, signatures and consensus solve different problems. A hash helps detect changed data relative to a known reference. A signature establishes that a request was authorized with a particular key. Consensus coordinates the accepted history among participants under a network’s assumptions.
A hash is not encryption: hashing a message does not make its contents secret. A signature does not prove that a statement about the physical world is true. Agreement among nodes does not fix a faulty business rule.
In a chain, a later block refers to an earlier block’s hash. Change the earlier contents and the stored references no longer match. Ethereum’s block documentation describes this parent relationship. Our lab uses a much simpler structure with one transfer per block, no Merkle trees and no real network protocol.
A wallet is the application through which a user interacts with accounts. The assets are represented in ledger state; they are not files physically stored inside the wallet. Ethereum distinguishes externally owned accounts from contract accounts, whose control rules differ. See Ethereum accounts.
3. What happens to a transaction?
Consider an Ethereum-style transfer at a high level:
- The user reviews an action in a wallet and authorizes it.
- The signed transaction is submitted through a node interface.
- Network participants check protocol validity, and the transaction may be included in a block.
- Execution applies the relevant rules to the ordered state. A contract call can revert even when its transaction is included; fees may still be charged.
- Other nodes verify the proposed result. Applications track inclusion and the network’s finality conditions before treating the result as settled.
Submission can fail, remain pending or be replaced. A transaction hash is therefore not a receipt proving successful business execution. Applications must inspect execution results. Ethereum’s transaction documentation explains signed transactions and their lifecycle.
On Ethereum, proof of stake uses validators and staked ETH. Its finality rules differ from Bitcoin’s proof-of-work confirmation model. Finality is a network-specific security property, not a promise that every infrastructure component can never fail. See Ethereum proof of stake.
A Layer 2 network adds another set of operational considerations. Rollups execute outside Ethereum’s base execution layer and submit data or commitments to it. Designs differ in proof mechanisms, upgrade controls and withdrawal conditions. “On Ethereum” is not enough information to assess an application’s trust model. See scaling.
4. What a token actually represents
Tokenization means representing an asset or right as a digital token. The interesting part is the relationship between that record and the thing it represents.
For the ticket lesson, the token is a unique identifier and an owner entry. The operator still has to decide whether that entry grants admission, how a scanner verifies it, and what happens after cancellation. For a physical asset, someone must maintain the connection between the digital record and the real item. Creating a token does not establish that connection by itself.
Native cryptocurrency, stablecoins and tokenized assets also serve different purposes. A native currency belongs to a blockchain’s protocol economics; a stablecoin seeks a reference value; a tokenized asset represents a defined asset or claim. Their names alone do not establish equivalent rights, backing or risk. This guide models a fictional ticket right, with no money or investment product.
A smart contract can enforce a rule over data it can access. It cannot independently observe whether a parcel arrived or whether an offchain document is authentic. External observations require a data source and an integration mechanism, commonly called an oracle. The source can be wrong or unavailable. See smart contracts and oracles.
This boundary is a valuable engineering lesson: the ledger can make an agreed state transition reproducible while the surrounding system remains responsible for identity, evidence and service delivery.
5. Should you use blockchain or a database?
For a ticket service operated by one trusted company, a conventional database is a strong starting point. Transactions, constraints, audit records and backups can address many requirements with less operational complexity.
Blockchain becomes a candidate when several independently governed participants need shared state, independent verification matters, and they cannot simply appoint one trusted database operator. Even then, the participants need rules for membership, upgrades, incidents and disputes.
| Question | Favors a conventional database | Makes a shared ledger worth investigating |
|---|---|---|
| Who controls writes? | One accountable operator | Several independent organizations |
| Who verifies results? | Users accept the operator’s records | Participants need independent verification |
| How do corrections work? | Administrative updates are acceptable | Historical changes need shared rules |
| What is sensitive? | Confidential records dominate | Shared state can be minimized and separated |
| What is the operating budget? | Low latency and simple operations dominate | Coordination benefits justify extra complexity |
This table is a design heuristic, not a product-selection benchmark. Public permissionless networks and permissioned consortium ledgers have different governance and participation models. A replicated database does not become a blockchain merely because multiple servers store it.
6. Run the beginner lab
Download the complete Blockchain Beginners Lab. It includes the implementation, demo, tests, README and editable diagrams.
Use Python 3.10 or newer. The package uses only the standard library. Extract the ZIP, open a terminal in its examples directory and run:
python demo.py
python -m unittest -v test_ledger
On systems where the command is named python3, substitute python3. Verification here ran on Python 3.13.14; we did not execute every supported Python version.
The demo prints:
Owner: bob
Valid history: True
Rejected: Sender is not the current owner
After tampering: False
Rewritten history, local check: True
Rewritten history, trusted tip: False
The model implements a hash-linked history and an ownership state machine in one process. It does not implement a blockchain network, mining, validators, wallet signatures, fees, persistence or concurrent requests. The names alice and bob are trusted test inputs: anyone running the program can supply them. Owner checking is a business rule, not caller authentication.
7. Read the code one concept at a time
The complete implementation is in ledger.py. Start with a request: an asset identifier, sender, recipient and nonce.
@dataclass(frozen=True)
class Transfer:
asset: str
sender: str
recipient: str
nonce: int
The nonce is a sender-specific counter. Alice’s first accepted request uses zero, then one, then two. It prevents replay of an old request after an asset returns to her in this model. It is not a password or proof of identity.
The transition function first validates the identifiers, owner and expected nonce. It returns new dictionaries only after all checks succeed. Our lesson deliberately rejects self-transfers; this is a teaching rule, not a universal blockchain rule.
def transition(owners, nonces, tx):
for value in (tx.asset, tx.sender, tx.recipient):
if type(value) is not str or not value or value != value.strip():
raise ValueError("Identifiers must be nonempty, trimmed strings")
if type(tx.nonce) is not int or tx.nonce < 0:
raise ValueError("Nonce must be a nonnegative integer")
if tx.asset not in owners:
raise ValueError("Unknown asset")
if owners[tx.asset] != tx.sender:
raise ValueError("Sender is not the current owner")
if tx.sender == tx.recipient:
raise ValueError("Self-transfer is excluded in this lesson")
if tx.nonce != nonces.get(tx.sender, 0):
raise ValueError("Unexpected sender nonce")
updated_owners = dict(owners)
updated_nonces = dict(nonces)
updated_owners[tx.asset] = tx.recipient
updated_nonces[tx.sender] = tx.nonce + 1
return updated_owners, updated_nonces
Next, the model makes a reproducible JSON representation and hashes it with SHA-256. Sorting keys avoids differences caused by dictionary insertion order. This is a model-specific format, not Ethereum transaction encoding or a general cross-language canonical JSON standard.
def digest(value):
encoded = json.dumps(value, sort_keys=True, separators=(",", ":"),
ensure_ascii=True).encode("utf-8")
return sha256(encoded).hexdigest()
The hash covers the transfer, height and previous hash. The initial ownership map also has a digest, which anchors the first transfer. In this example, the initial allocation is trusted configuration; issuance is outside the lesson.
Try the public API in a Python session started inside examples:
from ledger import Ledger, Transfer
ledger = Ledger({"ticket-001": "alice"})
ledger.submit(Transfer("ticket-001", "alice", "bob", 0))
assert ledger.owner_of("ticket-001") == "bob"
assert ledger.verify()
try:
ledger.submit(Transfer("ticket-001", "alice", "carol", 1))
except ValueError as error:
print(error)
The first submit call validates and appends the transfer. The second attempts to reuse Alice’s old authority and is rejected. Validation happens before commitment, so rejected requests do not change either ownership or history.
Verification replays the stored transfers from the initial ownership map, checks heights, hashes and links, and compares the reconstructed state with the cached state. This catches several classes of accidental or deliberate modification.
But an attacker controlling all local records can construct a different, internally consistent history. That is why the demo also compares a rewritten history against a separately retained, trusted tip hash. The reference must come from outside the attacker’s control, and must be updated under an appropriate policy. Merely storing it beside the editable ledger does not create that protection.
An internally consistent history is not automatically the accepted history. Real networks add authorization, agreement and finality mechanisms that this local lesson intentionally leaves out.
8. UML and BPMN: make the rules visible
The UML class model describes the actual teaching code. A Ledger contains zero or more immutable Block records; each Block contains one Transfer. The transition function computes candidate state before the ledger commits it. The model highlights structure, not a deployed network topology.
The BPMN model describes one local submission. After checking the request, an exclusive gateway chooses either rejection without mutation or block construction and commitment. The success end event means local acceptance only; it does not mean network finality or legal settlement.
Downloadable sources include PlantUML, SVG and a non-executable BPMN 2.0 XML file with diagram coordinates. The BPMN describes modeled business-rule rejection; runtime failures and concurrent submissions are outside its scope. It is documentation, not an executable workflow.
9. What we tested—and what those tests establish
The suite contains 28 passing unittest methods. They cover valid ownership changes, invalid owners and assets, identifier validation, nonce types and ordering, replay after an asset returns, independent sender counters, input copying, hash stability, payload and link tampering, changed heights, reordered history, cached-state mismatch, invalid rehashed transitions, truncation and complete rewrites checked against a trusted tip.
The rejection helper checks that history, tip, ownership and nonce state stay unchanged when a request fails. The rewrite tests are particularly useful: they confirm both that an alternate history can be locally valid and that it differs from the retained reference.
These are deterministic, offline tests of this implementation. They do not constitute a cryptographic audit, a distributed-consensus test, a load test or a real blockchain integration. The code is an educational model, not a component ready to protect assets.
10. What changes in a real system?
A production design must answer several questions that a local example can leave open:
- Authorization: Which keys or account policies may request a transfer? How are requests bound to the intended network and action?
- Agreement: Which network’s ordering and finality rules does the application trust? What happens before finality?
- Integration: How do retries, duplicate events, chain reorganizations and service outages affect the business workflow?
- Governance: Who can upgrade, pause or replace rules? How do participants discover those changes?
- Data boundaries: Which information must participants share, and which information belongs in controlled offchain storage?
- Recovery: How are compromised credentials, incorrect external evidence and operational failures handled?
For an application team, an adapter around the ledger is usually useful: keep network-specific concerns out of ordinary domain rules, and make transaction status explicit. A user interface should distinguish “submitted,” “included,” “execution succeeded” and the chosen settlement condition. Our immediate submit result deliberately compresses those stages into one local operation.
These are engineering considerations for a future design, not features demonstrated by the lab. Evaluate them against the exact network, service and business requirements before selecting technology.
11. Common beginner questions
Is blockchain the same as Bitcoin?
Bitcoin is one particular blockchain system. Other networks have different programming models, participation rules and consensus mechanisms. The transferable concept is a shared, ordered state history—not one universal protocol.
Is blockchain immutable?
Use that word with its assumptions attached. Hash links make modifications detectable against trusted references; network mechanisms determine the accepted history. Our demo shows why recomputing local hashes can still produce a different valid-looking history.
Do I need cryptocurrency to learn?
No. This lesson runs entirely offline. Learning state transitions, authorization boundaries and history verification does not require buying anything.
Is a smart contract a legal contract?
A smart contract is program code. Whether an arrangement creates legal rights depends on the surrounding arrangement and applicable rules. This lesson makes no legal claim about its fictional tickets.
What should I learn next?
First explain the difference between a hash, a signature and consensus without looking it up. Then modify the lab’s transfer rules and add tests. When those concepts are comfortable, study the account, transaction and finality documentation for one chosen network, and move to a local development network before handling real assets.
12. Sources and further reading
Primary sources checked on 9 November 2026. Current deployment facts and evolving roadmaps should be rechecked before implementation.
- ECB: Eurosystem brings central bank money to tokenised finance, 21 September 2026.
- ECB: Pontes overview.
- Ethereum roadmap and security roadmap.
- Ethereum: Blocks.
- Ethereum: Accounts.
- Ethereum: Transactions.
- Ethereum: Introduction to smart contracts.
- Ethereum: Proof of stake.
- Ethereum: Oracles.
- Ethereum: Scaling.
The ticket scenario, implementation, diagrams and technology-selection table are original educational material. The cover is an original AI-generated concept illustration; it is not a technical network diagram.