Kaspa Keccak on Windows gained an assembly-backed path for x86-64 systems when rusty-kaspa pull request #694 was merged. The contributor’s three microbenchmarks reported about 20% lower execution time for selected proof-of-work hash routines. That result concerns isolated hashing operations on one test environment; it is not evidence that a full node, wallet, or miner became 20% faster overall.
Key takeaways
- PR #694 extended the existing x86-64 Keccak assembly approach to Windows build environments.
- The patch added assembly sources for MinGW/GNU and MSVC-style Windows targets and updated target selection in
build.rs. - The author measured 19.9%–21.1% lower times across three
kaspa-hashesmicrobenchmarks. - Non-x86-64 targets and builds using the
no-asmfeature retain a portable implementation path. - Microbenchmark improvement must not be converted into an overall node-performance, mining-profit, or KAS-price claim.
What changed for Kaspa Keccak on Windows?
Kaspanet merged rusty-kaspa pull request #694 on November 2, 2025. GitHub records 2,336 additions, 45 deletions, and eight changed files. Most added lines are platform-specific assembly sources rather than a broad rewrite of node logic.
Before the change, the hashes crate selected the portable Keccak dependency on Windows even when compiling for x86-64. The patch changed the conditional compilation so x86-64 builds can use assembly unless the no-asm feature is selected. Its build script now examines target architecture, operating system, and target environment to choose an ELF, macOS, MinGW/GNU, or MSVC-compatible source.
The contributor said the approach was adapted from an earlier kaspa-miner assembly commit. During review, a Kaspa maintainer compared the relevant files against that implementation before approving the change.
What did the published benchmarks actually show?
The pull request ran cargo bench -p kaspa-hashes once with --features no-asm and once with the default assembly path. It published these Criterion-style results:
| Benchmark | Reported time with optimized build | Reported change |
|---|---|---|
| PoWHash including timestamp | 225.16–225.86 ns | 19.89%–20.50% lower |
| PoWHash without timestamp | 220.29–221.19 ns | 20.51%–21.10% lower |
| KHeavyHash | 215.44–216.02 ns | 19.94%–20.64% lower |
All three comparisons were labeled improved with p = 0.00 < 0.05 in the posted output. The benchmark also reported between five and eight outliers among 100 measurements, which is why preserving the ranges and test context is more informative than publishing a single rounded number.
These are contributor-supplied measurements. The PR does not identify a universal CPU model, Windows toolchain, power profile, or background workload, so another machine can produce different absolute times and relative gains.
Why can assembly execute this hash path faster?
Keccak-f[1600] repeatedly transforms a fixed-size state using bitwise operations and rotations. Carefully selected x86-64 instructions and register use can reduce overhead compared with a general-purpose implementation compiled for many architectures. Platform-specific assembly can also follow each object format and calling convention directly.
The tradeoff is maintenance surface. Separate assembly files must continue producing exactly the same digest as the portable path across supported toolchains. Build selection must be correct, and reviewers need to track upstream code provenance. Faster incorrect cryptography would be a consensus failure, so output equivalence and cross-platform testing matter more than the headline timing.
The merged change used the assembly path by default where supported and retained no-asm as an explicit alternative. That fallback helps unsupported architectures, troubleshooting, and comparative testing.
Does this make a Windows Kaspa node 20% faster?
No such conclusion appears in the evidence. A full node spends time on networking, BlockDAG and consensus processing, database reads and writes, transaction validation, RPC handling, synchronization, and many other hash and non-hash operations. A roughly 20% improvement in one microbenchmark only affects total runtime in proportion to how much of the real workload uses that exact path.
Measure an operator-relevant task—such as controlled synchronization, steady-state CPU use, or a fixed validation workload—before making a node-level claim. Keep software revision, data set, peers, hardware, and configuration constant. Our analysis of the 158 million transaction stress test applies the same rule: a narrow metric cannot answer every performance or market question.
What should builders and operators verify?
Builders should confirm the target triple, compiler environment, enabled Cargo features, and test suite. A Windows x86-64 MSVC build and a Windows x86-64 GNU build do not necessarily consume the same source file. Non-x86-64 builds should take the portable path. Record the binary checksum and exact rusty-kaspa revision when comparing results.
Operators using official release binaries should consult that release’s notes rather than assuming a merge-date change is present in every download. No user-facing flag is required to “turn on” the default supported assembly path, while explicitly using no-asm is a build-time decision.
Small data-structure changes can have similarly narrow scopes. The separate guide to Kaspa script vector optimization explains why implementation efficiency should be evaluated at the layer it actually changes.
Frequently asked questions
Is Keccak the same as every hash Kaspa uses?
No. The pull request concerns the Keccak permutation used inside specific routines in the kaspa-hashes crate. It does not mean every cryptographic or consensus operation follows this implementation.
Does the optimization change valid hash outputs?
It must not. Assembly and portable implementations are alternative execution paths for the same deterministic result. The source change targets speed and platform support, not consensus semantics.
Can the benchmark predict mining revenue or KAS price?
No. It measures nanosecond-scale software routines in a particular test. Mining outcomes involve network hash rate, hardware, energy, pool conditions, difficulty, and other variables; market prices depend on an entirely different set of supply-and-demand factors.
Source and verification note
This report uses merged rusty-kaspa PR #694 as its primary source. The merge date, changed files, Cargo feature conditions, assembly targets, review comparison, benchmark commands, ranges, percentage changes, p-value display, and outlier counts were checked against the public PR and diff. The approximately 20% figure is intentionally labeled a microbenchmark result, not independently reproduced end-to-end performance. Verify current source and release artifacts before relying on platform behavior.
