Blockchain Cryptography
Master the cryptographic primitives of major blockchains and understand quantum threats.
What is Blockchain Cryptography?
Blockchains are fundamentally cryptographic systems. Every transaction is authorized by a , every address is derived from a public key through hash functions, and every wallet generates its keys from elliptic curve mathematics. There is no central authority — cryptography alone establishes ownership and prevents fraud.
- Private key controls funds (256-bit secret)
- Public key derived via elliptic curve math
- Digital signatures prove transaction authority
- SHA-256 secures Bitcoin blocks and addresses
- Keccak-256 derives Ethereum addresses
- RIPEMD-160 shortens Bitcoin address hashes
- Addresses are hashes of public keys
- Each chain uses a different derivation pipeline
- HD wallets generate unlimited addresses from one seed
Elliptic Curves: secp256k1 vs Ed25519
Blockchain private keys are random 256-bit numbers. The corresponding public key is derived via scalar multiplication on an — a one-way trapdoor function that is easy to compute forward but computationally infeasible to reverse. Two curves dominate:
Used by Bitcoin and Ethereum. Defined in SEC 2 (Certicom, 2010). 128-bit security level. Public keys are 33 bytes (compressed) or 65 bytes (uncompressed). Signatures use .
Used by Solana. Defined in RFC 8032. Twisted Edwards curve with 128-bit security. 32-byte public keys. Signatures use with deterministic nonces — immune to nonce-reuse attacks.
secp256k1 ECDSA uses a random nonce per signature (nonce reuse leaks the private key). Ed25519 EdDSA derives the nonce deterministically from the message, eliminating this class of vulnerability entirely.
Address Derivation Across Chains
The same mathematical operation (private key × generator point = public key) is just the first step. Each blockchain then applies a different hashing and encoding pipeline to derive the final address:
1...0x...Bitcoin uses a double-hash (SHA-256 then RIPEMD-160) to produce a 20-byte hash before encoding. Ethereum uses Keccak-256 (note: this is the original Keccak submission, not the NIST SHA3-256 standard — they differ in padding). Solana is the simplest: the 32-byte Ed25519 public key is directly Base58-encoded as the address.
Digital Signatures: ECDSA vs EdDSA
Digital signatures prove that a transaction was authorized by the holder of a private key without revealing the key itself. Each chain uses a different signature scheme with different trade-offs:
HD Wallets and Key Management
Rather than managing separate private keys for each address, derive an unlimited number of keys from a single seed. The standard converts random entropy into a 24-word mnemonic phrase for human-readable backup. defines the tree derivation, and standardizes the path structure across chains.
| Chain | Derivation Path | Standard | Notes |
|---|---|---|---|
| Bitcoin | m/44'/0'/0'/0/0 | BIP-32 / BIP-44 | Coin type 0, supports non-hardened child keys |
| Ethereum | m/44'/60'/0'/0/0 | BIP-32 / BIP-44 | Coin type 60, same derivation as Bitcoin |
| Solana | m/44'/501'/0'/0' | All segments hardened — Ed25519 does not support non-hardened derivation |
Post-Quantum Threats to Blockchains
Every cryptographic algorithm covered above — (ECDSA), (EdDSA), and the elliptic curves underlying HD wallets — is vulnerable to . Understanding these threats is essential before working with blockchain cryptography hands-on.
Why This Matters: Quantum Threats to Blockchain
Every cryptographic algorithm you used in this module — secp256k1 (ECDSA), Ed25519 (EdDSA), and the elliptic curves underlying HD wallets — is vulnerable to . A sufficiently powerful quantum computer () could derive private keys from public keys, breaking the security of all three blockchains.
| Chain | Algorithm | Quantum Threat | Migration Status |
|---|---|---|---|
| Bitcoin | secp256k1 ECDSA | Shor's algorithm breaks ECDLP. ~$718B in vulnerable P2PK addresses with exposed public keys. | BIP-360 (P2QRH) — Draft New quantum-resistant address type via soft fork |
| Ethereum | secp256k1 ECDSA + BLS12-381 | All accounts that have transacted expose public keys. Validator BLS signatures also vulnerable. | EIP-7702 + AA path — Active PQC signing available today via Account Abstraction; EF PQC team funded |
| Solana | Ed25519 EdDSA | Shor's algorithm breaks Ed25519. All account public keys are the address itself (always exposed). | SIMD community discussion No ratified proposal; structural migration challenge |
Risk for Blockchains
On-chain data is immutable — unlike traditional systems where you can rotate keys, blockchain transaction history is permanent. Public keys exposed in past transactions remain harvestable indefinitely. When cryptographically relevant quantum computers arrive, every previously exposed public key becomes a target. This makes the HNFL threat particularly severe for blockchains: there is no retroactive fix for exposed keys.
Source: Federal Reserve Board FEDS Paper, September 2025
Active PQC Protection Initiatives
Hunter Beast's proposal introduces a new SegWit v3 output type (bc1r…) using post-quantum signatures (ML-DSA or FALCON-512). Requires a soft fork. Removes the quantum-vulnerable key-spend path from Taproot.
Two complementary paths: EIP-4337 Account Abstraction (live) lets smart-contract wallets verify PQC signatures today. EIP-7702 (Pectra) allows EOAs to delegate to contract code, enabling PQC signing without a full migration. The Ethereum Foundation PQC team is researching a future protocol-level replacement (STARK-based or lattice-based signatures).
No ratified SIMD (Solana Improvement Document) for PQC yet. The core challenge is structural: Solana addresses are Ed25519 public keys — there is no hash layer to hide behind. Community proposals explore new PQC-keyed account types requiring users to explicitly migrate all assets and positions.
SIMD repository