Hash
Fixed-size digest produced by a cryptographic hash function.
A hash is a fixed-length digital digest created by applying a hash function to input data of any size. A cryptographic hash function is designed to be one-way and resistant to collisions. The same input produces the same output, while a tiny input change should produce a substantially different digest.
Hashes are not encryption. Encryption transforms data so an authorized party can recover it with a key. A hash is not designed to reveal the original input. Weak or guessable inputs such as common passwords can still be tested repeatedly, which is why password storage needs specialized slow hashing, unique salts, and current security practices.
Blockchains use hashes throughout their data structures. A transaction hash identifies encoded transaction data. Block headers reference prior blocks by hash, making changes to history detectable. Merkle trees summarize many transactions so membership can be proved without transmitting every item. Smart contract platforms also use hashes for storage, signatures, identifiers, and deterministic addresses.
Proof-of-work mining repeatedly hashes candidate block headers until an output satisfies the network target. The function is quick to verify but requires miners to perform many attempts. Hash rate measures the number of attempts per second, not data-transfer speed or the number of confirmed transactions.
Common blockchain functions include SHA-256 in Bitcoin and Keccak-256 in Ethereum. Developers must distinguish standardized SHA-3 from Ethereum's earlier Keccak variant where implementations differ. Choosing the wrong encoding, byte order, field order, or function produces an unrelated result even if the displayed inputs appear similar.
A hash can confirm that data matches an expected digest, but cannot prove the data was trustworthy when hashed. Users downloading software should obtain checksums through an authenticated source; a malicious file and checksum on the same compromised site offer little protection. Developers should use reviewed libraries, explicit encoding, appropriate digest sizes, and domain separation. Hashes provide integrity and compact commitments when used correctly, not secrecy, identity, or truth by themselves.
When hashes appear in explorers or deployment records, users should compare the complete value rather than a shortened prefix. A few matching characters are easy to produce and do not establish equality.
Frequently asked questions
- A cryptographic hash should make it impractical to recover an input from its digest, find another input with the same digest, or find any collision. Small input changes should produce unpredictable output changes. Security depends on function and use case. SHA-256 and Keccak-family functions are common in blockchains, while obsolete choices should not protect new systems.
- Blockchains use hashes to identify transactions and blocks, link headers, commit to state, build Merkle trees, address content, and support proof of work. A digest lets users verify exact data efficiently, but it does not encrypt that data or prove an external claim is true. The surrounding protocol determines what a particular hash represents.
- Yes in theory, because unlimited possible inputs map to a fixed-size output. A collision-resistant cryptographic function makes deliberately finding such a pair computationally impractical at its intended security level. Accidental collision risk depends on digest size and number of values. Systems should use modern, sufficiently large hashes and include domain context when similar data has different meanings.