Cryptographic hash functions are the quiet workhorses of every blockchain, turning any piece of data into a short, fixed-length fingerprint that changes completely if even one bit of the input changes. Blocks, transactions, addresses and mining all depend on these fingerprints behaving exactly as expected.
Because so much rests on them, it helps to understand what a hash function promises and what it does not. This article explains the core security properties, the hash functions used by major blockchains, the places where hashing protects a ledger, and the mistakes developers make when they rely on hashes incorrectly.
A Fingerprint for Every Piece of Data
A hash function takes an input of any size, such as a sentence, a file or a block of transactions, and produces an output of fixed size called a digest or hash. SHA-256, for example, always returns 256 bits, usually shown as 64 hexadecimal characters.
The same input always yields the same digest, which makes hashes useful for checking whether data has changed. If two parties compute the hash of a file and get identical results, they can be confident the files match without comparing them byte by byte.
A cryptographic hash function adds stronger guarantees than an ordinary checksum. It is designed so that no one can practically find inputs that produce a chosen output or two inputs that collide. Those guarantees are what allow a blockchain to treat a short hash as a trustworthy stand-in for a large amount of data.
The Three Core Security Properties
Security researchers describe cryptographic hash functions using three main properties. Each one protects against a different kind of attack, and blockchain designs depend on all three.
Preimage Resistance
Given only a digest, it should be infeasible to find any input that hashes to it. This is sometimes called one-wayness. It allows systems to publish a hash of a secret, as atomic swaps do, without revealing the secret itself, and it keeps the hash from leaking useful information about the original input.
For a sound 256-bit function, the best known general approach is guessing, which is far beyond any realistic computing budget.
Second Preimage Resistance
Given one specific input, it should be infeasible to find a different input with the same digest. This protects existing data: if an attacker could craft an alternative transaction with the same hash as a real one, they might substitute it in a block without anyone noticing the change.
Blockchains rely on this property every time a node checks that a block or transaction matches the hash recorded elsewhere.
Collision Resistance
It should be infeasible to find any two different inputs that share a digest. This is the strongest of the three and the first to weaken as research advances. Older functions such as MD5 and SHA-1 have known collision attacks and are no longer considered safe for security purposes.
Because of the birthday paradox, collisions are found faster than preimages, which is why modern designs use digests of at least 256 bits.
The Avalanche Effect and Determinism
A well-designed hash function exhibits the avalanche effect: changing a single character of the input changes roughly half of the output bits in an unpredictable way. Two nearly identical transactions therefore produce digests that look completely unrelated to one another.
This behavior is what makes tampering obvious. If someone alters an amount in a historic transaction, its hash changes, which changes the hash of the block that contains it, which in turn breaks every later block that refers back to it. The change cannot stay hidden.
Determinism is equally important. Every node on the network must compute exactly the same digest from the same input, regardless of hardware or software. That consistency allows thousands of independent participants to agree on the state of the ledger without trusting one another.
SHA-256 and Bitcoin
SHA-256 belongs to the SHA-2 family standardized by the United States National Institute of Standards and Technology. Bitcoin uses it heavily, often applying it twice in a construction known as double SHA-256, for block hashes, transaction identifiers and proof of work.
In proof of work, miners repeatedly hash a block header with different values of a field called the nonce, searching for a digest below a target set by the network. Because the output is unpredictable, the only practical approach is trial and error, which ties block creation to real computational effort.
Bitcoin addresses also involve hashing. A public key is hashed with SHA-256 and then RIPEMD-160 to produce a shorter identifier for certain address types. Hashing the key adds a layer of protection, since the full public key does not need to appear on-chain until its owner spends from that address.
Keccak-256 and Ethereum
Ethereum relies on Keccak-256, a function from the Keccak family that won the competition later standardized as SHA-3. Ethereum adopted it before standardization was finished, and its padding differs from the final SHA3-256, so the two produce different digests for the same input.
This detail causes real bugs. A developer who assumes that a library’s SHA3-256 equals Ethereum’s Keccak-256 will compute wrong hashes, leading to mismatched addresses, failed signature checks or incorrect function selectors. Code should name the exact function it uses rather than relying on the label SHA-3.
Keccak-256 appears throughout Ethereum. It derives account addresses from public keys, generates function selectors from function signatures, computes storage locations for mappings, and hashes structured data before signing. Smart contract developers encounter it constantly, often through the built-in keccak256 function in Solidity.
Where Hashing Protects a Blockchain
Hashing shows up in nearly every layer of a blockchain, often in ways users never see. Recognizing these uses helps explain why a weakness in a hash function would be so serious for the whole system.
- Block linking: each block header contains the hash of the previous header, forming a chain that resists alteration.
- Transaction identifiers: each transaction is referenced by its hash, giving it a unique and verifiable name.
- Merkle roots: transactions are hashed in pairs up a tree, so one root commits to the whole set.
- Addresses: public keys are hashed into compact account identifiers.
- Mining: proof of work requires finding block hashes below a target value.
- Commitments: a party can publish a hash first and reveal the data later.
Each use relies on a slightly different property. Block linking needs second preimage resistance, commitments need preimage resistance and hiding, and Merkle trees need collision resistance. Designers should be clear about which property each feature depends on.
Commitment Schemes Built on Hashes
A commitment scheme lets someone lock in a value now and reveal it later, while proving they did not change it in between. With hashes, the committer publishes the hash of the value combined with a random salt, then later reveals both so anyone can verify the match.
Blockchains use commitments for sealed-bid auctions, fair random number generation and voting, where revealing choices early would let others react. The salt matters: without it, an observer could hash every plausible value, such as each possible bid, and discover the hidden choice by comparison.
Developers should generate salts with a secure random source and make them long enough to resist guessing. They should also define what happens if a participant never reveals, since a missing reveal can be used strategically to abort an auction or skew a random outcome in the committer’s favor.
Common Developer Mistakes With Hashes
Hash functions are strong, but code around them often is not. Many vulnerabilities come from using a sound primitive in an unsound way, which is why reviews should examine how inputs are encoded before hashing.
A frequent mistake is ambiguous encoding. If a contract hashes two variable-length strings by simply concatenating them, the inputs “ab” plus “c” and “a” plus “bc” produce the same bytes and therefore the same hash. In Solidity, abi.encodePacked with several dynamic types can create exactly this collision.
Other mistakes include hashing data without a domain separator, a fixed label that distinguishes one purpose from another, so a hash meant for one context is accepted in another. Using a hash of public on-chain data as a source of randomness is also unsafe, because miners or validators can influence or predict it.
Hashing Versus Encryption and Signing
People new to cryptography often confuse hashing with encryption. Encryption is reversible by anyone holding the right key, while a hash is designed to be one-way. A hash cannot be decrypted to recover the input, and it should not be described as encrypting data.
Hashing is also different from signing, although the two work together. A digital signature proves that the holder of a particular private key approved a message. In practice, wallets hash the transaction first and then sign the digest, because signing a short, fixed-length value is more efficient.
Understanding these roles prevents design errors. Storing a hash of sensitive data on a public ledger does not make that data private if the set of possible inputs is small, because anyone can hash the candidates and compare. Hashes provide integrity and commitment, not confidentiality.
The Long-Term Strength of Hash Functions
Hash functions can weaken over time as researchers find shortcuts or as computing power grows. The history of MD5 and SHA-1 shows that a function trusted for years can later be broken for collision resistance, prompting migrations across the industry.
Quantum computing is often raised in this context. Known quantum algorithms offer only a limited speedup against hash preimage searches, so well-sized modern hash functions are generally considered far more resilient to quantum attack than the elliptic curve signatures blockchains also use.
Blockchains benefit from planning for agility, meaning the ability to change algorithms if needed. Changing a consensus-critical hash function is difficult because it affects every node and historical data, so early design choices that allow future upgrades are valuable even if they are never used.
Choosing a Hash Function for a New Project
Teams building on an existing blockchain usually have little choice: they use the hash functions the platform exposes. Projects designing a new protocol, a sidechain or an off-chain system that interacts with a ledger must make that choice deliberately, and it deserves the same care as any other security decision.
Sensible selection criteria include:
- A public standard or long record of open analysis by independent cryptographers.
- No known practical collision or preimage attacks at the chosen output size.
- Native support on every chain the system must verify hashes on.
- Efficient implementations, including inside zero-knowledge proof circuits if those are planned.
- Mature, maintained libraries in the languages the team uses.
Specialized hash functions designed for zero-knowledge circuits can be far cheaper to prove but have received less scrutiny than SHA-256 or Keccak-256. Teams adopting them should follow published parameters exactly and watch for research updates more closely than they would for older, heavily studied designs.
Applying Hash Function Knowledge Safely
Developers can put these ideas into practice with a few habits. Use well-established hash functions provided by the platform or vetted libraries, never a homemade design, and document exactly which function each component uses, especially when mixing Keccak-256 and SHA3-256.
Encode inputs unambiguously before hashing by using fixed-length fields or length-prefixed encoding, and add domain separators for each distinct purpose. Treat on-chain hashes as public, and never assume that hashing low-entropy data, such as dates of birth or short codes, keeps it secret.
For users and security staff, the practical lesson is to verify hashes when software or files are published with them and to recognize that a blockchain’s integrity depends on these primitives. Keeping an eye on cryptographic research and network upgrade proposals helps teams prepare well before any algorithm needs replacing.