This is part of our series on a year of Bittensor experience, leading up to our anniversary at the 13th of July. We discuss 9 miner archetypes before digging deeper into incentive landscapes. After describing the honest, the rogue, the calculative, the blockchain-savvy, and the overfitting miner, we now discuss the devops miner. Slowly, the contours of proper subnet design are taking shape. Please let us know what you think in our Discord channel!
Sometimes you can be creative in optimizing, without breaking (or even touching) any functionality. In one subnet, bandwidth and response time between validator and miner was a thing, and miner results were sent to the validator via a URL via which >100 mb needed to be shared. It turned out to be most efficient not to use a third party “bucket” for remote storage, but to host the result on the miner itself, saving a costly data round-trip.
To further enhance response times:
- a virtual server was rented in the same rack (or on the same machine even?) as the only functioning validator (1 Gbit local Ethernet, hard to beat)
- ip addresses were used in the URL to eliminate DNS lookup
- http was used to eliminate SSL handshake
- the result file was served by a script that would delay up to five minutes if the result file wasn’t ready yet (the submission time of the URL was measured; not the download)
- a high availability approach was taken to minimize miner downtime*
This of course had nothing to do with actual quality of submission, but it allowed the miner to earn more than miners that used the official miner code on their own infrastructure that relied on third-party hosting. All the while, nobody could see how this miner pulled it off, except for the subnet owner, who was apparently too busy doing other subnet owner things.
Although these tricks may sound harmless, this behavior may be detrimental, indirectly, to the subnet, if nobody recognizes the tricks employed. It may obscure issues other miners experience with time-outs, for example. Here, again, proper and transparent logging is key, so that other miners can see all aspects of the winning submission.
(* side note: High availability was a challenge here, because the hosting provider chosen by the only functioning validator was pretty bad at his core business. The only validator being hosted on unreliable infrastructure was one of the big flaws of the subnet.)
Stay tuned for the (over)analyzing miner!
0 Comments