I do not understand that part.
In fact random mode is 9 times faster (or maybe it is better to say "more effective") than sequential (we test more valid keys), but we have no control over the work performed.
I'm confused now too:
On my dev card rtx3060 I have performance of about 8mln keys/s, which gives around 30k/s 'valid' keys,
Random mode works quite differently - using GPU we produce bunch of 'valid' keys and then we check all of them. That way we may check much more keys, but we are not able to verify if we do not have duplicates. The corresponding performance is about 600-750k/s.
The way I read it:
sequential 8M keys/s
random: 600-750 keys/s
It means that I am able to test 8mln mini-keys, but only 30k passed test (00) and I calculated public key + address. The benefit is that I know exactly which mini-keys were tested (so for example I may pause and resume work).
In random mode, I produce only valid mini-keys, so I receive 600k randomly generated valid mini-keys, which I test (public key + address). I do not know how many keys had to be tested to be able to produce desired bulk of valid keys, as I do not know if I do not test duplicated keys (but as you said before, the range is so big that it probably does not occur).
As we talk about misunderstanding:
Now let's build a dedicated ASIC device that does 0.5% of the
Bitcoin hash rate for testing keys. It's an round number: 10
18 keys per second. And we're not trying to crack all keys, just 1 out of every 5000 (which gives a reasonable chance to hit one of the 5000 funded addresses).
Now it only takes 58^21/10^18/5000/365/24/3600=68 million years to find a key. That makes mining Bitcoin blocks much more rewarding than cracking keys.
Maybe I had not enough coffee today.
You calculate only hashes/s - (number of sha256 operations)? We need 1 hash always - to exclude "wrong" mini-key, then we need second hash to produce private key. (We may say we need 257 hashes to have one private key to test). And then we must find public key for our private key - this is heavy and time consuming part. Later we talk again about hash needed to verify address, but as I observed operations on secp256k1 take majority of time.