Blockchain & Crypto Basics

Overview

Most software you have built so far assumes one party owns the database. Your company runs the server, your company decides what is true, and everyone else trusts that you will not change the records behind their back. A blockchain exists for the situations where that assumption breaks down — where the parties writing to a shared system do not fully trust each other and no single one of them should hold the keys.

In one line, a blockchain is an immutable, distributed, and decentralized database that coordinates diverse actors. Those four words do a lot of work, and pulling them apart is most of this lesson. Immutable means data is written once and read forever; once a fact is recorded it cannot be quietly edited. Distributed means the same database lives on many independent machines at once. Decentralized means no single operator decides the truth — the participants agree on the rules in advance and let those rules settle disagreements. And coordinating diverse actors is the point of the whole exercise: clients, competitors, and suppliers who sit outside your circle of trust can still read and write to the same ledger and stay in sync.

This module gives you enough working intuition to make technical decisions with confidence: what a blockchain actually is, how a transaction travels from a signature in your wallet to a permanent fact everyone agrees on, why "consensus" is a broader idea than the "mining" you may have heard about, what a smart contract is and is not, and how building on Web3 differs from the Web2 stack you already know.

What is a blockchain

A blockchain is, at heart, a special kind of database — but one with unusual properties that come from how it stores data, not from any one company running it.

Immutable: write once, read forever

A normal application database lets you UPDATE and DELETE rows. A blockchain ledger does not. You append a record and that record stays — write once, read forever — which is what makes the data tamper-proof. You cannot rewrite history to favour yourself, and neither can anyone else, because everyone is holding the same history.

Distributed and decentralized

The ledger does not live on one server; copies run on many independent machines spread across the network. That redundancy makes the system censorship-resistant (no single operator can block or erase a transaction) at the cost of requiring significant infrastructure to keep all those copies running and in agreement. Distribution is about where the data lives; decentralization is about who decides what is true. In a decentralized system, participants agree beforehand on the rules used to establish truth, and a consensus mechanism applies those rules — so no central authority is needed to referee.

Public or private

Not every blockchain is open to the world. Private chains are invitation-only and tend to be run by companies and consortiums who want shared, tamper-proof records among known partners. Public chains let anyone join and are suited to public services, governance, audits, and proving authenticity to people you have never met. The XRP Ledger (XRPL) is a public chain.

How a transaction works

Two ideas make the chain trustworthy: cryptographic hashing, which links the blocks together, and public-key cryptography, which proves who authorized each change.

Hashing links the blocks

A hash is a function that turns any input into a unique, fixed-size output. Feed "Learning center" into SHA-256 and you always get the same fingerprint; feed "University training" and you get a completely different one. Hashing is deterministic (same input → same output, every time) and one-way (you cannot run it backwards to recover the original text).

Data is written into blocks sequentially, and here is the trick: each block includes the hash of the block before it. Block 2 carries the hash of Block 1, Block 3 carries the hash of Block 2, and so on. Because the fingerprint of every block depends on the one before it, you cannot alter an old transaction without changing its block's hash — which would break every block that came after it. That chain of hash-linked blocks is, literally, the blockchain. It behaves like an append-only event store: a permanent, ordered log of everything that ever happened.

Signing proves who wrote it

So how do you actually add a transaction? Through public-key cryptography (PKC), the cornerstone of digital identity on the chain. Each user holds a key pair:

• a public key, which acts as your address — others use it to send to you and to verify your signatures;
• a private key, which acts like your password — you use it to sign transactions, and you never share it.

When you submit a transaction, you sign it with your private key. The network checks that signature against your public key. A valid digital signature is unique to each transaction and proves who created it, without ever exposing the private key. The signed-to-final path is now complete: you sign a transaction with your private key, the network verifies the signature, the transaction is bundled into a block, that block is hash-linked to the chain, and from that point it is immutable — final, and visible to everyone.

Consensus, not mining

Here is where beginners often get stuck, because the press talks about "mining" as if it were the whole story. It is not. The general idea is consensus: the agreed-upon procedure by which a distributed set of machines decides which transactions are valid and what order they go in — so that every honest copy of the ledger reaches the same answer.

There are many consensus mechanisms, and proof-of-work is only one of them. The family includes Proof of Work (PoW), Proof of Stake (PoS), Delegated Proof of Stake (DPoS), Proof of Importance (PoI), Proof of Capacity (PoC), Proof of Elapsed Time (PoET), Proof of Authority (PoA), and others. Proof-of-work is the mechanism behind Bitcoin: machines race to solve an expensive computational puzzle, and the winner earns the right to write the next block. That race is what "mining" refers to, and it deliberately burns enormous amounts of electricity to make rewriting history costly.

Other mechanisms reach the same goal — everyone agreeing on one history — without that energy race. The XRP Ledger, for instance, does not mine. A set of trusted validators repeatedly proposes and compares candidate transaction sets until a supermajority agrees, and the ledger closes in a few seconds. The practical payoff is finality: once consensus is reached, the result is settled. With proof-of-work you wait for several blocks to pile on top before you treat a payment as safe; with fast-consensus designs, agreement is reached up front, so settlement is quick and unambiguous. When you read "consensus," think the rules everyone agreed to in advance for settling the truth — not specifically mining.

Smart contracts

A smart contract is code that lives on the chain and runs exactly as written when its conditions are met. Think of it as a small program that holds its own rules and assets: "if X happens, automatically do Y," enforced by the network rather than by a company or a court. Because it executes on the same immutable, decentralized ledger, every participant can read its logic and trust that it will run the same way for everyone, with no operator able to quietly change the outcome.

Smart contracts are the right tool when a process needs to be trustless and automatic among parties who do not trust each other — escrow that releases funds when a condition is verified, or a token whose supply rules are fixed and public. They are the wrong tool when you need to store large or private data, when the logic changes often, or when the action depends on real-world information the chain cannot see on its own (an oracle has to feed that in, and that becomes a new point of trust). On-chain code is also expensive and effectively permanent — bugs are hard to patch. The discipline is to put on-chain only what genuinely needs the chain's guarantees, and keep everything else off-chain.

Web2 → Web3

The shift from Web2 to Web3 is mostly a shift in who controls the data and the trust:

• Trust model. Web2 trusts a company's servers as the source of truth. Web3 replaces that with cryptographic proofs and consensus — you trust the math and the rules, not the operator.
• Data ownership. In Web2 your data and balances live in a provider's private database they can change. In Web3 your assets live on a public ledger you control with your private key.
• Identity and accounts. Web2 identity is an email-and-password login a provider can reset or revoke. Web3 identity is a key pair: your public key is your address, your private key is your authority — and if you lose it, no one can recover it for you.
• State of records. Web2 records are mutable and editable behind the scenes. Web3 records are append-only and immutable, so history is auditable by anyone.
• Failure and censorship. A Web2 app goes down when its servers do, and the operator can block users. A Web3 network keeps running across distributed nodes and resists censorship.

The trade-offs are real: Web3 buys you trustlessness, ownership, and auditability, but pays for it with more infrastructure, the weight of immutability (mistakes are permanent), and the hard responsibility of key management. Choosing Web3 means choosing those guarantees because your problem genuinely needs them.

Check

You're done when you can explain, in about a page and in your own words: how a single transaction travels from signed (with a private key) to final (hash-linked into an immutable block everyone agrees on); how consensus is a broader idea than proof-of-work, and why faster consensus gives you cleaner finality; and at least three concrete ways building a Web3 app differs from a Web2 app (for example trust model, data ownership, and identity). A peer should be able to read your explanation and follow each point without already knowing the answer.