Hash

Hash is a fixed-length string produced from arbitrary input by a one-way function. In TON it is almost always SHA-256, producing 256 bits (32 bytes). A cryptographic hash is secure in the sense that a tiny change to the input flips the entire output, and inverting the function to recover the input is computationally infeasible.

Properties of a cryptographic hash

• Deterministic. The same input always yields the same output.
• Fast. SHA-256 over a megabyte of data runs in milliseconds on any device.
• Avalanche effect. Flipping one input bit changes about half of the output bits on average.
• Pre-image resistance. Recovering the input from the hash is infeasible.
• Collision resistance. Finding two different inputs with the same hash is infeasible in practice.

Where TON uses hashes

• Cell hash. Every cell in TON is identified by its hash. This allows compact references to complex data structures.
• Wallet address. address = workchain : hash(StateInit) — a TON wallet address is literally the hash of the contract code together with the public key.
• Block hash. Every block in the masterchain and shardchains has its own hash, forming a chain of linked blocks.
• Transaction hash. A transaction’s unique identifier is its hash; this is what Tonscan and Tonviewer use to look it up.
• Merkle proof. Lite clients verify the existence of a transaction without holding the full state by walking a hierarchy of hashes.

Typical encoding

TON typically presents hashes as hex (a1b2c3…, 64 hex chars) or base64. The EQ/UQ address format is essentially a base64 wrapper around workchain | hash | checksum | flags.

Where hashes do not help

A hash is not encryption — it only compresses with loss. Storing a password as plain SHA-256(password) is unsafe: rainbow tables and GPU brute force chew through such hashes quickly. Passwords need slow functions like scrypt, Argon2, or PBKDF2 (the last one is used in BIP-39 to stretch the seed phrase into the master seed).