This is part of our series on a year of Bittensor experience, leading up to our anniversary at the 13th of July. After discussing miner archetypes we now discuss incentive landscapes, before moving on to validator design. After discussing the Dirac, the flat and a hybrid incentive landscape, we try to find criteria for an incentive design that does work. Please let us know what you think in our Discord channel!
An optimal incentive landscape is not easy to design. Miners should want to mine on one UID only. Idle miners should not be rewarded for doing nothing. Miners should not get rewards by pure luck. Miners should not be able to monopolize the subnet. From these and other criteria we can try to distill some rules we can then apply to the subnet we are trying to build. There are so many angles to this that the article touches on many seemingly unrelated aspects.
Subnets that provide a service in volume (“bandwidth”) have to be careful to not fall into the flat-incentive trap. If the amount to earn per miner is capped, miners have every incentive to accumulate registrations, leading to a monopoly as described before. This leads to the conclusion that there should be no cap on the incentive per miner, and that a single miner should be scored both on quality and volume. This in turn implies that an (implicit, fixed) rate limit per miner is not preferable. It also implies that rewarding responses to an endless stream of “synthetic challenges” is not such a good idea.
Still there could be an incentive for a miner to register multiple UIDs, openly or covertly. Getting rid of this behavior in a decentralized system is hard. One way is to not reward absolute quality and volume (as percentage of total quality and volume) but to also factor in the score of a miner relative to the miners below them on the scoreboard. This way, registering a second UID would hurt earnings of the first UID; and it should hurt more than the second UID makes up for. This however requires careful design and simulation, as it can easily become an exploitable feature for the optimizing and/or rogue miner – so it’s probably not a good idea.
Another approach is to incentivize miners to collect their winnings on one UID, e.g. by rewarding longevity in some way. We have seen moving averages being applied to miner scores, which may appear to do such a thing, but mathematically they don’t. The goal is to have “1+1=3” logic so that a miner would always want to focus all his effort on one UID, rather than to split his earnings over multiple UIDs. In “bandwidth” subnets providing a service in volume, a miner can also be rewarded by increasing his rate limit after success, growing his earning capacity. This would also help manage validator load, by not allowing it to be flooded by clueless miners. Again, this all requires careful design, but we think it can be done.
A huge factor in logic such as described here, is that the blockchain does not provide support for it; the miner state that is required, is local to the validator. This is one important reason to consider running one validator only – but that is a topic for a later article.
The next question is how to avoid the downsides of a winner-takes-all mechanism in subnets that do have one clear winner. The incentive mechanism could reward the top-N miners of the last day or week with some non-zero amount, while giving those below the top-N zero incentive, so that only their UIDs can be recycled. Rewarding the number 2..N miners might also help keeping them engaged.
Blockchain skill is a related topic. There are subnets where the battle isn’t about mining anymore, but rather about who has the skill to register all UIDs, or to register a particular range of (typically low) UIDs, or post their commitment before others. This logic is built into the chain and almost impossible to eliminate for a subnet owner. What an owner can do, as a solution of last resort, is to pre-register hotkeys and hand them out to aspiring miners at his own discretion. The validator can keep the keys alive with a non zero weight, while poorly performing miners do get zero weight and will be deregistered. This effectively implements fine-grained miner immunity control in the validator code, on top of the immunity provided by the underlying blockchain. Using coldkey-swap the handover from subnet owner to miner can be done in a safe manner. Vetting the aspiring miners is then up to the subnet team. The subnet team hopefully has the required blockchain skill to keep their stock of registered hotkeys filled, even if someone is trying to monopolize the subnet.
Hopefully the measures discussed earlier can prevent unwanted behavior to occur in the first place.
The next articles will discuss validator design.
0 Comments