Secp256k1 Performance
Performance characteristics, benchmarks, and optimization strategies for elliptic curve operations.Operation Costs
Relative Complexity
| Operation | Algorithm | Typical Time | Complexity |
|---|---|---|---|
| Hash (Keccak256) | Sponge construction | ~0.01ms | O(n) input size |
| Public key derivation | Scalar multiplication | ~0.5-1ms | O(log n) bits |
| Signing | Scalar mult + modular ops | ~1-2ms | O(log n) bits |
| Verification | 2× scalar mult + point add | ~2-3ms | O(log n) bits |
| Recovery | Sqrt + 2× scalar mult | ~2-4ms | O(log n) bits |
TypeScript Benchmarks
@noble/curves (v1.2.0)
Measured on MacBook Pro M1 (Node.js v20):- Derivation: 0.4-0.6ms per public key
- Signing: 1.0-1.5ms per signature
- Verification: 2.0-3.0ms per signature
- Recovery: 2.5-3.5ms per recovery
Comparison: noble vs libsecp256k1
| Operation | @noble/curves | libsecp256k1 (C) | Ratio |
|---|---|---|---|
| Derivation | 0.50ms | 0.20ms | 2.5× slower |
| Signing | 1.25ms | 0.50ms | 2.5× slower |
| Verification | 2.50ms | 1.00ms | 2.5× slower |
Zig Benchmarks
Native Build (ReleaseFast)
Measured on MacBook Pro M1:- Derivation: 0.15-0.25ms per key
- Signing: 0.40-0.60ms per signature
- Verification: 0.80-1.20ms per signature
WASM Performance
ReleaseSmall vs ReleaseFast
| Operation | ReleaseSmall | ReleaseFast | Native TS |
|---|---|---|---|
| Derivation | 2.5ms | 1.2ms | 0.5ms |
| Signing | 4.0ms | 2.0ms | 1.2ms |
| Verification | 6.0ms | 3.5ms | 2.5ms |
- ~2× faster than ReleaseSmall
- Larger bundle size (~50KB vs ~30KB)
- Use for compute-intensive applications
- Slower but smaller bundle
- Use for bundle-size-sensitive web apps
EVM Precompile
ecRecover (Address 0x01)
Gas cost: 3000 gas (fixed) Performance at 50M gas/sec:- 3000 gas / 50M gas/sec = 60 microseconds
- ecRecover precompile: 0.06ms (fastest)
- Zig native: 0.8-1.2ms (15-20× slower)
- TypeScript @noble: 2-3ms (30-50× slower)
- WASM ReleaseFast: 3-4ms (50-60× slower)
Optimization Techniques
Batch Operations
Point additions can be batched for multiple verifications:Precomputation
For repeated operations with same generator point G:Windowed NAF (wNAF)
Non-Adjacent Form reduces point operations: Standard binary method:Hardware Acceleration
Not available for secp256k1 (no CPU instructions):- Intel SHA-NI: SHA-256 only
- ARM Crypto Extensions: AES, SHA only
- No native ECC instructions
- Algorithm improvements (wNAF, precomputation)
- Memory access patterns (cache-friendly)
- Compiler optimizations (SIMD autovectorization)
Bottlenecks
Modular Arithmetic
Elliptic curve operations require modular arithmetic modulo large primes: Field prime (p): 2²⁵⁶ - 2³² - 977 (256-bit) Curve order (n): 2²⁵⁶ - ~2³² (256-bit) Expensive operations:- Modular multiplication: ~100-200 CPU cycles
- Modular inversion: ~10,000-20,000 cycles (Extended Euclidean algorithm)
- Modular exponentiation: Variable (used in square root)
Point Operations
Point addition (different points):- 2 modular inversions
- ~12 modular multiplications
- ~4 modular additions/subtractions
- 1 modular inversion
- ~8 modular multiplications
- ~6 modular additions/subtractions
Scalar Multiplication
For 256-bit scalar k, double-and-add requires:- ~256 point doublings (worst case)
- ~128 point additions (average, half bits are 1)
- Total: ~384 point operations
Real-World Performance
Web Application
- <100ms: Imperceptible
- 100-300ms: Slight delay, acceptable
- >300ms: Noticeable lag, consider async
High-Throughput Server
- Use native library (libsecp256k1)
- Implement batch verification
- Parallelize across CPU cores
Blockchain Node
Ethereum mainnet processes ~15 transactions/second: Per block (12 seconds):- ~180 transactions
- 180 signature verifications required
- Total: 180 × 2.5ms = 450ms
- Well within 12-second block time
- ~30-50 TPS
- ~600 verifications per block
- Total: ~1.5 seconds (still manageable)
Optimization Recommendations
Web Applications
✅ Do:- Use @noble/curves (battle-tested, good performance)
- Sign in main thread (1-2ms imperceptible)
- Verify in Web Worker if processing many signatures
- Use WASM if bundle size not critical
- Implementing custom crypto
- Blocking UI thread for batch operations
- Unnecessary verifications (cache results)
Node.js Services
✅ Do:- Use @noble/curves for simplicity
- Consider libsecp256k1 bindings for 2-3× speedup
- Batch operations when possible
- Use worker threads for parallelization
- Synchronous crypto in request handlers (use async)
- Re-deriving public keys (cache them)
Smart Contracts
✅ Do:- Use ecRecover precompile (3000 gas)
- Validate signatures off-chain when possible
- Batch signature checks to amortize cost
- Implementing ECDSA in Solidity (expensive, error-prone)
- Unnecessary on-chain verifications
- Unvalidated ecRecover results (check != 0x0)
Related
- Signing - ECDSA signing implementation
- Verification - Signature verification
- Security - Constant-time requirements
- Test Vectors - Benchmark validation

