---
title: "Slashing"
description: "Slashing ist eine protokolldefinierte Reduzierung des strafbaren Einsatzes nach zuordenbarem Fehlverhalten eines Validators oder Operators. Analysieren Sie die genaue Straftat, Beweise, Einsatzbasis, Strafformel, Zeitpunkt, Delegation und Auszahlungsrisiken, anstatt davon auszugehen, dass jede versäumte Pflicht oder angegebene Prozentzahl denselben Effekt hat."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Slashing
> Nur zu Bildungszwecken; keine Anlageberatung. Investieren kann zu Verlusten führen.
## Direkte Antwort
Slashing ist eine protokolldefinierte Verringerung des Stakes nach einer zurechenbaren Regelverletzung durch einen Validator, Operator oder anderen gebundenen Teilnehmer. Eine vollständige Regel benennt den slashbaren Verstoß, den Nachweis oder Zähler, der ihn belegt, den exponierten Stake, die Strafberechnung und den Anwendungszeitraum. Slashing kann mit Sperrung, Deaktivierung, erzwungenem Austritt, entgangenen Belohnungen oder einer Meldeprämie verbunden sein; sofern das Protokoll sie nicht gemeinsam definiert, sind dies jedoch getrennte Zustandsübergänge.
Es gibt keine universelle Slash-Regel. Ethereum kürzt widersprüchliche Vorschläge und Bescheinigungen, behandelt jedoch gewöhnliche versäumte Pflichten und das Inaktivitätsleck getrennt. Eine Cosmos SDK-Kette kann sowohl Doppel-Signatur- als auch Ausfall-Slashes konfigurieren. Polkadot unterscheidet zwischen Verstößen, Slashing, Deaktivierung und Änderungen des Rufs. Ein Restaking-Dienst kann eine weitere bestrafbare Verpflichtung hinzufügen, deren Verträge, Betreibergruppe und Auszahlungsfenster sich von der Basiskette unterscheiden. Lesen Sie die aktiven Regeln für das genaue Netzwerk, den Fork, die Laufzeit oder die Vertragsbereitstellung.
Slashing beweist eine Protokollprädikat, nicht böswillige Absicht. Ein duplizierter Validator-Schlüssel, Split-Brain-Failover, wiederhergestelltes Backup, Remote-Signer-Rennen oder eine beschädigte Slashing-Schutz-Datenbank kann zwei gültige Signaturen erzeugen, die in Konflikt stehen, selbst wenn der Betreiber keinen Angriff beabsichtigte. Im Gegenteil, schlechte Betriebszeit ist nicht automatisch auf jedem Netzwerk strafbar, und eine ungültige oder verspätete Nachricht ist nicht strafbar, es sei denn, sie erfüllt eine definierte Verstoßregel.
Halten Sie diese Konzepte getrennt:
- **Verpasste Belohnung oder gewöhnliche Strafe:** eine Pflicht war abwesend, verspätet oder falsch, aber kein strafbares Vergehen wurde nachgewiesen.
- **Inaktivitätsmechanismus:** Strafen steigen oder das Stimmgewicht ändert sich bei längerer Nicht-Finalität; die Inaktivitätslücke von Ethereum ist an sich keine Kürzung.
- **Slashing:** ein On-Chain- oder protokollanerkanntes Zustandsübergang verringert den an einem nachgewiesenen Verstoß angehängten Einsatz.
- **Inhaftierung, Deaktivierung, Ausstoßung oder „Tombstoning“:** Die Teilnahme an ist ausgesetzt oder beendet; die Aktion kann mit oder ohne zusätzliche Einsatzminderung erfolgen.
- **Soziale oder vertragliche Strafe:** Governance, eine Dienstleistungsvereinbarung, Versicherungspolice oder koordinierter Fork legt eine Konsequenz außerhalb der automatischen Basisprotokoll-Slash-Funktion fest.
Die Partei, die den Schlüssel bedient, ist nicht unbedingt die einzige Partei, die den Verlust trägt. Protokollregeln und Dienstleistungsverträge können Eigenanteile, delegierte Anteile, Nominatorenanteile, wiederangelegte Zuweisungen, wartende Abhebungen oder gebündelte Ansprüche betreffen. Versicherung und Erstattung sind separate Kreditversprechen, keine Rücknahmen des Protokollereignisses.
## Wie Slashing analysiert wird
### 1. Regelwerk und Beobachtungszeitpunkt festlegen
Zeichnen Sie die `network`, `chain ID`, aktive `fork version` oder Laufzeit, Block oder Epoche, Client/Spezifikationsversion und relevante Vertragsadressen auf. Trennen Sie Konsensregeln von den Bedingungen eines Staking-Anbieters und der Benutzeroberfläche. Eine aktuelle Parameterabfrage und ein finalisierter Zustand sind stärkere Beweise als eine undatierte Hilfeseite.
### 2. Den genauen Verstoßtatbestand formulieren
Benennen Sie die Regel in ausführbaren Begriffen: zwei verschiedene Vorschläge eines Validators für denselben Slot, ein `double vote`, ein `surround vote`, eine vom Protokoll erkannte ungültige Abstimmung oder `missed > max_missed` innerhalb eines Liveness-Fensters. Ersetzen Sie das Prädikat nicht durch Bezeichnungen wie „bösartiges Verhalten“, „offline“ oder „Angriff“.
### 3. Überprüfen Sie die Zuordnung und die Beweise
Überprüfen Sie die Identität des Validators oder Operators, Signaturen, `signing root`, Domain-Trennung, Fork-Kontext, Höhen oder Epochen und das Alter der Beweise. Bei Verstößen mit widersprüchlichen Nachrichten bewahren Sie beide signierten Objekte auf. Für Liveness-Regeln reproduzieren Sie den Zähler und das Fenster des Protokolls. Die Einbeziehung von Beweisen kann nach dem Verstoß erfolgen, daher unterscheiden Sie zwischen `infraction time`, `detection time` und `application time`.
### 4. Alle exponierten Guthaben bestimmen
Bestimmen Sie, ob die Basis `effective balance`, gebundener Einsatz in der Verletzungshöhe, aktueller Einsatz, Selbst-Einsatz, delegierter Einsatz, eine Validator-Slot-Zuweisung oder Einsatz, der einem `operator set` zugeordnet ist, entspricht. Überprüfen Sie Obergrenzen, Untergrenzen, Rundungsinkremente, Einheit, frühere Strafen, Neuzuweisungen und ob wartende Abhebungen weiterhin strafbar sind.
### 5. Jede Strafkomponente nachrechnen
Teilen Sie das Ergebnis in `initial penalty`, `correlation penalty`, fortlaufende Pflichtstrafen, entgangene Belohnungen, erzwungene Austrittswirkungen und Melde- oder Whistleblower-Belohnungen auf. Eine einfache feste Regel kann `slash_amount = slashable_stake * slash_fraction` verwenden; viele laufende Protokolle verwenden stattdessen zustandsabhängige Funktionen. Wenden Sie niemals einen Überschriftenprozentsatz auf den Wallet-Saldo an, ohne die Basis zu bestätigen.
### 6. Vollständigen Zeitablauf und Verlustträger abbilden
Verfolgung von Verstößen, Weitergabe von Beweismitteln, Einbeziehung, Slashing-Buchführung, Gefängnis- oder Sperrzeit, Berufungs- oder Stornierungsfenster, Austritt, Entbindung und Abschluss der Auszahlung. Dann verteilen Sie den Verlust gemäß dem Protokoll und dem Servicevertrag unter Betreiber, Delegatoren, Nominatoren, Pool-Token-Inhabern und Restakern. Beziehen Sie Token-Preis- und Liquiditätseffekte separat von verbrannten Einheiten ein.
### 7. Überprüfen Sie die Kontrollen und gleichen Sie den Status ab
Überprüfen Sie die wichtigsten Aspekte der Verwahrung, der Exklusivität des Unterzeichners, der Haltbarkeit von `slashing protection database`, der Failover-Abgrenzung, der Wiederherstellung von Backups, der Überwachung von Uhr und Netzwerk, der Diversität der Clients und der Vorfallverfahren. Berechnen Sie das Ereignis anhand des finalisierten Zustands, der Parameter, der Beweise und der Bilanzänderungen neu; gleichen Sie es mit Explorer-Etiketten, Anbieterangaben, Buchungseinträgen und etwaigen Versicherungszahlungen ab, ohne eine Quelle als endgültig zu behandeln.
## Beispielaufgaben
### Ethereum-Stil widersprüchliche Signaturen
Angenommen, Validator `V` signiert Blockheader `A` und einen anderen Header `B` für `slot = 8`, mit gültigen Signaturen unter demselben anwendbaren Fork-Kontext. Das Paar erfüllt die Ethereum-Proposer-Versatzform; ein verpasster Vorschlag in Slot 9 nicht. Für Attestierungen seien `A = (source = 120, target = 125)` und `B = (source = 118, target = 127)`. Da `B` `A` umgibt, hat das Paar die Surround-Vote-Form. Die Labels allein sind nicht ausreichend: Die tatsächlich signierten Daten, Domains, Validator-Index und Slashable-Period-Prüfungen müssen die aktive Spezifikation bestehen.
Dieses Beispiel zeigt auch, warum Absicht keine Eingabe ist. Zwei Maschinen, die denselben Schlüssel verwenden, können die Beweise erstellen. Ein Screenshot mit der Aufschrift "double sign" kann es nicht; das Protokoll benötigt gültige widersprüchlich signierte Objekte.
### Verlustberechnung anteiliger Beteiligung
Betrachten Sie ein anschauliches Protokoll mit `slashable_stake = 12,500`-Token und einem festen `slash_fraction = 0.015`. Der Protokollverlust ist:
`12,500 * 0.015 = 187.5 tokens`.
Wenn die Regel alle unterstützenden Einsätze anteilig belastet, verlieren `2,500` Token des Eigenanteils des Betreibers `37.5`, während `10,000` delegierte Token `150` verlieren. Wenn der Servicevertrag die Delegierenden entschädigt, aber nicht den Betreiber, ist diese Zahlung eine separate Forderung und Kreditrisiko. Sie ändert nicht die On-Chain-Strafzahlung, und diese Zuweisung darf nicht auf ein Protokoll übertragen werden, das Delegierende schützt oder eine andere Einsatzbasis verwendet.
### Cosmos-Stil Lebendigkeitsfenster
Angenommen, eine auf Cosmos SDK basierende Kette hat die Parameter `window = 1,000` und `min_signed = 0.95` abgefragt. Ihre maximal erlaubten Fehlversuche sind:
`max_missed = 1,000 - (0.95 * 1,000) = 50`.
Wenn die aktive Regel ausgelöst wird, wenn `missed > max_missed`, genau `50` verfehlt, wird die Schwelle nicht überschritten, während `51` dies tut. Der resultierende Abschlagsanteil, die Gefängnisdauer, der Rücksetzungszähler und die Möglichkeit, das Gefängnis zu verlassen, stammen aus den aktiven Parametern und der Modulversion dieser Kette. Dies ist ein konfiguriertes Kettenbeispiel, keine universelle Proof-of-Stake-Regel und keine Behandlung von Ausfallzeiten von Ethereum.
### Formel für korrelierte Verstöße
Die überprüften Unterlagen von Polkadot geben den Äquivokationsanteil `min((3 * x / n)^2, 1)` an, wobei `x` die Anzahl der Straftäter und `n` die Anzahl der aktiven Validatoren ist. Mit `x = 5` und `n = 100`:
`min((3 * 5 / 100)^2, 1) = 0.0225 = 2.25%`.
Angewendet auf `40,000` Einheiten Einsatz im Validator-Slot, sind das `900` Einheiten. Mit `x = 20` liefert die gleiche Formel `36%`, nicht viermal `2.25%`. Dies zeigt das Korrelationsrisiko; es autorisiert nicht die Verwendung dieser Formel auf Ethereum, einer Cosmos-Chain, einer Parachain oder einer anderen Polkadot Laufzeit, ohne die aktuellen Regeln zu überprüfen.
## Risiken und Prüfungsfehler
- **Falsches Regelwerk:** Eine andere Chain, Fork, Runtime, Testnet oder Vertragsbereitstellung kann unterschiedliche Verstöße und Strafen haben.
- **Verwechslung von Vergehen und Strafe:** Verpasste Belohnungen, Inaktivitätsstrafen, Inhaftierung, Deaktivierung, Ausschluss und Kürzung bei sind keine austauschbaren Bezeichnungen.
- **Veraltete Parameter:** Governance und -Upgrades können Fenster, Brüche, Obergrenzen, Verzögerungen und geschützte Salden ändern.
- **Domänenverwirrung:** Signaturen aus unterschiedlichen Fork- oder Domänenkontexten dürfen keine slashbaren Beweise bilden.
- **Ungültiger Beweis:** fehlerhafte, doppelte, abgelaufene, falsch indizierte oder nicht authentifizierte Beweise können abgelehnt werden.
- **Verzögerte Entdeckung:** Beweise können nach der Neuordnung oder Einleitung des Austritts eintreffen, daher unterscheiden sich die Verstöße- und Anwendungszustände.
- **Falscher Einsatz-Snapshot:** Der aktuelle Kontostand von ist möglicherweise nicht der Kontostand, die Stimmkraft oder der effektive Einsatz, der nach der Regel verwendet wird.
- **Korrelationsverstärkung:** Ein geteilter Kunde, Cloud, Unterzeichner oder Verfahren kann einen Fehler in eine zustandsabhängige Massenstrafe verwandeln.
- **Duplizierte Schlüssel:** kopierte Keystores und gleichzeitig aktive Backups können widersprüchliche Signaturen erzeugen.
- **Fehler beim Remote-Signer:** Wiederholungen, veraltete Sperren, inkonsistente Datenbanken oder mehrdeutige Bestätigungen können zu doppelter Unterzeichnung führen.
- **Split-Brain-Failover:** Zwei Standorte können beide glauben, dass sie primär sind, es sei denn, das Failover ist kryptographisch abgesichert.
- **Verlust der Schutzdatenbank:** das Wiederherstellen von Schlüsseln ohne vollständige Signaturgeschichte kann einen scheinbar sauberen Validator unsicher machen.
- **Operatorenkonzentration:** viele Validatoren unter einer Kontrollinstanz teilen operationelle und Korrelationsrisiken.
- **Delegationsdurchleitung:** Delegierende oder Nominierende können Verluste tragen, die durch einen Betreiber verursacht werden, den sie nicht direkt kontrollieren können.
- **Restaking-Überlappung:** ein Vermögenswert kann mehrere Verpflichtungen mit unterschiedlichen Slashing-Behörden und Zuweisungsregeln unterstützen.
- **Entzugsrisiko:** Entbündelung oder in der Warteschlange stehende Abhebung kann für frühere oder neu zurechenbare Verstöße weiterhin strafbar bleiben.
- **Unsicherheit in der Governance:** Berufungen, Kündigungsfristen, Upgrades oder soziale Wiederherstellung können den Zeitplan ändern, sind jedoch keine garantierten Lösungen.
- **Buchführung und Rundung:** effektive Guthaben-Erhöhungen, Aktienumwandlungen, Obergrenzen und Token-Dezimalstellen können die Multiplikation des Wallet-Guthabens verhindern.
- **Beobachtbarkeitslücken:** Explorer-Labels können das Evidenzpaar, den Parametersnapshot, betroffene Delegationen oder spätere Strafen weglassen.
- **Vertrags- und Gegenparteirisiko:** Pool, Verwahrung, Versicherung und Rückerstattungsversprechen können unabhängig von der Richtigkeit des Konsenses fehlschlagen.
## Häufige Missverständnisse
### Wird jeder Offline-Validator bestraft?
Nein. Ethereum wendet Strafen für versäumte Pflichten und Inaktivität an, klassifiziert jedoch gewöhnliche Ausfallzeiten nicht als strafbare Handlung. Cosmos SDK-Ketten können das Slashen bei Ausfallzeiten konfigurieren. Andere Protokolle können deaktivieren, sperren, Belohnungen reduzieren oder nichts tun. Fragen Sie die genaue Regel ab, anstatt von einem Netzwerk zu verallgemeinern.
### Erfordert das Slashing den Nachweis böswilliger Absicht?
Normalerweise bewertet die automatische Regel unterzeichnete Nachrichten, Beweise, Gegenstände und Zustände, nicht das Motiv. Ein Betriebsunfall kann dasselbe Prädikat erfüllen wie eine absichtliche Täuschung. Die Absicht kann für Verwaltung, Versicherung, Rechtsstreitigkeiten oder einen Dienstvertrag von Bedeutung sein, nicht jedoch für den deterministischen Zustandsübergang.
### Ist der maximale Verlust der angegebene Prozentsatz der Kürzung?
Nicht unbedingt. Der Prozentsatz kann auf effektive, gebundene, zugewiesene, delegierte oder historische Beteiligung zutreffen; Korrelation und fortlaufende Strafen können Verluste hinzufügen; ein erzwungener Ausstieg führt zum Verlust zukünftiger Belohnungen; und der Token-Preis oder Rabatte beim Liquid-Staking können den wirtschaftlichen Wert verändern. Umgekehrt kann eine Obergrenze oder ein geschütztes Guthaben die berechnete Basis reduzieren.
### Beendet das Einleiten eines Ausstiegs die Slashing-Exposition sofort?
Keine universelle Regel besagt das. Beweise können verzögert sein, Unbonding existiert teilweise, um die Verantwortlichkeit zu wahren, und einige Restaking-Abhebungen bleiben während einer Warteschlange strafbar. Überprüfen Sie die letzte strafbare Zeit für jede Verpflichtung, nicht nur die Transaktion, die den Austritt beantragt hat.
### Beseitigen Delegation, Versicherung oder soziale Wiederherstellung das Slash-Risiko?
Nein. Sie verteilen oder versprechen, einen Verlust nach zusätzlichen Regeln zu erstatten. Die Deckung kann gekoppelte Fehler ausschließen, ablaufen, Ansprüche begrenzen, von der Governance abhängen oder Gegenparteirisiken schaffen. Der Protokoll-Slash bleibt ein separates Ereignis, das unabhängig abgeglichen werden sollte.
## Verwandte Themen
- [Nachweis des Einsatzes](/de/crypto/proof-of-stake/)
- [Validator](/de/crypto/validator/)
- [Staking](/de/crypto/staking/)
- [Neustaking](/de/crypto/restaking/)
- [Validator-Ausgangs- und Rückzugswarteschlange](/de/crypto/validator-exit-withdrawal-queue/)
## Quellen
- [Proof-of-Stake-Belohnungen und Strafen](https://ethereum.org/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/) - Ethereum.org (zugegriffen: 2026-08-19)
- [Ethereum Konsens-Spezifikationen: Ehrlicher Validator](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/validator.md) - Ethereum Foundation (zugegriffen: 2026-08-19)
- [Ethereum Konsensspezifikationen: Beacon-Chain](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation (zugegriffen: 2026-08-19)
- [Cosmos SDK x/slashing-Modul](https://docs.cosmos.network/sdk/v0.53/build/modules/slashing/README) - Cosmos SDK (zugegriffen: 2026-08-19)
- [Cosmos SDK x/evidence-Modul](https://docs.cosmos.network/sdk/latest/modules/evidence/README) - Cosmos SDK (zugegriffen: 2026-08-19)
- [Verstöße und Slashing](https://docs.polkadot.com/infrastructure/staking-mechanics/offenses-and-slashes/) - Polkadot Developer Docs (zugegriffen: 2026-08-19)
- [Casper Friendly Finality Gadget](https://arxiv.org/abs/1710.09437) - Buterin und Griffith (abgerufen: 2026-08-19)
- [EigenLayer Delegationsmanager](https://github.com/Layr-Labs/eigenlayer-contracts/blob/main/docs/core/DelegationManager.md) - Eigen Labs (zugegriffen: 2026-08-19)
Source: https://wiki.fcontext.com/de/crypto/slashing/index.mdx