Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#38 6 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
25/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
solidity
Bereich
blockchain, security

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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)

Vorherrschende Sprache
Python
Sterne
4
Forks
7
Ø Merge
3 T. 4 Std.
Gemergte PRs (30 T.)
34

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus InfiniteZeroFoundation/DevNet

Alle Issues in InfiniteZeroFoundation/DevNet

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.