Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

P3 dispute: upheld S4 dispute slashes colluders but never replaces the wrong finalCID or refunds the honest dissenter

Ouverte
  • Quelque chose ne va pas ?
#194 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
Active
Stack technique
solidity
Domaine
blockchain, security

Piste de recherche

Read foundry/src/DINTaskCoordinator.sol around settleRecomputation and the bad consensus slash in DINTaskCoordinator.sol:971, then review Developer/design/adversarial-threat-model.md row 5 and Part 2's test_knownGap_t1WrongCID. First define how confirmed disputes recover dissenters' slashes and install a recomputed CID through downstream T2 and global model state; completion should make test_defended_t1WrongCID pass.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

enhancement

Summary

An upheld and confirmed S4 dispute punishes the colluding T1 aggregators but does not repair the damage. The wrong CID stays the batch's result, and the honest dissenter stays slashed.

Scenario: 2 of 3 aggregators in a T1 batch collude and submit the same wrong CID. Majority vote finalizes it, and the honest third aggregator is slashed a full minStake for AGG_T1_BAD_CONSENSUS (foundry/src/DINTaskCoordinator.sol:971), because its CID disagrees with the (wrong) majority.

The S4 path is openDispute → lockDisputeSeed → resolveDispute(upheld=true) → settleRecomputation(confirmed=true). On confirmed=true, settleRecomputation (DINTaskCoordinator.sol:1351-1400):

  • returns the challenger's bond (disputeBondClaimable),
  • slashes the aggregators whose submission matched the disputed CID, S4_INVALID_AGGREGATION,
  • does not replace tier1Batches[_GI][batchId].finalCID (or the T2 equivalent), so the wrong model remains in that GI's aggregation,
  • does not refund the honest dissenter's AGG_T1_BAD_CONSENSUS slash.

_assignFreshSubgroup is bookkeeping only and does not re-open the GI state machine. The fresh subgroup never submits a CID on-chain, so there is no corrected CID to install even if the contract wanted to.

Impact

This holds even with an honest owner-adjudicator (TA-1). The attack partially succeeds: the wrong model propagates for that GI, and the only validator who behaved correctly loses a full minStake. That also discourages honest dissent in future batches.

This is separate from No. 181, which is about who adjudicates disputes (removing the owner-adjudicator trust assumption). This issue is about what a successful dispute does, whoever adjudicates it.

Needed

  1. Refund the dissenter: on confirmed=true, reverse the AGG_T1_BAD_CONSENSUS / AGG_T2_BAD_CONSENSUS slash for batch members whose submission differed from the disputed finalCID. This needs either a refund path on DinValidatorStake or the bad-consensus slash held pending until the dispute window closes.
  2. Repair the result: have the fresh subgroup submit its recomputed CID on-chain and install it as finalCID on confirmed=true, or define what happens downstream (T2 / next GI's global model) when a finalized CID is later shown to be wrong.

Both touch slashing/dispute mechanism design, so this likely needs a design note before implementation.

Tracking

Row 5 (KNOWN GAP, decided in PR No. 182's review) of the adversarial threat model, Developer/design/adversarial-threat-model.md (task_240926_17). Part 2's test_knownGap_t1WrongCID should flip to test_defended_t1WrongCID when this is fixed.

Langage dominant
Python
Étoiles
4
Forks
7
Merge moyen
3 j 5 h
PR mergées (30 j)
34

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de InfiniteZeroFoundation/DevNet

Toutes les issues de InfiniteZeroFoundation/DevNet

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.