Section 2 — Blockchain Foundations
Lesson 6 explains how transaction information becomes part of a linked blockchain record and why tamper-evident is more accurate than unchangeable.
Estimated time: 65–100 minutes
Educational boundary: This lesson explains technology. It does not recommend any network, company, product, or digital asset. It does not provide individualized financial, investment, legal, or tax advice. You do not need internet access, an account, a wallet, or a digital asset to complete the lesson.
Lesson 5 introduced a blockchain as a shared digital ledger. In this lesson, we will slow the process down and examine how a proposed transaction can become part of a block and how hashes help connect one block to the next.
When I encounter a technical subject, I find it useful to separate the process into smaller questions. What information is being proposed? Who or what checks it? How is it grouped? What evidence would reveal a later change? I encourage you to use that method here. You do not need to memorize a formula or become a cryptographer. Your goal is to build a mental model that you can explain accurately, test against an example, and improve through writing.
Careful wording is part of the lesson. People often say that blockchain records are “immutable,” meaning they cannot change. That single word may hide important conditions and tradeoffs. By the end of the lesson, you should be able to explain why tamper-evident and tamper-resistant are usually more responsible descriptions.
Lesson 6 explains how transaction information moves toward an accepted block, what a cryptographic hash does, and why a chain of hash references can make altered records detectable.
Essential question: How do transactions, blocks, and hashes work together to create an ordered record, and what does that structure prove—or fail to prove?
After completing this lesson, you should be able to:
Definition: A proposed action or change that a system may verify and add to its record. A transaction does not have to involve money.
Sample sentence: Recording that an organization issued a digital credential can be treated as a transaction.
Definition: A group of accepted records or transactions stored together in a blockchain.
Sample sentence: The validator included several accepted transactions in the next block.
Definition: A fixed-length result produced when a hash function processes data. A cryptographic hash is designed so that a change to the input produces a different result and so that reversing the result or finding two matching inputs is extremely difficult.
Sample sentence: The learner compared the two hashes to see whether the recorded data had changed.
Definition: The study and use of mathematical methods that help protect information and support functions such as confidentiality, integrity, authentication, and verification.
Sample sentence: A blockchain uses cryptography as one part of its security design, but cryptography does not remove the need for sound rules and responsible participants.
Definition: Time-related information attached to a record or block according to a system's rules.
Sample sentence: The block included a timestamp that helped place it within the network's sequence.
Definition: Designed so that an unauthorized or unexpected change leaves evidence that can be detected.
Sample sentence: The linked references made the record tamper-evident because changing an earlier block caused later references to stop matching.
A transaction begins as a proposed change. In a payment system, it might propose transferring a digital asset. In a credential system, it might propose recording that an authorized organization issued or revoked a credential. In a supply system, it might propose changing the recorded quantity of an item.
The word transaction describes a system event, not necessarily a purchase. The important question is what change the system is being asked to recognize.
A proposed transaction is not automatically an accepted fact. The system first applies its rules. Depending on the network, those rules may check the format, authorization, digital signature, available balance, sequence number, or other conditions. A transaction that fails the applicable checks should not enter an accepted block.
Passing those checks still does not prove that every statement about the outside world is true. If an authorized person submits an incorrect course-completion record, the transaction may be technically valid even though the underlying claim is false. Blockchains can check information that exists within their rules. They cannot independently observe every real-world event.
Different blockchain networks use different procedures, but a beginner can understand the general path in five stages.
Lesson 7 will examine nodes, validators, miners, and consensus mechanisms more closely. For now, notice that a transaction does not move directly from one person's request into permanent history. A system of checks, roles, and rules stands between the proposal and the accepted block.
There may also be a delay. A transaction can wait before selection. A block can be proposed before the network treats it as final. Some networks may temporarily disagree about the most recent history and later settle on one version under their rules. Words such as pending, included, confirmed, and finalized can describe different stages. They should not be treated as exact synonyms.
A hash function accepts input data and produces an output called a hash, hash value, or message digest. For a particular hash algorithm, the output has a fixed length even when the input varies in length.
Imagine placing a document into a machine that produces a short code. The same document processed by the same machine produces the same code. Change one character in the document, and the code changes. That analogy is useful, but it has limits. A real cryptographic hash function uses mathematics, not a physical machine, and the output may appear as a long string of numbers and letters.
Secure cryptographic hash functions are designed around several properties:
Collision-resistant does not mean that matching outputs are mathematically impossible. A fixed-length output has a limited number of possible values, while possible inputs are far more numerous. Secure algorithms are designed to make a useful collision extraordinarily difficult to find. The strength also depends on using an appropriate algorithm and implementing it correctly.
Hashing and encryption are related to cryptography, but they perform different jobs.
Encryption transforms readable information into a protected form that an authorized person can reverse with the proper key. A cryptographic hash is intended to be one-way. It produces a digest used for comparison or as part of another security process. It is not a container that someone later opens to recover the original message.
A hash also does not automatically hide the input. If someone knows a small set of possible inputs, that person may hash each possibility and compare the results. Sensitive information should not be placed on a public blockchain merely because the system stores or references a hash. Privacy decisions require a broader analysis.
In a simplified blockchain model, each block includes transactions, time-related information, and a reference derived from the previous block's data. That reference is commonly a cryptographic hash.
Suppose Block 20 contains a hash of Block 19. Block 21 then contains a hash of Block 20. If someone changes a transaction in Block 19, the hash calculated for Block 19 changes. The reference stored in Block 20 no longer matches the altered Block 19. That mismatch creates evidence that the chain has been changed.
Recalculating one hash would not be enough to hide the alteration. The person would also need to rebuild the later references and overcome the network's rules for accepting history. As more blocks are added and more independent participants maintain the accepted chain, rewriting older history may become increasingly difficult.
The hash link provides tamper evidence. The network, consensus process, participant independence, software security, and incentives help provide tamper resistance. A hash alone does not make a record impossible to change.
A timestamp helps place a transaction or block in time according to a system's rules. It can support ordering and help participants evaluate whether information fits the expected sequence.
A timestamp should not be treated as perfect proof that an outside event occurred at an exact moment. Networks differ in who supplies time information, how much variation their rules permit, and when a proposed block becomes accepted. The timestamp belongs to the technical record. Additional evidence may be needed to prove when a real-world event happened.
The word immutable literally suggests that something cannot change. In ordinary blockchain discussion, people often use it more loosely to mean that accepted history is difficult to alter without detection.
Several situations show why precision matters:
For those reasons, tamper-evident describes the evidence left by a change, while tamper-resistant describes the difficulty of making an accepted change succeed. Neither phrase claims that alteration is impossible under every condition.
As of July 20, 2026, BNB Chain's official documentation describes BNB Smart Chain as a network in which validators produce blocks under its consensus rules. Its developer documentation also describes methods for retrieving transactions from a block and locating transaction data by a transaction hash.
This provides a practical use of hash language. A transaction hash can act as an identifier that lets software or a block explorer locate the transaction record. A block has its own hash-based references within the chain. These identifiers help people compare records and follow the sequence.
The transaction hash does not prove that every outside statement connected with the transaction was accurate. It also does not, by itself, prove that the transaction succeeded, became final, or was authorized by the right real-world person. A careful reviewer examines the transaction data, its status or receipt, the block, the network, and the surrounding evidence.
Mentioning BNB Smart Chain is an educational example. It is not an endorsement, an invitation to acquire BNB, or a request to conduct a transaction.
Hashes are useful for integrity checks, but their limits matter.
A matching hash can show that the compared data produced the same digest under the same function. It does not prove:
Other tools and procedures address those questions. Digital signatures can help check authorization. Governance rules can assign responsibility. Privacy controls can limit access. Audits and source documents can help verify outside facts. No single technical feature replaces the entire system of judgment.
Three nonprofit warehouses coordinate deliveries of shelf-stable food. Each warehouse submits daily records showing the number of cases received and distributed. The organizations use a shared chain of blocks. Each new block contains accepted records and a hash reference to the previous block.
An auditor later receives two copies of the history. In the first copy, Block 8 says that Warehouse B received 80 cases. In the second copy, the entry says 60 cases. The two versions produce different hashes, and the later references match only the first copy.
The hash comparison reveals that one version was changed. It does not prove that 80 cases actually arrived. The original delivery receipt may have been wrong, the data-entry person may have made a mistake, or an authorized person may have submitted false information.
Reasoned conclusion: The linked hashes help the auditor detect a disagreement and identify which history matches the later chain. The organizations still need source documents, authorized submitters, correction procedures, and accountability. Technical integrity and factual truth are related, but they are not the same.
Estimated time: 20–25 minutes
Materials: Separate paper and a pencil. A calculator is optional.
This exercise uses a simple two-digit check code to demonstrate linked references. The code is not secure and is not a real cryptographic hash. It is intentionally simple enough to calculate on paper.
For each block, calculate:
Toy hash = previous hash + block number + quantity + number of words in the transaction. Keep only the final two digits.
Count Receive, Issue, the number, and the item as words. For example, “Receive 5 books” contains three words. Begin with previous hash 00.
Previous hash: 00
Transaction: Receive 5 books
Calculation: 00 + 1 + 5 + 3 = 09
Toy hash: 09
Previous hash: 09
Transaction: Issue 2 books
Calculation: 09 + 2 + 2 + 3 = 16
Toy hash: 16
Previous hash: 16
Transaction: Issue 1 book
Calculation: 16 + 3 + 1 + 3 = 23
Toy hash: 23
Copy the three blocks onto your paper. Draw an arrow from each toy hash to the next block's previous-hash line.
Write brief responses to these questions:
Important limitation of the simulation: This toy rule is a checksum-like classroom device. It has frequent collisions, is easy to reverse, and provides no security. A real blockchain uses secure cryptographic hash functions, network software, validation, digital signatures, and consensus rules. The exercise demonstrates linked references and tamper evidence only.
A. Proposal, basic checking, selection into a proposed block, network agreement, and recording
B. Recording, deletion, advertising, and automatic proof of truth
C. Payment, bank approval, password recovery, and printing
D. Hashing, encryption, guaranteed acceptance, and permanent secrecy
A. A reversible container that hides a message until a key opens it
B. A fixed-length result used to represent input data and help detect change
C. A guarantee that the input came from an honest person
D. A timestamp that proves when an outside event occurred
A. The later block contains a reference derived from the earlier block's data.
B. Every participant stores information in one physical computer.
C. Hashes automatically correct false information.
D. A block can contain only one transaction.
The practical skill is learning to ask two separate questions: Does the record show evidence of alteration, and was the information accurate and authorized when it entered the system?
Write one coherent journal entry of approximately 300–400 words. Do not submit a disconnected list of answers. Use the prompts below to organize a beginning, middle, and conclusion:
Your response should demonstrate your reasoning. You are not being asked to calculate a real cryptographic hash, create an account, open a wallet, purchase an asset, or conduct a transaction.
Write your response on separate paper or in an approved institutional messaging system. Include your name or approved Profile identifier, Lesson 6: Blocks, Transactions, and Hashes, and the date you completed the entry.
Use one of the established Prison Professors Profile methods, subject to your facility's rules:
Keep a copy when circumstances permit. Never include passwords, private keys, seed phrases, authentication codes, account numbers, real wallet addresses, or other sensitive credentials.
