English:Blockchain Technology
Blockchain Technology
Introduction
Blockchain technology is a family of methods for maintaining a shared digital record across multiple computers. A blockchain groups records into blocks, links those blocks with cryptographic hashes, distributes copies of the ledger across participating nodes, and uses agreed rules to decide which new records are accepted. NIST describes blockchains as distributed digital ledgers whose cryptographic linking makes changes tamper-evident and, as blocks accumulate, increasingly tamper-resistant. This wording is more precise than calling every blockchain absolutely immutable.
A blockchain is not identical to Bitcoin, cryptocurrency, or a database. Bitcoin is one influential application of blockchain ideas. A blockchain itself is the ledger; a blockchain network is the technical and social system that maintains it. Depending on the design, participants may be open to anyone or restricted to authorized organizations.
For university-level study, you should examine blockchain as a combination of cryptography, distributed systems, incentives, software engineering, economics, and governance. The central question is not merely "How does blockchain work?" but "Which trust problem does a particular blockchain architecture solve, under which assumptions, and at what cost?"
Learning Objectives
After completing this aiMOOC, you should be able to explain how transactions, blocks, hashes, digital signatures, distributed nodes, and consensus interact in a blockchain system. You should also be able to compare permissionless and permissioned architectures, distinguish proof of work from proof of stake, reason about smart-contract risks, evaluate scalability and privacy trade-offs, and decide whether a proposed application genuinely benefits from a blockchain.
From Shared Ledger to Blockchain
A ledger is an ordered record of events or transactions. Traditional ledgers are usually controlled by one organization or by a small set of trusted intermediaries. A distributed ledger instead keeps synchronized records at multiple nodes. A blockchain is a particular kind of distributed ledger in which records are grouped into blocks and each block refers cryptographically to earlier data.
The network must solve several problems at once. It needs rules for identifying valid transactions, mechanisms for authenticating actions, a method for ordering or finalizing records, and procedures for resolving competing histories. These are technical problems, but they are also governance problems because someone must define, implement, update, and operate the rules.
Decentralization is not a single binary property. A system can be decentralized in node operation yet concentrated in software development, token ownership, infrastructure providers, governance votes, or transaction ordering. Good analysis therefore asks which functions are decentralized, among whom, and with what consequences.
Cryptographic Foundations
Hash Functions
A cryptographic hash function maps input data of arbitrary length to a fixed-length output called a hash or digest. Secure cryptographic hash functions are designed so that it is computationally difficult to recover the original input from a digest, find two different inputs with the same digest, or predictably control how a small input change affects the output.
Blockchains use hashes for integrity checks, block linking, transaction identifiers, and data structures such as Merkle trees. If a previous block changes, its hash changes. Any later block that stores the old hash will no longer correctly reference that altered block. This makes tampering detectable.
A hash does not encrypt data and does not prove who created it. Authentication typically requires additional cryptographic mechanisms such as digital signatures.
Public Keys and Digital Signatures
Many blockchain systems use public-key cryptography. A participant controls a private key and derives or uses a corresponding public key. To authorize a transaction, the participant creates a digital signature with the private key. Other nodes can verify that signature using the public key without learning the private key.
A valid signature demonstrates control of the relevant private key and protects transaction integrity, but it does not automatically establish a person's legal identity. A blockchain address is usually a technical identifier. Connecting it to a real person or institution requires additional evidence, identity systems, or regulation.
Private-key security is therefore critical. If a private key is stolen, an attacker may be able to create validly signed transactions. If a key is lost, the legitimate user may lose the ability to authorize future transactions unless a recovery mechanism exists.
Transactions, Blocks, and Merkle Trees
A transaction is a proposed state change. Its exact structure varies by blockchain. It may transfer a digital asset, invoke a smart contract, register an event, or update shared state. Nodes check transactions against protocol rules before treating them as valid candidates for inclusion.
A block generally contains a block header and a collection of transactions or references to transactions. Many designs store a hash of the previous block header, creating the characteristic chain of references. Bitcoin block headers also include a Merkle root, timestamp-related data, a difficulty target representation, and a nonce used in proof-of-work mining.
A Merkle tree summarizes many data items by repeatedly hashing pairs of values until one root hash remains. A Merkle proof can show that a particular item is included in a committed data set without transmitting every item in that set. This is useful for efficient verification.
The sequence "transaction → validation → block proposal → consensus or finalization → replicated state" is a useful conceptual model. Real protocols differ substantially in timing, roles, and finality rules.
Distributed Networks and Consensus
A blockchain network contains nodes that communicate over a peer-to-peer or otherwise distributed network. Nodes may relay transactions, validate data, store ledger state, propose blocks, vote, attest, or perform several of these functions. Different node types can have different storage and trust assumptions.
Consensus is the process by which participants converge on an accepted history or state despite failures, delays, and potentially malicious behavior. Consensus is not the same as every node agreeing at every instant. Protocols specify how to progress when messages arrive at different times or when participants disagree.
The Byzantine fault problem illustrates why agreement is difficult when some participants may act inconsistently or deceptively. Blockchain consensus mechanisms adapt ideas from distributed systems and combine them, in some systems, with economic incentives.
Proof of Work
In proof of work, block publishers compete to find a computational result satisfying a protocol-defined condition. In Bitcoin, miners repeatedly hash candidate block headers while varying data such as the nonce until a block hash falls below the current target. The network's chain-selection rule favors the valid chain representing the greatest cumulative proof of work.
Proof of work makes rewriting old history costly because an attacker must redo the required work and catch up with or surpass honest participants. Its security is therefore connected to assumptions about available computational power, network behavior, and incentives. Its major disadvantages include substantial energy use and specialized infrastructure in many deployments.
Proof of Stake
In proof of stake, validators commit economically valuable stake and participate in proposing, attesting to, or finalizing blocks according to protocol rules. Many proof-of-stake systems penalize certain provably dishonest behaviors by reducing or destroying part of a validator's stake, a mechanism often called slashing.
Proof of stake generally requires far less energy than proof of work because security does not depend on continuous large-scale hash computation. However, it introduces its own design questions, including stake concentration, validator incentives, long-range attacks, key management, governance, and precise finality rules. Different proof-of-stake protocols should therefore be analyzed on their own specifications rather than treated as identical.
Permissioned Consensus
In permissioned networks, validator identities are restricted. Such systems may use crash-fault-tolerant or Byzantine-fault-tolerant voting protocols, proof of authority, or other consensus mechanisms. They can provide high throughput and clear organizational accountability, but they shift trust toward the institutions that control membership, credentials, infrastructure, and governance.
Permissionless and Permissioned Blockchains
A permissionless blockchain allows broad public participation under protocol rules. Anyone may typically read public data, submit transactions, and in many designs compete or qualify to help validate the ledger. Bitcoin and Ethereum are prominent examples, although their consensus mechanisms and data models differ.
A permissioned blockchain restricts one or more roles to approved participants. A consortium of banks, manufacturers, universities, or government agencies could use such a network when the participants are known but do not want a single member to control the shared record.
The architecture affects transparency, performance, governance, censorship resistance, legal accountability, and privacy. Permissioning does not automatically make a system secure, and openness does not automatically make it trustworthy. The right design depends on the threat model and institutional context.
Smart Contracts and Programmable Ledgers
A smart contract is program code deployed to a blockchain environment and executed according to that platform's rules. On Ethereum, a smart contract contains code and persistent state at an address. Users or other contracts can trigger functions through transactions. This enables decentralized applications, tokens, automated exchanges, escrow logic, and many other programmable workflows.
Calling smart contracts "contracts" can be misleading if it suggests that code alone has the status of a legally enforceable agreement. Legal effect depends on jurisdiction, parties, intent, and surrounding documentation. Technically, the key idea is deterministic or protocol-governed program execution on shared state.
Smart contracts introduce software-engineering risk. A bug can become economically significant because deployed code may control valuable assets and because state-changing transactions may be difficult or impossible to reverse. Secure development therefore requires careful specification, testing, code review, access control, dependency management, monitoring, and sometimes formal verification.
Oracles create another important trust boundary. A smart contract cannot directly know whether an off-chain event occurred unless an external mechanism supplies that information. If the oracle is wrong, manipulated, or unavailable, correct on-chain execution may still produce an undesirable real-world outcome.
Forks, Finality, and Governance
A fork occurs when nodes follow different rule sets or temporarily disagree about the ledger history. A soft fork changes validity rules in a way intended to remain compatible with older software under defined conditions. A hard fork introduces rules that can cause upgraded and non-upgraded nodes to accept different histories.
Some protocols offer probabilistic finality: confidence increases as more blocks accumulate after a transaction. Other protocols provide stronger forms of explicit or economic finality after specified votes or checkpoints. You should distinguish "included in a block" from "sufficiently final for the application's risk tolerance."
Governance includes formal voting, software releases, client implementations, validator or miner behavior, developer coordination, user choices, economic incentives, and legal constraints. Blockchain governance is therefore partly encoded in software and partly embedded in institutions and communities.
Security Model and Common Failure Modes
Blockchain security is an end-to-end property. A protocol may have strong cryptography while applications built on top of it remain vulnerable. Important risks include stolen private keys, weak wallet security, smart-contract bugs, compromised bridges, malicious or faulty oracles, denial-of-service attacks, consensus attacks, software supply-chain compromise, and governance capture.
A so-called "51 percent attack" is a useful shorthand for some proof-of-work risks, but the exact threshold and consequences depend on the protocol and attacker goal. Control of sufficient consensus resources may enable transaction reordering, censorship, or reorganization; it does not magically reveal private keys or allow arbitrary creation of valid signatures.
Public blockchains are often transparent rather than anonymous. Addresses may be pseudonymous, but transaction graphs can reveal patterns. Privacy-enhancing techniques can reduce exposure, yet they introduce their own assumptions and regulatory considerations.
Scalability and Layered Architectures
Blockchains face trade-offs among throughput, latency, decentralization, storage, verification cost, and security. Increasing block size or execution capacity can improve throughput but may raise the hardware and bandwidth requirements for independent nodes. Lowering verification costs can support broader participation but may require more sophisticated cryptography or layered designs.
Layer 2 systems move some computation or transaction processing away from the base chain while using the base layer for settlement, data availability, or dispute resolution. Examples include payment channels and rollup-style systems. Their security properties depend on how data is published, how state transitions are verified, and what assumptions users must make about operators or sequencers.
Interoperability bridges connect assets or messages across separate networks. Bridges can be useful but expand the attack surface because they must correctly verify or trust information from more than one system.
Energy, Sustainability, and Resource Use
Blockchain energy use depends strongly on the consensus mechanism and implementation. Proof-of-work systems intentionally expend computation to secure consensus, while proof-of-stake systems do not require the same competitive hashing process. It is therefore inaccurate to assign one universal energy profile to all blockchains.
A rigorous sustainability assessment should consider electricity use, hardware production, electronic waste, data-center infrastructure, geographic energy mix, and the utility delivered by the system. It should also compare blockchain designs with realistic non-blockchain alternatives that provide the same service.
Applications and Non-Applications
Potential blockchain applications include digital assets, inter-organizational reconciliation, provenance records, identity-related credentials, supply-chain events, decentralized finance, shared registries, and automated coordination through smart contracts. However, a blockchain does not guarantee that off-chain data is true. If false information is entered, cryptographic integrity can preserve a false record just as effectively as a true one.
Before choosing blockchain, ask whether multiple parties need a shared writeable record, whether they lack a single mutually trusted administrator, whether independent verification is valuable, whether data can be represented reliably, and whether the benefits justify the complexity and cost.
If one trusted organization can efficiently maintain the authoritative database, a conventional database may be simpler, faster, cheaper, easier to correct, and easier to govern. Blockchain is a design option, not a default solution.
A Framework for Evaluating Blockchain Proposals
Use a structured evaluation rather than beginning with the technology. First define the actors, assets, transactions, and trust problem. Then identify adversaries and failure modes. Specify who may read, write, validate, upgrade, and recover the system. Compare at least one centralized and one distributed non-blockchain alternative. Only then evaluate consensus, data availability, privacy, scalability, governance, interoperability, legal obligations, and total cost.
For university projects, make assumptions explicit. A claim such as "blockchain removes trust" is usually too broad. More precise analysis asks how trust is redistributed among protocol rules, software maintainers, validators, users, key custodians, oracle providers, infrastructure operators, and legal institutions.
Sources and Further Reading
- Blockchain: Start with the English Wikipedia overview and follow its references for terminology and historical context.
- Cryptographic hash function: Review why collision resistance and preimage resistance matter for integrity.
- Distributed consensus: Connect blockchain consensus to the wider theory of distributed systems.
- Smart contract: Compare programmable blockchain execution with conventional server-side applications.
- NISTIR 8202: Blockchain Technology Overview: A technical overview of blockchain components, consensus, forks, smart contracts, permissions, limitations, and misconceptions.
- Bitcoin: A Peer-to-Peer Electronic Cash System: The 2008 paper describing Bitcoin's peer-to-peer electronic cash design and hash-based proof of work.
- Ethereum smart-contract documentation: Technical documentation on smart contracts, state, transactions, deployment, and execution.
- Ethereum proof-of-stake documentation: A concrete example of a modern proof-of-stake protocol and its validator incentives.
Interactive Tasks
Quiz: Test Your Knowledge
What makes a blockchain tamper-evident? (Cryptographic links between blocks) (!A secret central database) (!Unlimited transaction speed) (!Automatic legal enforcement)
What is the primary role of a cryptographic hash in a blockchain? (To create a fixed length digest that can reveal data changes) (!To decrypt every transaction) (!To identify a legal owner by name) (!To guarantee that external data is true)
What does a digital signature primarily demonstrate in a blockchain transaction? (Control of the relevant private key) (!Guaranteed anonymity) (!Unlimited account recovery) (!Consensus among all nodes)
What does a Merkle proof help verify efficiently? (Inclusion of data in a committed set) (!The legal identity of a user) (!The market value of a token) (!The energy source of a validator)
What is consensus used for in a blockchain network? (To establish an accepted ledger history or state) (!To compress every private key) (!To eliminate all software bugs) (!To make every participant anonymous)
What resource secures Bitcoin proof of work most directly? (Computational work) (!Legal contracts) (!Central bank reserves) (!Biometric identity)
What is staked in a proof of stake system? (Economically valuable assets) (!File compression ratios) (!Email addresses) (!Database passwords)
What is a smart contract in technical terms? (Program code executed under blockchain rules) (!A guaranteed court judgment) (!A private encryption key) (!A physical mining device)
Why can an oracle be a security risk? (It supplies off chain information that may be wrong or manipulated) (!It always changes the hash algorithm) (!It removes every validator) (!It makes signatures impossible)
When may a conventional database be preferable to a blockchain? (When one trusted administrator can efficiently maintain the authoritative record) (!Whenever digital signatures are used) (!Whenever more than one user exists) (!Whenever data must be stored)
Memory Game
| Hash | Fixed length digest used to detect changes in data |
| Signature | Cryptographic proof that an authorized private key approved data |
| Merkle tree | Hash based structure that supports efficient inclusion proofs |
| Consensus | Rules and processes for converging on accepted ledger state |
| Validator | Participant that checks or attests to protocol valid data |
| Nonce | Value varied in a proof of work block header search |
| Oracle | Mechanism that supplies external information to on chain logic |
| Finality | Degree of confidence that an accepted record will not be reversed |
Drag and Drop
Create the correct matches between blockchain design concepts and their descriptions.
| Match the correct terms. | Topic |
|---|---|
| Permissionless participation | Open network access under public protocol rules |
| Permissioned participation | Restricted roles controlled by approved identities |
| Proof of work | Consensus based on costly computational effort |
| Proof of stake | Consensus based on economically bonded validators |
| Smart contract | Program that changes shared state according to deployed logic |
...
Crossword Puzzle
| Consensus | What process lets distributed participants converge on an accepted state? |
| Nonce | What adjustable value is commonly changed during proof of work hashing? |
| Validator | What participant checks or attests to valid blocks in many protocols? |
| Hashing | What process maps data to a fixed length digest? |
| Forking | What process can split ledger histories or protocol rule sets? |
| Ledger | What ordered record of transactions is replicated across blockchain nodes? |
LearningApps
Cloze Text
Open-Ended Tasks
Easy
- Hash Experiment: Create a short demonstration showing how tiny changes in an input produce different cryptographic hash outputs, and explain why this property matters for tamper evidence.
- Blockchain Diagram: Draw and annotate a five-block chain that includes transactions, previous-block hashes, and one deliberately altered block, then explain how the alteration propagates.
- Key Management Interview: Interview a software developer or IT administrator about practical private-key protection and summarize three lessons that apply to blockchain wallets.
- Concept Video: Produce a two-minute explainer video that distinguishes blockchain, cryptocurrency, and distributed ledger using one concrete example for each.
Standard
- Consensus Comparison: Build a comparison matrix for proof of work, proof of stake, and one permissioned consensus approach using security assumptions, energy use, finality, participation, and governance.
- Smart Contract Prototype: Design or implement a small test-network smart contract, document its state transitions, and identify at least three failure cases before deployment.
- Blockchain Case Study: Analyze a real blockchain application and compare it with a conventional database architecture using explicit criteria for trust, cost, performance, and governance.
- Oracle Investigation: Trace how one decentralized application obtains off-chain data, identify its oracle trust assumptions, and propose a failure-mitigation strategy.
Advanced
- Threat Model: Produce a formal threat model for a blockchain-based system, identifying assets, adversaries, trust boundaries, attack surfaces, security assumptions, and mitigations.
- Scalability Research: Compare two layer-two approaches or rollup designs and evaluate their data availability, verification, sequencing, finality, and user-exit assumptions.
- Governance Analysis: Examine a historical blockchain fork or protocol upgrade and explain how technical rules, developer coordination, economic incentives, and user choices interacted.
- Blockchain Design Review: Propose a blockchain architecture for a multi-organization problem, defend every major design choice, and include a reasoned argument for why a non-blockchain alternative is less suitable.
Learning Assessment
- Architecture Reasoning: Given a consortium data-sharing scenario, justify whether the system should be centralized, permissioned blockchain, or permissionless blockchain, and make every trust assumption explicit.
- Consensus Failure Analysis: Explain how a network partition or malicious validator behavior could affect two different consensus mechanisms and compare their recovery paths.
- Smart Contract Audit: Review a short contract specification or implementation, identify security and governance weaknesses, and rank the risks by impact and likelihood.
- Evidence and Oracles: Design a method for recording real-world events on a blockchain while distinguishing cryptographic integrity from the truthfulness of the original observations.
- Scalability Trade-off: Recommend an architecture for an application with high transaction volume and strict finality requirements, explaining what is gained and sacrificed at each layer.
- Governance Transfer: Apply blockchain governance concepts to another distributed infrastructure project and explain which lessons transfer and which do not.
Evidence of Learning
- Knowledge
You can accurately explain hashes, digital signatures, transactions, blocks, Merkle trees, nodes, consensus, forks, finality, smart contracts, oracles, permission models, and common scalability approaches.
- Analytical skills
You can identify trust assumptions, distinguish protocol security from application security, compare consensus mechanisms, construct threat models, and evaluate trade-offs rather than repeating slogans about decentralization or immutability.
- Practical products
Your portfolio can include an annotated blockchain model, a hash experiment, a smart-contract prototype, a consensus comparison, a threat model, a case study, and a design review.
- Transfer achievements
You can decide when blockchain is appropriate, compare it with conventional databases and other distributed systems, and apply concepts such as fault tolerance, cryptographic integrity, incentives, governance, and adversarial thinking to new technical domains.
OERs on the Topic
Linked Learning Areas
