Développer un subnet robuste et durci sur Bittensor est un défi. Les propriétaires de subnets doivent surveiller en permanence l’activité au sein de leur subnet pour comprendre si la conception de leurs incitations fonctionne comme prévu. Une partie de ce processus de développement et de surveillance du subnet consiste à examiner les inévitables allégations et preuves d’exploitation du mécanisme d’incitation du subnet.
Chaque subnet possède ses propres propriétés et sa propre conception ; les exploits potentiels diffèrent donc naturellement d’un subnet à l’autre dans l’écosystème. Nous pensons toutefois qu’un cadre unique et global pour le traitement des allégations d’exploitation de subnets profite à l’ensemble de la communauté. Il sert de guide aux propriétaires de subnets pour que les attentes concernant les émissions au sein de leur subnet soient claires, et il définit les attentes de ceux qui formulent des allégations d’exploitabilité d’un subnet.
Nous concevons un cadre de traitement des exploits de subnets que la communauté pourra utiliser. Ci-dessous, nous identifions et décrivons, à haut niveau, le processus attendu.
Preuve d’un exploit de subnet
La charge de la preuve incombe à l’entité qui affirme qu’un exploit de subnet est possible ou est en cours. Des données ou des preuves claires doivent étayer les allégations d’un prétendu exploit. Cela aide la communauté au sens large à comprendre la situation et permet au propriétaire du subnet d’enquêter et de répondre à des accusations précises.
Enquête du propriétaire du subnet
Une fois les allégations et les preuves à l’appui d’un éventuel exploit de subnet transmises, nous attendons du propriétaire du subnet qu’il commence à enquêter sur ces allégations.
Si le propriétaire du subnet confirme l’exploit, il doit faire une déclaration publique le reconnaissant et suspendre les enregistrements jusqu’à ce que l’exploit soit résolu.
Suspension des enregistrements sur le subnet
Lorsque les enregistrements sont suspendus sur un subnet, ses émissions sont recyclées, ce qui signifie qu’aucun participant du subnet (c’est-à-dire les propriétaires de subnets, les mineurs et les validateurs) ne reçoit d’émissions. Cela garantit que personne ne peut tirer profit d’une attaque active contre un subnet présentant un exploit connu. Tant que les enregistrements du subnet sont suspendus, nous ne retirerons pas les poids du subnet. En revanche, si un propriétaire de subnet ne suspend pas les enregistrements, nous retirerons probablement les poids du subnet.
Résultats de l’enquête du propriétaire du subnet
Une fois que le propriétaire d’un subnet a enquêté sur l’exploit, nous attendons de lui qu’il fournisse une documentation détaillant en quoi consistait l’exploit et comment il ajustera son subnet pour supprimer la vulnérabilité. En tant que validateurs, cela nous aide grandement à accélérer notre examen du problème et à déterminer si, selon nous, les ajustements du propriétaire du subnet résoudront entièrement le problème.
Dans l’ensemble, nous voulons que ce processus favorise la transparence et la communication ouverte entre les propriétaires de subnets, la communauté et des validateurs comme nous. Pour clarifier ce cadre, nous pouvons envisager deux scénarios différents.
Scénario 1
Dans cet exemple, nous supposons qu’un exploit est découvert, correctement documenté et confirmé par le propriétaire du subnet.
À ce stade, le propriétaire du subnet suspend les enregistrements sur le subnet et commence à évaluer comment supprimer le vecteur d’attaque. Une fois qu’il a déployé sur le subnet un correctif qui résout le problème et documenté la façon dont celui-ci a été résolu, il reprend les enregistrements.
Dans ce scénario, nous ne retirerions pas les poids de ce subnet, car son propriétaire gère correctement le processus. Le subnet et ses participants en profitent, puisqu’il n’y a aucune perturbation des émissions du subnet après la reprise des enregistrements.
Scénario 2
Dans cet exemple, nous supposons qu’une allégation d’exploit est formulée avec des preuves suffisantes pour justifier une enquête du propriétaire du subnet, mais que celui-ci rejette l’allégation.
De plus, comme il ne reconnaît pas l’existence d’un problème, le propriétaire du subnet néglige également de suspendre les enregistrements sur le subnet. Dans ce scénario, nous retirerions les poids du subnet et n’envisagerions de les rétablir qu’après que l’équipe a reconnu le problème, enquêté dessus et partagé ses conclusions avec nous.