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

P3 slashing: conditions taxonomy, penalty tiers, slashed-stake destination, dispute resolution (P3-4.1/4.2/4.3)

Aperta
  • Qualcosa non va?
#38 6 commenti 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
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
solidity
Ambito
blockchain, security

Direzione di ricerca

Read MECHANISM_DESIGN §4 and inspect DINTaskCoordinator's openDispute/resolveDispute path; the issue names no source or test files. First clarify the open penalty and dispute parameters, then trace how slashing and stake destinations are handled. Done means implementing the S1–S6 conditions, penalty tiers, explicit slash destination, and recomputation-based dispute flow, with invariants covered by the P3-6.3b fuzz tests.

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

Descrizione

enhancement

Part of the P3 mechanism-design push (#36).

Summary

Today slashing is liveness-only with a flat minStake() penalty, and slashed stake strands in the stake contract (an accidental burn). Specify and implement correctness-based slashing: a conditions taxonomy, partial/full penalty tiers, an explicit slashed-stake destination, and a dispute-resolution layer.

Scope (from MECHANISM_DESIGN §4)

  • Conditions taxonomy S1–S6: missed audit vote, missed T1/T2 submission, score deviation from cross-auditor median (S3), invalid aggregation proven by recomputation (S4), recidivism (S5), registration without capacity (S6)
  • Penalty tiers: partial slash as a DAO-settable fraction of minStake (today's flat amount over-punishes liveness faults); full slash + blacklist reserved for provable malice (S4) and recidivism (S5); keep jailing below min stake
  • Explicit slashed-stake destination — burn / treasury / redistribute / split (recommendation: 50% burn / 50% treasury; no redistribution to reporters beyond a fixed dispute bounty)
  • Dispute resolution (P3-4.3): dispute bond + window, fresh-subgroup re-evaluation excluding accused + original batch, bounty from treasury if upheld
  • Folded in from #40 (2026-09-10, #40 closed as a result): aggregator auditing — T1/T2 outputs must be verifiable by recomputation, with any validator able to open an S4 dispute (no proactive re-audit of every batch). This is the general dispute path on DINTaskCoordinator (openDispute/resolveDispute), distinct from PR #110's test-data-specific dispute mechanism on DINTaskAuditor (which closed the rest of #40's scope). Today this path is centralized (onlyOwner) with no recomputation-based verification — it's the same "general dispute path" gap already named above, just making explicit that S4/aggregator-recomputation is part of it.
  • Invariants feeding P3-6.3b fuzz tests (staked supply never increases after a slash; slashed amount always reaches its declared destination; no negative stake states)
  • White paper §8.1 semantics to weigh: delegator penalty % and permanent removal + re-registration (gap item 4 in the whitepaper summary) — ✅ Resolved for 2.0 (Abraham, 2026-07-21): jail/blacklist, not permanent removal. Full §8.1 alignment (forced re-registration, delegator penalties) deferred until delegation lands.

Open decisions (→ slashing-economics discussion)

  • Slashed-stake destination (MECHANISM_DESIGN §9, decision 1) — ✅ Resolved: 50% burn / 50% treasury. Burn is a deflationary sink; treasury funds dispute adjudication; reporters get a fixed bounty only, never a share of the slash (Abraham, 2026-07-21).
  • Partial-slash fraction and S3 deviation threshold — needs P3-SCR empirical data; shadow-mode first (decision 2). Still open on the exact numbers, but Abraham's reply layered an Ethereum-style penalty framework on top to build the fraction/threshold into: a correlation penalty scaling with how many validators are slashed in a short window, ejection to a draining withdrawal queue, and an inactivity leak for persistent offline validators. Note: this framing is in Ethereum consensus terms (double-signing, 1/32 immediate penalty) and needs translating to DIN's S1–S6 liveness/correctness conditions — not a literal drop-in.
  • Dispute bond size and window length (decision 7) — not addressed, still open

Design sources

MECHANISM_DESIGN §4 · whitepaper-summary §4.5, §8 gap items 3–4

Roadmap anchors: P3-4.1 (conditions spec, in progress), P3-4.2 (engine), P3-4.3 (disputes), P3-DOC3 (slashing rules reference — external-validator blocking requirement)

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.