validate-sync uses pure-JS secp256k1 (~25x slower) — WASM secp fails to load in Node

[melvincarvalho]

The full testnet4 validation took ~17.4h, and ~95% of that was ECDSA signature verification running on the pure-JS secp256k1 fallback instead of the WASM backend.

Root cause

loadSecpWasm() fetches the .wasm via fetch() on a relative path. That works in the browser but fails in Node (no relative-path fetch), so the verify backend silently falls back to the pure-JS secp256k1 — which is roughly 10–25x slower per verification than the WASM/libsecp path.

Impact (estimated)

• testnet4 has ~31.75M inputs to verify. At pure-JS ~1.8 ms/verify that's ~16h — which is essentially the entire 17.4h run.
• With WASM secp (~50–75 us/verify) the signature work would be ~40 min, dropping a full validation from ~17h to roughly ~1.5h.
• This is the realistic baseline; our 17h number is inflated ~10x by the slow fallback. (It also means most of the apparent "SwiftSync speedup" in our runs was actually "we stopped doing slow JS signature checks", not the accumulator.)

Fix

Make the WASM loader work under Node: read secp256k1.wasm from disk (e.g. readFile / fileURLToPath(new URL('./secp256k1.wasm', import.meta.url))) instead of fetch() when running in Node, and confirm the verify backend selects WASM (not the pure-JS fallback). Add a startup log line stating which backend is active so a silent fallback can't hide again.

Where

Engine WASM loader (wasm/secp-wasm.js in the kernel snapshot; canonical in bitcoin-desktop/schema). Symptom surfaces in node src/validate-sync.mjs.

[melvincarvalho]

Correction — this issue's premise is wrong; closing.

validate-sync.mjs already uses the fast WASM secp (setVerifyBackend(wasmBackend) via the node's own src/wasm-secp.js), not the pure-JS fallback. So the 17h run was not ~95% slow pure-JS signature verification, and the impact estimate here is incorrect.

The only real underlying observation: the engine's loadSecpWasm() uses fetch(), which fails in Node — but the node already works around that with src/wasm-secp.js, so it never affected validate-sync. Cleaning up the engine loader to work natively in Node is a minor, separate code-hygiene item, not a perf bug.

Where the 17h actually went needs profiling — likely fat-block decode/processing in the dense inscription regions (observed at ~0.27–2 blk/s), not signature verification. Not signature crypto.