The last module ended with a promise: the next thing you'd learn is the cryptography that makes blockchains possible at all. This lesson keeps that promise by starting with the smallest, simplest cryptographic tool in the box. Hashing. It's a function that takes any input and returns a short, fixed-size hash, and it's the load-bearing pillar of every blockchain you'll ever meet. Everything else in cryptography (signatures, addresses, identity, the integrity of a block) is built on top of it. Start here and the rest of the module assembles itself.

A hash function takes any input, of any size, and returns a fixed-size output. Cryptographic hash functions add a few extra properties that make them safe to use in security-critical contexts.

Run any blockchain-relevant hash function on three different inputs:

SHA-256("hello")
  → 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

SHA-256("hello!")
  → ce06092fb948d9ffac7d1a376e404b26b7575bcc11ee05a4615fef4fec3a308b

SHA-256("Lorem ipsum dolor sit amet, consectetur adipiscing elit...")
  → 5bd6045a7697c48316411ff00be02595cf3d8596d99ba12482d18c90d61633cb

Three things you can see immediately. The output is always the same length, 256 bits, written as 64 hex characters. One added character (hello → hello!) produces a completely different output. A long input gets compressed to the same size as a short one.

The playground below has two inputs pre-filled with hello and hello!, each wired to its own hashing node. The two output hashes share zero structure even though the inputs differ by one character. Edit either input and watch them shift independently. That live behavior is the lesson. The rest of this page is just the formal explanation of what you're seeing.

Those three observations are already most of what you need to know. The rest of the lesson explains the formal properties behind them and why blockchains can't exist without them.

A regular hash function, the kind used in hash tables, only needs to spread inputs evenly across the output range. A cryptographic hash function has to resist an attacker who is actively trying to break it. Four properties matter.

Deterministic. The same input always produces the same output. SHA-256 of "hello" is the same string on your laptop, on a Bitcoin node in Tokyo, and on a Solana validator in Frankfurt. Without this, no two nodes could ever agree on anything.

Fast to compute, slow to invert. Computing the hash of a 1 MB file takes milliseconds. But finding an input that produces a given hash requires trying inputs one by one. For SHA-256, that's roughly 2²⁵⁶ attempts in the worst case, a number comparable to the count of atoms in the observable universe. The asymmetry is the whole point.

Preimage resistance. Given a hash output h, it's computationally infeasible to find any input x such that hash(x) = h.

Collision resistance. It's computationally infeasible to find any two different inputs x and y such that hash(x) = hash(y). If you could, you'd have a transaction whose contents you could swap without changing its identifier, which would destroy every signature-based guarantee in the system.

A consequence of these properties is the avalanche effect: changing a single bit of input changes roughly half the output bits, in a way that looks completely random. Going from hello to hello! flips almost every bit of the resulting 256-bit value. There's no smooth gradient. Small input changes produce large, unpredictable output changes.

Two uses are enough to make the point.

Integrity checking. This one predates blockchain by decades. Software distributors publish a file alongside its hash. You download the file, hash it yourself, and compare. If your hash matches the published hash, the file wasn't modified in transit. If even one byte was changed, by a network error, a malicious mirror, anything, your hash will be completely different from the published one and you'll know. This is the simplest possible use of a hash function and it's the seed of every other security property in the rest of the course.

Block linking. Every block in a blockchain contains the hash of the previous block as one of its fields. The diagram below shows what that looks like in practice.

Change anything in a historical block, even a single bit, and that block's hash changes. The next block's prev_hash field no longer matches, so it becomes invalid, and so does every block after it. Tampering with the past is detectable by anyone holding the chain, in constant time, by recomputing one hash per block. This is the property that turns a list of records into a tamper-evident chain.

Three names cover almost everything in the ecosystems you'll work in. You don't need to remember the details right now. The point is to recognize the names when they show up in later lessons.

SHA-256. Designed by the NSA, published by NIST in 2001, part of the SHA-2 family. This is the hash function Bitcoin uses for almost everything. 256-bit output. Battle-tested for 25 years with no known practical break.

Keccak-256. The function Ethereum uses. It won the SHA-3 competition in 2012, and Ethereum adopted it before NIST finalized the standard. The final SHA-3 standard ended up with slightly different padding, so Ethereum's "Keccak-256" and the official "SHA3-256" produce different outputs for the same input even though they share the same underlying algorithm. This catches people off guard the first time they try to compute an Ethereum hash off-chain using a generic SHA-3 library and get a different answer than they expected.

RIPEMD-160. An older function with a 160-bit output. Bitcoin uses it in combination with SHA-256 in a few places. You'll see it again in a later lesson. For now, just notice that it produces shorter outputs than the other two.