Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#194 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
solidity
Ambito
blockchain, security

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Python
Stelle
4
Fork
7
Merge medio
3g 58m
PR unite (30g)
39

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di InfiniteZeroFoundation/DevNet

Tutte le issue di InfiniteZeroFoundation/DevNet

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.