Note: This library is still in active development and is subject to breaking changes
Though there is a wide variety of Proof of Work algorithms, finding the technical details for the implementations is quite a task. Both Kawpow and Firopow are variations off of ProgPow, though finding the exact differences is no easy task. This is meant to be a unified library to make the implementation of existing Proof of Work algorithms easier.
All DAG-based algorithms only implement a light DAG, which is sufficient for verification
but not full nodes or miners. For the DAG-based algorithms and verthash, data is cached in ~/.powcache.
Ethash will generally be between 40-80Mb per epoch (and generally 3 caches are stored), but verthash
requires a strict 1.2Gb, so be careful if you're using verthash in memory. At the time of writing, running
make test will throw about 2.2Gb of data into ~/.powcache due to the variety and breadth of tests.
The estimated hash times are meant to be relative since it can vary across different hardware. All tests were run with the respective DAG already calculated. In almost all cases hashing functions are the bottleneck (which is how PoW algorithms are designed to behave).
| Algorithm | DAG | Estimated Hash Time |
|---|---|---|
| Ethash | yes | 4ms |
| Etchash | yes | 4ms |
| Kawpow | yes | 17ms |
| Firopow | yes | 18ms |
| Verthash | yes | 8ms disk, 270μs in memory |
| Equihash | no | 30μs |
| Autolykos2 | no | 580μs |
Most profitable Proof of Work chains nowdays use some sort of DAG, and that is almost always the Ethash DAG. There are then layers on top of the Ethash DAG like ProgPow, which can be considered both a Proof of Work algorithm and a class of algorithms (Kawpow, Firopow). There isn't really a good way to organize all of these into a given structure but even if there was, a new algorithm could appear tomorrow and break that structure. powkit takes the approach of allowing most parameters to be varied and will implement new algorithms on an as-needed basis.
Currently, though powkit is used in production internally, it probably isn't a good idea to use yourself. The API is still in flux and each minor version will probably be breaking. Once we do a v1.0.0 release, the structure will probably be pretty set in stone. Hopefully that will happen in the next few months.