Why and How I Plan to Change the Mining API
Notice to miners: Some users have figured out how to mine automatically using the EarthBucks API. If this is you, please read this post. I plan to change the mining API to reduce the load on the database instance. Most likely, I will not provide both APIs simultaneously due to the difficulty of maintaining two separate APIs. Therefore, please be prepared to switch to the new API when it is released.
I am using PlanetScale for the database, which is a managed Vitess/MySQL provider. Very quickly after launching EarthBucks, as more people joined and started mining, I had to update the database instance from the base configuration at $40/mo by eightfold to a $179/mo configuration. This rapid increase in cost is why I started working on Identellica, a separate identity verification service that will be integrated into EarthBucks and provides a way for me to start earning fiat currency to pay for server costs, and it is also why I have decided to change the mining API. Without charging fiat currency and changing the API, the growth of this project would quickly overwhelm my ability to subsidize it.
The problem with the current API is as follows. Every single button swipe requests a “workpack” from the server. Each workpack requires writing the workpack to the database. The miner then works on the workpack and returns the result to the server. Both invalid and valid shares require additional updates and writes to the database. All of these writes and updates are extremely expensive in terms of database resources. At this moment, the most expensive database query is adding new shares to the database, which happens for every swipe. The other most expensive queries are updating these shares.
The way I designed this API is not optimal and it can be improved significantly to reduce the load on the database. Instead of writing every single share to the database for each swipe, the API should instead get only recent mining data and build a signed workpack for the miner. The signed workpack does not need to be written to the database. Only when the workpack is returned as valid will it need to be written to the database. This approach should reduce the load on the database by a significant amount, possibly by an order of magnitude or so.
As I roll out the Identellica integration, which will allow automatic mining, I will also be updating the mining API. I plan to make the changes to the API before I enable automatic mining, because if I don’t, the database load is likely to increase even further. Thus, before enabling automatic mining, it is best to make the API changes to reduce the load on the database first.
As stated, it is most likely that I will not provide both APIs simultaneously due to the difficulty of maintaining two separate APIs. Therefore, please be prepared to switch to the new API when it is released. I will continue to provide updates on this blog as I make progress on this project.