Slashing für Solana

Einführung

Slashing ist ein Mechanismus, der die Netzwerksicherheit durch Strafen für böswilliges oder fahrlässiges Verhalten von Validatoren durchsetzt. Sobald ein Fehlverhalten bestätigt wurde, wird ein Teil des delegierten Stakes verbrannt, der mit den verantwortlichen Validatoren verknüpft ist.

Dies ist ein besonderes Merkmal von Proof-of-Stake-Netzwerken (PoS) wie Solana. Bei Proof of Work (PoW) gibt es kein Äquivalent, da der Mechanismus darauf beruht, dass das Protokoll finanzielle Strafen direkt durch die Vernichtung gestakter Assets durchsetzen kann. Bei PoW gibt es keinen vergleichbaren Mechanismus, da die Blockchain die physische Mining-Hardware unehrlicher Akteure weder beschlagnahmen noch zerstören kann.

Slashing bietet mehrere wichtige Vorteile:

• Es wirkt als direkter wirtschaftlicher Anreiz gegen böswillige Aktivitäten
• Es motiviert Staker, ihren Stake auf vertrauenswürdige Validatoren zu verteilen, und verbessert so die Dezentralisierung
• Es motiviert größere Betreiber, heterogene Infrastrukturen aufzubauen, die das Risiko gemeinsamer Fehler reduzieren, etwa indem sie ihren Stake zwischen Firedancer- und Agave-Clients aufteilen.
• Es bietet Validatoren eine weitere Möglichkeit, sich abzuheben und Reputation aufzubauen, indem sie Slashing-Verstöße vermeiden und böswillige Aktivitäten anderer Teilnehmer erkennen.

Solana hat sich im Laufe seiner Geschichte auf einen manuellen, von der Community getragenen Konsensansatz verlassen, der als Social Slashing bezeichnet wird. Verhält sich ein Validator in diesem Modell böswillig, indem er beispielsweise die Verfügbarkeit oder Sicherheit des Netzwerks gefährdet, können sich ehrliche Teilnehmer off-chain koordinieren, um einen Hard Fork einzuleiten, das Netzwerk neu zu starten und den Stake des Verursachers zu slashen. Diese Methode ermöglicht zwar flexible Einzelfallentscheidungen, verursacht aber erheblichen Koordinationsaufwand und ist grundsätzlich reaktiv.

Bis heute wurde kein Validator auf Solana geslasht. Einem Slashing-ähnlichen Ereignis kam Solana im Mai 2020 am nächsten, zwei Monate nach dem Mainnet-Start. Damals verbrannte die Solana Foundation freiwillig 11,36 Millionen SOL aus ihrer eigenen Zuteilung. Damit reagierte sie auf Bedenken der Community wegen nicht offengelegter Token-Darlehen an Market Maker. Dies reduzierte das gesamte Token-Angebot um 2,3 %, von 500 Millionen auf 488,64 Millionen SOL. Es handelte sich zwar nicht um ein formelles Slashing-Ereignis, doch der Burn diente als selbst auferlegte Strafe, um Vertrauen wiederherzustellen und die von der frühen Community angesprochenen Transparenzprobleme zu beheben.

Seit mehreren Jahren wird gefordert, dass Solana einen formelleren Slashing-Mechanismus einführt. Dieser wird häufig als programmgesteuertes Slashing bezeichnet und direkt on-chain durch ein fest im Protokoll verankertes Programm durchgesetzt. Verstößt ein Validator in diesem System gegen bestimmte Protokollregeln, kann ein kryptografischer Beweis für den Verstoß erstellt und an ein dediziertes Programm übermittelt werden, das anschließend automatisch das Slashing auslöst. Dieses Modell reduziert die Abhängigkeit von menschlicher Koordination. Es ermöglicht zudem, kleinere Verstöße zu ahnden, ohne den Netzwerkbetrieb zu stören, und schafft damit die Grundlage für skalierbare, dezentrale Verantwortlichkeit.

Die bevorstehende Aktivierung des Feature Gates für SIMD-0204: Verifizierung von Slashing-fähigen Ereignissen ist Solanas erster großer und bedeutender Schritt zur Einführung von formellem programmgesteuertem Slashing im Mainnet. Wie wir später in diesem Bericht zeigen, sind programmgesteuerte Slashing-Ereignisse in Blockchain-Netzwerken glücklicherweise selten und die Strafen meist gering. Doch bereits die Möglichkeit, dass das Protokoll den Stake eines Validators automatisch vernichtet, bringt neue Risiken mit sich, die alle Beteiligten sorgfältig abwägen müssen. Viele Fragen zum optimalen Ansatz für programmgesteuertes Slashing auf Solana sind noch offen. Wie alle wirtschaftlichen Änderungen erfordern auch die Parameter und Strafen des Slashings eine umfassende Diskussion in der Community. Letztlich müssen sie durch eine formelle Governance-Abstimmung genehmigt werden.

SIMDs zum Slashing

Mehrere SIMDs betreffen die Einführung von programmgesteuertem Slashing auf Solana. Die ersten beiden, SIMD-180 und SIMD-204, sollen in den kommenden Monaten im Mainnet aktiviert werden.

Die erste Voraussetzung ist SIMD-0180: Vote-Account-Adresse als Schlüssel für den Leader-Zeitplan verwenden. Dieses SIMD ersetzt im Leader-Zeitplan die Identitätsadresse des Validators durch seine Vote-Account-Adresse. Diese Änderung ist für eine genaue Zuordnung beim Slashing unverzichtbar, da sie eine direkte und eindeutige Verbindung zwischen den Aufgaben eines Validators bei der Blockproduktion und seinem delegierten Stake herstellt.

SIMD-0204: Verifizierung von Slashing-fähigen Ereignissen beschreibt ein neues Slashing Program. Es führt einen On-Chain-Mechanismus ein, mit dem jeder Beweise für Slashing-fähiges Verhalten einreichen und protokollieren kann. So entsteht ein verifizierbarer, unveränderlicher Datensatz über das Fehlverhalten von Validatoren.

Abschließend beschreibt SIMD-0212: Slashing die Implementierung von Slashing im Solana-Protokoll. Es baut auf der durch SIMD-0204 geschaffenen Grundlage auf, um Strafen für bestätigte Verstöße zu verhängen. Dieser Vorschlag ist noch offen und wird weiterhin aktiv diskutiert.

Fehlererkennung und Zuordnung

Das Slashing Program ist als rein beobachtende Ebene konzipiert. Es verändert weder Stakes noch Rewards. Seine einzige Funktion besteht darin, Verstöße zu verifizieren und zu erfassen. Ein früher Prototyp ist bereits im Testnet live. Beispielübermittlungen wie DuplicateBlockProof-Transaktionen zeigen, wie Verstöße erfasst werden können.

Doppelte Blockproduktion

Bei der ersten Einführung konzentriert sich das Programm auf eine einzelne Art böswilligen Verhaltens: die Erkennung doppelter Blockproduktion. Dabei übermittelt ein Leader zwei oder mehr verschiedene Versionen eines Blocks für denselben Slot. Das ist ein eindeutiger und objektiver Konsensverstoß. 

Im September 2022 löste ein Validator bereits einen Netzwerkausfall aus, weil er versehentlich doppelte Blöcke auf derselben Blockhöhe produzierte. Dies geschah, weil sowohl der primäre Node des Validators als auch sein Ersatz-Node gleichzeitig aktiv wurden. Beide verwendeten dieselbe Node-Identität, schlugen aber unterschiedliche Blöcke vor.

Dieses Problem wurde inzwischen behoben. Selbst wenn ein Betreiber heute einen Hot Spare verwendet, enthält der Validator-Client Schutzmechanismen, die ihn beim Erkennen mehrerer Instanzen herunterfahren. Ohne eine absichtliche, böswillige Änderung der Validator-Software wäre die Produktion doppelter Blöcke daher äußerst unwahrscheinlich.

Doppelte Blockproduktion ist ein Beispiel für einen Protokollverstoß, der in Echtzeit schwer zu erkennen, im Nachhinein aber leicht zu verifizieren ist. Der Versuch, eine synchrone Reaktion zu koordinieren, bei der das Netzwerk angehalten wird, um die gemeinsame Beobachtung des Duplikats zu bestätigen, würde erhebliche Komplexität verursachen. Die nachträgliche Erkennung und Durchführung des Slashings ist deutlich praktikabler.

Eingereichte Beweise für doppelte Blöcke enthalten zwei widersprüchliche Shreds für denselben Slot, die beide vom selben Validator signiert wurden. Das Slashing Program verifiziert den Beweis, indem es sicherstellt, dass die Shreds einen gültigen Beweis für einen doppelten Block bilden, zum selben Slot gehören und korrekt vom verantwortlichen Validator signiert wurden. Diese Logik entspricht dem Ansatz, den Solanas Gossip-Protokoll bei der Verarbeitung von Beweisen für doppelte Blöcke im Fork-Choice-Prozess verwendet.

struct DuplicateBlockProofData {
  shred1_length: u32      // Unaligned four-byte little-endian unsigned integer,
  shred1: &[u8]           // `shred1_length` bytes representing a shred,
  shred2_length: u32      // Unaligned four-byte little-endian unsigned integer,
  shred2: &[u8]           // `shred2_length` bytes representing a shred,
}

Der Melder erstellt einen Beweis, speichert ihn in einem On-Chain-Buffer-Account und übermittelt anschließend eine Transaktion an das Slashing Program unter der Adresse `S1ashing11111111111111111111111111111111111`, die auf seinen Buffer-Account verweist. Nach erfolgreicher Verifizierung eines Beweises werden die Ergebnisse zur späteren Verwendung in einer `report_account` Program Derived Address (PDA) gespeichert, die dem Slashing Program gehört. Dadurch lassen sich leicht Dashboards erstellen, die Slashing-Daten anzeigen. Dazu genügt ein getProgramAccounts-Aufruf für das Slashing Program. Validatoren können damit prüfen, ob Verstöße gegen sie gemeldet wurden, und bei Bedarf Korrekturmaßnahmen ergreifen.

Anza wird voraussichtlich Tools veröffentlichen, mit denen sich diese Ereignisse beobachten, Beweise erstellen und on-chain übermitteln lassen. Wahrscheinlich wird es mehrere Implementierungen geben, darunter eine in die Validator-Software integrierte Version. Es genügt, wenn ein einzelner ehrlicher Teilnehmer einen Verstoß innerhalb einer Epoche meldet, da jede eindeutige Kombination aus Verursacher und Slot nur einmal gemeldet werden kann. Das Programm prüft, ob bereits eine Meldung für denselben Slot und Verursacher existiert. Wird eine passende Meldung gefunden, lehnt es die neue Einreichung ab. Meldungen können bis zu eine Epoche nach dem Verstoß eingereicht werden, ausgehend von dem Slot, in dem er stattfand, also bis zu 432.000 Slots später, wie von der `Clock` sysvar erfasst.

Belohnungen für Whistleblower

Eine häufige Frage beim Slashing-Design ist, ob Personen, die Verstöße melden, also Whistleblower, belohnt werden sollten. Eine Belohnung für Whistleblower scheint zwar ein einfacher Anreizmechanismus zu sein, bringt aber erhebliche Herausforderungen mit sich.

Da Leader auf Solana die Aufnahme von Transaktionen kontrollieren, erzeugt eine Whistleblower-Belohnung ein Frontrunning-Risiko. Angenommen, ein Validator übermittelt dem aktuellen Block-Leader einen gültigen Slashing-Beweis. Der Leader könnte den Beweis einfach kopieren, selbst einreichen und die ursprüngliche Transaktion zensieren. So würde er die Belohnung erhalten, ohne die Arbeit geleistet zu haben. Das untergräbt das Anreizmodell und ermöglicht Missbrauch.

Ethereum bietet eine kleine Whistleblower-Belohnung: 1/512 des effektiven Guthabens des geslashten Validators. Bei einem Validator mit den vollen 32 ETH entspricht dies 0,0625 ETH. Die Belohnung wird als neue ETH geprägt, aber durch den höheren Betrag ausgeglichen, der aus dem Stake des geslashten Validators verbrannt wird. Der geringe Wert ist beabsichtigt. Er soll Integrität und ehrliche Teilnahme fördern, statt opportunistisches, profitorientiertes Verhalten.

Verstöße bei Abstimmungen

Künftige Versionen des Slashing Program sollen voraussichtlich verschiedene Arten von Abstimmungsverstößen unterstützen, etwa Lockout-Verstöße und Verstöße gegen Switching Proofs.

Ein Lockout-Verstoß liegt vor, wenn ein Validator auf zwei getrennten Forks abstimmt, ohne abzuwarten, bis sein Tower Lockout nach der erforderlichen Zeit abläuft. Sobald ein Validator im aktuellen Konsensalgorithmus von Solana, TowerBFT, in einem bestimmten Slot für einen Fork stimmt, ist er für eine bestimmte Dauer von Abstimmungen über konkurrierende Forks „ausgesperrt“. Stimmt der Validator vor Ablauf dieser Lockout-Periode für einen anderen Fork, verstößt er gegen die Lockout-Regel.

Der von Solana-Mitgründer Michael Vines entwickelte Votalizer-Bot läuft derzeit im Solana Tech Discord und erfasst Lockout-Verstöße im gesamten Netzwerk. In der Praxis begehen Validatoren solche Verstöße nur selten unbeabsichtigt, da dies normalerweise eine absichtliche Änderung des Validator-Clients erfordern würde. Integrierte Schutzmechanismen stellen sicher, dass der Client seine jüngste On-Chain-Abstimmung abruft und Aktionen verhindert, die zu einem Lockout-Verstoß führen würden.

Lockout-Verstöße werden im Slashing-SIMD und in der frühen Dokumentation ausdrücklich als Beispiel für einen Abstimmungsverstoß genannt, den das Slashing Program behandeln könnte. Das geplante Alpenglow-Konsensupdate wird Tower BFT jedoch entfernen und damit das Lockout-Konzept abschaffen. Deshalb werden Abstimmungsverstöße voraussichtlich erst nach dem Start von Alpenglow eingeführt.

Zu den neueren Alpenglow-Abstimmungsverstößen, die das Slashing Program erkennen könnte, zählen möglicherweise widersprüchliche Stimmen für denselben Slot, beispielsweise wenn sowohl ein `NotarVote` als auch ein `SkipVote` abgegeben wird.

Künftige Arten von Verstößen

Programmgesteuertes Slashing muss an verifizierbare und eindeutige Fälle von Fehlverhalten gebunden sein. Leider erschwert dies die Durchsetzung bei subjektiveren oder systemischen Problemen erheblich, etwa bei absichtlich langsamer Blockproduktion oder schädlichen Formen der MEV-Extraktion.

Bei vergleichbaren Blockchain-Netzwerken unterscheiden sich die Verhaltensweisen, die typischerweise zu Slashing führen, je nach Protokoll. Häufige Beispiele sind:

• Doppelte Signatur: Produktion zweier widersprüchlicher Blöcke auf derselben Höhe oder im selben Slot.
• Ausfallzeit: Offline gehen und nicht am Konsens teilnehmen.
• Surround Voting: Abgabe von Stimmen, die früheren Stimmen widersprechen, um das Netzwerk zu manipulieren oder zu destabilisieren.

Ein neuartiger Slashing-Vorschlag, den Helius’ eigener 0xIchigo im vergangenen Jahr einbrachte, sah Strafen für Validatoren innerhalb der Supermajority vor, die nicht an formellen Governance-Abstimmungen teilnehmen. Ziel war es, stärkeres Engagement zu fördern. Dieser Ansatz erfüllt zwar die Anforderung objektiver Verifizierbarkeit, mehrere Kommentatoren äußerten jedoch Bedenken. Einige wiesen darauf hin, dass rechtliche Einschränkungen bestimmte Validatoren an der Abstimmung hindern könnten. Andere argumentierten, Slashing müsse strikt auf Verhalten beschränkt bleiben, das die Sicherheit oder Integrität des Netzwerks direkt gefährdet.

Durchsetzung von Strafen

Sobald Solana über einen zuverlässigen On-Chain-Mechanismus zum Melden und Verifizieren von Slashing-fähigen Verstößen verfügt, hat die wirtschaftliche Durchsetzung des Slashings Priorität. Dazu müssen die genauen Parameter und Strafformeln für verschiedene Arten von Verstößen definiert werden.

Die Richtlinien werden weiterhin aktiv diskutiert. Die in diesem Abschnitt vorgestellten Inhalte spiegeln aktuelle Vorschläge wider, die informieren, den Dialog fördern und anhand des Feedbacks der Community weiterentwickelt werden sollen. Da diese Entscheidungen die Wirtschaftlichkeit des Betriebs eines Solana-Validators direkt betreffen, werden alle Änderungen öffentlich in der Community diskutiert und müssen durch einen formellen Governance-Prozess genehmigt werden.

Bei der Festlegung von Slashing-Strafen gilt ein zentrales Prinzip: Seltene, einmalige Betreiberfehler dürfen nicht übermäßig hart bestraft werden. Idealerweise sollte das Strafsystem kleinere Vorfälle tolerieren, die den Konsens nicht beeinträchtigen und gegen die angemessene Schutzmaßnahmen bestehen, statt ehrliche Fehler mit schweren Strafen zu ahnden.

Als Schwelle für diesen Puffer wird derzeit die Linie des Nakamoto-Koeffizienten (NC) erwogen. Sie liegt auf der Stake-Höhe des kleinsten Validators in der Superminority, also bei ungefähr 1 % des Stakes. 

Die vorgeschlagene Funktion bestimmt den geslashten Anteil jeder Delegation pro Vote-Account. Liegt der gesamte Stake, der einen Verstoß begeht, unter der NC-Linie, wird kein Stake geslasht. Ist dagegen der Konsens gefährdet, weil mehr als ein Drittel des gesamten Stakes an Verstößen beteiligt ist, sollte das Protokoll entschieden reagieren und 100 % des verantwortlichen Stakes slashen.

Für Fälle zwischen diesen Extremen sieht der aktuelle Vorschlag eine quadratische Straffunktion mit langsamer Wachstumsrate vor. Der zu slashende Stake-Anteil für jeden Vote-Account wird mit folgender Formel berechnet:

v = Slashing-fähiger Vote-Account

TSS = Gesamter Slashing-fähiger Stake

TS = Gesamter Stake

NC-Linie = Linie des Nakamoto-Koeffizienten

Mit dieser Formel lässt sich der prozentuale Anteil des Stakes berechnen, der beim verantwortlichen Validator geslasht wird:

• 1,2 %, wenn 4,66 % des Stakes gegen die Regeln verstoßen (d. h. (3 * (0.0466 - 0.01) / 1)²)
• 7,3 %, wenn 10 % des Stakes gegen die Regeln verstoßen (d. h. (3 * (0.1 - 0.01) / 1)²)

Das folgende Diagramm zeigt die vorgeschlagene Kurve mit zwei Alternativen: aggressiv und linear.

Der gesamte Slashing-fähige Stake (TSS) wird anhand einer Gewichtung nach Art des Verstoßes berechnet. Abstimmungsverstöße erhalten eine Gewichtung von 1, da sie weniger schwerwiegend sind. Verstöße durch doppelte Blöcke werden mit 10 gewichtet, da sie als schwerwiegender gelten.

Ein wichtiger Vorteil quadratischer, korrelierter Slashing-Strafen wie im aktuellen Vorschlag ist der Anreiz für Betreiber mehrerer Validatoren, etwa Börsen oder Staking-as-a-Service-Anbieter, eine hochwertige und unabhängige Infrastruktur zu betreiben. So minimieren sie das Risiko weitreichender, korrelierter Ausfälle.

Alternativen zum traditionellen Slashing

Das Slashing delegierter Stakes wirft wichtige Fragen zu Fairness und Verantwortlichkeit auf. Im aktuellen Staking-Modell ist bei den meisten nicht privaten Validatoren der überwiegende Teil, wenn nicht sogar der gesamte Stake delegiert. Wenn Slashing stattfindet, tragen daher typischerweise die Delegatoren die Hauptlast der Strafe und nicht die Validator-Betreiber, die den Verstoß begangen haben. Selbst sorgfältige Staker, die vertrauenswürdige Validatoren auswählen, könnten ohne eigenes Verschulden geslasht werden, wenn ein Validator böswillig handelt oder seinen Node falsch konfiguriert.

Um dieses Ungleichgewicht zu beheben, wurden mehrere alternative Slashing-Designs vorgeschlagen. Ein Ansatz verlangt von allen Validatoren einen Mindestanteil an eigenem Stake. Dadurch tragen Betreiber ein eigenes Risiko und können die gesamten Slashing-Kosten nicht auf ihre Delegatoren abwälzen. Eine strengere Variante würde nur den eigenen Stake slashen und gleichzeitig alle mit einem geslashten Validator verbundenen Delegatoren automatisch destaken. Die Delegatoren würden zwar Rewards verlieren, aber ihr Kapital behalten. So könnten sie ihren Stake mit minimalen langfristigen Auswirkungen einem anderen Validator zuweisen.

Ein weiterer Ansatz besteht darin, Accounts für einen definierten Zeitraum einzufrieren. Währenddessen können sie keine Rewards verdienen, den Besitzer wechseln oder Guthaben abheben. Die Dauer der Sperre würde mit der Schwere des Verstoßes steigen. Alternativ könnte das Protokoll künftige Rewards slashen. Dadurch würden die Einnahmen des Validators und seiner Delegatoren für einen festgelegten Zeitraum sinken, ohne den ursprünglichen Stake anzutasten.

Einige haben vorgeschlagen, geslashten Stake nicht zu verbrennen, sondern als positive Verstärkung an ehrliche Validatoren umzuverteilen. Das Verbrennen von SOL erzielt jedoch effektiv ein ähnliches Ergebnis: Es reduziert das Gesamtangebot und erhöht dadurch den relativen Anteil jedes Holders am Netzwerk.

Überlegungen

Die Einführung von Slashing auf Solana hat mehrere wichtige Auswirkungen. In diesem Abschnitt untersuchen wir zwei zentrale Bereiche: Cooldown-Perioden sowie die daraus entstehenden Risiken, Versicherungsfragen und betrieblichen Belastungen für Teilnehmer des Ökosystems.

Cooldown-Perioden

Eine zentrale Schwachstelle des aktuellen Staking-Modells entsteht, wenn ein Validator einen Slashing-fähigen Verstoß begeht, seinen Stake aber deaktiviert, bevor der Verstoß beobachtet und gemeldet wird. Ohne einen Mechanismus, der die Auszahlung verzögert, könnten böswillige Akteure diese zeitliche Lücke ausnutzen, um einer Bestrafung zu entgehen.

Eine Cooldown-Periode, in der Stake auch nach der Deaktivierung weiterhin geslasht werden kann, würde dieses Problem entschärfen. Dieser Cooldown muss länger sein als die maximal erforderliche Zeit, in der Validatoren oder externe Beobachter einen Verstoß erkennen und eine Slashing-Reaktion koordinieren können. Das gilt besonders unter widrigen Bedingungen wie DDoS-Angriffen auf Netzwerkebene oder Absprachen zwischen böswilligen Validatoren. In der Praxis sollten Cooldown-Perioden daher mehrere Tage dauern.

Solanas Abhängigkeit von vorab berechneten Stake-Snapshots verschärft dieses Problem. Mehrere kritische Protokollkomponenten, darunter der Leader-Zeitplan und die Fork-Choice-Regel, verwenden im Voraus berechnete Stake-Werte. Dadurch kann deaktivierter oder sogar vollständig abgehobener Stake den Konsens weiterhin beeinflussen.

Der Leader-Zeitplan wird beispielsweise aus einem früheren Stake-Snapshot abgeleitet, der eine Epoche im Voraus an der Epochengrenze erstellt wurde. Dadurch entsteht ein Zeitfenster, in dem ein Validator einen Slashing-fähigen Verstoß begehen könnte, obwohl er seinen Stake bereits in der vorherigen Epoche deaktiviert und zu Beginn der aktuellen Epoche abgehoben hat. Wenn der Verstoß entdeckt wird, ist kein aktiver Stake mehr vorhanden, der bestraft werden könnte.

Eine Lösung wäre eine zusätzliche Cooldown-Periode, in der der Stake weiterhin geslasht werden kann, aber nicht mehr zum Stake-Gewicht des Protokolls zählt. Staker, die ihren Stake in Epoche N deaktivieren, könnten ihn erst zu Beginn von Epoche N+3 abheben. Das würde die Sicherheit verbessern, aber die User Experience verschlechtern, da Staker weitere ~2–4 Tage warten müssten, bevor sie ihren Stake vollständig abheben können. Eine mögliche Lösung wären kürzere Epochen, damit die realen Unstaking-Verzögerungen dem aktuellen Standard ähneln. Jede Verkürzung der Epochendauer könnte jedoch unvorhergesehene Auswirkungen auf das Protokoll haben und müsste sorgfältig geprüft werden.

Risiken, Versicherungen und betriebliche Belastung

Die Einführung von Slashing auf Solana betrifft viele Teilnehmer des Ökosystems, insbesondere jene, die gestakte SOL verwahren, verwalten oder darauf Finanzprodukte aufbauen. Schon die Möglichkeit eines Slashings kann finanzielle Risiken, betriebliche Komplexität und Reputationsprobleme verursachen. Dies gilt besonders für Institutionen mit treuhänderischen oder regulatorischen Verpflichtungen. Schutzmaßnahmen wie Versicherungen oder Bürgschaften können diese Risiken abdecken.

Zu den potenziell betroffenen Stakeholdern gehören:

• Liquid-Staking-Protokolle
• Stake-Pools
• Verwahrende Staking-Anbieter
• Restaking-Protokolle
• DeFi-Protokolle
• Staking-ETFs

Für einige dieser Akteure könnte ein Slashing-Ereignis Kaskadeneffekte auslösen. Liquid-Staking-Token (LSTs) basieren beispielsweise auf der Annahme, dass die zugrunde liegenden Validatoren sicher arbeiten. Wird ein Validator geslasht, könnte dies eine starke Neubewertung seines LST auslösen. In Extremfällen könnte die Bindung verloren gehen, wenn das Vertrauen in den Validator zusammenbricht, bei dem die zugrunde liegenden SOL gestakt sind. Wird der LST als Sicherheit in einem Kreditprotokoll verwendet, könnte dies Liquidationen auslösen.

In anderen Ökosystemen bieten Staking-Anbieter häufig Slashing-Versicherungen an, um diese Risiken zu mindern. Auf Ethereum stellen beispielsweise viele Anbieter günstigen Schutz gegen Slashing-Verluste bereit. Der Umfang hängt vom jeweiligen Tarif ab.

Das Slashing-Risiko schafft außerdem neue betriebliche Pflichten entlang der gesamten Staking-Wertschöpfungskette. Betroffen sind unter anderem:

• Betreiber von Staking-Diensten, die das Verhalten von Validatoren überwachen und Risiken proaktiv mindern müssen
• Verwahrplattformen und Kryptobörsen, die von Drittbetreibern abhängig sind und ihre Validator-Sets möglicherweise prüfen und diversifizieren müssen
• Institutionelle Vermögensverwalter, die möglicherweise eine Eigenschadenversicherung gegen Slashing-Verluste durch externe Betreiber benötigen

Vergleich mit ähnlichen Netzwerken

Dieser Abschnitt untersucht, wie Slashing in vergleichbaren Proof-of-Stake-Netzwerken wie Ethereum und Cosmos implementiert ist. Diese Netzwerke setzen programmgesteuertes Slashing seit vielen Jahren durch und bieten wertvolle reale Daten zur Häufigkeit von Slashing-Ereignissen und deren Auswirkungen auf die Netzwerksicherheit und das Verhalten von Validatoren.

Ethereum

Das mit dem Start der Beacon Chain im Dezember 2020 eingeführte Proof-of-Stake-Protokoll von Ethereum nutzt Slashing seit dem ersten Tag als zentralen Durchsetzungsmechanismus. Ethereum definiert vier konkrete Slashing-fähige Verstöße, die alle mit Equivocation zusammenhängen:

• Vorschlagen mehrerer Blöcke für denselben Slot
• Übermitteln widersprüchlicher Attestierungen für denselben Ziel-Checkpoint
• Attestieren verschiedener Head-Blöcke mit denselben Quell- und Ziel-Checkpoints
• Erstellen zweier Attestierungen, bei denen eine die andere hinsichtlich der Quell- und Zielstimmen „umschließt“

Für jeden dieser Verstöße gilt dieselbe Strafstruktur. Wird ein Validator geslasht, erhält er sofort eine Strafe in Höhe von 1/32 seines effektiven Guthabens. Aufgrund des maximalen effektiven Guthabens von 32 ETH ist sie auf 1 ETH begrenzt. Anschließend wird der Validator zwangsweise aus dem aktiven Set entfernt und für ungefähr 36 Tage in die Exit-Warteschlange gestellt.

Während dieses Zeitraums ist der Validator inaktiv und kann kein Guthaben abheben. Ihm entgehen weiterhin Rewards, die er im aktiven Zustand verdient hätte. Dadurch entstehen kontinuierliche Opportunitätskosten. Nach 18 Tagen wird eine zusätzliche Korrelationsstrafe verhängt. Sie steigt proportional zur Anzahl der Validatoren, die innerhalb eines Zeitfensters von 36 Tagen geslasht wurden. Werden nur wenige Validatoren geslasht, fällt die Strafe gering aus. Bei Massen-Slashing-Ereignissen, sei es durch koordiniertes Fehlverhalten oder gemeinsame Infrastrukturfehler, steigen die Strafen jedoch drastisch. Im schlimmsten Fall könnte ein Validator fast sein gesamtes gestaktes Guthaben verlieren.

Obwohl Slashing ein zentraler Bestandteil des Ethereum-Protokolls ist, kommt es in der Praxis äußerst selten vor. Bis Mai 2025 wurden bei 131 Vorfällen nur 484 Validatoren geslasht, weniger als 0,05 % des gesamten Validator-Sets. Diese Vorfälle gingen häufig auf einen einzelnen Fehler zurück, der mehrere Validatoren betraf. Meist waren Betreiberfehler oder Softwarefehler die Ursache, nicht böswillige Absichten.

Das größte Slashing-Ereignis fand im November 2023 statt, als Bitcoin Suisse wegen inaktivitätsbezogener Verstöße 100 geslashte Validatoren verzeichnete, die jeweils 1 ETH verloren.

Bis heute hat kein Slashing-Vorfall auf Ethereum die allgemeine Integrität des Protokolls gefährdet. Das deutet darauf hin, dass Slashing zwar eine wichtige Abschreckung darstellt, tatsächlich aber nur selten durchgesetzt wird. Das Validator-Ökosystem hat die Verhaltensweisen zur Vermeidung dieser Strafen weitgehend verinnerlicht.

Cosmos

Cosmos und auf dem Cosmos SDK basierende Chains wie der Cosmos Hub implementieren Slashing als integrierten Sicherheitsmechanismus gegen zwei zentrale Fehler: doppelte Signaturen und längere Ausfallzeiten. Diese Slashing-Regeln dienen dazu, sowohl die Sicherheit als auch die Verfügbarkeit des Protokolls durchzusetzen.

Ein Validator, der zwei verschiedene Blöcke auf derselben Höhe signiert, wird sofort bestraft. Jeder Teilnehmer kann einen On-Chain-Beweis für den Verstoß einreichen. Nach der Verifizierung werden automatisch 5 % der gestakten Token des Validators geslasht und er wird in einen Tombstoned-Status versetzt. Damit wird er dauerhaft aus dem aktiven Validator-Set entfernt und kann nicht zurückkehren. Nach dem Tombstoning müssen sowohl der Validator als auch seine Delegatoren die Unbonding-Periode abwarten, bevor ihr Stake erneut delegiert werden kann. Ein Betreiber eines Validator-Nodes mit Tombstoned-Status kann zwar mit einem neuen Schlüssel neu starten, muss seine Reputation und Delegationen aber von Grund auf neu aufbauen.

Cosmos setzt die Verfügbarkeit außerdem durch automatisches Slashing bei längeren Ausfallzeiten durch. Signiert ein Validator weniger als 5 % der letzten 10.000 Blöcke, gilt er als inaktiv und wird mit einem Slashing von 0,01 % seines Stakes bestraft. Diese Strafe ist im Vergleich gering, wird aber strikt und ohne Ausnahmen durchgesetzt. So müssen Validatoren eine hohe Verfügbarkeit und zuverlässige Teilnahme am Konsens gewährleisten.

Interessanterweise akzeptieren einige Validatoren diese geringe Strafe bewusst als Kosten einer freiwilligen Betriebseinstellung, da sie den Verlust als vernachlässigbar betrachten.

Cosmos-SDK-Netzwerke verwenden gemeinsame Standardparameter für Slashing, doch einzelne Chains können diese Regeln ändern oder erweitern, um ihre eigenen Sicherheitsannahmen und Risikomodelle abzubilden. Diese Flexibilität erlaubt es jedem Netzwerk, sein Slashing-System an die Größe seines Validator-Sets, seine Dezentralisierungsziele oder seine erwartete Fehlertoleranz anzupassen. Die Slashing-Aktivität in 57 auf dem Cosmos SDK basierenden Mainnets bietet einen umfassenderen Überblick über die Durchsetzung im gesamten Ökosystem:

• 12.143 Slashings wegen Ausfallzeiten
• 111 Slashings wegen doppelter Signaturen
• 326 andere Verstöße
• Insgesamt 12.580 Slashing-Vorfälle

Diese Zahlen zeigen, dass doppelte Signaturen zwar selten auftreten und hart bestraft werden, Slashing wegen Ausfallzeiten aber häufiger vorkommt und vor allem als routinemäßige Betriebskosten betrachtet wird. 

Fazit

Slashing bleibt eines der meistdiskutierten und emotional aufgeladensten Themen der Blockchain-Branche. Sobald neue Formen des Fehlverhaltens von Validatoren oder fehlgeleitete Anreize auftreten, folgen schnell Forderungen nach Slashing. Der Grund ist leicht nachvollziehbar: Auf den ersten Blick scheint Slashing eine starke Abschreckung zu sein. Es bietet einen direkten On-Chain-Mechanismus, um böswillige Akteure zu bestrafen und die Integrität des Netzwerks zu schützen.

Wie dieser Artikel jedoch gezeigt hat, ist programmgesteuertes Slashing alles andere als ein Allheilmittel gegen Fehlverhalten. Seine Wirksamkeit hängt davon ab, dass Verstöße sowohl eindeutig als auch beweisbar sind. Diese Bedingungen lassen sich in komplexen realen Situationen nicht immer leicht erfüllen. Slashing bei unklarer oder interpretationsfähiger Beweislage birgt das Risiko, ehrliche Akteure zu bestrafen, Vertrauen zu destabilisieren und möglicherweise mehr Schaden anzurichten als die Verstöße, die es verhindern soll.

Der wohl größte Nutzen automatisierter Slashing-Formen für ein Netzwerk ist ihre psychologische Wirkung auf Stakeholder. Schon die Möglichkeit eines wirtschaftlichen Verlusts bei einem Verstoß kann risikoscheue Staker dazu bewegen, ihre Delegationen auf mehrere Validatoren zu verteilen, selbst wenn solche Verstöße selten sind. Gleichzeitig motiviert sie Betreiber, in vielfältige und unabhängige Infrastruktur zu investieren.

Weitere Ressourcen

• Slashing: Allheilmittel oder Büchse der Pandora? - Tim Roughgarden, Accelerate Conference
• Die wirtschaftlichen Grenzen erlaubnisloser Konsensmechanismen - Eric Budish, Andrew Lewis-Pye, Tim Roughgarden 
• Nachweisbare Verfügbarkeit - Andrew Lewis-Pye, Joachim Neu, Tim Roughgarden, Luca Zanolini