Repository navigation
M0.1 Benchmark: WASM-SIMD secp256k1 verify throughput in Web Workers #2
Description
Part of #1 (M0). This is the single most important number in the project.
Goal
Measure ECDSA and Schnorr verifications/sec using a WASM-compiled libsecp256k1, single-core and scaled across N Web Workers, on real signatures pulled from mainnet blocks.
Why
Whether full validation is hours or days hinges on this. The engine's current crypto is pure JS (~20-100x too slow); the node needs WASM secp. Everything downstream is speculative until this is measured.
Benchmark / acceptance
- Report verifies/sec/core (ECDSA and Schnorr), with and without WASM SIMD.
- Report total throughput scaling 1..N workers (near-linear?).
- Report the x-factor vs native libsecp on the same machine.
- Use real signatures from downloaded blocks, not synthetic.
- Confirm: >= ~10k verifies/sec/core in WASM, scaling roughly with core count.
Notes
Use an existing WASM build of libsecp256k1. Output feeds M0.5's revised time model.
Activity
melvincarvalho commentedon Jun 18, 2026
Measured (single core, this dev machine), via
npm run bench:secp(bench/secp-verify.js):secp256k1.js)tiny-secp256k1)WASM is 16x the pure-JS engine. Projected full-chain signature work (~2.5B ECDSA verifications):
This revises the roadmap model down. I had estimated ~10k verify/s/core and ~3h on 24 cores; the real
tiny-secp256k1figure is ~3,840/s. The gap is per-call JS↔WASM marshalling overhead, which makes this WASM ~5-10x off native (not the 1.5-2x kernel figure).Conclusions:
tiny-secp256k1does neither, so it is a floor, not a ceiling.Next: benchmark a batched / SIMD secp before committing to block validation.