Cryptographic primitives create bounded evidence, not magic trust

Blockchain protocols combine hash functions, digital signatures, authenticated data structures, canonical encodings, and carefully managed keys. Each primitive answers a narrow question. A hash can bind later verification to exact bytes; it does not hide those bytes, prove who created them, or establish that their real-world meaning is true. A signature can authenticate a message to a public key; it does not prove human identity, informed intent, legal authority, or eventual inclusion in canonical history. A Merkle proof can show that a leaf is committed by a trusted root; it does not establish where that root came from or whether the underlying data is available.

A cryptographic hash maps arbitrary input to a fixed-size digest. Production designs rely on preimage resistance, second-preimage resistance, and collision resistance, which are distinct properties with different generic security bounds. Collision resistance for an n-bit ideal digest is roughly n/2 bits because of the birthday bound. Hashes are deterministic and therefore do not protect low-entropy secrets: an attacker can guess a password or small-domain value offline and compare its digest. Passwords require a salted, deliberately expensive password-hashing construction; commitments to predictable values require random blinding.

Protocols must name the exact algorithm and encoding. SHA-256 and Keccak-256 are not interchangeable, and Ethereum's Keccak-256 is not simply any implementation labelled SHA3-256. A digest commits to bytes, so field order, integer width and endianness, Unicode normalization, absent values, and domain identifiers must be canonical. Ambiguous concatenation such as hashing two variable-length fields without framing can let different logical messages produce the same byte sequence even when the hash remains secure. Use a versioned canonical serialization and test byte-level vectors across every supported implementation.

Domain separation prevents a valid value in one protocol context from being accepted in another. Prefix or structurally encode the application, network, message type, version and purpose before hashing or signing. Chain identifiers and typed signing formats reduce cross-chain and cross-protocol replay. They do not replace application nonces, expirations, authorization checks, or idempotency. Verification must reconstruct exactly the intended domain and reject unknown or ambiguous versions.

Digital signatures use a private key to sign and a corresponding public key to verify message integrity and origin authenticity. The signed object is the canonical message or an explicitly defined digest of it. ECDSA additionally requires a unique unpredictable per-message secret; reuse or bias can reveal the long-term private key. Deterministic nonce generation such as RFC 6979 removes dependence on fresh runtime randomness for this step but still requires correct implementation, side-channel resistance, and protection of the private key.

Signature malleability and representation rules matter to transaction identity. Some schemes or encodings permit more than one valid signature representation for the same message. Protocols may require canonical low-S values or define transaction identifiers over a representation that excludes malleable material. An application must follow the network's exact validation rules rather than assuming that a signature byte string is a globally stable business identifier.

Public keys, addresses and identities are separate layers. An address is normally a network-specific encoding or derivation from a public key, often with a checksum. A checksum catches some transcription errors; it is not an authenticity proof. Recovering or verifying a public key shows possession of a corresponding private key under the signature scheme. Binding that key to a person, organization, role, device, account, or legal authority requires a separate enrollment and authorization process.

Merkle trees recursively hash leaves and child nodes to one root commitment. A membership proof supplies the sibling hashes and ordering needed to recompute a trusted root, normally in logarithmic proof size. Verification must bind leaf encoding, path or index, tree depth, child orientation, tree type, algorithm, and root context. Duplicate-last rules, sorted-pair trees, sparse trees, Merkle Patricia tries and SSZ merkleization have different proof semantics; proof formats are not portable merely because all are called Merkle proofs.

Non-membership is not automatically proven by failure to produce a membership path. It requires an authenticated structure with explicit absence semantics, such as neighboring ordered leaves, an empty sparse-tree leaf, or a trie proof showing where a path terminates. Multiproofs can share branches for efficiency but need strict index validation to prevent duplicate, missing, or reordered leaves from changing the logical claim.

Hash commitments do not provide data availability. A root may be valid while the leaves are withheld. Light clients and rollups therefore need separate availability assumptions and protocols. Likewise, a proof verified against an untrusted root proves only internal consistency with attacker-chosen data. The verifier needs an authenticated root from consensus, a trusted checkpoint, or another explicit trust anchor and must associate it with a block, network, version and finality state.

Wallet security is key-management security. Keys should be generated with a cryptographically secure random source, kept in the smallest practical trust boundary, protected at rest and during use, and never logged or exposed to analytics. Hardware-backed or threshold designs can reduce single-process exposure, but signing policy, firmware, recovery, access control and supply-chain assumptions remain. Backups must be encrypted, tested and governed; an unusable backup and an attacker-readable backup are opposite failures of the same control.

Hierarchical deterministic wallets derive a tree of keys from seed material. Hardened and non-hardened derivation expose different capabilities and risks. An extended public key can enable address discovery without spending authority, but it is privacy-sensitive and, in some derivation designs, combining it with a leaked non-hardened child private key compromises the parent branch. A mnemonic is an encoding used to derive seed material, not a password reset mechanism. Optional passphrases create different valid wallets, so mistakes can be indistinguishable from empty accounts.

Key rotation on an immutable ledger is an application protocol, not an edit to old signatures. Systems need explicit ownership-transfer, multisignature, social recovery, threshold, pause, or migration rules. Old signatures remain historically verifiable; future authority moves according to on-chain or off-chain policy. Compromise response must define how detection occurs, which actions can be frozen, who may rotate, how users verify the new key, and what happens when an attacker races the recovery transaction.

Cryptographic agility is the ability to introduce new algorithms and parameter sets without ambiguous downgrade or silent reinterpretation. Store algorithm and version identifiers with signed objects, reject unsupported choices, isolate verification policies, keep test vectors, inventory dependencies and plan migrations. Agility does not mean letting an unauthenticated sender choose a weak algorithm. Long-lived ledgers must also assess quantum migration: sufficiently capable quantum computers threaten widely used discrete-log signatures, while hash security degrades differently and can generally be compensated with output size.

Production verification is fail-closed and observable without leaking secrets. Parse bounded inputs; require canonical encodings; validate public keys, curve points, subgroup and network; bind domain and freshness; perform authorization after cryptographic verification; and distinguish malformed, invalid, unauthorized, expired and already-used messages. Use vetted libraries and constant-time implementations instead of custom cryptography. Test official vectors, cross-language byte equality, invalid encodings, boundary values, replay, wrong domains, altered proofs, corrupted backups, rotation, compromised signers and dependency upgrades. The engineering goal is a precise chain of evidence whose assumptions, keys, encodings, roots and recovery paths are all explicit.