A cryptographic hash function is a machine that takes any input — a single letter, a book, a video file — and produces a fixed-size fingerprint of that input. Change one bit of the input and the fingerprint changes completely. Given only the fingerprint, you cannot figure out what the input was. That is it. The whole concept, in one paragraph.
Every blockchain is built on hashing. Bitcoin uses SHA-256. Ethereum uses Keccak-256. Solana uses Blake3. Understanding what makes a hash function useful (and what does not) is a prerequisite to reading almost anything about blockchain internals.
The three properties
A good cryptographic hash function has three defining properties:
**One-way (preimage resistant)**: given a hash output, you cannot practically compute an input that produces it. If you have "3a4f7c..." you cannot work backward to whatever was hashed. The only way to find an input that maps to a target hash is to guess — try inputs, hash them, and check.
**Deterministic**: the same input always produces the same output, on any machine, any language, any decade. This is the "fingerprint" property. If you hash "hello" today on your laptop, and someone hashes "hello" in 2050 on a mainframe, they will get the exact same output.
**Avalanche**: change one bit of the input and the output changes on average in half of its bits. Similar inputs do not have similar hashes. "hello" and "hellp" produce hashes that share no visible pattern. This prevents any partial-preimage attacks or shortcuts.
The hash output size
A cryptographic hash function specifies its output size. SHA-256 always produces a 256-bit output (32 bytes, or 64 hexadecimal characters). SHA-512 produces 512 bits. Blake3 can produce arbitrary-length output but standardly 256 bits.
The output size determines the security. A 256-bit hash has 2^256 possible outputs — an unfathomably large number. For any random input you hash, you can be effectively certain no one else will ever hash a different input that produces the same output. This is why 256 bits is the standard: it is large enough to make collision attacks (finding two different inputs with the same hash) infeasible.
Why blockchains need this
A blockchain is, at core, a linked list where each block contains the hash of the previous block. This creates the "chain": to modify an old block, you would have to recompute its hash, which changes the hash reference in the next block, which requires recomputing that block's hash, and so on to the tip. Modifying any historical block requires re-doing every block after it.
For Bitcoin, "re-doing" a block means finding a new proof-of-work — essentially, hashing random inputs until the output falls below the difficulty target. This takes an enormous amount of computation. Re-doing years of blocks would require more computation than the entire Bitcoin network has produced in its history. This is the security of the chain.
Hash functions also produce Merkle trees (which we cover elsewhere), address formats (a Bitcoin address is a hash of a public key), and integrity checks throughout the protocol. Every place a blockchain says "here is a commitment to this data," it is really saying "here is a hash of this data."
SHA-256 (Bitcoin's choice)
SHA-256 is part of the SHA-2 family, designed by the NSA and standardized by NIST in 2001. It has been the workhorse of Bitcoin and much of the internet's security infrastructure for over two decades without any practical break.
Bitcoin uses SHA-256 for proof-of-work mining, block hashing, transaction IDs, Merkle roots, and address generation (in combination with RIPEMD-160). Every corner of the protocol touches SHA-256 somewhere.
Well-analyzed, hardware-optimized (ASICs exist that compute SHA-256 at trillions of hashes per second — that is the entire Bitcoin mining industry), and universally implemented. The main criticism: it was designed by a government agency, though decades of external cryptanalysis have not turned up backdoors.
Keccak-256 (Ethereum's choice)
Ethereum uses Keccak-256, which was the winner of the SHA-3 competition. Note: Ethereum uses the original Keccak-256, not the slightly different final SHA-3-256 (there was a minor padding change between the competition winner and the final NIST standard, and Ethereum froze before the standard did).
Keccak was chosen partly because SHA-2 and SHA-3 have completely different internal structures — if SHA-2 were ever broken, SHA-3 would likely survive. Ethereum wanted a hash function structurally different from what Bitcoin used.
Every Ethereum contract, transaction, and event uses Keccak-256 somewhere. When you compute the hash of "Transfer(address,address,uint256)" to get an event topic, you are running Keccak-256. When you compute a contract address from a deployer and nonce, Keccak-256 again.
Blake and Blake3 (Solana, Zcash, some Cosmos chains)
Blake is a hash function family designed for speed. Blake2 was one of the SHA-3 competition finalists. Blake3, released in 2020, is significantly faster than SHA-2 and SHA-3 on general-purpose CPUs.
Solana uses Blake3 in its Proof of History mechanism, where fast hashing is critical to throughput. Zcash uses Blake2b in its zero-knowledge proofs. Blake is not as universally supported as SHA-2 but is common in newer, performance-focused designs.
The speed comes at some cost to hardware optimization — because it is designed for general CPUs, you cannot dominate with an ASIC the way you can with SHA-256. This is intentional for chains that want to resist mining centralization.
What hashing does not do
Hashing is not encryption. Encryption is reversible with a key — you can encrypt a message and decrypt it later. Hashing is one-way; there is no decryption function. If you hash a password, you cannot get the password back from the hash. This is a feature for password storage: the server can verify a password by hashing what you typed and comparing to the stored hash, without ever needing to store the plaintext.
Hashing does not compress. A 1 KB input and a 1 GB input both hash to the same fixed-size output. This is not a way to shrink files — the original data is not recoverable from the hash.
Hashing is not signing. A signature is proof that a specific key holder authorized a specific message; hashing produces a fingerprint but not authorization. Signatures use hash functions internally (you sign the hash of the message, not the message itself, for efficiency), but signing and hashing are different operations.
Collision resistance in the real world
The one theoretical vulnerability of any hash function is a collision: finding two different inputs that produce the same output. For a 256-bit hash, the birthday paradox means collisions become likely at around 2^128 hashes — an insurmountably large number, but the specific vulnerability is real if the function is weakened.
SHA-1 (an older function, 160 bits) had a first practical collision demonstrated in 2017 after decades of theoretical weakness. MD5 (older, 128 bits) has had trivial collisions since 2005. Both are considered broken for security purposes. Any modern usage should be SHA-256 or better.
SHA-256, Keccak-256, and Blake3 are all considered unbroken. No practical collision has been demonstrated for any of them, and none is expected in the foreseeable future without an unexpected mathematical breakthrough.
Why this matters for you
You will never write hash function code as a crypto user. You will encounter hashes constantly: transaction IDs, block hashes, address derivations, contract addresses, event signatures, Merkle proofs. Every one of these is a hash function output, and knowing what that means — a deterministic fingerprint of some specific data — makes reading a block explorer or a smart contract much less mysterious.
The math is unbreakable in practice. The security bugs come from misusing hashes, not from hashes themselves.
