Dealing with Subnet Exploits

Developing a robust and hardened subnet on Bittensor is challenging. Subnet owners must constantly monitor activity within their subnet to understand if their incentive design is working as intended. Part of this process of subnet development and monitoring involves investigating the inevitable claims and evidence of exploitation of the subnet’s incentive mechanism. 

Each subnet has its own unique properties and design, so potential exploits will naturally differ across the ecosystem. However, we believe that a single, overarching framework regarding the processing of claims of subnet exploitation is beneficial to the entire community. It serves as guidance to subnet owners to ensure expectations are clear regarding emissions within their subnet, and it defines the expectations for those who bring forth claims of subnet exploitability.  

We’re designing a subnet exploit processing framework for the community to leverage. Below we identify and outline, at a high level, the expected process.

Evidence of Subnet Exploit

The burden of proof is on the entity claiming a potential subnet exploit is possible or is occurring. There must be data or clear evidence to support claims of an alleged exploit. This helps the broader community understand the situation, and it allows a subnet owner to investigate and respond to specific allegations. 

Subnet Owner Investigation

Once allegations and supporting evidence of a potential subnet exploit have been delivered, we expect the subnet owner to begin investigating the claims. 

If the exploit is affirmed by the subnet owner, then they should make a public statement acknowledging the exploit and pause registration until the exploit is resolved.

Pausing Subnet Registration

When registration is paused on a subnet, its emissions are recycled, meaning no subnet participants (i.e., subnet owners, miners, and validators) receive emissions. This ensures no one can benefit by actively attacking a subnet with a known exploit. With subnet registration paused, we will not remove weights from the subnet. However, if a subnet owner does not pause registration, we will likely remove weights from the subnet.

Subnet Owner Investigation Results

After a subnet owner investigates the exploit, we expect them to deliver documentation detailing what the exploit was and how they will adjust their subnet to remove the vulnerability. As a validator, this greatly assists us in expediting our review of the issue and helps us determine if we believe the issue will be fully resolved by the subnet owner adjustments. 

Overall, we want this process to promote transparency and open communication between subnet owners, the community, and validators like ourselves. To provide more clarity around this framework, we can consider two different scenarios.

Scenario 1

In this example, we assume an exploit is discovered, properly documented, and affirmed by the subnet owner. 

At this point, the subnet owner pauses registration on the subnet and begins assessing how to remove the attack vector. Once the subnet owner pushes a fix to the subnet that resolves the issue and documents how the issue is resolved, they proceed to unpause registration. 

In this scenario, we would not remove weights from this subnet as they are properly managing the process. The subnet and its participants benefit in this scenario since there is no disruption to subnet emissions after unpausing registration. 

Scenario 2

In this example, we assume a claim of an exploit is made with sufficient evidence warranting an investigation by the subnet owner, but they dismiss the claim. 

Additionally, since they don’t acknowledge there is an issue, the subnet owner also neglects to pause registration on the subnet. In this scenario, we would remove weights from the subnet and would only consider re-adding weights after the team acknowledges the issue, investigates it, and shares their findings with us.