Top Cryptographic Primitives Behind Every Blockchain

Every blockchain claim — "this transaction is final," "this address owns this asset," "this history hasn't been altered" — ultimately reduces to a handful of cryptographic primitives doing narrow, well-defined jobs. None of them are blockchain inventions. Hash functions, digital signatures, and Merkle trees predate Bitcoin by decades. What blockchains did was combine them into a system where no single party has to be trusted for any of those claims to hold.

This guide walks through the primitives that actually carry the weight: hash functions that fingerprint data, digital signatures that authorize transactions, Merkle trees that make huge datasets verifiable in pieces, the elliptic-curve math those signatures run on, and commitment schemes — the building block that leads into zero-knowledge proofs. Understanding each one is the fastest way to understand what a blockchain is actually doing under the hood.

Cryptographic Hash Functions (SHA-256, Keccak)

A hash function takes an input of any size and deterministically produces a fixed-size output — a "digest" — such that flipping a single bit of input scrambles the output completely, and finding two different inputs that hash to the same output is computationally infeasible. That property, collision resistance, is what makes a hash usable as a compact, tamper-evident fingerprint for arbitrarily large data.

Bitcoin uses SHA-256 throughout: block headers are chained by embedding the SHA256(SHA256()) hash of the previous header in each new one, so altering any past block changes its hash and breaks every header that follows it (Bitcoin Developer Guide). The same double-SHA-256 construction hashes transactions into the block's Merkle tree (Bitcoin.org reference).

Ethereum instead standardizes on Keccak-256 (the original Keccak submission, distinct from the later NIST SHA-3 standard) as its general-purpose hash. Every account address is derived by taking the last 20 bytes of the Keccak-256 hash of the account's public key (ethereum.org), and the same function underlies the key/value content-addressing used throughout the Merkle Patricia Trie that stores Ethereum's state.

Hashing is also what links block headers into a chain rather than a loose collection of records: changing a header changes its hash and breaks the references in descendant headers. The additional requirement to redo later work and overtake the honest network is specific to Bitcoin's proof-of-work consensus, where an attacker changing a past block must redo that block's proof of work and all work after it, then catch up with the honest chain (Bitcoin whitepaper, §4). Other blockchains authenticate and finalize history under different consensus rules, so hash linking alone does not create that proof-of-work cost. The linked header hashes are the literal reason the data structure is called a blockchain.

Public-Key Cryptography & Digital Signatures (ECDSA, EdDSA, BLS)

A blockchain has no login form, so it needs another way to prove "this transaction really came from the owner of this account." Public-key cryptography solves this with a key pair: a private key kept secret and a public key that can be shared freely. Signing a transaction with the private key produces a digital signature that anyone can verify against the public key — proving authorization without ever revealing the private key itself.

Ethereum accounts derive their public key from the private key using the Elliptic Curve Digital Signature Algorithm, ECDSA, over the secp256k1 curve — the same curve Bitcoin uses (ethereum.org accounts docs; EIP-2, secp256k1 signature malleability fix). ECDSA is fast to verify and has decades of scrutiny, but it has one operational weakness relevant to newer designs: individual ECDSA signatures don't aggregate efficiently, so verifying thousands of them means doing thousands of separate checks.

That's the gap EdDSA and BLS signatures fill. EdDSA (used by chains like Solana and Stellar) uses a different curve construction that's deterministic and resistant to certain implementation pitfalls that have historically caused ECDSA nonce-reuse bugs. BLS signatures go further: because of the mathematical pairing property of the curves they use, many BLS signatures can be combined into a single aggregate signature that verifies all of them at once. Ethereum's proof-of-stake consensus layer relies on exactly this — validators sign attestations with BLS keys so the beacon chain can aggregate votes from hundreds of thousands of validators into signatures compact enough to verify quickly, which is what makes large-scale proof-of-stake practical at all (ethereum.org, The Beacon Chain). Ethereum also exposes BLS12-381 curve operations as EVM precompiles specifically to support BLS signature verification in smart contracts (EIP-2537).

Merkle Trees

A Merkle tree is what lets a blockchain summarize thousands of transactions into a single 32-byte hash without forcing every participant to store every transaction. Leaves are hashes of individual data items (transactions, account states); each pair of hashes is concatenated and hashed again, repeating until one hash — the root — remains (Bitcoin Developer Guide). That root is stored directly in the block header, which is what lets a full node commit to the entire contents of a block using almost no extra space.

The payoff is proof size. To show that one transaction is included in a block, you don't need the whole block — just the transaction plus a "Merkle branch," the sibling hashes along the path from that leaf to the root, typically on the order of log₂(n) hashes for n transactions. This is the basis of Simplified Payment Verification (SPV): a lightweight client that has only block headers can still verify a specific transaction happened by checking its Merkle branch against the header's root, without downloading the entire blockchain (Bitcoin Developer Guide).

Ethereum extends the idea with the Merkle Patricia Trie, a hybrid of a Merkle tree and a prefix (radix) trie used to store the entire account state, not just a list of transactions. Every block header carries three separate trie roots — stateRoot, transactionsRoot, and receiptsRoot — each independently provable (ethereum.org). This is what lets a smart contract or a light client verify a single account balance or a single storage slot without replaying the whole chain.

Elliptic-Curve Cryptography

Elliptic-curve cryptography (ECC) is the mathematical foundation ECDSA, EdDSA, and BLS all sit on top of. Instead of relying on the difficulty of factoring large numbers (as classic RSA does), ECC relies on the difficulty of the elliptic-curve discrete logarithm problem: given a point on the curve reached by adding a base point to itself many times, it's computationally infeasible to recover how many times — even though computing the point itself, going forward, is easy. That asymmetry (easy one direction, hard to reverse) is exactly what makes a private key safe to use for signing while the derived public key stays safe to publish.

The specific curve and signature scheme matter. Bitcoin and Ethereum both use secp256k1, a Koblitz curve standardized by the Standards for Efficient Cryptography Group with well-studied 256-bit parameters (SEC 2: Recommended Elliptic Curve Domain Parameters). Other ecosystems make different tradeoffs: Ed25519 is a concrete EdDSA signature scheme instantiated over the Edwards25519 curve (RFC 8032, §5.1), and RFC 8032 places it around the 128-bit classical security level (§8.5); BLS12-381 is a pairing-friendly curve chosen for operations such as BLS signature aggregation, with EIP-2537 describing 120+ bits of security (EIP-2537). Those estimates are not a claim of equal "security per key bit": the systems use different groups, encodings, and assumptions, and nominal key length is not itself security strength. For example, NIST maps 128-bit classical security to 256–383-bit ordinary ECC keys but 3072-bit RSA keys (NIST SP 800-57 Part 1 Rev. 5, Table 2), which helps explain why elliptic-curve systems became the default for blockchain accounts.

Commitment Schemes (a Bridge to Zero-Knowledge)

A commitment scheme lets you "lock in" a value — publish something that binds you to a specific piece of data — without revealing the data itself, and later "open" the commitment to prove what it was. The everyday analogy is a sealed envelope: you can hand someone a sealed envelope today as proof you already decided on an answer, without them seeing it until you choose to open it later, and once sealed, you can't swap the answer inside.

This sounds like a small primitive, but it's the load-bearing piece underneath most zero-knowledge proof systems. Ethereum's blob-based data-availability design, for instance, uses KZG polynomial commitments to reduce each blob to a small cryptographic commitment. A KZG proof can authenticate an evaluation or sampled cell against that commitment, but it does not by itself prove that the full blob is available: availability comes from the consensus layer's distribution and sampling rules, while KZG supplies the integrity check for the data received (EIP-4844; EIP-7594, PeerDAS). This separation is what lets a verifier check a small part of a blob without mistaking a compact evaluation proof for proof that all blob data was published. A Merkle root, in fact, is itself a simple commitment scheme: it commits to an entire dataset via its root hash, and a Merkle branch is the "opening" that reveals one piece of it. ZK-rollups build on more advanced commitment schemes (polynomial and vector commitments) to compress an entire batch of transaction execution into a proof that's cheap to verify on-chain — the topic covered in depth in Perfect vs. Computational Zero-Knowledge.

Comparison: Blockchain Cryptographic Primitives

How This Connects to Tokenized Domains

Every one of these primitives shows up directly when you tokenize a domain. The NFT representing ownership is protected by the chain's account and token-authorization rules. If an externally owned account holds it, that account's private key authorizes account actions; a contract account has no private key and is controlled by its code (ethereum.org, Ethereum accounts). For an ERC-721 token, an approved address or operator can also initiate a transfer (ERC-721). That is why hardware wallets and careful seed phrase custody matter for self-controlled EOA ownership, while smart-contract and custodial wallets introduce different authorization and trust boundaries. The domain's ownership record lives in the same Merkle-committed state that secures every other account balance and smart contract on the chain, which is exactly what gives a tokenized domain the same tamper-evidence as any other on-chain asset — transferable, verifiable, and provably owned without a registrar's database being the sole source of truth.

Understanding these primitives also clarifies what tokenization does and doesn't change: the domain's DNS record and registry status still follow ICANN rules, but its ownership proof now runs on the cryptography described above instead of a login-protected registrar account. Explore the broader picture in Blockchain Consensus Mechanisms and Blockchain Scaling Approaches, or start tokenizing at namefi.io.

Sources and Further Reading

• Bitcoin Developer Guide — Block Chain, chaining via SHA256(SHA256()) of the previous header
• Bitcoin — Bitcoin: A Peer-to-Peer Electronic Cash System, proof-of-work history rewriting and cumulative work
• Bitcoin Developer Reference — Block Chain, Merkle root construction
• Bitcoin Developer Guide — Operating Modes, SPV and Merkle branches
• ethereum.org — Ethereum Accounts, ECDSA and Keccak-256 address derivation; EOA and contract-account control
• ethereum.org — Merkle Patricia Trie, state/transactions/receipts roots
• ethereum.org — Danksharding, KZG polynomial commitments
• EIP-4844 — Shard Blob Transactions, blob commitments, proofs, and consensus-layer availability
• EIP-7594 — PeerDAS, cell proofs and data-availability sampling
• ERC-721 — Non-Fungible Token Standard, token ownership, approvals, and operators
• EIP-2 — Homestead Hard-fork Changes, secp256k1 signature constraints
• EIP-2537 — Precompile for BLS12-381 curve operations
• RFC 8032 — Edwards-Curve Digital Signature Algorithm (EdDSA), Ed25519's scheme, curve, and security level
• SEC 2: Recommended Elliptic Curve Domain Parameters — secg.org
• NIST SP 800-57 Part 1 Rev. 5 — Recommendation for Key Management, comparable ECC and RSA security strengths
• The Eth2 Book — Signatures and BLS aggregation
• NIST — NIST Releases First 3 Finalized Post-Quantum Encryption Standards