BLS Signatures
BLS (Boneh-Lynn-Shacham) signatures are short signatures with efficient aggregation properties, enabling thousands of validator signatures to be compressed into a single 96-byte signature. This is the foundation of Ethereum 2.0’s consensus mechanism.Overview
BLS signatures leverage the bilinear pairing property of BLS12-381 to enable:- Short Signatures: 48 bytes (G1) or 96 bytes (G2)
- Aggregation: Combine n signatures into one without coordination
- Batch Verification: Verify multiple signatures in a single pairing check
- Deterministic: Same message + key always produces same signature
Signature Schemes
Two standard schemes exist, differing in signature/pubkey group placement:Minimal-Signature-Size (Ethereum Standard)
- Signatures: G1 points (48 bytes compressed, 96 bytes uncompressed)
- Public Keys: G2 points (96 bytes compressed, 192 bytes uncompressed)
- Advantage: Smaller signatures (critical for blockchain bandwidth)
- Use Case: Ethereum 2.0 validators
Minimal-Pubkey-Size (Alternative)
- Signatures: G2 points (96 bytes compressed)
- Public Keys: G1 points (48 bytes compressed)
- Advantage: Smaller public keys
- Use Case: Identity systems with many keys
Basic Operations
Key Generation
Signing
Verification
BLS verification uses pairing check:Hash-to-Curve
Converting messages to G1 points is critical for security:- Domain Separation Tag (DST): Prevents cross-protocol attacks
- Expand-Message-XMD: SHA-256 based expansion
- SSWU Map: Simplified SWU mapping to curve
Signature Aggregation
Non-Interactive Aggregation
Multiple signatures can be combined without coordination:- Order-independent (addition is commutative)
- Size constant (always 48 bytes compressed)
- No interaction required between signers
Aggregate Verification (Same Message)
When all signatures are on the same message:Batch Verification (Different Messages)
When signatures are on different messages:- Individual: ~2ms per signature × n
- Batch: ~2ms + ~23ms per pair (much faster for large n)
Security Considerations
Rogue Key Attacks
Problem: Attacker chooses pubkey_attack = pubkey_target - pubkey_honest- Aggregated pubkey = pubkey_honest + pubkey_attack = pubkey_target
- Attacker can forge signatures for target’s key
Domain Separation
Different signature types must use different DSTs:Point Validation
Always validate deserialized points:Ethereum 2.0 Usage
Validator Signatures
Sync Committee Aggregation
Performance
Native (BLST):- Key generation: ~80 μs
- Signing: ~100 μs
- Verification: ~2 ms
- Aggregation (100 sigs): ~1.5 ms
- Aggregate verification: ~2 ms (vs 200ms individual)
- Batch verify when possible
- Precompute hash-to-curve for known messages
- Use compressed point formats for storage
- Cache public key aggregations
Test Vectors
See BLS Test Vectors for official test cases.Related
- Aggregation Strategies - Advanced aggregation patterns
- Pairing Operations - Bilinear pairing details
- Security Best Practices - Comprehensive security guide

