This thread is meant to combine the research efforts regarding the possibility of using RandomX as our Plasma PoW algorithm.
In my ongoing research into Metamask Snaps and wallet provider services, I’ve also taken a look at how RandomX PoW would work in that context and I want to share some of the insights I’ve gained.
Background
Our current plasma PoW hashing algorithm is SHA3-256 and this hash algorithm is fine for our current network utilization rate. Since SHA3-256 isn’t an ASIC-resistant algorithm, it would be possible to create an ASIC for it, resulting in PoW generation speeds so high that it would render PoW generation on consumer hardware pointless.
Building such an ASIC isn’t worth it right now, but it can be argued that in a highly utilized, multi-billion dollar network, network throughput would be so valuable that there would be sufficient economic incentive to build such an ASIC.
RandomX is an (very good) attempt at a maximally ASIC-resistant PoW algorithm. The potential gain in speed from purpose built hardware for RandomX is limited, because of how the algorithm has been designed. Ideally with RandomX, we could be more certain that PoW generation on our network is feasible on hardware that’s readily available to consumers even with high network utilization. This is a significant benefit that RandomX could provide.
Mr. Kaine has also repeatedly advocated using RandomX as the PoW algorithm for plasma generation on our network once we implement dynamic plasma.
Downsides and potential issues with RandomX
While RandomX has many of the qualities we want (primarily the ASIC-resistance), it has some potential problems for us.
RandomX is a resource intensive algorithm. To run the algorithm in the so called “fast mode”, it requires at least ~2.5 GiB of RAM. During my testing of the RandomX algorithm I noted that initializing the RandomX VM in fast mode took around 30 to 60 seconds and this is with a relatively powerful computer. With lower end hardware this time most likely increases.
This means that using the fast mode for PoW generation on clients will increase the waiting time for the user, since whenever PoW needs to be generated, the VM has to be initialized first.
One option would be to keep the VM in memory all the time so that it only needs to be initiliazed once at startup, but Syrius is already a memory hog. A total RAM requirement of 5-10 GiB to run Syrius and an embedded node is not ideal if we’re targeting regular consumer computers.
This also poses challenges on mobile devices that have limited memory and due to other requirements of the algorithm, it is completely unfeasible to run RandomX in browser environments.
The alternative to fast mode is light mode. Light mode runs at a much lower hashrate, but the initialization time is much faster - only around 2 seconds on my computer. Light mode only requires 256 MiB of RAM so it is much more suitable for regular consumer hardware.
On my computer the fast mode appears to be around 5x faster than the light mode. So the question is, can clients run in light mode and maintain a fast enough hashrate to generate PoW in a reasonable amount of time?
For the sake of comparison, someone using an expensive high end CPU can reach a hashrate that is over 20 times faster than on a low end consumer laptop. If the consumer laptop is running the algorithm in light mode, the difference in speed can be 100x. With ten high end CPUs the difference can be 1000x.
These aspects should be taken into account when we consider what the role of PoW is in dynamic plasma.
RandomX PoW generation proof-of-concept
Here’s a minimal PoC implemenation of our client PoW generation library that has been modified to use RandomX instead of SHA3: GitHub - hypercore-one/znn-pow-links-cpp at randomx-poc
