Oct 3, 2026

Notice there is a sweet spot for dbcache. A formerly optimal 10GB (which we used in the last run) is no longer optimal. So I've reduced the config back to the default for this run. So there is less RAM consumed by in-memory utxo state but more time spent hitting the disk. The threadpool defaults to 8 (always) but that would very likely be too high for Jennings, a 4 thread machine, and they only reported 8-16 thread machines. The threadpool shares CPU with validation, and validation already runs at 100% CPU inside a block. While a naive look at CPU would show ~92% overall, this is an average of low CPU between blocks and nearly 100% CPU within blocks. So there's nothing to recover when the blocks are too small to max out CPU on script validation. And in those cases there's also not much to gain. The performance loss from sequential validation is in the time between blocks, including the ramp up and down of work dispatch within each block. That can't be recovered by creating a secondary dispatch of work within the block. It's work that each validator thread can just do on its own, with the same outcome and less complexity and less pool overhead. We don't do any parallelization within a block, that's far too granular of a dispatch, which would result in a lot of avoidable marshalling overhead. We just dispatch each block on its own thread, populate the prevouts of the entire block internal to the validation, and validate the whole block. We do dispatch the prevout population on a c++ parallel loop, but that doesn't compete with the block validation, it precedes it sequentially. It's the blocks validating concurrently that fill the gaps in the sawtooth CPU plot, allowing 100% actual utilization. The sweet spot scenario that this optimization provides is for a machine with high thread count and low memory. With high memory there is no benefit from the parallel disk reads (a deduction confirmed by their own numbers). The marshalling cost eats up the benefit of the small number of cache misses. And with low thread count the prefetch just competes with the validator. So there's no improvement in scalability and no benefit at the low end, which I expect we'll measure.