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. The previous article discussed the honest miner. Please let us know what you think in our Discord channel!
Some validator codebases are so badly written, that they are easy to crash by a single miner submitting a specially crafted commitment, or by slowing the validator down by drowning it in submissions.
Validator code should treat any data as untrusted and adversarial. By crashing the validator at precise moments, some miners have been able to maximize earnings. The optimal moment to trigger a crash is when the rogue miner is in a winning position, and the subnet team is known to be inactive (e.g. sleeping). The miner UID initiating the crash, does not have to be the miner that is winning – it doesn’t have to be very clear who is doing what and whether the issues are triggered intentionally. Long live decentralization.
A particular subnet’s validator code was so badly written, and contained so many obfuscating layers, added in such a rush, that this trick could be repeated day after day. It was a game of whack-a-mole between miners and subnet owners. The upside was that the validator code was hardened within a week. Most miners – even those that initially lose incentive – seem to judge this as fair play and see such winnings as a fair bounty for uncovering and exposing bugs. A bug bounty program may provide the same effect, without the downtime.
Complicated calculations in scoring mechanisms can get so out of hand, that, despite the code being littered with try-except, significant issues can be triggered by a rogue miner. Such issues may for example force a particular (unforeseen) code path, messing up the internal scoring data structure. This in turn renders the miner ranking into a random mess, benefiting the rogue miner who may otherwise be struggling to stay afloat in a competitive landscape.
One lesson to be taken from this is that the validator code should contain very clear log messages, that the logs should be easy to find and analyze, that data is logged in a way that allows structured analysis, and preferably that even the contents of communication between validators and miners becomes public, for later scrutiny. The miners are often the ones debugging the validator, if not for their own immediate gain, then for lowering the gains of competing miners by fixing exploitable bugs.
The next article will discuss the calculative miner.
0 Comments