PoW performance

Posted May 26, 2021 by Aravinth Manivannan ‐ 3 min read

Last Edited September 1, 2021

We are mCaptcha. We build kickass CAPTCHA systems that gives (DDoS) attackers a run for their money. And we do all of this without tracking your users. Oh and did I mention our UX is great?

mCaptcha uses a proof-of-work(PoW) mechanism to rate limit users or potential bots. In order for this to be effective, the PoW should be configured properly. The difficulty requirement can’t be too high, as it could cause accessibility issues on the client-side while at the same time, it shouldn’t be too low, as it wouldn’t offer proper protection against bots.

Malicious bots(the ones that wreak havoc), run native code which is capable of running in a multi-threaded context. This creates an unfair advantage for crackers using these bots over legitimate users, who usually use browsers to access a website.

I wanted to see how much of an advantage a native program would have over our WASM library.

Benchmark tools

So I wrote these to compare native and WASM performances:

Results

The tests were run on my development machine featuring an Intel Core i7-9750h.

Native

DifficultyRealUserSys
500000m0.040s0m0.040s0m0.000s
3000000m0.122s0m0.122s0m0.000s
5500000m0.124s0m0.119s0m0.003s
8000000m0.123s0m0.118s0m0.003s
10500000m0.933s0m0.932s0m0.000s
13000000m1.227s-0m0.007s
15500000m1.260s0m1.256s0m0.003s
18000000m1.243s0m1.242s0m0.000s
20500000m2.524s0m2.510s0m0.000s
23000000m2.545s0m2.543s0m0.000s
25500000m2.561s0m2.551s0m0.004s
28000000m2.555s0m2.540s0m0.006s
30500000m2.513s0m2.508s0m0.000s
33000000m2.484s0m2.481s0m0.000s
35500000m2.643s0m2.642s0m0.000s
38000000m2.663s0m2.661s0m0.000s
40500000m2.663s0m2.660s0m0.000s
43000000m2.689s0m2.683s0m0.004s
45500000m2.688s0m2.686s0m0.000s
48000000m2.517s0m2.509s0m0.003s

Browser

I ran the tests on both Firefox and Chromium to compare results

Firefox

  • User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0
  • Hardware concurrency: 12
DifficultyDuration(in ms)
500000401
1000000413
1500000398
2000000394
25000001495
30000001556
35000003971
40000004235
45000004116

To be fair, my Firefox installation is loaded with a gazillion extensions while the Chromium instance is clean, as I don’t use it much

Chromium

  • User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36
  • Hardware concurrency: 12
DifficultyDuration(in ms)
500000399.40000000037253
1000000354.6000000014901
1500000351.19999999925494
2000000353.80000000074506
25000001337.800000000745
30000001311.199999999255
35000003417.5999999996275
40000003488.800000000745
45000003458.2999999988824

Conclusion

At the highest difficulty factor, the native implementation was a almost second faster than the WASM library. But the fact that both of them were able to run to completion in under 5 seconds is impressive!

So, in my opinion, native implementation is only slightly faster than the WASM library and for all intents and purposes, this shouldn’t matter much.


P.S Work is underway to benchmark multiple platforms. A detailed report will be published when that data is available.

For this post, I asked some of my friends to run the tests on their computers. The results slightly varied but even the slowest case generated proof for 4500000 difficulty(the highest in this test), in under 15 seconds!

Edit this page on GitHub