ECDSA vs EdDSA vs BLS
The three signature schemes you'll meet across the crypto stack — what each does well, what tradeoffs they impose, and why Ethereum uses three of them simultaneously.
Why Three Schemes?
Almost every cryptocurrency transaction is authorised by a digital signature. The math behind that signature can use different schemes, each with its own performance, security, and feature profile. The three you'll meet most often are ECDSA (Bitcoin, Ethereum's externally-owned accounts), EdDSA (Solana, Cardano, many newer chains), and BLS (Ethereum's consensus layer, Filecoin, Chia). Knowing the difference helps you understand why some chains can aggregate millions of signatures into one and others can't.
ECDSA — The Bitcoin Original
ECDSA (Elliptic Curve Digital Signature Algorithm) on the secp256k1 curve is what Bitcoin chose in 2009 and what every EOA on Ethereum still uses. It's well-understood, widely deployed in hardware (every YubiKey, every TPM), and supported by every wallet and library. The catch: it requires good randomness during signing (a deterministic variant, RFC 6979, fixes this), can't aggregate easily, and verification is moderately expensive.
EdDSA — Cleaner and Deterministic
EdDSA (Edwards-curve Digital Signature Algorithm) on Ed25519 was designed in 2011 to fix ECDSA's footguns. Signing is deterministic by default (no randomness needed, so no risk of leaking the key via bad RNG), verification is faster, and the API is simpler. Solana, Cardano, Stellar, Near, and most chains designed after ~2015 use it. The catch: it doesn't aggregate well either, and it's less universally supported by old hardware.
- ECDSA (secp256k1): Bitcoin, Ethereum EOAs, classic web crypto
- EdDSA (Ed25519): Solana, Cardano, Stellar, Near, Polkadot, modern wallets
- BLS (BLS12-381): Ethereum consensus, Filecoin, Chia, Aleo, threshold protocols
- All three give you 'I have the key, here's a signature' — the differences are about cost, determinism, and aggregation
Key Takeaways
- Three dominant schemes: ECDSA (Bitcoin/ETH-EOAs), EdDSA (most modern chains), BLS (consensus + aggregation)
- ECDSA needs careful randomness; EdDSA is deterministic by design
- BLS uniquely allows aggregating many signatures into one — critical for Ethereum's million validators
- You'll see all three in production crypto code; they're not competing, they fit different niches
Related Content
More Topics
Browse all 179 topicsAccount Abstraction (ERC-4337)
How ERC-4337 brings smart-contract wallets, social recovery, gasless transactions, and arbitrary signature schemes to Ethereum without changing the protocol — and why every wallet UX of the next decade will use it.
Data Availability Sampling
How light nodes can be cryptographically confident that a block's full data was published — without downloading it — and why this is the key unlock for Ethereum's full danksharding and the modular blockchain stack.
Finality and Fork Handling
What it means for a transaction to be 'final,' why different chains finalise differently, how reorgs happen, and the MEV incentives that complicate the picture.
State Pruning and Expiry
Why Ethereum's state has grown to hundreds of gigabytes, what 'archive,' 'full,' and 'light' nodes actually store, and how proposals like EIP-4444 and Verkle trees aim to keep node hardware accessible for years to come.
zk-SNARK vs zk-STARK vs PLONK
How the three major proof-system families compare on trusted setup, proof size, prover cost, and quantum resistance — and which production rollups picked which.
Threshold Signatures and MPC
How t-of-n threshold signatures and multi-party computation let multiple parties sign together without any one holding the full key — the cryptography behind Fireblocks, Lit Protocol, and modern institutional custody.
Verifiable Random Functions
How VRFs produce randomness that's both unpredictable before commitment and cryptographically verifiable after — enabling fair lotteries, leader election, and on-chain randomness without trusted parties.
Hash Functions Compared
SHA-256, Keccak-256, Blake3, and Poseidon — which one each chain uses, why ZK systems needed a new family of 'arithmetic-friendly' hashes, and what tradeoffs each makes.
References & further reading
- secondary
- secondary